The Incident: "Meridian Partners" OAuth Consent Phishing

Meridian Partners is a composite based on real-world patterns. The firm runs Microsoft 365 E3, uses a single Entra ID tenant, and had Conditional Access policies covering only VPN and admin portals — not OAuth application grants.

Timeline of attack:​‌‌​​‌​​‍​‌‌​​‌‌​‍​‌‌​‌​​‌‍​‌‌‌​​‌​‍​​‌​‌‌​‌‍​‌‌​​​‌‌‍​‌‌​​​​‌‍​‌‌‌​​‌‌‍​‌‌​​‌​‌‍​​‌​‌‌​‌‍​‌‌‌​​‌‌‍​‌‌‌​‌​​‍​‌‌‌​‌​‌‍​‌‌​​‌​​‍​‌‌‌‌​​‌‍​​‌​‌‌​‌‍​‌‌​‌​​‌‍​‌‌​‌‌‌​‍​‌‌​​​‌‌‍​‌‌​‌​​‌‍​‌‌​​‌​​‍​‌‌​​‌​‌‍​‌‌​‌‌‌​‍​‌‌‌​‌​​‍​​‌​‌‌​‌‍​‌‌‌​​‌​‍​‌‌​​‌​‌‍​‌‌‌​​‌‌‍​‌‌‌​​​​‍​‌‌​‌‌‌‌‍​‌‌​‌‌‌​‍​‌‌‌​​‌‌‍​‌‌​​‌​‌‍​​‌​‌‌​‌‍​‌‌‌​​​​‍​‌‌​‌‌​​‍​‌‌​​​​‌‍​‌‌‌‌​​‌‍​‌‌​​​‌​‍​‌‌​‌‌‌‌‍​‌‌​‌‌‌‌‍​‌‌​‌​‌‌‍​​‌​‌‌​‌‍​‌‌‌​​‌‌‍​‌‌​‌‌​‌‍​‌‌​​​‌​

• Day 0 (14 March): A finance team member clicks a "DocuSign – Review Document" phishing link. The landing page requests OAuth permissions to a legitimate-looking app called "SharePoint Sync Manager." She clicks Accept.
• Day 1–12: The attacker uses the delegated access token to read her mailbox silently via Microsoft Graph API. No MFA challenge fires because the consent grant operates under the user's already-authenticated session.
• Day 13: The attacker finds an active email thread with a conveyancing client regarding a property settlement. A spoofed follow-up email redirects the client to pay $340,000 into a controlled account.
• Day 15: The client phones Meridian to confirm receipt. Finance checks. The money is gone.

Stage 1: Detection

The first indicator came not from a SIEM alert but from a human — the client's phone call. Once the finance team escalated, the IT lead pulled three artefact sets simultaneously.

EDR alerts (CrowdStrike Falcon):

Detection: Suspicious PowerShell Download
Severity: Low (informational)
Host: FIN-LPT-042
Timestamp: 2026-03-14 09:41:12 AEDT

This alert had been auto-resolved because the user was local admin on her laptop — a finding that would resurface in lessons learned.

Entra ID Sign-in Logs:

Get-MgAuditLogSignIn -Filter "appId eq '3d5b124e-xxxx-xxxx-xxxx-xxxxxxxxxxxx'" -All

The query revealed Graph API sign-ins from an IP geolocated to a Bulgarian hosting provider, spanning Days 1–13, all authenticated via the OAuth refresh token — no interactive sign-in required.

M365 Unified Audit Log:

Search-UnifiedAuditLog -Operations "MailItemsAccessed" -UserIds "[email protected]" -StartDate "2026-03-14" -EndDate "2026-03-26"

Hundreds of MailItemsAccessed operations confirmed the attacker had read every email in Sarah's inbox, including attachments, over 12 days.

Stage 2: Triage

The IT lead classified this as a P1 — Active Compromise with Financial Impact using the ACSC's incident severity framework. Key triage actions:

