Man-in-the-middle phishing

Expanded Definition

Man-in-the-middle phishing is a live relay attack that sits between a user and the legitimate service, proxying the login experience so the victim believes the session is authentic. Unlike static credential theft, it captures passwords, session tokens, and authentication prompts in real time, which is why conventional MFA can be bypassed when the attacker relays the challenge as it happens. Guidance varies across vendors on whether this should be treated as a phishing subtype or as a session hijacking technique, but the operational pattern is the same: the attacker owns the channel, not the account.

In NHI and IAM environments, the term matters because the same relaying technique can be used against admin portals, SSO flows, developer consoles, and machine-access workflows that reuse human authentication steps. The control objective is not just stronger authentication, but phishing-resistant authentication, token binding, and transaction context that cannot be cleanly replayed. NIST CSF 2.0 frames this through protective access controls and identity assurance, while the NIST Cybersecurity Framework 2.0 reinforces the need to harden authentication pathways. The most common misapplication is treating successful MFA as proof of safety, which occurs when the login ceremony is relayable and the session remains reusable after capture.

Examples and Use Cases

Implementing defenses against man-in-the-middle phishing rigorously often introduces user friction and integration work, requiring organisations to weigh phishing resistance against rollout complexity and legacy compatibility.

• A user clicks a convincing sign-in link, enters credentials into a proxy page, and the attacker forwards the login to the real IdP, capturing a session cookie after MFA completes.
• An attacker targets a developer portal that issues API keys after browser-based SSO, then uses the stolen session to mint secrets and pivot into CI/CD systems. This is especially dangerous when secrets are already exposed across tooling, a pattern highlighted in Ultimate Guide to NHIs.
• A cloud admin authenticates through a cloned page that relays the challenge to the true tenant console, enabling the adversary to modify role assignments before the session ends.
• An organization deploys phishing-resistant authenticators and origin-bound sessions for high-risk users, aligning with the access hardening direction reflected in NIST Cybersecurity Framework 2.0.
• A machine operator uses a human-facing login flow to approve an automation dashboard, allowing a relay attack to capture both the human session and downstream NHI credentials.

Why It Matters in NHI Security

Man-in-the-middle phishing is not only a human credential problem. In NHI security, it often becomes the entry point for stealing API keys, service account access, and privileged cloud sessions that were reachable only after a browser login. That matters because NHIs already represent a major governance gap: NHI Mgmt Group reports that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, and 90% of IT leaders say proper NHI management is essential for successful zero-trust implementation in the Ultimate Guide to NHIs. Once a relay attack succeeds, the attacker can move from a human login to durable machine access, making token lifecycle controls, rotation, and offboarding immediately relevant.

This is where governance breaks down if organizations focus only on password resets and ignore the downstream secrets issued during the compromised session. Practical defenses include origin-aware authentication, phishing-resistant MFA, short-lived tokens, and rapid invalidation of any secrets minted after suspicious login activity. Organisations typically encounter the full operational cost only after a session has been hijacked and a service account or API key has already been issued, at which point man-in-the-middle phishing becomes an incident response and NHI containment problem.

Related resources from NHI Mgmt Group

• Why do phishing-resistant methods still fail against man-in-the-middle attacks?
• Why do phishing-resistant credentials reduce man-in-the-middle risk?
• How should security teams reduce man-in-the-middle risk in IAM environments?
• Why do man-in-the-middle attacks still succeed when HTTPS is enabled?