OAuth Abuse at a SaaS Provider
At a SaaS provider serving 14 enterprise tenants, the security team finds anomalous OAuth activity 30 days after a helpdesk vishing call. An attacker posing as a new employee persuaded the service desk to reset MFA and enroll a new device. Since then, 6 tenants show impossible-travel sign-ins, 2,300 mailboxes have inbox rules that move messages containing 'invoice' to RSS Feeds, and a third-party app was granted Mail.Read and offline_access. EDR is clean; no malware was found. The identity team sees token replay from two residential proxies. One tenant reports a fraudulent payment change. The CISO must brief the board in 48 hours and decide whether to notify all tenants, hunt further, or treat this as contained BEC.
1. Map the intrusion to MITRE ATT&CK and the cyber kill chain. Which controls failed and which detection gaps remain?
Read the worked answer
The intrusion maps to phishing for voice (T1566.004), MFA request generation or fatigue (T1621), account manipulation through MFA reset and device enrollment (T1098), and illicit consent grant or token theft (T1528). The inbox rules map to email hiding or forwarding rule behavior (T1114.003), and the payment change is consistent with financial fraud. Collection likely includes remote email collection (T1114.002), with exfiltration over a web service (T1567.002). In kill-chain terms: reconnaissance of the helpdesk process, weaponization of a plausible new-hire story, delivery by phone, exploitation of identity verification, installation of a persistent OAuth grant and device, command and control through token replay, and actions on objectives including BEC.
Controls that failed include helpdesk identity proofing, MFA reset authorization, conditional access for new devices, OAuth consent governance, and mailbox-rule monitoring. Detection gaps remain for consent grants to low-reputation apps, token replay from residential proxies, and bulk inbox-rule creation. EDR being clean is expected in identity-centric intrusions; it is not evidence of containment. The team should hunt identity logs, app registrations, consent events, and mailbox audit records across all 14 tenants.
2. Assess whether this is espionage, financial crime, or both. What evidence would shift your judgment?
Read the worked answer
The current evidence leans toward financially motivated crime: a fraudulent payment change, invoice-themed mailbox rules, residential proxies, no malware, and a 30-day dwell that produced fraud rather than intellectual-property collection. However, identity-centric access can serve both. An espionage actor might maintain OAuth access quietly, collect executive or engineering mail, and avoid payment fraud to preserve access. A criminal actor might use the same access for BEC and then sell it.
I would look for what was collected, not just what was accessed. If the 2,300 mailboxes include source code, merger discussions, incident-response plans, or tenant secrets, espionage becomes more plausible. If the actor only created invoice rules, changed payment details, and used residential proxies consistent with fraud infrastructure, financial crime is more likely. Other discriminators: duration and stealth of token use, targeting of specific roles, use of cloud storage for staged files, and whether the actor contacted tenants for extortion. My confidence would be moderate, not high, and I would state what would change it. The board should hear both possibilities without premature attribution.
3. Recommend the 48-hour board message and tenant-notification decision.
Read the worked answer
I would not describe this as contained BEC. Six tenants are affected, token access remains possible, and the mailbox rules indicate collection beyond a single payment fraud. In 48 hours I would brief the board on what is known, what is not known, containment actions taken, and the decision required. Containment should include revoking the illicit OAuth grant, resetting credentials and sessions for affected accounts, removing inbox rules, blocking the proxies, and reviewing all consent grants across tenants. I would preserve evidence and involve counsel.
On notification, I would notify the six affected tenants quickly and prepare a broader notification to all 14 if shared identity infrastructure or token replay is found. The message should state the observed facts, the actions tenants must take, and the limits of current knowledge. I would not wait for full attribution. Regulated tenants may have their own breach-notification clocks, so counsel should advise on timing. I would also set a 72-hour hunt checkpoint for new consent grants, mailbox rules, and payment changes. The board message should be decision-oriented: contain, notify, hunt, and preserve, not 'we believe it is contained.'