Adversary-in-the-Middle (AitM) phishing frameworks like Evilginx3, Muraena, and Modlishka have fundamentally transformed the economics of credential harvesting. Rather than cloning static HTML login pages, modern threat actors proxy genuine HTTP traffic between the victim and the legitimate banking portal in real time.
How AitM Proxies Bypass Multi-Factor Authentication#
When a victim clicks an AitM phishing link:
◆
The proxy server forwards the victim's requests to the real corporate identity provider (IdP) or banking endpoint.
◆
The authentic server generates an SMS OTP challenge, which the proxy displays to the victim.
◆
The victim inputs their valid 6-digit OTP.
◆
The proxy submits the OTP to the legitimate server, successfully completing authentication.
◆
The legitimate server issues an authorized HTTP session cookie (e.g.,
ASP.NET_SessionId, JSESSIONID, or JSON Web Token).◆
The proxy intercepts the
Set-Cookie response header, saves the authenticated token into a database, and redirects the victim to a decoy confirmation page.With the harvested session token, the attacker imports the cookie directly into their browser, bypassing credentials and OTP validation entirely.
Mitigating AitM with FIDO2 / WebAuthn Hardware Authentication#
The only cryptographically resilient defense against AitM transparent proxies is FIDO2 / WebAuthn (Passkeys / Hardware Tokens):
◆
FIDO2 authenticators bind cryptographic signatures to the browser's current TLS origin domain (
window.location.origin).◆
If an attacker hosts the proxy on
secure-bank-login-verify.in, the hardware token generates a signature for the fake domain.◆
When the proxy passes this signature to
bank.com, the bank's cryptographic verification fails immediately because of the domain origin mismatch.DESCAM RESEARCH TEAM