CCOA (ISACA): MFA Pushes at 22:10

Order is driven by two clocks: the attacker's session lifetime and audit-log retention.

1. Revoke sessions and refresh tokens (0-5 min). A password reset alone leaves the existing token valid; session revocation is what actually evicts an adversary. Do it before the reset so the reset does not tip them into using the token faster.
2. Export mailbox audit and sign-in logs to a case folder (5-10 min). Retention is finite and every remediation step is itself logged; capture the pre-remediation state.
3. Record, then remove, the inbox rule. Note its exact name, conditions and target folder first - it is both evidence and the mechanism hiding invoice mail.
4. Remove the OAuth consent for 'MailSync Pro' and review the granted scopes; an app with Mail.Read can keep reading after a password change.
5. Reset the password and re-register MFA from a known-clean device. Do not let her re-enrol from the personal laptop.
6. Check the mailbox beyond the rule: forwarding, delegate permissions, sent items, and any new transport rule.

The 22:10 call rules out a benign MFA-fatigue false positive - she denied the pushes, so someone holds her password and is pushing. Every step above is evidence-handling, not just cleanup.

Severity: high - confirmed account takeover with active business email compromise. What lifts this above 'suspicious sign-in' is the combination of a concealment rule, a fresh OAuth grant, and an outstanding supplier bank-detail change request in the same 24 hours. The objective is money and the window is days.

Declare a P2 major incident and open the formal process. Not P1 - nothing is encrypted and no service is down - but it must not sit in a queue overnight.

Notification order:

• Immediately: incident commander on call; finance controller and AP lead by phone, not email, because mail to that team is not trustworthy while the mailbox is compromised.
• Immediately after: legal and compliance. The mailbox is under legal hold, so deleting the malicious rule or quarantining messages can later be argued as spoliation. They must authorise and record it.
• Within the hour: the bank, and the supplier via the phone number in the vendor master record - never a number from the suspect thread.
• Within the day: the OAuth app publisher and, if the consent came via a phishing link, the cloud provider's abuse channel.

Record that finance was notified before the technical investigation finished. Speed protects funds; root-cause analysis can follow. Also confirm whether AP has already actioned the bank-detail change - that single fact changes the incident from 'contained' to 'financial loss'.

Treat it as the likely initial-access vector and as a device you cannot forensically control.

Do not attempt to image it. No management agent, no chain of custody, and in most jurisdictions no lawful authority to seize a personal device. An 'image' you cannot authenticate is worse than none.

Instead:

• Interview without leading. When and how did she sign in from it? Did she follow an emailed link to a 'document portal' or 'shared invoice' and enter her password and MFA there? That is the classic adversary-in-the-middle pattern - a proxy page relays the MFA and a valid token is issued - and it explains both the OAuth consent and why she got pushes for sessions she never started (or got none at all).
• Use the tenant logs as the forensic record. For that device: user agent, device ID, IP, and whether the authentication was a fresh challenge or a token refresh. An AiTM session appears as a legitimate token issued to a real browser from an unfamiliar address.
• Force clean state: fresh MFA registration, remove the device from remembered-device and 'my sign-ins' lists.
• Advise, don't mandate, that she run a reputable scanner and change any personal password she has reused with the corporate one.

If she needs to work during quarter-end close, issue a managed loaner. What you must not do is let the unmanaged device re-enter the mailbox as a trusted endpoint because the business needs her online this week.