Securing Against OAuth Exploitation: A Step-By-Step Guide

Recent findings from Microsoft Threat Intelligence reveal a concerning trend: threat actors exploiting vulnerabilities in Microsoft 365 and Azure environments to execute attacks, with a focus on OAuth application abuse.

In this blog post, we explore two incidents included in Microsoft’s findings. We explore the actions involved in each and the measures you can take to secure your organization, leveraging Obsidian’s Integration Risk Management (IRM), Posture, and Threat solutions.

Incident #1

A threat actor known as Storm-1283 gained unauthorized access to an OAuth application by compromising a user account. They used this access to deploy virtual machines (VMs) within the organization’s infrastructure, leading to significant financial losses of up to $1.5 million USD.

Let’s unpack the phases of this attack and the measures you can take to address them using the Obsidian platform.

Phase 1: Gain Initial Access

In SaaS environments, compromising a user account is a gateway for carrying out numerous malicious activities. 

Storm-1283 likely employed a range of techniques, such as session hijacking and exploiting compromised credentials with weak authentication, to execute their attack. They likely focused on users with less robust authentication controls, as well as those with heightened permissions or access to pre-existing connected OAuth applications.

You can address these risks by taking the following actions within the Obsidian Platform: 

1. Enhance user account security by ensuring strong Multi-Factor Authentication (MFA).
2. Monitor for account compromise with Obsidian’s set of Initial Access detections. 

Note: Our latest advancements in threat detection address techniques such as MFA fatigue, pass-the-cookie, and the addition of attacker-owned secondary MFA devices.

Phase 2: Achieve Persistence

Attackers often exploit existing OAuth applications to evade detection. By leveraging existing applications, attackers can “live-off-the-land”, evading security measures that commonly trigger alerts when new OAuth applications are introduced to a service. One tactic involves adding attacker credentials to an internal OAuth application, enabling the attacker to operate discretely and avoid detection. This technique was similarly observed in the SolarWinds attack from 2020.

Take the following steps within the platform to address these risks:

1. Evaluate internal applications where the service principal has recently added credentials, specifically risk factors: “Internal application with credentials” and “Recently added credentials.” 
2. Create an action policy that triggers in the event specific risk factors are added to existing applications.
3. Eliminate unused internal applications. Attackers often target existing applications rather than introducing new ones, as this approach reduces the chances of triggering alarms or encountering limitations imposed by existing controls.
4. Enforce restrictions on how users can consent to applications within the Azure environment. If the compromised account did not have an associated highly permissioned OAuth application, the attacker could have added one if certain application-based restrictions were not in place. Monitor and manage user consent for applications through Obsidian’s posture capabilities. 

Phase 3: Leverage the OAuth application to deploy VMs

Leveraging the compromise credentials, the attacker deployed virtual machines in the customer’s Azure environment with the purpose of cryptomining.

Address these risks by assessing internal applications. Use Obsidian’s risk factor “High Exposure Keys” to identify instances where key credentials are used in multiple locations. The application’s new running locations are likely to align with the infrastructure controlled by the attacker and deviate from your organization’s common infrastructure.

Incident #2

A malicious actor infiltrated user accounts, exploiting them to establish OAuth applications for the purpose of maintaining persistence and executing email phishing/spam campaigns. The attackers leveraged OAuth applications to act on behalf of the compromised users, sending spam and fraud emails as well as manipulating the compromised user’s mailbox to avoid detection.

Let’s explore the phases of this attack and the measures you can take to address them using the Obsidian platform.

Phase 1: Gain Initial Access

Attackers can re-use stolen session tokens to bypass multi-factor authentication (MFA), thereby gaining access to the Microsoft environment with equivalent access to that of the targeted user. In this incident, the attacker leveraged adversary-in-the-middle phishing and session hijacking.

Obsidian helps address these threats through our token compromise detection capabilities. Learn more about some of our recent threat analysis related to phishing and session token compromise: 

• Detecting AiTM Phishing Sites with Fuzzy Hashing
• Behind the Breach: Phishing & Token Compromise in SaaS Environments

Phase 2:  Achieve Persistence

Attackers established persistence by crafting internal OAuth applications with high-risk scopes, using generic names like “oAuth” or “app.” This allowed them to exploit compromised user accounts and discreetly perform activities such as sending emails on behalf of authorized users. To counteract this threat, carry out these actions within the Obsidian platform:

1. Conduct regular searches for internal delegated Microsoft applications with suspicious names, like “oAuth” or “app,” to promptly identify potential threats.
2. Evaluate recently created applications with scopes allowing mail-related actions, such as mail.readwrite, to detect and address potential risks.
3. Remove any unused applications to reduce the attack surface and minimize the likelihood of exploitation.

Phase 3:  Defense Evasion

In a business email compromise attack, attackers often send emails aiming to prompt responses, such as requests for invoice payments or payroll changes. These attempts may result in security notification emails being triggered to the compromised user. Concealing or suppressing these emails increases the likelihood of success and duration of the attack.

Obsidian’s threat research team has developed machine learning-based detections to identify compromised user accounts with suspiciously created email inbox rules. Learn more about Obsidian’s approach here.

Final Thoughts

Ensure the security of your Microsoft 365 and Azure environments with a proactive approach. Explore how Obsidian can assist you by downloading The Forrester Wave™: SaaS Security Posture Management, Q4 2023, or schedule a demo today.