The session is the prize
In July 2022, Microsoft described an adversary-in-the-middle phishing campaign that intercepted passwords and authenticated session cookies, followed by attempts at business email compromise. Microsoft said the campaign had attempted to target more than 10,000 organisations since September 2021. That is a count of attempted targeting in its telemetry, not a count of organisations successfully breached.
The mechanism explains why an incident report can contain a successful MFA event and still describe an account takeover. A reverse proxy relays the sign-in exchange through an attacker-controlled origin. Once the user completes a susceptible sign-in flow, the attacker can obtain the resulting session material and try to reuse it. The attacker is exploiting how the session is acquired and accepted, rather than breaking the cryptography of a one-time code.
Follow the trust boundary, not the page design
A polished sign-in page and a valid HTTPS certificate do not establish that a user is authenticating at the intended origin. Transport encryption protects the connection to the site in the address bar, including when that site belongs to an attacker.
CISA's phishing-resistant MFA guidance explains the role of FIDO/WebAuthn authenticators. Origin binding changes the authentication decision: an authenticator should not produce the expected credential for an unrelated phishing origin. That protection should not be generalised into a claim that a passkey makes every session immune to endpoint malware, recovery-channel abuse or theft after a legitimate sign-in.
| Control | Where it helps | Remaining question |
|---|---|---|
| Origin-bound authentication | Resists credential use at the wrong web origin | How are recovery and fallback handled? |
| Conditional access | Adds device and other context to access decisions | Are sessions re-evaluated when context changes? |
| Session revocation | Terminates supported existing access paths | Which tokens and applications does revocation cover? |
| Mailbox audit review | Helps identify activity after sign-in | Are the necessary logs retained? |
These controls work at different points. Buying a stronger authenticator does not automatically supply the incident-response records needed after an account is suspected to be compromised.
A response order for a suspected mailbox takeover
First identify the affected account, its privileges and the relevant sign-in window. Preserve the available identity and mailbox audit records. Restrict access and revoke affected sessions using the identity provider's current documented procedures; reset compromised credentials and review registered authentication and recovery methods.
Then inspect changes that can outlive the original session: mailbox forwarding, inbox rules, delegated access and third-party application grants. These are investigation areas, not a claim that all were used in Microsoft's reported campaign or in any particular victim account.
Review payment-related conversations with the business owner. If an attacker could read an ongoing invoice discussion, the risk is not limited to another suspicious login. A fraudulent payment instruction may already have reached a customer or supplier. Verify changes to payment details through a separately established contact route.
What a tabletop exercise should test
A useful exercise begins with a completed MFA prompt and an unfamiliar mailbox session. Ask the team to establish who can revoke access, how long relevant logs remain available, and which business process verifies urgent payment changes. The exercise can be run with synthetic records; there is no need to collect a real user's authentication cookies.
Measure time to a documented decision: access restricted, evidence preserved, persistence reviewed and business contacts checked. Counting the number of people who spotted the phishing email misses the recovery problem this attack creates.
The connection to CI secret leakage
The tj-actions incident involved a different entry point, but the same recovery distinction applies: removing the malicious mechanism is separate from invalidating the credentials it exposed. For identity incidents the reusable object may be a session; for build systems it may be a deployment token. The response needs to follow the authority granted by that object.
Start with a bounded sign-in review
For an organisation collecting Entra sign-in records into the documented Azure Monitor SigninLogs table, this read-only KQL query provides a small recent review set:
SigninLogs
| where TimeGenerated > ago(7d)
| project TimeGenerated, UserPrincipalName, IPAddress,
AppDisplayName, ConditionalAccessStatus
| order by TimeGenerated desc
| take 100
The query uses the current documented table rather than pretending the 2022 research schema is unchanged. It requires the relevant collection, retention and reader permissions. The result is a review population, not a detection of session theft. A successful conditional-access result says a policy decision succeeded; it does not prove that later session use was legitimate.
Adjust the period and identity scope to the incident. A 100-row limit can omit relevant activity. Correlate unfamiliar sessions with device context, account changes and mailbox actions before drawing a conclusion. Mobile networks, proxies and legitimate travel can change source addresses without an account takeover.
Review persistence in the mailbox's own control surface
In an authorised Exchange environment, the supported inbox-rule tooling can inspect an affected mailbox. For example, where the installed module supports these parameters:
Get-InboxRule -Mailbox '[email protected]' -IncludeHidden |
Select-Object Name, Enabled, ForwardTo, RedirectTo, DeleteMessage
The address is a reserved illustrative placeholder. Use the intended mailbox under the incident's permissions and current Exchange documentation. This is a read operation, not a command to remove every rule. Hidden rules, forwarding and deletion actions need context: some are legitimate, while a new rule near suspicious access can warrant further investigation.
Keep the raw rule results inside the response process because they can include private addresses and business information. Inspect delegation and application grants through their own supported controls as well. An inbox-rule query does not cover every persistence mechanism.
Compare the stolen authority, not just the entry point
CitrixBleed, disclosed in October 2023, acquired session material through an appliance information-disclosure flaw. AiTM acquires it through an authentication relay. Both require a verified session-response procedure, but the exposure evidence and software remediation differ.
The June 2024 Snowflake customer-account campaign illustrates another lifetime mismatch: credentials from older endpoint infections could remain accepted by a connected service. The documented campaign involved customer credentials; it should not be described as the same mechanism as a phishing-proxy session theft.
Those comparisons produce a practical response rule. Identify the exact reusable object, the services accepting it and the invalidation process that applies to it. Then investigate any business actions already performed with that authority. A password reset is one possible action in that sequence, not a complete description of recovery.