Lesson 1.1: OAuth Phishers: Ransomware Case Study

Compliance Framework Mapping

Introduction

Welcome to Lesson 1.1: OAuth Phishers: Ransomware Case Study! Over the next 45 minutes, we will explore how a simple, trusted login process can be weaponised to deliver ransomware, bypassing traditional security advice.

But first, let me tell you about Marcus Webb.

It's 10:15 on a Tuesday in October. Marcus, a senior project manager at a mid-sized engineering firm in Bristol, is reviewing a project timeline. The office hums with the quiet click of keyboards and the faint smell of coffee. A new email notification flashes on his second monitor.

The email appears to be from the company's IT support team, asking him to review a shared document on OneDrive. The link looks correct—it points to login.microsoftonline.com, the legitimate Microsoft login page he uses every day. He clicks it, logs in as prompted, and grants permissions to what he believes is a work app. Nothing seems out of the ordinary.

Thirty-seven minutes later, file icons on the shared network drive begin flickering, changing to unfamiliar extensions. A plain text file appears on every desktop: 'YOUR FILES ARE ENCRYPTED. PAY 5 BITCOIN TO GET THEM BACK.' The company's data, including sensitive client designs and financial projections, is locked. Marcus's routine login had just handed over the keys.

This is the story of Ransomware. By the end of this lesson, you'll understand exactly why Marcus never stood a chance, and more importantly, what could have saved him.

Content Section 1: The New Phishing Playbook

Think of traditional phishing like a forger trying to copy a banknote. They might get the colour or the paper wrong. OAuth phishing is different. It's like the forger convincing the bank teller to hand over real money from the vault directly. The link Marcus clicked was real. The page he logged into was real. That's what makes this so effective.

How OAuth Phishing Works

The attacker doesn't try to steal a password. Instead, they create a malicious application and register it with a legitimate cloud service provider like Microsoft. They then send a phishing email with a link that goes to the real Microsoft login page.

When the victim logs in, they are asked to authorise the attacker's malicious app to access their data, like emails, files, or contacts. The prompt looks like a standard permission request, which many users are conditioned to accept for work tools.

Once the user clicks 'Accept', the attacker's app receives an OAuth token. This token is a digital key that lets the app act on the user's behalf, without needing their password. It can access data, send emails, and in ransomware cases, encrypt files stored in connected services like OneDrive or SharePoint.

Why It's Perfect for Ransomware

This method gives attackers direct, API-driven access to cloud storage. They don't need to deploy malware on an endpoint; they can encrypt files directly through the cloud service's own API, using the victim's authorised token.

This bypasses endpoint detection tools that look for suspicious processes or file encryption behaviour on a local machine. The encryption commands come from what looks like a trusted, cloud-based application.

DORA Article 5-17 DORA's ICT risk management framework requires financial entities to identify and manage risks from information and communication technology, including threats that exploit authorised access and cloud service integrations.

ISO A.5.1 ISO 27001 A.5.1 mandates that management provides direction and support for information security, which includes establishing policies for authorising third-party applications and managing user consent.

Content Section 2: Anatomy of a Cloud-Native Ransomware Attack

Understanding the OAuth token's power reveals why it's so effective. Let me show you exactly how Marcus's authorised session was turned against his organisation.

The Attack Flow

Step 1: The attacker registers a new, malicious application in the Azure Active Directory portal (or another cloud platform). They give it a plausible name like 'Document Viewer' or 'Company Analytics'.

Step 2: A phishing email is sent, containing a link to a legitimate file stored on a service like SharePoint. The link is crafted to trigger an OAuth authentication request.

Step 3: The victim clicks, arrives at the real Microsoft login page, and enters their credentials. They then see a consent screen asking them to allow the 'Document Viewer' app to access their profile, read files, and write files.

Step 4: Upon granting consent, an OAuth access token is issued to the attacker's application. This token is now a valid key to the victim's Microsoft 365 account, with the permissions that were granted.

From Access to Encryption

With the token, the attacker's application can use Microsoft Graph API—the same API used by legitimate Office apps. It can list all OneDrive and SharePoint files, download them, encrypt them locally, and upload the encrypted versions back to the cloud, overwriting the originals.

Because this is done via API calls from what appears to be a registered app, it can happen very quickly and from any internet-connected location, not from the victim's computer.

Why Traditional Defences Are Blind

Notice what all of these methods have in common. They are looking for something illegitimate—a bad link, malicious code, or stolen credentials. This attack operates entirely within the bounds of legitimate authorisation.

Standard security controls are designed for different attack models. Here’s how they are bypassed:

NIST PR.AC-1 NIST CSF PR.AC-1 requires that identities and credentials are managed for authorised users and devices. This attack exploits a failure in managing the authorisation of third-party applications, not the user's identity itself.

NIS2 Article 21 NIS2 Article 21 mandates risk management measures. This includes assessing risks from supply chain and third-party relationships, which encompasses unauthorised or malicious applications integrated via OAuth.

