How do attackers bypass MFA using proxies?

Attackers use Adversary-in-the-Middle (AiTM) tools like Evilginx2 to relay real-time authentication flows, allowing them to capture session cookies and bypass SMS or TOTP-based MFA.

Can FIDO2 prevent AiTM attacks?

Yes, FIDO2 and WebAuthn standards offer inherent protection against proxying because they bind the authentication process to the specific, legitimate origin URL.

Why is MFA proxy detection difficult in India?

Detection is challenging in India due to the widespread use of Carrier-Grade NAT (CGNAT) by ISPs, which causes frequent IP rotations and complicates traditional IP-based reputation scoring.

MFA Proxy Detection: Stop AiTM Attacks & Session Hijacking

Q: What is MFA Proxy Detection?

MFA Proxy Detection is the process of identifying transparent proxies during authentication by analyzing network latency, TLS fingerprints, and specific HTTP headers to prevent session hijacking.

I observed a significant shift in the telemetry of recent phishing campaigns targeting Indian financial institutions. We are no longer seeing simple credential harvesting pages; instead, adversaries are deploying Adversary-in-the-Middle (AiTM) frameworks like Evilginx2 and Muraena, managed via the Starkiller interface. These setups do not just steal passwords; they proxy the entire authentication flow in real-time, capturing the session cookie (Session Token) and effectively bypassing Multi-Factor Authentication (MFA).

Understanding MFA Proxy Detection: Why It’s Critical for Modern Security

The fundamental flaw in traditional MFA—whether it is SMS-based OTP or standard push notifications—is that it validates the user's identity but not the integrity of the connection path. When an attacker sits in the middle, they relay the legitimate site's challenge to the user and the user's response back to the site. Once the "Set-Cookie" header is issued by the legitimate service, the proxy intercepts it.

What is MFA Proxy Detection?

MFA Proxy Detection involves identifying the presence of a transparent proxy during the authentication phase. We look for discrepancies in network latency, mismatched TLS fingerprints, and the presence of specific HTTP headers that reveal the relay. In our testing, we found that even high-end residential proxies used by sophisticated groups leave traces in the TCP handshake and the HTTP request headers.

The Evolution of Multi-Factor Authentication Vulnerabilities

Traditional MFA was designed to stop credential stuffing. However, the commoditization of AiTM toolkits has moved the goalposts. Attackers now use these proxies to bypass:

SMS OTPs
Time-based One-Time Passwords (TOTP) like Google Authenticator
Push-to-Accept notifications

Only FIDO2/WebAuthn standards, which bind the authentication to the specific origin URL, offer inherent protection against this proxying.

Why Traditional MFA is No Longer a Silver Bullet

In several Red Team engagements, I have successfully bypassed MFA by simply sending a convincing phishing link that points to a server running an Empire agent managed by Starkiller. The user sees a perfect replica of the Microsoft 365 or Google login page because they are actually interacting with the real page through my proxy. Those looking to master these offensive tactics can find specialized training in our Academy. The session is hijacked before the user even realizes they have been compromised.

How Attackers Use Proxies to Bypass MFA

The mechanism relies on T1557.002 (Adversary-in-the-Middle: Transparent Proxy). The attacker hosts a "phishlet" that mirrors the target's login flow. When the victim enters their credentials, the proxy forwards them to the real service. When the real service asks for MFA, the proxy forwards that request to the victim.

Adversary-in-the-Middle (AitM) Attacks Explained

The proxy acts as a bridge. If the user is logging into portal.office.com, the attacker might use a domain like portal-office-com.security-update.in. The proxy handles the SSL termination and re-encryption. During this process, we can detect the proxy by looking for certificate issuer mismatches. We tested this using the following command to inspect the certificate chain of a suspected phishing URL:



$ openssl s_client -connect portal-office-com.security-update.in:443 -showcerts | openssl x509 -noout -issuer -dates
Output:
issuer=C = US, O = Let's Encrypt, CN = R3
notBefore=Oct 12 08:00:00 2023 GMT
notAfter=Jan 10 08:00:00 2024 GM

T

If the legitimate service (e.g., Microsoft) typically uses its own CA or a specific high-assurance provider, a "Let's Encrypt" certificate on a login portal is a high-fidelity indicator of an AiTM setup.

The Role of Transparent Proxies in Session Hijacking

The ultimate goal is the session cookie. Once the user completes the MFA, the legitimate server sends a session token. The proxy captures this and logs it into the Starkiller console. We observed that attackers then immediately inject this cookie into a headless browser to gain access to the account, often before the victim has even finished their initial redirect.

