What are the signs that an AiTM phishing kit is being used against an organisation?

Why AiTM Phishing Kits Matter for Authentication Defences

An adversary-in-the-middle kit changes phishing from simple credential capture into live session interception. That matters because the user may complete a valid login while the attacker captures tokens, cookies, or post-authentication traffic, which can bypass MFA if the session is already established. For defenders, the signal is not just a bad-looking login page, but evidence that the authentication journey itself has been proxied or manipulated. NIST’s SP 800-53 Rev 5 Security and Privacy Controls remains useful here because the issue is as much authentication assurance and monitoring as it is email hygiene. In practice, many security teams first notice AiTM activity only after a legitimate user reports an account problem or after abnormal session use has already started.

How AiTM Activity Shows Up Across the Login Flow

AiTM kits are often easiest to spot when you trace the user journey end to end rather than looking at any single indicator in isolation. A lure may begin with a message that pushes urgency, then redirect the user through a lookalike domain, then present an intermediate challenge page, and finally proxy the real identity provider so the victim sees a normal login. If the kit succeeds, the attacker receives whatever the browser sends after authentication, which is why session persistence and cookie handling become central to detection.

Operationally, defenders should look for patterns that are unusual at the edge and in the identity plane at the same time. Examples include clustered domain registrations, redirect chains that are longer than expected, generic hosting or challenge infrastructure sitting between the lure and the target site, and authentication events that do not match the user’s normal device, location, or timing profile. A useful clue is when traffic shape changes after the user submits credentials, because that often indicates the kit is switching from lure delivery to live proxying.

• Email and QR-based lures that lead to a brand-matched login page instead of the expected service.
• Challenge pages, redirectors, or filter pages placed in front of the real login flow to evade automated scanning.
• Successful authentication followed by suspicious session reuse, token replay, or impossible travel-style access.
• Domains and infrastructure that are short-lived, recently registered, or reused across multiple campaigns.

Where teams get this wrong is treating the fake page as the entire problem. In reality, the page is only the delivery mechanism; the real compromise signal is often visible in the authentication telemetry that follows the user’s submission.

When the Usual Warning Signs Are Not Enough

Tighter inspection of login traffic often increases analyst workload, requiring organisations to balance early detection against false positives from legitimate proxies, privacy tools, and regional delivery services. Not every redirect or challenge page is malicious, and not every abnormal sign means the same kit is in use.

One common edge case is that some enterprise services legitimately place users behind challenge or reputation-based filtering, which can resemble an AiTM proxy at a glance. Another is that a user may truly log in from a new device or new geography, so a single anomalous sign should not be over-interpreted. The strongest view is contextual: combine lure characteristics, domain age, redirect behaviour, and post-login session anomalies before concluding that an AiTM kit is operating. There is no consensus that any one indicator is sufficient on its own, especially in organisations with heavy use of remote access, mobile devices, or outsourced identity workflows.

For this reason, teams should treat AiTM detection as a correlation problem rather than a signature problem. If the evidence only shows a suspicious landing page but no authentication anomaly, confidence should stay low. If the evidence shows a normal-looking login paired with immediate token reuse or session drift, concern rises sharply.

Risk and Threat Considerations

The material risk is session theft after a user has already authenticated, which allows an attacker to bypass the protection that MFA would normally provide. AiTM kits are designed to abuse trust in the browser session, not just the password exchange, so the compromise can look legitimate until the session is reused elsewhere.

Failure mechanism: The attacker proxies the login in real time, captures the resulting session artefact, and replays it from a separate environment. Detection fails when monitoring is focused on password events alone and does not correlate the user’s authentication, device context, and subsequent session use.

Impact: An attacker can gain access to email, SaaS applications, identity portals, and downstream systems that trust the stolen session, creating rapid account takeover and lateral abuse opportunities.

Practitioner Guidance

What to prioritise: Correlate suspicious lure activity with post-authentication behaviour. A convincing lookalike page matters, but the decisive evidence is usually what happens immediately after login, especially session reuse from a different context.

What to verify: Check whether the suspicious domain was recently registered, whether the redirect chain is unusually long, and whether the user’s authenticated session is being reused from a device, ASN, or geography that does not match normal access patterns.

What good looks like: Mature detection links email security, web telemetry, and identity logs so a single phishing event can be evaluated as a full attack chain rather than as isolated alerts. That is the difference between spotting a lure and spotting a takeover in progress.

Practitioner takeaway: The most reliable AiTM signal is not the fake page itself, but the combination of a proxy-like login path and an authenticated session that behaves as if it was issued to someone else.

Related resources from NHI Mgmt Group

• What are the signs that an organisation’s identity controls are failing against attacker-in-the-middle phishing?
• What are the signs that deepfake phishing is being used against an organization?
• What are the signs that credential dumping is already being used against an organisation?
• Should organisations rely on MFA alone against AITM phishing?