How an OAuth Attack Unfolds: Breaking Down a Simulated Microsoft 365 Compromise

Most attackers have stopped using malware. They send a convincing email, wait for one click, and walk right into the network. Attackers don’t break in, they log in, and an OAuth consent attack looks like a legitimate workflow that deceives users.

In our webinar, OAuth Live Attack: Why a Password Reset Won’t Stop It, we ran a simulated attack against a fictional finance user and showed every step of the attack from the user’s perspective and the bad actor’s perspective.

This recap walks through what happened, why it works, and how Blackpoint ITDR and our 24/7 SOC contain it within seconds.

What Is an OAuth Attack?

An OAuth attack, also called OAuth phishing or an illicit consent grant, tricks a user into granting permission. The attack redirects the user to a genuine Microsoft or other cloud provider consent screen.

If the user approves the request, they unknowingly grant the malicious application access to resources such as email, files, and other organizational data. Because the attacker abuses legitimate OAuth authorization protocols, they can maintain access through the granted token without needing the user’s password and can often bypass traditional credential theft and multi-factor authentication defenses.

How Does an OAuth Attack Work?

1. The user receives an email that looks like a normal SharePoint or OneDrive share from a coworker.
2. The link sends the user to a real Microsoft sign-in page, where they enter their password and approve their usual MFA prompt.
3. The email domain then shows an app consent page asking for permissions.
4. The user clicks Accept, and the attacker’s application is now registered in the tenant.
5. The bad actor uses that approved app to access emails, set forwarding rules, and more.

Why Attackers Target Identities

Malware has become easier to detect, while identity abuse can easily go undetected. Email accounts hold more than just emails. Access to files, invoices, and payment conversations makes them a lucrative target, and an approved app reaches all of it without touching a device.

Recent ConnectWise and Cloud Backup, formerly SkyKick, compromises used the same pattern but at a much larger scale. Both abused trust in an enterprise application that MSPs and their clients had approved and then left running in the background.

The simulation reaches the same permissions by a different door: it earns consent from a user, where the supply-chain incident used compromised vendor credentials.

What This Means for SMBs

One finance user clicking Accept can lead to business email compromise, exposed files, internal reconnaissance, and an attacker who stays connected. For an MSP, that is a client’s payment data and your reputation on the line from a single afternoon email.

A Simulated Microsoft 365 Attack Step by Step

Stage 1: Initial Access

How the Attack Started

Everything in the simulation is fictional, from the user to the attacker’s Kali Linux box. Our target is “Karen,” a finance employee who just got back from lunch.

She sees an email notification from her coworker Steve with a SharePoint link to an Excel file. It carries Microsoft-style branding and a little urgency, and it arrives through a real Microsoft sharing workflow. The file is shared through an app called CloudDocs Sync.

Karen has no reason to know what powers Microsoft 365 behind the scenes, and nothing about this email looks different from the dozen she opens every week.

Karen clicks and lands on a genuine Microsoft 365 sign-in page. Attackers do this by abusing Azure Dev Tunnels, a developer feature for testing authentication, that sit in the middle of a sign-in.

Karen enters her email address and her usual password, then approves a real Microsoft Authenticator push by entering the number shown on screen. Her credentials and her MFA are both completely legitimate, and both do their job.

Then comes the page the attacker built the whole scheme around: an app consent screen listing permissions. Karen wants her document, so she clicks Accept.

Karen goes back to her spreadsheet and keeps working. Nothing on her screen shows that she just gave CloudDocs Sync read and write access to her email, OneDrive, and SharePoint data.

Stage 2: Establishing Persistence

Staying Connected After Initial Access

The consent click creates the attacker’s foothold. CloudDocs Sync is now an enterprise application in the tenant with permission to act on Karen’s behalf. The attacker’s automation was waiting for exactly this moment and picks up access through the approved app.

It also keeps a refresh-token session, which allows it to return later without Karen doing anything.

This is why traditional tools struggle to see it. Every sign-in event looks routine because Karen did sign in, and every follow-up action runs through an application she approved. The activity looks like a user and a trusted app doing their jobs.

It is also why a password reset leaves the attacker in place. The application’s grant, its sessions, and its tokens live separately from Karen’s password. Ending access means revoking all three.

Stage 3: Discovery and Reconnaissance

Learning About the Environment

Within seconds of the click, the attacker’s automated job gets to work through the approved app. It indexes Karen’s mailbox, sets up forwarding rules, and downloads files with sensitive information.

Attackers learn who she talks to, which vendors she pays, and where the invoices live.

The tooling here is a Kali Linux box running publicly available tools. No advanced AI sits behind it. This is plain automation at scale, which is why the whole sequence can take less than a minute.

Stage 4: Expanding the Attack

Lateral Movement Opportunities

Once the data is in hand, the attacker builds in cover and picks the next target:

