Overview
The Praetorian Labs team recently conducted research into potential initial access vectors for red team engagements, focusing on attack techniques leveraging malicious applications distributed through platforms like the Microsoft Store. This included OAuth applications, malicious Outlook extensions, and other types of applications that could be delivered via the Windows Store. As part of this effort, we performed a feasibility study on using malicious OAuth applications for initial access within customer environments.
During our research, we identified multiple attack chains where malicious OAuth applications could be used to escalate privileges or move laterally within a target environment. Recognizing a gap in existing tooling for executing these attacks in red team engagements, we developed OAuthSeeker along with companion utilities such as OAuthPillage and OAuthAzure to facilitate these techniques. To contribute to the broader security community, we are open-sourcing these tools, enabling others to better understand and mitigate these threats. The tool has rather extensive and detailed documentation so the purpose of this article isn’t to replace the official tool documentation, but to discuss our research process and methodology. We are excited to announce that we are releasing OAuthSeeker as part of the Black Hat USA 2025 Arsenal and DEF CON 33 Demo Labs.
Initial Research
During our initial research into malicious OAuth applications targeting Microsoft Office 365 and Microsoft Azure we identified an article from TrustedSec titled Creating a Malicious Azure AD OAuth2 Application which was incredibly useful in understanding various attack scenarios related to malicious OAuth applications.
At a high-level there are kind of three different types of OAuth applications:
- External Unverified Applications: These are applications anyone can create in their attacker-controlled tenant and are external to the victim user’s tenant. They don’t require any additional verification to be installed, but there are significant restrictions on what permissions they can request.
- External Verified Applications: These are the same as external verified applications, but they are linked with a Microsoft Partner Network identifier. This allows the attacker to request broader permissions under default configurations, such as the ability to read emails, Microsoft Teams, OneDrive, etc.
- Internal Unverified Applications: These are effectively the same as external verified applications, but they can only be installed by users within the same tenant. These applications are also able to request broader permissions as long as they don’t require admin consent. Under the default configurations, any user within Microsoft Office365 can create new Azure App Registrations. This makes it an incredibly valuable tool for internal phishing attacks.
We discuss these three types of applications in more detail in the following sections.
External Unverified Applications
External unverified applications do not require verification from Microsoft, making them easily accessible for attackers. These applications are limited in the permissions they can request, primarily restricted to User.ReadBasic.All, which allows access to basic user profile details. Attackers often use these applications in phishing campaigns to trick users into granting access, providing an entry point for further reconnaissance and subsequent attacks. This collected information can then be leveraged for follow-on attacks using either verified applications or other phishing methods such as device code phishing, phone phishing, etc., depending on the goal of the engagement.
External Verified Applications
External verified applications require approval through a Microsoft Partner Network (MPN) identifier. If an organization permits the installation of verified external applications without admin consent (a default setting in many cases), attackers can leverage this to gain elevated access. By tricking users into installing a verified application, attackers can request extensive permissions, such as Mail.ReadWrite and Files.ReadWrite.All, enabling data exfiltration and persistent access.
Additionally, the verification status increases user trust, making these applications an effective attack vector. Setting up and obtaining a Microsoft Partner Network identifier with a cover identity is out of the scope of this blog post, but it’s important to note that this is possible if you submit the appropriate paperwork and proper forms. It’s actually quite straightforward, albeit the documentation from Microsoft isn’t very good.
Internal Unverified Applications
Once an attacker gains access to a tenant—through methods such as device code phishing—they can create internal unverified applications. Many organizations allow standard users to register OAuth applications internally, which enables attackers to escalate privileges and move laterally within the environment. By phishing internal users into consenting to these applications, attackers can gain access to sensitive data, such as emails and files, and establish long-term persistence within the compromised tenant.
Based on our research, we developed the following attack-path map showing potential attack paths that could be leveraged during a red-team engagement alongside this capability. There are some interesting attack scenarios an attacker could leverage, such as phishing a victim user with device code phishing, but then very quickly registering a new internal application and leveraging it for follow-on attacks and persistence.
Potential Attack Paths
Based on our research we developed the following attack-path map showing certain potential attack paths that could be leveraged during a red-team engagement alongside this capability (see Figure 1). There are some interesting attack-scenarios an attacker could leverage such as phishing a victim user using Evilginx, but then very quickly registering a new internal application and leveraging it for follow-on attacks and persistence purposes.
One of the more interesting attack paths we identified is that it is possible for external verified or internal unverified applications to request user_impersonation privileges within Microsoft Azure which then allows the attacker to impersonate the user to cloud computing resources within Microsoft Azure such as accessing compute infrastructure such as virtual machines. There are some interesting attack scenarios where this capability could be chained with other techniques such as leveraging device code phishing for initial access and then persisting via a malicious Azure app registration.
Unfortunately, during our research we didn’t find a method which could be used to register new Azure applications from a malicious verified external OAuth application. Our research indicates that requesting this permission even within a verified application requires admin consent to be granted to the application. We attempted to bypass this constraint by requesting user_impersonation privilege within Microsoft Azure, however, we were ultimately unable to identify a method to leverage Azure impersonation privileges to register new applications and configure them with the appropriate scopes.
Setup and Configuration
For detailed setup and usage instructions, please refer to the official Setup Guide. This blog post does not cover setup and configuration, as it is already documented in the guide linked above. This guide explains how to configure and setup an OAuthSeeker server as well as how to leverage various utilities such as OAuthAzure and OAuthPillage for post-exploitation purposes.
Detection and Prevention Considerations
To mitigate the risks associated with malicious OAuth applications, organizations should implement a layered security approach. Start by restricting OAuth application permissions by blocking external unverified and verified applications in Azure AD unless explicitly approved by administrators, and requiring admin consent for all permissions. Deploy Microsoft Defender for Cloud Apps to monitor OAuth activity, detect suspicious behavior, and control risky user actions, ensuring proper licensing and activation of the service. Enhance monitoring and detection by auditing Azure AD logs for anomalous app registrations and consent activities, and leverage tools like Microsoft Sentinel to track unusual OAuth token usage.
Apply privileged access controls by limiting app registration rights to specific roles or groups and regularly reviewing and revoking unused or high-risk app consents. Additionally, improve user awareness through training programs focused on identifying OAuth phishing attempts and suspicious consent prompts, complemented by phishing simulations to strengthen detection and reporting. Finally, establish robust response measures, such as revoking tokens for malicious applications, resetting compromised user credentials, and removing unauthorized app consents, to quickly neutralize threats and safeguard the environment. This comprehensive strategy enhances security posture and reduces exposure to OAuth-based attacks.
Demo Video
To accompany this release, we have prepared a demo video showcasing OAuthSeeker in action. The demo highlights key functionality and example use cases to help you quickly understand the tool’s capabilities. For full technical details, installation instructions, and comprehensive usage documentation, please refer to the README and supporting documentation available in the OAuthSeeker repository.
The following demo video shows an example scenario where we phish a user with a verified Azure application and then leverage the embedded GraphRunner utility from Black Hills Information security to perform post-exploitation. For usability purposes, we embed the GraphRunner utility into OAuthSeeker so that operators don’t need to context switch between multiple tools.
Conclusion
In this article, we discussed the core attack-paths where a red team operator can leverage OAuthSeeker during a red team engagement. OAuthSeeker makes it easy for red team operators to spin-up a malicious OAuth application to leverage during phishing attacks during a red team engagement. Operators can leverage OAuthSeeker for both gaining initial access into an environment, for lateral movement after obtaining initial access, and for persistence purposes after compromising an account leveraging other methods.
