DFIR Case Study: How an OAuth Consent Grant Let Ransomware Into an Australian SMB

The Incident: Ransomware via OAuth Consent Grant

RedSouth Advisory (composite, anonymised) is a mid-tier accounting firm in Melbourne. On a Tuesday morning in March 2026, staff arrived to find file shares encrypted with .locked extensions and a ransom note demanding 4.2 BTC. The initial reaction was disbelief — they had MFA enabled, EDR deployed, and quarterly phishing training. But the entry point wasn't a credential theft or a phishing email. It was an OAuth consent grant.

A threat actor registered a malicious multi-tenant Entra ID application named "SharePoint Sync Manager" with a convincing publisher display name. On the preceding Thursday, a finance team member clicked "Accept" on a consent prompt while reviewing what appeared to be a clie

nt document link. The app requested Mail.Read, Files.ReadWrite.All, and Sites.ReadWrite.All — enough scope to access every SharePoint site and OneDrive in the tenant.​‌‌​​‌​​‍​‌‌​​‌‌​‍​‌‌​‌​​‌‍​‌‌‌​​‌​‍​​‌​‌‌​‌‍​‌‌​​​‌‌‍​‌‌​​​​‌‍​‌‌‌​​‌‌‍​‌‌​​‌​‌‍​​‌​‌‌​‌‍​‌‌‌​​‌‌‍​‌‌‌​‌​​‍​‌‌‌​‌​‌‍​‌‌​​‌​​‍​‌‌‌‌​​‌‍​​‌​‌‌​‌‍​‌‌​‌‌‌‌‍​‌‌​​​​‌‍​‌‌‌​‌​‌‍​‌‌‌​‌​​‍​‌‌​‌​​​‍​​‌​‌‌​‌‍​‌‌‌​​‌​‍​‌‌​​​​‌‍​‌‌​‌‌‌​‍​‌‌‌​​‌‌‍​‌‌​‌‌‌‌‍​‌‌​‌‌​‌‍​‌‌‌​‌‌‌‍​‌‌​​​​‌‍​‌‌‌​​‌​‍​‌‌​​‌​‌‍​​‌​‌‌​‌‍​‌‌‌​​‌‌‍​‌‌​‌‌​‌‍​‌‌​​​‌​

For four days, the attacker exfiltrated data via Microsoft Graph API calls, then deployed ransomware through a scheduled task pushed via Intune — which the compromised app had been granted access to as a delegated administrator.

Stage 1: Detection — What Triggered the Alarm

Detection came from two sources 30 minutes apart:

EDR alert: CrowdStrike Falcon flagged unusual schtasks.exe execution with encoded command-line arguments across three endpoints at 07:42 AEST.

Entra ID anomaly: Microsoft Entra ID Protection raised a sign-in risk event at 07:14 — a Graph API session originating from a Tor exit node (185.220.101.xx) accessing the /sites/{site-id}/drive/items endpoint at anomalously high volume.

Key artefacts pulled during detection:

• Entra sign-in logs: Get-MgAuditLogSignIn -Filter "appId eq 'redacted-app-id'" revealed 14,000+ API calls over four days from 11 distinct source IPs, nine belonging to known proxy/Tor ranges.
• M365 Unified Audit Log: Search-UnifiedAuditLog -RecordType AzureActiveDirectory -Operations "Consent to application" showed the consent event at Thu 15:32:07 AEST, recorded as ConsentType: Principal for the compromised user.
• EDR telemetry: Lateral movement via PsExec from an workstation named WS-FIN-04 at 07:38, followed by vssadmin delete shadows /all /quiet across three servers.

Stage 2: Triage — Scope and Severity Assessment

The IR team classified this as Severity 1 — Critical based on:

1. Active ransomware deployment across production file servers
2. Confirmed data exfiltration (Graph API download logs showed 38 GB transferred)
3. Potential for ongoing access through the persisted OAuth app

Triage queries executed in the first 60 minutes:

# Identify all users who consented to the malicious app
Get-MgServicePrincipal -Filter "displayName eq 'SharePoint Sync Manager'"
Get-MgOAuth2PermissionGrant -All | Where-Object {$_.ClientId -eq $maliciousAppId}

# DNS logs: check for C2 domain resolution
Get-DnsServerResourceRecord -ZoneName "redsouth.local" -RRType A | 
  Where-Object {$_.HostName -match "sharepoint-sync|graph-proxy|cdn-update"}

