Invoice Thread, Warsaw Sign-In, and a Consented App

Scope in three rings: this mailbox, then the tenant, then the downstream recipients.

Ring 1 - the known-compromised mailbox (last 30 days, unified audit log):

• New-InboxRule, Set-InboxRule, UpdateInboxRules - rules are the primary hiding mechanism; the RSS Feeds folder is a classic sink.
• Set-Mailbox for ForwardingSmtpAddress / ForwardingAddress (silent external forwarding outlives the rule).
• Add-MailboxPermission, Set-MailboxFolderPermission - delegated access is a persistence route.
• Sent Items and message trace from the account, to find what the actor sent as the user.

Ring 2 - tenant-wide:

• Azure AD audit log for Consent to application and Add service principal around the 'MailSync Pro' approval; enumerate enterprise apps and their Graph permissions (Mail.Read, Mail.Send, offline_access are the red flags).
• Sign-in logs filtered by the Warsaw IP and the autonomous system, across all 400 users - the consent phish likely hit more than one person.
• Search all mailboxes for the reply-to domain and for the sender's infrastructure.

Ring 3 - business impact: did any payment leave, and did the actor email customers or other suppliers from the account?

Order matters: mailbox-level queries are fast and tell you whether you are dealing with one victim or a campaign.

Order: revoke sessions and tokens, then remove the OAuth grant, then reset credentials, then clean the mailbox, then harden MFA.

1. Revoke refresh tokens / sign out all sessions. A password reset alone leaves existing tokens valid - the attacker keeps reading mail for up to an hour or more. This is the step most often skipped, and it makes every subsequent step cosmetic.
2. Remove the 'MailSync Pro' consent and revoke its grants / service principal. If the app holds Mail.Read/offline_access, it is an independent persistence mechanism that survives password changes entirely. If you remove the rule but leave the app, you have contained nothing.
3. Reset the password (and re-register MFA if the authentication methods were altered - check User registered security info events).
4. Delete the inbox rule and any forwarding, after exporting both as evidence.
5. Block the reply-to domain and sender infrastructure at the mail gateway.

Then widen: if any other user consented to the same app, step 2 must be repeated tenant-wide before you close the ticket. The single-mailbox fix is not the incident.

Document each action with a timestamp; the sequence is also the answer to 'how long was the actor still reading mail after we knew'.

Treat it as an active fraud in progress, not an email hygiene problem.

Next four hours, in parallel where possible:

• Bank first. Call the treasury contact and the receiving bank by phone, not email. Wire recalls succeed in hours and fail in days; if funds have not moved, a recall or hold request is the highest-value action available. Get the exact amount, value date, and reference.
• Verify the supplier out-of-band using the phone number from the signed contract or the vendor master record - never a number from the email thread. Tell them their name is being used and ask whether they received a change-of-details request.
• Search for other victims of the same pattern in message trace: the same reply-to domain, the same sender, the same lure wording, across all 400 mailboxes. BEC actors routinely run the same script on every finance contact they can reach.
• Preserve the original messages with full headers (Received, Return-Path, Message-ID, SPF/DKIM/DMARC results) before any mailbox cleanup; the headers are what law enforcement and the bank's fraud team will ask for.
• Report to law enforcement and your insurer per policy; notify counsel if the form contained personal data.

What not to do: send a 'is this really you?' email to the reply-to address, or quietly delete the thread. Both destroy evidence and tip off the actor while the wire is still recoverable.