AitM Campaign Hits 97 Microsoft 365 Mailboxes Across 79 Organizations
Moyen · The Hacker News ·
En bref
- Attackers relayed authentication traffic to capture sessions and replay tokens.
- Huntress and Microsoft tied the activity to 97 compromised mailboxes, 79 organizations and 497 sign-in events.
- No CVE was involved; the exposure centers on session trust and token handling.
- Admins should revoke sessions, enforce phishing-resistant MFA and tighten conditional access.
A credential-free intrusion campaign used an adversary-in-the-middle relay to position itself between users and Microsoft 365 authentication. Instead of relying on stolen passwords, the operators captured valid session material and replayed it to reach mailbox data. Huntress and Microsoft documented the activity, which ran from July 14, 2026 through September 22, 2026.
The campaign touched 97 accounts spread across 79 organizations, with 497 authentication events linked to the intrusion. That spread points to broad targeting rather than a single-tenant event, with a limited number of mailboxes reached at each victim organization. The actors remain unidentified.
Because replayed tokens can satisfy authentication checks, ordinary MFA prompts may appear to have been completed legitimately. Captured sessions give an intruder time to read mail, alter downstream access, and blend into normal cloud activity. No CVE was assigned; this is not a patchable software defect but abuse of authentication flow and token lifetime.
AitM kits are a familiar phishing pattern: a proxy page relays traffic to the real login service, then keeps the resulting session artifacts. The public reporting names Huntress and Microsoft as the vendors tracking this event. The absence of a CVE means patching alone will not close the gap.
Watch for unusual sign-ins, token issuance from unfamiliar locations, new inbox rules, mail forwarding changes, and OAuth consent grants. Treat session revocation as containment, not merely a password reset. Organizations should also review conditional access policies that allow long-lived sessions or unmanaged devices.
À faire maintenant
- Revoke refresh tokens and active sessions for any confirmed or suspected affected accounts, then force reauthentication.
- Reset credentials after session revocation, but do not treat password changes alone as containment.
- Enforce phishing-resistant MFA such as FIDO2 security keys or passkeys, and block legacy authentication paths.
- Tighten conditional access with compliant-device requirements, shorter session lifetimes and token protection where available.
- Hunt for AitM indicators: anomalous sign-in locations, new inbox rules, forwarding changes and unfamiliar OAuth grants.
- Restrict user consent for third-party applications and review existing app permissions for excessive mailbox access.
- Brief users on proxy-based phishing and require prompt reporting of unexpected Microsoft 365 login prompts.
Source originale
Analyse originale assistée par IA, sources citées. Vérifiez auprès de l'avis du fournisseur avant d'agir.