OAuth Consent Phishing in a Finance Department
At 09:10 on a Monday, a 400-user manufacturer's security team receives an alert: two finance users granted a Microsoft 365 OAuth application named 'InvoiceSync Helper' permission to read mail. The app's publisher is unverified. One user's mailbox now has a hidden rule forwarding messages containing 'invoice' or 'payment' to an external address, and sign-in logs show a successful login from Lagos, Nigeria, 14 minutes after a Tokyo login for the same account. MFA was satisfied by an older SMS method. The help desk has already reset one password but did not revoke sessions. The company uses Entra ID, Exchange Online, and a SaaS expense system. The CFO is asking whether to shut down email for the finance department, and the incident commander needs a containment plan that preserves evidence and avoids tipping off the attacker.
1. Prioritize the first 30 minutes of containment and justify the order.
Read the worked answer
First preserve volatile evidence: export sign-in logs, audit logs, OAuth grants, inbox rules, and message traces before changing the mailbox. Then revoke refresh tokens and sessions for both users; a password reset alone does not invalidate existing tokens. Remove the forwarding rule and block the unverified application tenant-wide. Reset passwords after revocation. Disable the accounts only if active access continues or the attacker is still moving; disabling can alert the attacker, but containment takes priority. Do not shut down all finance email, which would disrupt business and may not stop token-based access. Check the second user's grants and rules before assuming only one mailbox is affected. Notify legal and the CFO through the incident process.
2. How would you scope data exposure and persistence beyond the visible mailbox rule?
Read the worked answer
Query the unified audit log for consent grants, inbox rule creation and modification, forwarding settings, delegate permissions, SendAs rights, and application permissions. Review enterprise applications and user consent grants for additional OAuth tokens, including refresh tokens that survive password resets. Examine sign-in logs for impossible travel, unfamiliar user agents, MFA method changes, and token issuance. Search mail for invoices, payment threads, and external recipients. Check the expense SaaS for SSO logins, API tokens, and role changes from the same session. Preserve evidence with hashes and chain of custody, and look for other consent-phishing messages sent to additional users.
3. Recommend durable controls to prevent recurrence.
Read the worked answer
Restrict user consent to verified publishers or require admin approval for all new applications. Enforce conditional access with risk-based policies, compliant-device requirements for finance, and token protection where available. Move high-risk users to phishing-resistant MFA such as FIDO2 or number matching, and retire SMS where feasible. Block legacy authentication. Alert on new inbox rules, forwarding to external domains, new OAuth grants, and impossible travel. Add user reporting for consent prompts and run a tabletop exercise. These controls address the initial grant, token persistence, and the mailbox rule rather than only the visible symptoms.