Beyond credentials: weaponizing OAuth applications for persistent cloud access 

Key takeaways       

OAuth applications can be used to gain persistent access within compromised environments. 
OAuth applications maintain their authorized access even if user credentials are reset, or multifactor authentication is enforced. 
Such attacks can be fully automated as shown in a PoC and a dedicated tool created by Proofpoint researchers. 
Threat actors are already actively exploiting those vulnerabilities. 

Introduction 

Cloud account takeover (ATO) attacks have become a significant concern in recent years, with cybercriminals and state-sponsored actors increasingly adopting malicious OAuth applications as a means to gain persistent access within compromised environments. These attacks allow malicious actors to hijack user accounts, conduct reconnaissance, exfiltrate data, and launch further malicious activities. 

The security implications are particularly concerning. Once an attacker gains access to a cloud account they can create and authorize internal (second party) applications with custom-defined scopes and permissions. This capability enables persistent access to critical resources such as mailboxes and files, effectively circumventing traditional security measures like password changes. 

To better understand and demonstrate this attack vector, Proofpoint researchers have developed a tool that automates the creation of malicious internal applications within a compromised cloud environment. This blog post provides an in-depth technical analysis of that tool and its implications for enterprise security. Additionally, we will examine a real-world incident detected through our telemetry, offering concrete evidence of how threat actors are actively exploiting such vulnerabilities in the wild. 

OAuth application types: second-party vs. third-party 

In the context of cloud environments, particularly Microsoft Entra ID, it’s crucial to understand the distinction between second-party and third-party applications. 

Second-party applications. These are applications registered directly within an organization’s tenant. Also known as internal applications, they are generally created and managed by the organization’s administrators or users with appropriate privileges. Second-party applications inherit a level of implicit trust within the environment, as they originate from within the organization’s own directory. 

Third-party applications. These applications are registered in external tenants and request access to resources in other organizations’ tenants. Common examples include widely-used services like Zoom or DocuSign. Third-party applications typically undergo additional scrutiny through administrative consent workflows and organizational security policies before being granted access. 

This distinction is particularly relevant from a security perspective, as threat actors often prefer creating second-party applications during post-exploitation phases. These internal applications can be more difficult to detect and may bypass security controls designed primarily for external application monitoring. 

Attack flow 

Initial access vector

Cybercriminals often leverage a combination of techniques to gain initial access to cloud user accounts. One common tactic is the use of reverse proxy toolkits accompanied by individualized phishing lures that enable the theft of credentials and session cookies (more information can be found in our recent blog about FIDO downgrade attack). 

Once the attackers have stolen a user’s login credentials, they can establish unauthorized access to the targeted accounts, setting the stage for the next phases of the attack. 

Establishing persistence through OAuth applications

Following successful initial access, attackers often pivot to creation and deployment of malicious OAuth applications. This process typically involves: 

Leveraging the compromised account’s privileges to register new internal applications. 
Configuring specific permissions and API scopes for maximum impact. 
Authorizing these applications to access critical organizational resources. 

The strategic value of this approach lies in its persistence mechanism: even if the compromised user’s credentials are reset or multifactor authentication is enforced, the malicious OAuth applications maintain their authorized access. This creates a resilient backdoor that can remain undetected within the environment indefinitely, unless specifically identified and remediated. 

Technical implementation: automating OAuth-based persistence 

Proofpoint researchers have developed an automated toolkit which demonstrates methods by which threat actors establish persistent access through malicious OAuth applications. The PoC implements several key capabilities that mirror real-world attack scenarios. 

Core functionality 

Automated OAuth application registration and configuration 
Customizable permission scope selection
Persistent access mechanism independent of user credentials
Configurable application naming conventions

Operational workflow

Starting from an initially compromised account, the tool streamlines the post-exploitation process through automated application creation. While this demonstration uses randomized application names, real-world threat actors typically employ deceptive naming strategies that mimic legitimate business applications to avoid detection. 

Figure 1: Future Account Super-Secret Access tool, Version 1:  Welcome screen. 

During the automated deployment process, an application is registered with pre-configured permission scopes that align with the attacker’s objectives. A critical aspect of this implementation is the ownership attribution: the compromised user account becomes the registered owner of the newly created application, effectively establishing it as a legitimate internal resource within the organization’s environment. 

This ownership model provides several tactical advantages: The application appears as an internally developed resource and the authentication requests originate from within the organization’s tenant. The application inherits trust relationships associated with internal resources and standard third-party application security controls may not detect or flag this activity. 

Figure 2: Application creation process. In the example the app name is ‘justSOMEniceAPP’. 

Figure 3: Application scopes selected: Mail.Read and offline_access. 

Upon successful application registration, the tool automatically establishes two critical authentication components. 

Application secret generation 

