M365: How They Steal Credentials (and How to Respond)

It was a Monday morning when Sara, the procurement manager, called the helpdesk with that voice you recognize immediately: "I got replies to emails I never sent". Invoices in negotiation, suppliers asking for confirmations, wire transfers to approve. This is not a hypothetical — it happens every week, in organizations of every size. And every time, the chain is the same.

How They Steal Credentials

The most common entry point today is not a technical vulnerability — it is a cloned Microsoft login page. Attackers use OSINT (LinkedIn, company websites, data leaks) to personalize phishing: the link contains the target's name, role, and often the company's Azure tenant ID. The user sees a plausible URL on a typosquatted domain — micros0ft-login.com, login.microsoftonIine.com — and the page is pixel-perfect.

The real leap forward is AiTM (Adversary-in-the-Middle). Frameworks like EvilProxy, Mamba2FA, and Tycoon2FA do not clone a static page: they act as a transparent proxy toward the real Microsoft login. The user enters username, password, and MFA code — all genuine, all forwarded to the legitimate server. But the proxy intercepts the session cookie and authentication token in real time. At that point, MFA has already been satisfied: the token is valid, authenticated, and ready to be reused by the attacker.

The second vector is more blunt: MFA Fatigue. The attacker already knows the password (from a leak or credential stuffing) and sends 20-30 push notifications to the Authenticator app in rapid succession, often at night or during a meeting. It relies on fatigue, distraction, the user who taps "Approve" just to stop the phone from buzzing. This is exactly what happened to Uber in 2022.

The third scenario is token theft. Entra ID session tokens and refresh tokens have lifetimes ranging from hours to days. An infostealer like Redline or Lumma running on a user's laptop can extract these tokens from the browser or MSAL cache. With a valid token, neither password nor MFA is needed — the attacker accesses Microsoft 365 APIs directly. Tools like AADInternals automate this in a few commands.

The fourth vector, which exploded in spring 2026, is device code phishing: the PhaaS platform Kali365, flagged by the FBI in May 2026, abuses Microsoft's OAuth 2.0 device authorization grant flow. The attacker starts a device code request against their own registered app, pastes the resulting code into a phishing page impersonating a OneDrive or SharePoint share, and the victim enters it at microsoft.com/devicelogin — a legitimate Microsoft domain. At that point the attacker's app receives the token: no password typed, no MFA prompt to approve. MFA is never even touched, because the flow doesn't involve it.

After the First Access

The first minutes after compromise are silent reconnaissance. The attacker reads the inbox, checks drafts, searches for keywords like "wire transfer", "IBAN", "invoice", "contract". They enumerate users, groups, SharePoint and OneDrive via the Graph API. All of this with the user's legitimate token — no alert, no visible anomaly.

Persistence is built in layers. First come inbox rules: automatic forwarding to an external address, or a rule that silently deletes emails containing "password reset", "security alert", "suspicious activity" — so the user never sees security notifications. Then a second MFA method is added (the attacker's phone number). Finally, the most insidious persistence: an OAuth app with delegated permissions (mail.read, mail.send, files.read) registered on the account. OAuth apps survive a password reset — they are a backdoor that stays open even after the incident appears resolved.

From that foothold, the attacker moves laterally: sends internal phishing to colleagues ("check this document", with an AiTM link), accesses other users' mailboxes via pre-existing delegated permissions, and initiates Business Email Compromise: modifies the IBAN on a pending invoice, replies to a financial email thread impersonating the CFO, approves urgent payments.

Incident Response: The Exact Sequence

For the user: call IT immediately, do not wait. Do not use the compromised account to do so (use your phone, personal email, or walk over in person). Do not change your password on your own before IT revokes sessions — a password change without token revocation leaves the attacker inside. List everything you clicked in the last 24-48 hours.

For the admin — operational sequence:

1. Immediately revoke all active sessions:

# Via PowerShell (AzureAD module)
Revoke-AzureADUserAllRefreshToken -ObjectId <user-object-id>

# Or via Entra ID: Users → select user → Revoke sessions

2. Admin-initiated password reset (not self-service):

Set-AzureADUserPassword -ObjectId <user-object-id> -Password <new-secure-password> -ForceChangePasswordNextLogin 

3. Remove unrecognized MFA methods (Entra ID → Users → Authentication methods). Check phone number, Authenticator app, recovery email.

4. Inspect inbox rules:

Get-InboxRule -Mailbox user@company.com | Select Name, ForwardTo, DeleteMessage, SubjectContainsWords | Format-List

5. Revoke suspicious OAuth apps: Entra ID → Enterprise Applications → filter by "User consent" → look for apps registered in the last 24-48h → revoke permissions.

6. Analyze sign-in logs: Entra ID → Sign-in logs → filter by user, last 48h. Look for anomalous IPs, unusual user agents (automation), unexpected countries. Note: reused tokens show the AiTM proxy IP, not the actual attacker.

7. Check sent and deleted emails during the compromise window. In Exchange Online:

Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-2) -EndDate (Get-Date) -UserIds user@company.com -Operations SendMail,HardDelete,SoftDelete

8. If outbound phishing or BEC occurred: notify affected recipients, report emails as phishing, initiate recall for unread messages.

Useful tools: Microsoft Secure Score (baseline), Defender for Office 365 Threat Explorer (attack timeline), Microsoft Defender for Cloud Apps (impossible travel, token replay detection), HAWK or GOOSE for PowerShell-based log forensics.

The Real Defense Is Not MFA

Classic MFA — push notifications, SMS, TOTP — does not stop AiTM. Attackers bypass it systematically. Real defense is built on multiple layers: Conditional Access with device compliance (only managed, compliant devices can authenticate), FIDO2/passkeys which are phishing-resistant by design (the key is bound to the original domain, not a proxy), aggressive token lifetime policies (short session tokens, refresh tokens with IP binding), and continuous monitoring of anomalous sign-ins.

Against Kali365 specifically, the only effective defense is blocking the flow upstream: Conditional Access → Authentication flows, disable the device code flow if your organization doesn't need it (most don't). Since it acts before MFA ever comes into play, no strong-authentication policy can stop it once it's underway.

And above all: users who call without shame. Sara did the right thing. The damage was contained because she picked up the phone immediately, without waiting to be "sure" it was a real problem. That call cost 10 minutes. Not making it would have cost weeks.