• An inbox rule hides invoice and payment messages, so replies about a fraudulent payment request never reach Karen.
• The refresh-token session stays active, so access continues even after Karen closes her laptop.
• Karen’s trusted email address becomes the launch point for the next victim, a coworker who will open a message from her without a second thought.

The Business Impact if Nobody Responds

If nobody responds, the business impact grows quickly. Payment fraud, exposed client files, a spreading compromise across coworkers, and a costly breach all trace back to clicking one Accept button.

Why a Password Reset Leaves the Door Open

The attacker’s access belongs to the application. A new password changes Karen’s credentials but leaves the app’s grant, active sessions, and tokens untouched.

Real cleanup means disabling the malicious enterprise application, revoking sessions and tokens, and resetting any credentials or keys involved.

How Blackpoint Detected the Attack

Blackpoint’s SOC investigates what attackers did once they use an identity or a token to gain access. Behavior gives the attack away, so detection does not require a malware signature.

For every suspicious login, the SOC monitors the login source, proxy, VPN involvement, brute-force indicators, geolocation, the user’s history, device management status, operating system characteristics, exposed services on the source address, and whether the activity is interactive or non-interactive.

In the simulation, the detection summary flagged a login through a VPN, brute-force indicators, an unusual device profile, and the real location behind the login.

It can be anything from a first-time country with no travel request, an unmanaged device, or a non-interactive login that signals an identity or token is compromised. Together they separate an attacker from an admin doing legitimate work, such as a migration.

With Blackpoint’s CompassOne platform, the SOC also ingests authentication error signals, including KMSI interrupts, which can expose adversary-in-the-middle activity before authentication succeeds.

Attackers often store a captured token and use it much later, so the detections keep watching identity and token behavior after sign-in.

How Blackpoint Contained the Threat

Response Actions Taken

When the SOC confirms suspicious activity, the response can:

• Isolate or disable the compromised account.
• Revoke sessions and tokens.
• Rotate credentials or keys.
• Disable malicious enterprise applications, which stops them from making further Microsoft Graph queries or retrieving more data.

Why Speed Matters

Timing matters. Microsoft event delivery adds roughly 0 to 5 minutes, and Blackpoint then receives and processes the event in about 10 seconds.

In the demonstration, containment and a detection summary landed within seconds of the compromise. In this scenario, the SOC would kill the process and then notify the MSP of the incident, along with a full summary in Blackpoint’s CompassOne platform.

Think of it as a smoke detector. You hear it when the fire starts, instead of getting a report afterward on how the house burned down.

That speed gives you a better client conversation. You can tell the client what happened, which action was taken, and finish remediation by restoring the user’s access. This makes you look like the hero you are and helps build trust as their security advisor.

Forensic Reporting for Root Cause and Compliance

When an incident is identified as critical, CompassOne generates a Forensic Report that documents the accessed emails, downloaded or modified files, inbox rules, attacker commands, event timing, and every containment action, laid out as an exact attacker timeline from the first email to containment.

That record supports root cause analysis, remediation planning, and compliance or breach notifications.

Why speed matters: shorter dwell time, less business disruption, and an attacker who never reaches the next mailbox.

How to Stop an OAuth Attack

The most effective single step is to change the email settings so only admins can approve consent for enterprise applications. Users then submit a request for access, an admin reviews it, and an app reaches company data only after that approval.

Make this change for every client tenant, including the ones that have pushed back on it before.

Then layer detection on top. New vulnerabilities and new consent tricks will keep appearing, and the working assumption is breach.

We recommend asking four questions about every token and app in your environment:

• What permissions does it hold?
• Who can see it?
• Could you detect it if it was compromised?
• How much damage could it do?

Key Lessons for MSPs and SMBs

Identity Is the New Security Perimeter

Attackers log in with credentials and bypass MFA with stolen tokens. Protecting the identity, and every app that holds permissions on it, protects the business.

MFA Works Best Alongside Other Controls

Karen completed MFA exactly as designed, and the compromise happened one step later at the consent screen. Pair MFA with admin-approved consent and identity threat detection so each layer covers the next.

Detection and Response Matter as Much as Prevention

No configuration catches every future technique. A 24/7 SOC that recognizes attacker behavior and contains it within seconds protects your clients on the day a new technique arrives.

Show Clients Their Risk with an ITDR Historical Scan

A client who has never been on Blackpoint can still see what ITDR would have found. The Historical Scan reviews up to 180 days of Microsoft 365 activity and produces a client-ready risk summary.

Run it before onboarding, and you walk into the conversation with evidence from the client’s own tenant. The result is a faster path to a risk discussion, a clear view of the value ITDR adds, and one more reason clients see you as their trusted security advisor.

Get Your Historical Scan →

See It for Yourself

Learn how Blackpoint helps MSPs and their clients detect, investigate, and contain identity-based threats before they turn into breaches.

Watch the session on the webinar event page, then request a free ITDR Historical Scan for a Microsoft 365 tenant to see what’s lurking in your or your client’s environment.