Content Section 3: Seeing the Invisible Attack

Marcus's company had security tools. Their systems knew something was wrong. They just couldn't tell him in time. The signals were there, but they weren't looking in the right place.

Identity Provider Signals

The first place to detect this attack is in the identity provider logs, like Azure AD audit logs. A key indicator is a user granting consent to a new, unfamiliar application.

Look for application consent events where the 'Client App' is not a known, company-approved application. The application name and publisher information in the log can be checked against an allow list.

Another signal is a high volume of file activities (read, write, delete) from a single application identity across multiple users in a short time, which could indicate a ransomware encryption sweep.

Cloud Application Security Signals

Tools like Microsoft Defender for Cloud Apps can monitor for anomalous behaviour. A sudden spike in file download or upload volume from a specific OAuth application, especially one recently authorised, is a major red flag.

Look for 'impossible travel' scenarios where an application (not a user) appears to be making requests from geographically disparate locations in an unrealistic timeframe, suggesting a compromised token is being used from an attacker's infrastructure.

Building a Defence

The most effective control is to disable user consent for OAuth applications entirely, or restrict it to a set of verified publishers. Administrators should manage all application consent through a review and approval process.

Regularly audit and review the OAuth applications that have been granted permissions in your tenant. Remove any that are unused, unrecognised, or no longer needed.

Implement conditional access policies that restrict what applications can do, even after they are granted consent. For example, a policy could block a newly consented app from accessing SharePoint or OneDrive until it is reviewed.

SOC2 CC6.1 SOC 2 CC6.1 requires logical access security over protected information. This includes controls over the authorisation of software and applications, ensuring only approved applications can access sensitive data, which directly addresses the OAuth consent risk.

GDPR Article 32 GDPR Article 32 requires appropriate security of personal data. Failing to control which third-party applications can access personal data via OAuth tokens could be viewed as a lack of appropriate technical measures.

Content Section 4: Turning Knowledge into Evidence

Compliance documentation can feel like paperwork for paperwork's sake. But in this case, it's the blueprint for closing the door Marcus's attacker walked through. It's the policy that says, 'We do not allow users to authorise random cloud apps.'

Evidence Generation

This lesson provides documentation for multiple compliance frameworks:

For DORA Article 5-17 auditors... For DORA auditors, you can now demonstrate that your ICT risk management framework includes specific procedures for assessing and authorising third-party application integrations via OAuth, mitigating a known ransomware vector.

For ISO A.5.1 auditors... For ISO 27001 assessors, you can evidence management policies that define clear rules for OAuth application consent, providing direction to limit information security risks from unauthorised cloud applications.

For NIST PR.AC-1 auditors... For NIST CSF reviewers, you can show that your identity management processes extend beyond user credentials to include the management and review of application identities and their granted permissions.

Audit Trail

Document your completion of this lesson:

• Lesson title and date completed
• Time invested: approximately 45 minutes
• Key learnings in your own words
• Activity submission reference
• Follow-up actions identified

Conclusion

Let me tell you how Marcus's story ended.

The engineering firm did not pay the ransom. They spent over two weeks restoring data from offline backups, during which they could not bid on new projects. The incident cost them an estimated £250,000 in recovery efforts and lost business. Marcus, though not officially blamed, left the company six months later.

The organisation eventually implemented strict controls. They disabled user OAuth consent, created an application approval process, and deployed Microsoft Defender for Cloud Apps to monitor for anomalous application behaviour. The policy change was simple: no one could authorise a new cloud app without IT security review.

But it doesn't have to be your story. That's why we're here.

You should now understand that modern phishing attacks target authorisation, not just authentication. You understand how OAuth tokens can be weaponised for ransomware. You know that detection must shift to monitoring application consent and API behaviour. And you understand that the fix is often a policy change, not just a new tool.

Next, we'll explore Next, we'll explore Lesson 1.2: The Ransomware Supply Chain. We'll look at how attackers use compromised vendors and software updates to get inside organisations, and how to assess your own exposure.

See you there.

Resources

The course materials folder contains downloadable resources for this lesson:

• Lesson 1.1 Quick Reference Card - Summarise the key detection indicators in Azure AD logs and immediate response steps for an OAuth-based ransomware incident on a single page.
• Compliance Mapping Worksheet - Map your organisation's OAuth application consent policies and monitoring controls to DORA, ISO 27001, NIST CSF, NIS2, SOC 2, and GDPR frameworks.
• Risk Assessment Template - Assess your organisation's specific exposure to OAuth phishing and token-based ransomware based on current consent settings and application governance.
• Further reading - Links to official Microsoft documentation on managing OAuth app consent and Microsoft Defender for Cloud Apps detection rules for ransomware behaviour.

OAuth phishers make ‘check where the link points’ advice ineffective Defence Masterclass | Threat Intelligence | Lesson 1.1
© LimitedView Limited | 2026