1. Scope the OAuth grant. Ran Get-MgServicePrincipal -All to enumerate all consented applications. Found "SharePoint Sync Manager" with Mail.Read, Mail.ReadWrite, and User.Read delegated permissions — granted by three users, not just Sarah.
2. Check lateral movement. Searched the Unified Audit Log for Add-MailboxPermission and New-InboxRule operations. Found no mailbox forwarding rules, but did find the attacker had accessed two additional mailboxes via shared mailbox permissions Sarah held.
3. DNS log review. Queried the firewall DNS proxy for graph.microsoft.com lookups from non-standard sources during the attack window. Confirmed consistent API polling from the Bulgarian IP block.

Stage 3: Containment

Immediate actions within the first 4 hours:

• Revoke the OAuth grant: Remove-MgServicePrincipal -ServicePrincipalId <objectId> for the malicious app, then Revoke-MgUserSignInSession for all three affected users.
• Force password reset and re-register MFA for all three accounts.
• Block the attacker IP range at the firewall: 203.0.113.0/24 (anonymised).
• Enable Conditional Access for OAuth app consent: Set admin consent required for any application requesting Mail.Read or higher.
• Preserve artefacts: Exported Entra audit logs, M365 audit logs, and EDR telemetry to a secure evidence container with hash verification.

Stage 4: Eradication

Over the next 48 hours:

• Removed residual delegated permissions and verified no other suspicious service principals existed.
• Rebuilt Sarah's laptop from a known-clean image (the EDR alert suggested possible local tooling).
• Rotated all service account credentials and app registration secrets in the tenant.
• Engaged the firm's bank and the Australian Federal Police via the ACSC's reporting portal to initiate recovery of the misdirected funds.

Stage 5: Recovery

• Restored mailbox integrity by confirming no inbox rules or delegates were added by the attacker.
• Communicated transparently with the affected client, providing a full incident timeline.
• Engaged an external forensic firm to validate the eradication scope — a critical step for liability and insurance purposes.

Stage 6: Lessons Learned

Three root causes emerged:

1. No admin consent policy for OAuth. Any user could consent to any application requesting mail access.
2. Conditional Access did not cover token-based access. Policies only enforced MFA for interactive VPN and admin portal logins.
3. Users had excessive local admin rights. The initial EDR alert was auto-dismissed because the user was a local admin — a false-negative that delayed detection by 15 days.

Three Preventive Controls That Would Have Blocked This Attack

1. Entra ID Admin Consent Policy (blocks at Day 0) Require admin approval for any third-party application requesting Microsoft Graph permissions above a minimal baseline. Navigate to Entra ID > Enterprise applications > Consent and permissions > Admin consent workflow. This single control would have prevented Sarah from granting access.

2. Conditional Access: Token and App-Enforced Controls (blocks at Day 1) Create a policy targeting "Cloud apps > Office 365 Exchange Online" with the condition "Client app types > Mobile apps and desktop clients" and enable "Require device to be marked as compliant." This forces MFA and device trust even for token-based API access — closing the gap that let the attacker poll Graph API for 12 days without challenge.

3. OAuth Application Monitoring and Alerting (detects at Day 1) Deploy a scheduled query — either via Microsoft Sentinel or a scripted Get-MgServicePrincipal baseline — that alerts on any new application consent grant with Mail.Read or higher within 24 hours. Detection on Day 1 would have prevented the $340,000 loss entirely. For SMBs without Sentinel, the free Microsoft Defender for Cloud Apps discovery dashboard provides OAuth app anomaly detection out of the box.

FAQ

Conclusion

The Meridian Partners incident is not an edge case — it is the template for how Australian SMBs are being compromised in 2026. The attacker used no zero-days, no custom malware, and no nation-state tooling. They abused a legitimate Microsoft authentication mechanism and a lack of administrative guardrails. The fix is not expensive. It is operational discipline: consent policies, Conditional Access, and monitoring.

If your organisation has not reviewed its OAuth consent configuration in the last 90 days, treat that as a P1 gap. Visit consult.lil.business for a free cybersecurity assessment — we will audit your Entra ID tenant, review your Conditional Access posture, and give you a prioritised remediation plan within 48 hours.

References

1. Australian Cyber Security Centre — Annual Cyber Threat Report 2024-2025
2. Microsoft — OAuth 2.0 and App Consent in Entra ID
3. NIST SP 800-61 Rev. 2 — Computer Security Incident Handling Guide
4. SonicWall 2026 Cyber Protect Report — SMB Threat Landscape
5. IBM Cost of a Data Breach 2025 Report