DNS logs revealed the malicious app's redirect URI resolving to login.microsoftonline.com (legitimate), but the refresh token was being used from an attacker-controlled session proxy at api[.]sharepoint-sync-manager[.]io.

Stage 3: Containment — Stopping the Bleed

Containment proceeded in parallel across identity, network, and endpoint layers:

Identity containment (0-30 min):

• Revoked all refresh tokens enterprise-wide: Revoke-MgUserSignInSession -All
• Removed the OAuth consent grant: Remove-MgOAuth2PermissionGrant -OAuth2PermissionGrantId $grantId
• Disabled the compromised service principal: Update-MgServicePrincipal -ServicePrincipalId $spId -AccountEnabled:$false
• Blocked Tor/proxy exit nodes in Entra conditional access

Network containment (0-45 min):

• Isolated affected VLANs at the firewall layer
• Blocked outbound traffic to the C2 domain at DNS and perimeter proxy

Endpoint containment (0-60 min):

• EDR network containment mode activated on all affected endpoints
• Disabled the malicious scheduled task across the Intune-managed fleet

Stage 4: Eradication — Removing the Attacker's Foothold

Eradication required purging every persistence mechanism:

1. Removed the malicious Entra application registration entirely from the tenant — not just disabled, deleted via Remove-MgApplication.
2. Reset credentials for all 12 users whose mailboxes or OneDrive folders showed Graph API access, enforcing new passwords and re-registering MFA.
3. Purged compromised Intune policies — the attacker had created a device configuration profile deploying the ransomware scheduled task. This required Remove-MgDeviceManagementDeviceConfiguration.
4. Scanned all endpoints for residual persistence: registry run keys, WMI event consumers, and alternate data streams. Two endpoints had secondary scheduled tasks planted as backstops.

Stage 5: Recovery — Restoring Operations

RedSouth Advisory restored from immutable backups (Veeam with S3 Object Lock) taken the previous Saturday. Total downtime: 38 hours. Recovery sequence:

1. Rebuilt three file servers from clean images
2. Restored file shares from backup — validated against known-good checksums
3. Re-joined endpoints to the domain with fresh credentials
4. Monitored Entra sign-in logs for 72 hours for anomalous Graph API patterns before declaring clean

Stage 6: Lessons Learned — Preventive Controls That Would Have Stopped This

Three controls, had they been in place, would have blocked the attack at earlier stages:

1. OAuth Consent Policy (would have blocked at Stage 0): Entra ID allows administrators to restrict user consent to only verified publishers and low-risk permissions. Setting ManagePermissionGrantsForSelf-service-signup-applications to restrict consent to Classification: Low would have prevented the finance team member from granting Files.ReadWrite.All to an unverified app. This single policy — a 10-minute Entra configuration change — would have stopped the entire attack chain.

2. Conditional Access: Block Legacy Auth and Anomalous Locations (would have blocked at Stage 1): A conditional access policy blocking sign-ins from anonymous IP addresses (Tor exit nodes) and requiring compliant devices for Graph API access would have terminated the attacker's session within minutes of the first suspicious call.

3. EDR Detection of Graph API Abuse Patterns (would have detected at Stage 1): While CrowdStrike caught the ransomware deployment, an EDR or SIEM correlation rule flagging Files.ReadWrite.All scope usage from non-compliant devices or atypical volumes would have triggered an alert during the four-day exfiltration window — not just at the ransomware stage.

FAQ

Conclusion

RedSouth Advisory's breach is a textbook example of how modern cloud attacks bypass traditional perimeter defences. The attacker never needed to phish a password or exploit a vulnerability — they needed one employee to click "Accept" on a consent prompt. The fix isn't more EDR or better phishing training. It's tightening the identity layer: restrict OAuth consent, enforce conditional access, and monitor Graph API usage patterns. These are free or low-cost configurations within existing Microsoft 365 licenses that most Australian SMBs haven't enabled.

Visit consult.lil.business for a free cybersecurity assessment — we'll check your Entra consent policies, conditional access rules, and audit log coverage in under an hour.

References

1. ACSC — Email and Account Protection Guidance
2. Microsoft — OAuth App Authorization in Microsoft 365
3. NIST SP 800-61 Rev. 3 — Computer Security Incident Handling Guide