Residential vs. Data Center Proxies: Which Pose the Greatest Risk?

Data center proxies (AWS, Azure, DigitalOcean) are easy to block via IP reputation. However, attackers are increasingly using residential proxy networks (like Luminati or Oxylabs) to mask their origin. In the Indian context, we see attackers using residential IPs from local ISPs like Hathway or Alliance Broadband to bypass "Impossible Travel" rules, as the IP appears to be from the same city as the victim.

Core Technologies Behind MFA Proxy Detection

Detecting these proxies requires a multi-layered approach that goes beyond simple IP blacklisting. We focus on the "fingerprint" of the connection itself, much like the techniques used for implementing SIEM rules to detect crypto-stealing C2 traffic.

IP Intelligence and Reputation Scoring

We integrate feeds from services that track known proxy exit nodes. However, for residential proxies, we must rely on ASN (Autonomous System Number) analysis. If a login originates from an ASN associated with a data center but the User-Agent suggests a mobile device on a cellular network, we flag it.

Detecting Proxy Headers and VPN Signatures

Many proxies, even transparent ones, may inadvertently leak headers or alter the standard header order. We use nmap to scan suspected phishing IPs for common proxy indicators:



$ nmap -p 443 --script http-headers --script-args='http-headers.useget=true' 
Look for:
X-Forwarded-For
X-Real-IP
Via
Proxy-Connectio

n

If any of these headers appear in a response from what should be a primary authentication endpoint, it is a confirmed proxy.

Behavioral Biometrics and User Pattern Analysis

We monitor the speed of form completion. Automated scripts or proxy-mediated interactions often show "inhuman" timing. For example, the delay between entering a password and submitting an MFA code is often suspiciously consistent or extremely low when an automated relay is involved.

Network Latency and Round-Trip Time (RTT) Triangulation

An AiTM proxy adds a measurable delay to the TCP handshake. By measuring the RTT between the client and the server, and comparing it to historical baselines for that user's region (e.g., Mumbai to Chennai), we can detect the presence of an intermediate hop.

The Benefits of Implementing Real-Time Proxy Detection

Implementing these checks at the point of authentication significantly reduces the window of opportunity for attackers using Starkiller.

Preventing Account Takeover (ATO) Before It Happens

By identifying the proxy during the initial GET request to the login page, we can terminate the session before the user even enters their password. This prevents the attacker from even obtaining the initial credentials, let alone the MFA token.

Reducing Fraud-Related Costs and Compliance Risks

Under the DPDP Act 2023, Indian organizations are liable for data breaches resulting from inadequate security measures. Implementing MFA proxy detection demonstrates technical due diligence. A single session hijack can lead to unauthorized access to PII, resulting in fines that could reach ₹250 crore under the new regulations.

Enhancing User Trust Without Increasing Friction

Detection happens at the network and protocol level. Unlike "Number Matching" which requires user interaction, proxy detection is invisible. It allows legitimate users to pass through while silently blocking or challenging suspicious connections.

Challenges in Modern MFA Proxy Detection

The cat-and-mouse game between researchers and attackers is particularly intense in the proxy space.

The Difficulty of Identifying Sophisticated Residential Proxies

Advanced attackers use "backconnect" residential proxies. The IP the server sees is a legitimate home broadband connection in India, but the traffic is being routed from an attacker in a different country. This makes geo-fencing useless.

Balancing False Positives with Security Rigor

In India, major ISPs like Jio and Airtel use Carrier-Grade NAT (CGNAT). This means thousands of users might share a single public IP, and that IP might change frequently as the user moves between cell towers. SIEM rules that trigger on "IP Rotation" or "New IP" often generate excessive noise.

Adapting to Evolving Proxy-in-the-Middle (PitM) Frameworks

Frameworks are now incorporating TLS fingerprinting obfuscation. They can mimic the JA3 fingerprint of the victim's browser, making it harder to detect the proxy by looking at the SSL handshake. We must pivot to analyzing the HTTP/2 frame priority or window size settings, which are harder to spoof.

Best Practices for Deploying MFA Proxy Detection Solutions

We recommend a tiered approach to detection, starting with the most common indicators and moving to advanced behavioral analysis.

Integrating Detection into the Authentication Workflow

Your Identity Provider (IdP) should consume risk scores from your network security stack. If a connection is flagged as a "High Risk Proxy," the IdP should automatically upgrade the MFA requirement to a FIDO2 hardware key or deny the request entirely.

Utilizing Adaptive Authentication Based on Risk Scores