The tool first creates a cryptographic client secret for the application. This serves as the application’s own authentication credential, required for confidential client authentication flows. This is essential for server-side applications requesting tokens. 

Token harvest  

The automation then proceeds to collect multiple OAuth token types, each serving distinct purposes in maintaining persistent access: an access token, a refresh token, and an ID token. 

Figure 4: Tokens collected. 

To validate the effectiveness of this persistence mechanism, this tool includes a practical demonstration of access retention.  

Credential reset test – User’s password is changed to simulate standard incident response. This action would typically terminate unauthorized access obtained through stolen credentials. 

Figure 5: Demonstration of user password change. 

Access verification – Despite the password change, the malicious application maintains full access. Some OAuth tokens and application secret continue to function, and all previously authorized permissions remain active. 

Figure 6: New tokens generated after the password change. 

Following the password reset, this tool demonstrates the sustained effectiveness of the malicious application’s access through several key activities. 

Email access demonstration – Successfully retrieves user mailbox contents and maintains continuous access to incoming and historical emails. The app now operates independently of user credential changes. 

The scope of unauthorized access extends well beyond email, encompassing any resources specified in the application’s configured permissions, which may include, for example:  

SharePoint documents and collaborative content
OneDrive stored files
Teams messages and channel data
Calendar information
Organizational contacts
Other Microsoft 365 resources

Figure 7: User emails accessed even after password change. 

The malicious application’s footprint can be observed within the Microsoft Entra ID administrative interface, specifically: 

Location and Navigation Path: Entra ID Portal → App Registrations  

Application appears as a standard internal registration 

Application configuration details under the application’s management interface, several key components are visible: 

Application configuration:  

Basic application metadata
Authentication settings
API permissions and granted scopes

Client secrets – Located under ‘Certificates & Secrets’ section: 

Displays the active secret credentials. This is a critical component enabling persistent programmatic access.
Expiration dates and secret status

This visibility in standard administrative interfaces underscores the importance of regular application auditing and monitoring, as malicious applications may blend in with legitimate business applications unless specifically scrutinized. 

Figure 8: Location of application secrets in Microsoft Azure.

The malicious application’s ability to maintain unauthorized access is directly tied to the absence of two critical factors. 

Access termination conditions  

Manual deletion of the application registration and explicit revocation of granted permissions. 
Expiration of the client secret credentials. 

In this demonstration, the application’s client secret is configured with a two-year validity period, providing the attacker with:  

Extended persistent access without requiring credential renewal
Long-term capability to access protected resources
Significant window of opportunity for data exfiltration
Prolonged dwell time within the environment

This extended persistence window presents substantial risks, potential for long-term undetected access, continued data exposure even after initial compromise discovery, challenges in identifying historical unauthorized access, and the need for proactive application lifecycle management. 

Without active discovery and remediation efforts, the application remains a viable attack vector until either administrative action is taken, or the client secret naturally expires. 

Real-world attack analysis 

Our telemetry revealed a real-world account takeover (ATO) incident that persisted for four days. The initial compromise was detected through a successful login attempt using the user agent ‘Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.0.0 Iron Safari/537.36’. Based on our threat intelligence, this user agent signature is most likely associated with Adversary-in-the-Middle (AiTM) phishing attacks, specifically the Tycoon phishing kit. 

The threat actor, operating through US-based VPN proxies, executed several malicious actions: 

Created malicious mailbox rules
Registered an internal application named ‘test’
Added application secrets with Mail.Read and offline_access permissions, enabling persistent access to the victim’s mailbox even after password changes

After approximately 4 days the user’s password was changed, following which we observed failed login attempts from a Nigerian residential IP address, suggesting the threat actor’s possible origin. However, the application remained active. This case study serves as a concrete example of the attack patterns discussed in our blog, demonstrating that these threats are not merely theoretical – but active, exploited risks in the current threat landscape. 

Remediation and recommendations

Upon discovery of a suspected malicious application in the environment, immediate remediation steps are critical. 

Priority actions 

Client secret revocation – Immediately invalidate all client secrets. Remove all existing certificates. This immediately terminates the application’s ability to request new tokens. 

User token revocation – Immediately revoke all existing user tokens. 
Application removal – Delete the entire application registration and revoke all previously granted permissions. Remove all associated service principals. 
Implement continuous monitoring – By continuously monitoring your line-of-business apps and applying automatic remediation, you may prevent attackers from establishing persistent access to valuable resources. This can also help to stop them from launching more attacks.  
Empower your users – Your users are a vital part of your defense. Conduct regular trainings to educate them on how to:  
Recognize malicious apps and tenants that seem credible. 
Treat unexpected consent requests as suspicious. 
Promptly report unusual application authorizations.  Proofpoint Threat InsightRead More