sysop@hub:~/explainers/war-stories/aitm-help-desk$
The help desk that answered too fast
A finance employee approved an MFA prompt for a sign-in that wasn't theirs. Forty minutes later, an invoice went out with different bank details.
timeline
A finance team member receives an email that looks like a DocuSign request from a known vendor contact. It links to a page that looks exactly like the Microsoft sign-in page, hosted on a domain that differs from microsoft.com by one character.
She enters her username and password. The page relays them live to the real Microsoft sign-in page behind the scenes, an adversary-in-the-middle setup.
Her phone shows an MFA push notification. She has just tried to sign in, so approving it feels routine. She taps approve. The attacker's proxy captures the resulting session cookie the instant it is issued.
The attacker replays the stolen cookie from their own machine. Because the session already counts as fully authenticated, no further password or MFA prompt appears.
The attacker opens her mailbox, searches for "invoice" and "payment", and reads several weeks of correspondence with a real vendor about an upcoming payment.
A new inbox rule is created that silently moves any reply from the vendor's domain to a rarely-checked folder, then the attacker sends the vendor a message from her real account: "Apologies for the confusion, please use these updated bank details for the upcoming payment."
The vendor's accounts team, seeing the message came from her real, correct address, updates their records and pays the next invoice to the new account.
The original vendor calls asking why they have not been paid. The finance employee has no memory of the "updated bank details" email, since it was sent from her own account without her knowledge. The investigation begins.
- MFA was completed correctly by the real user; the theft happened after authentication, at the session cookie, which the AiTM proxy captured in real time.
- The inbox rule that hid the vendor's replies was created 6 minutes after the session was stolen and was never noticed because nobody was looking for new rules on that account.
- The look-alike domain had been registered two weeks earlier and had a valid TLS certificate from a free certificate authority, so the padlock looked completely normal.
- Move privileged and finance accounts to phishing-resistant MFA (FIDO2 keys or passkeys), which cannot be relayed by an AiTM proxy. See how this attack works step by step
- Require a compliant, managed device for Conditional Access on finance and payment systems, so a replayed cookie from an unmanaged machine fails. Try the Conditional Access simulator
- Alert on new inbox rules and on forwarding rules created outside business hours or shortly after a sign-in from a new location. KQL queries for this
- Require a second channel (phone call to a known number) to confirm any change of bank details, regardless of how legitimate the email looks.
This is a composite scenario built from common, publicly documented attack patterns. It does not describe a specific real organization or incident.