Misusing SaaS app integrations for persistence

Learn how attackers abuse SaaS integrations for hidden persistence and re-entry into enterprise environments.

Aug 28, 2025

Imagine a building with two entrances:

The front door is guarded by security cameras and biometric scanners (endpoint defenses).
The side door is rarely used but can be opened with a special badge (OAuth tokens).

An attacker does not try to sneak past the guard at the front. Instead, they convince an employee to hand them a badge for the side door. Once they have it, they can walk in whenever they like, without triggering alarms.

Follow my journey of 100 Days of Red Team on WhatsApp, Telegram or Discord.

When people think of persistence in a red team operation, the first ideas that come to mind are registry keys, scheduled tasks, or hidden services on endpoints. These techniques are well-known and often monitored. However, in today’s enterprise environment, a large portion of work happens in the cloud, particularly within Software-as-a-Service (SaaS) platforms such as Microsoft 365 and Google Workspace. These platforms bring convenience and scalability, but they also open the door for red teams to create persistent access in ways that are invisible to traditional endpoint defenses.

One particularly powerful technique is the misuse of OAuth applications. OAuth is the framework that allows one application to request permission to access data or resources from another, on behalf of the user. For example, a productivity app might ask permission to “read your emails” or “access your calendar.” Most employees are used to seeing these consent screens and will often click “Accept” without thinking twice.

From a red team perspective, this creates an opportunity. A red team operator can register their own “fake productivity app” in the target’s cloud environment. This app can be disguised to look like something harmless, perhaps a tool named “PDF Converter” or “Calendar Assistant.” During the consent process, the red team operator’s app can request far more permissions than it actually needs. For example:

Read and send emails
Access files on a cloud drive
Read calendar events
Access contacts and directory data

Once a user accepts, the app is granted an OAuth token. This token allows continuous access to the account’s data, even if the user changes their password or signs out of their devices i.e. if the OAuth token is not invalidated after a password change or logout (this is not done by default and depends on the identity provider). In essence, the red team operator has created a backdoor into the cloud environment, and it does not rely on malware, implants, or compromised endpoints.

Why this works so well

This technique is effective because it blends seamlessly into the way modern organizations operate. Security teams are often focused on endpoint malware, phishing payloads, or network traffic anomalies. But in this case:

No malicious binary runs on the system.
No suspicious persistence mechanism appears in autoruns or registry keys.
No C2 traffic stands out in the firewall.

Instead, the persistence lives entirely in the cloud, authorized by the victim’s own consent. The only signs are in the audit logs, which many organizations do not actively monitor for OAuth misuse.

Persistence beyond the cloud

At first glance, this type of persistence seems limited to SaaS applications. But in practice, it can serve as a launchpad for access to the broader enterprise environment. The red team operator may not be running code directly on endpoints, but the persistent OAuth app gives them a guaranteed delivery channel into the organization.

Consider these scenarios:

The red team operator uploads a malicious script into a cloud drive folder. Since these folders sync to user devices, the payload appears directly on endpoints.
With permissions to send emails, the red team operator can deliver weaponized attachments or links that originate from a trusted internal account, drastically increasing success rates.
Even if defenders wipe compromised endpoints or reset passwords, the red team operator’s SaaS app remains authorized. They can simply re-deliver payloads later, regaining shell access.

In this way, SaaS persistence does not produce a traditional backdoor by itself, but it guarantees the red team operator can re-establish access on demand, making it just as powerful.

Why should red teams care about it?

For red teams, this technique highlights the importance of thinking beyond traditional persistence methods. Instead of asking, “How can I stay hidden on this endpoint?” the question becomes, “How can I stay hidden in this organization’s SaaS ecosystem?” By leveraging OAuth applications, a red team can maintain long-term access and regain access whenever needed, often without detection.

TL;DR
- OAuth based fake apps (e.g. fake productivity apps) can gain excessive permissions with little user resistance.
- Persistence extends beyond SaaS, acting as a delivery channel for fresh payloads.
- Access can be regained even after endpoints are cleaned or passwords reset.
- OAuth-based persistence is stealthy because it bypasses endpoint defenses.