They work because the attacker is not trying to crack the code. Instead, the phishing site relays the live username, password, and OTP to the real service as the victim submits them, then captures the resulting session. That makes MFA weaker when the factor is phishable, since the attacker can authenticate as the user in real time.
Why the OTP Does Not Break the Attack Chain
An adversary-in-the-middle kit succeeds because it turns a login page into a live relay, not because it can guess or defeat the one-time passcode. The victim types valid credentials into a counterfeit page, and the kit forwards them to the real service in real time. If the service accepts the OTP, the attacker receives the resulting authenticated session and can reuse it before it expires.
The core weakness is that the factor is phishable and the attack happens inside the authentication transaction. A one-time code is still useful against passive theft, but it does not help when the attacker can observe and forward the code as it is entered. This is why phishing-resistant authenticators matter more than any factor that can be copied, proxied, or replayed in-session.
That pattern is consistent with documented credential and session theft campaigns, including attacks that use a real service as the ultimate verifier while the phishing layer only acts as a man-in-the-middle. See MITRE ATT&CK Enterprise Matrix for credential access and session theft patterns, and NIST SP 800-63 Digital Identity Guidelines for phishing-resistant authenticator guidance.
What Makes Adversary-in-the-Middle Kits So Reliable
These kits are effective because they compress the gap between authentication and session issuance. Once the victim completes login, the attacker does not need to solve MFA again, they inherit the live session, cookies, or tokens that the service issues after successful verification. That makes the attack especially effective against workflows where the session is long-lived or where the application treats an authenticated browser state as proof of trust.
They also exploit user expectations. The login page looks normal, the OTP prompt appears normal, and nothing obviously fails during the exchange. From the user’s point of view, the session often behaves like a successful login, which reduces suspicion until the attacker starts using the account. CISA cyber threat advisories regularly reflect this broader pattern of credential theft, session abuse, and follow-on compromise in real-world intrusions.
For practitioners, the key distinction is between authentication strength and phishing resistance. A second factor can improve assurance and still remain vulnerable if the attacker can capture and relay it live. The control question is not simply “Was MFA used?” but “Could the authenticator be proxied without breaking the login flow?”
What to Verify in Practice
What to verify: Confirm whether your highest-risk logins rely on phishable factors, especially OTP-based flows that do not bind the authenticator to the origin, device, or transaction. If a successful login can immediately create a reusable browser session, the attacker’s objective shifts from stealing the code to stealing the session.
Decision rule: If the account protects privileged, customer, financial, or administrative access, treat OTP-only resistance as insufficient against adversary-in-the-middle tooling and prioritise phishing-resistant methods such as FIDO2/WebAuthn. If you still allow OTPs, pair them with tighter conditional access, session controls, and rapid detection of unusual token issuance or impossible travel.
What good looks like: The login path should make real-time relay materially harder, session replay should be constrained, and suspicious authentication should produce signals that security teams can investigate before the session is abused. For a broader control baseline, OWASP API Security Top 10 and NIST Cybersecurity Framework 2.0 help teams align authentication weakness with downstream account and session protection.
Practitioner takeaway: If an attacker can relay the login in real time, the OTP is being validated by the service, not protecting the user. The practical defence is to remove the attacker’s ability to proxy trust, then watch for session theft as aggressively as you watch for password compromise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST SP 800-63, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Phishing-Resistant Authenticators — Phishing-Resistant Authenticators | Directly addresses OTP relay weakness and authenticator binding. |
| Recommendation — Prefer phishing-resistant authenticators for high-value logins. | ||
| MITRE ATT&CK | T1557 — Adversary-in-the-Middle | Models live relay phishing used to capture credentials and sessions. |
| Recommendation — Map relay-phishing detections to Adversary-in-the-Middle techniques. | ||
| NIST CSF 2.0 | PR.AA — Identity Management, Authentication, and Access Control | Covers authentication controls and session trust decisions behind the attack. |
| Recommendation — Harden authentication and session controls for privileged access. | ||
| CIS Controls v8 | 5 — Account Management | Supports account and session protection after credential capture. |
| Recommendation — Limit account exposure and review high-risk access paths regularly. | ||
Related resources from NHI Mgmt Group
- Why do adversary-in-the-middle phishing kits continue to succeed against cloud identities even when multifactor authentication is enabled?
- Why do attacker-in-the-middle phishing kits remain so effective against SaaS and identity workflows?
- Why do automated crypto phishing operations remain effective even when users and security tools are alert to the threat?
- Why do advanced phishing kits remain effective even against standard email and login defenses?
