The headline shift over the last 18 months in phishing operations is that adversary-in-the-middle (AitM) tooling is now commodity. Frameworks that used to require a skilled operator now ship as turnkey services with documentation, support, and a recurring subscription model.
For defenders, the practical consequence is that multi-factor authentication on its own is no longer a sufficient mitigation against credential-targeted phishing. Tokens are stolen alongside passwords through a reverse-proxy interception of the real authentication flow, replayed within minutes, and used to establish persistence before any human notices.
Detection layers have to look for replay signals — impossible-travel events, unusual user-agent strings, session-token reuse from new networks — rather than relying on the initial authentication event as the trust anchor. The shift is from "detect the phish at delivery" to "detect the misuse of stolen artefacts after authentication".
Microsoft has acknowledged this shift in their Entra documentation and product roadmap. Conditional Access policies that include device-compliance signals, sign-in risk evaluation, and continuous access evaluation are now the recommended baseline. Most organisations we work with have not yet completed the migration to this baseline.
On the training side, the message to employees has evolved. "Check the URL" was always weak advice — URLs are easy to typosquat and easier to obscure — but in an AitM world the URL the user sees during sign-in is genuinely the real Microsoft sign-in page, reverse-proxied. The user's URL bar inspection will reveal a wrong domain only if they explicitly check the registrable component and recognise the deviation. Most users will not.
What works better as a training message: "expect, recognise, and report." Expect that legitimate access requests originate from systems and contexts you have used before. Recognise unfamiliar prompts ("why is this asking me to sign in to Microsoft again?") as worth attention. Report through a single low-friction channel.
The reporting message is especially important in the AitM context. If the user authenticates through the phishing infrastructure but reports it within minutes, the SOC has a short window to revoke the session before the attacker can act on the stolen token. We have observed successful revocation windows as tight as four minutes in client engagements; we have also observed unreported tokens used productively for weeks.
Practical implications for awareness curricula: less time on URL-inspection content, more time on the "this feels unusual" signal and the reporting workflow. Practical implications for simulation programmes: include scenarios that test what happens after credential capture, not just whether the user clicked the link.
We are increasingly running AitM-aware simulation engagements where the simulated infrastructure mimics token-capture flow (without actually capturing tokens) and the success metric is reporting time post-authentication rather than click-rate. The metrics tell a different story than traditional simulation; the clients we have run them with consistently say the new story is more useful.