What are the signs that a phishing campaign is using an attacker-in-the-middle kit to steal session access?

Why Attacker-in-the-Middle Kits Leave Visible Clues

An attacker-in-the-middle phishing kit is designed to do more than collect a password. It proxies the victim’s real login flow so the attacker can capture the live session, token, or cookie that follows successful authentication. That means the page often has to look convincing to a person while also behaving selectively enough to avoid casual inspection and automated scanning.

Common signs include a landing page that is visually close to the real service but not actually hosted on the service’s domain, small domain changes that exploit lookalikes, and flow-control tricks such as only loading when opened from a specific redirect, ad click, or referral chain. Those behaviours matter because they are often part of the kit’s anti-analysis design, not just poor implementation. A page that fails or redirects oddly when opened directly is especially suspicious when the rest of the campaign appears polished.

For defenders, the important distinction is that the goal is not merely credential theft. The attacker wants the authenticated browser state that lets them bypass MFA enforcement after the fact. In practice, many security teams first notice the campaign only after a valid session is reused from an unexpected location, rather than while the phishing page is still active.

How the Kit Behaves During the Login Flow

These kits typically sit between the user and the real service, forwarding the username, password, MFA challenge, and final session material to the attacker in near real time. That proxy behaviour creates several observable patterns. The page may load external assets inconsistently, mirror the legitimate branding only on the first visit, or break when security tools request the URL without the expected browser context. Some kits also gate the page behind IP, geolocation, or referer checks so analysts do not see the same content the victim sees.

A practical review should focus on whether the page is trying to prove a human path before it reveals anything useful. If it only functions after an ad click, a shortened link, or a redirect chain, the operator is likely trying to separate victims from scanners. If the page then hands off to a real authentication service or immediately repeats the user’s credentials into a second domain, that is consistent with real-time relay rather than a simple fake login form.

• Check whether the visible page domain matches the organisation’s real authentication domain exactly.
• Inspect redirect chains, not just the final landing page, because relay kits often hide the malicious hop upstream.
• Compare page behaviour from a fresh browser session, a direct URL entry, and an isolated analysis environment.
• Look for MFA prompts that behave normally for the user but are being relayed to the attacker in the background.

When this pattern is present, the decisive clue is usually not one artifact but the combination of lookalike branding, flow restrictions, and a live authentication relay that only appears to work for a real user. These controls tend to break down when the kit depends on dynamic browser context, because automated inspection and direct navigation expose the mismatch between the bait page and the real service.

Edge Cases That Make Detection Harder

Tighter evasion controls often make these campaigns look less like classic phishing and more like selective web gating, which increases analyst effort. Some kits reuse legitimate cloud hosting, content delivery services, or carefully registered domains, so a domain reputation check alone is not enough to distinguish them from benign infrastructure.

Current guidance suggests treating the strongest indicators as behavioural rather than visual. A convincing login page is expected; what matters is whether the page resists analysis, enforces a specific visit path, or fails to behave consistently across sessions. A campaign can also be noisy in one phase and quiet in another, so an isolated observation should be weighed against the full chain: lure, redirect, login proxy, and session reuse.

Where teams get caught out is assuming MFA means the account is safe once the password is entered. An attacker-in-the-middle kit is built to capture the result of successful MFA, so the real warning sign is not only a fake page, but any workflow that turns a normal sign-in into a relay opportunity.

Risk and Threat Considerations

The material risk is session theft after authentication, which can defeat MFA and give the attacker access that looks like a legitimate user. This is especially dangerous when the harvested session reaches email, SaaS, admin portals, or identity consoles, because the attacker may not need the password again.

Failure mechanism: The kit proxies the login in real time and captures the issued session cookie or token after the victim completes MFA. Anti-analysis gating, referer checks, and redirect tricks reduce the chance that defenders or automated tools see the same flow as the victim, which delays detection.

Impact: The attacker can reuse the live session, bypassing the protected login step, and can often move directly into mailbox abuse, data theft, account takeover, or privilege escalation depending on what the session can reach.

Practitioner Guidance

What to prioritise: Treat any suspicious login page with path gating, unusual redirects, or direct-access failures as a session-theft investigation, not just a phishing report. The important question is whether the page is harvesting credentials or relaying a live authentication flow into an attacker-controlled session.

What to verify: Validate the full browser path, including referrers, redirects, and post-authentication behaviour. If the page only works from a specific lure path and then hands the user into a real sign-in sequence, assume the kit is trying to capture the authenticated browser state rather than only the password.

Practitioner takeaway: The most important signal is not how convincing the fake login page looks, but whether it is shaping the victim’s browser path to capture a usable session after MFA succeeds.

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 a phishing campaign is using DLL sideloading to deliver malware?
• What are the signs that a trojan is using persistence and command retrieval to stay hidden?
• What are the signs that session management is failing in a web application?