TheDPDPAct.com -
Official WhatsApp Channel
Stay updated with the latest DPDP Act news, compliance insights, updates, and resources.
Join Our WhatsApp Channel →Multi-factor authentication worked. That is the uncomfortable part. Microsoft's own threat researchers put it plainly when analysing a large phishing campaign: "MFA is the reason that threat actors developed the AiTM (An Adversary-in-the-Middle) session cookie theft technique in the first place." Attackers did not give up on stealing access. They changed what they steal. Instead of a password, they take the session that exists after the password and the second factor have both succeeded. Group-IB's High-Tech Crime Trends Report 2026 describes the larger shift: identity has become the primary attack surface. If your security story ends at "we enabled MFA," this blog is about the chapter that follows.
What Group-IB's Report Says
Group-IB's 2026 report states that "identity has become the primary attack surface" and that token compromise "became far more prominent in 2025." Its illustration is a single stolen OAuth token that gave access to interconnected tenants, third-party services, and CI/CD pipelines, turning identity compromise into what the report calls a "force multiplier for systemic breaches." The report links this to the Drift, Salesloft, and Salesforce token incident, which it lists as affecting 700 organisations.
A token is not a password a user can be trained to protect. It is a credential held by software and quietly trusted by every system downstream.
A Balanced Reading of the Data
Identity is not the only door, and it would be a mistake to claim so. Verizon's 2026 Data Breach Investigations Report found vulnerability exploitation overtook stolen credentials as the top initial access vector for the first time in the report's 19-year history. According to a Descope summary of the report, exploitation accounted for 31% of breaches and credential abuse for 13% as the initial vector (about 16% on the previous year's methodology). But the same summary notes that credential abuse appears in 39% of breaches at any stage, still more than any other action, and that 73% of ransomware victims had an associated infostealer or credential leak within the preceding year. Those figures are from a secondary summary, so confirm them against Verizon's report before quoting.
The reading that fits both sources: identity is not always the way in, but it is usually the thread attackers pull once inside. That is why it deserves perimeter-level attention.
How Adversary-in-the-Middle Phishing Works
Microsoft's analysis of a multi-stage campaign shows the mechanics clearly.
1. The lure. Phishing emails arrived from a compromised trusted vendor, linking to a fake OneDrive preview.
2. The relay. A lookalike sign-in page collected the victim's credentials and started a real login with the genuine provider. When MFA was requested, a forged page prompted the victim, and the code was relayed in real time.
3. The theft. Once the login completed, the attacker received the session cookie. Microsoft notes that attackers "can then replay the session with the stolen session cookie before the token expiration time," so no further password or MFA prompt is needed.
4. The follow-on. The attacker added a new MFA method to the account, which by default did not require re-authentication, hid incoming mail with an inbox rule, and sent more than 16,000 phishing emails from the compromised mailbox.
The user did everything the policy asked. The control was bypassed by relaying it, not by breaking it.
Why "We Have MFA" Is Not a Finish Line
Not all MFA is equal. CISA has called phishing-resistant MFA "the gold standard" and stated that FIDO standards and the WebAuthn protocol are the only widely available phishing-resistant forms. The reason is design: a FIDO authenticator ties the login to the genuine site's address, so a relayed lookalike page cannot complete it. Codes typed into a screen, whether sent by SMS or generated by an app, can be relayed, as the Microsoft case shows.
Even strong MFA does not protect a session that has already been issued. Once a token exists, whoever holds it is the user, until it expires or is revoked. That is why attackers have moved from passwords to tokens, and why defence must cover the session, not just the sign-in.
Defences That Address the Session
* Phishing-resistant MFA where it matters most. CISA advises rolling it out in phases, starting with high-value targets and services such as hosted mail. Think administrators, finance, and executives.
* Conditional access. Microsoft recommends risk-based policies, compliant-device and trusted-location requirements, and continuous access evaluation, so a token replayed from an unfamiliar device or network is challenged or refused.
* Protect the account's own settings. Require re-authentication to add or change MFA methods. Alert on new inbox rules and forwarding.
* Govern OAuth access. Group-IB's token example is a reminder to inventory third-party app consents, remove unused ones, and limit the scopes granted.
* Respond to the session, not just the password. Microsoft is explicit that remediation means revoking session cookies and rolling back attacker-made MFA changes. A password reset alone leaves the stolen session alive.
Check your suppliers. The DBIR summary reports that only 23% of third-party organisations fully remediated missing or improperly secured MFA on their cloud accounts. Your identity perimeter includes theirs.
How to Test for It
Policy settings describe intent; testing shows behaviour. A scoped, authorised identity test asks:
* Can a relayed login capture a working session? Against test accounts and with approval, does your sign-in flow resist an AiTM-style proxy, or does it hand over a session?
* Does a stolen session replay? If a token is used from a different device and network, does anything notice or block it?
* How long does a token live, and does logging out, changing a password, or disabling an account actually invalidate it?
* Can MFA be changed silently? Does adding a new method demand re-authentication, and would anyone be alerted?
* Who can consent to OAuth apps, and what could a malicious one reach?
* Would you see it? Do monitoring and incident response notice an anomalous session, a new inbox rule, or a mass mailing from a trusted account?
Penetration testing answers the first set: it examines how your applications and identity configuration handle sessions, tokens, and MFA, and where they can be bypassed. Red team testing answers the last: it chains the steps together, from a phishing lure to a stolen session to access inside the business, and measures whether your detection and response teams catch it in time.
Where ILLUME Can Help
ILLUME Intelligence's Penetration Testing service examines authentication, session management, and access control across your applications and cloud identity setup. Our Red Team Testing service runs a realistic, goal-driven attack, including identity-based entry, to show how far an intruder could get and how quickly you would respond. A good starting scope is your most privileged accounts.
The Bottom Line
MFA is still essential, and no one should switch it off. But it protects the moment of login, and attackers have moved to the moment after. Treat identity as a perimeter that needs its own controls: phishing-resistant sign-in for the people who matter most, conditional access around sessions, governed third-party tokens, and a response plan that revokes sessions as well as passwords. Then test it, because a control you have never attacked is one you only assume works.