We use Sigma rules to detect session anomalies in Microsoft 365 logs. Integrating these into a centralized SIEM allows for real-time alerting. Here is a configuration we developed to identify potential session reuse from an AiTM attack:


title: MFA Proxy Bypass via AiTM (Session Cookie Reuse) logsource:   product: m365   service: signinlogs detection:   selection:     Status.errorCode: 0   filter_ips:     condition: selection | count(IPAddress) by UserId > 1   timeframe: 10m   condition: filter_ips fields:   - UserPrincipalName   - IPAddress   - DeviceDetail.browser falsepositives:   - Users switching from Corporate WiFi to Mobile Data (CGNAT) level: high

Continuous Monitoring Post-Login to Prevent Session Theft

Detection shouldn't stop at login. We monitor for "Session Jumping," where a valid session cookie is suddenly used by a different User-Agent or from a different ASN within minutes of the initial login. This is a classic sign that an attacker has imported the stolen cookie into their own browser.

The Indian Context: CGNAT and Localized Targeting

Indian infrastructure presents unique challenges. CERT-In has recently issued advisories regarding the targeting of Indian critical infrastructure via phishing. Attackers are specifically tailoring phishlets for Indian banks (ICICI, HDFC, SBI) and government portals.

The prevalence of CGNAT means we cannot rely on IP addresses as a primary identifier. I have observed cases where a user's IP changes three times during a single session on a mobile network. In these environments, we prioritize:

JA3/JA3S Fingerprinting: Identifying the specific SSL/TLS client library.
Browser Fingerprinting: Canvas rendering and font enumeration.
App-level Heartbeats: Monitoring for consistent session persistence from the same device ID.

The Future of MFA: Moving Beyond Simple Detection

As long as we rely on "shared secrets" (even temporary ones like OTPs), proxies will remain a threat.

The Shift Toward Passwordless and FIDO2 Standards

The industry must move toward FIDO2. By using public-key cryptography and origin binding, FIDO2 ensures that the browser will only provide the authentication credential to the specific domain it was registered for. An AiTM proxy at portal-office-com.security-update.in will fail because the browser will refuse to sign the challenge for a domain that is not portal.office.com.

AI and Machine Learning in Predictive Threat Detection

We are training models to recognize the "shape" of proxy traffic. This includes analyzing the inter-packet arrival times. A proxying operation introduces micro-delays that follow a specific pattern compared to a direct connection to a CDN-backed site.

Building a Zero Trust Architecture with Proxy Awareness

Zero Trust is not just about "who" but "how." A connection from a verified user, using a verified device, should still be treated as untrusted if the underlying transport shows signs of proxying. Implementing a zero-trust terminal ensures that even if a session is hijacked, the attacker cannot move laterally. We are moving toward a model where the "Transport Integrity" is a mandatory claim in the OIDC (OpenID Connect) flow.

Technical Deep Dive: Analyzing the Attack Surface

To understand the threat, we must look at how CVEs are chained to deliver these proxies. For instance, CVE-2024-21413 (Microsoft Outlook Remote Code Execution) can be used to send a malicious link that, when clicked, doesn't just execute code but redirects the user to an AiTM landing page.

In another scenario, CVE-2023-38177 (Windows SharePoint Server Elevation of Privilege) allows an attacker to gain an initial foothold in an Indian SME's network. From there, they deploy an Empire agent. The Starkiller GUI then allows the attacker to manage multiple victims who have been redirected to the MFA proxy.

Analyzing Traffic with tcpdump

When we suspect a proxy is active on the network, we use tcpdump to capture the initial GET requests and look for anomalies in the HTTP headers:



$ tcpdump -i eth0 'tcp port 443 and (tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x47455420)' -

A

We are looking for the User-Agent string. If it matches a standard Windows Chrome agent but the TCP window size is characteristic of a Linux-based proxy server, we have a mismatch.

Verifying Cookie Integrity

Finally, we can use curl to inspect how cookies are being set by a suspected phishing site. Attackers often fail to properly replicate all cookie attributes, such as SameSite or Secure flags, or they might add their own tracking cookies to manage the session on their end.



$ curl -I -L --user-agent 'Mozilla/5.0'  | grep -i 'Set-Cookie

'

If you see multiple Set-Cookie headers that don't match the legitimate site's known patterns, or if the domain attribute of the cookie is being set to the attacker's domain, the proxy is active.

Next Command: Monitor your IdP logs for UserAgent strings that contain HeadlessChrome or Electron associated with successful logins; these are often the first signs of an automated session takeover following a successful MFA proxy bypass.