0x01 Fundamentals: Capturing Credentials and Session Cookies via AiTM

Technical Analysis

Why the proxy needs its own TLS certificate. The proxy domain terminates TLS itself before forwarding the request to the real target, so it needs a certificate of its own — it cannot simply reuse or forward the target's certificate. Managed TLS (Let's Encrypt-style ACME issuance) requires the domain to be publicly resolvable and reachable, which a local .pclabs zone pointing at 127.0.0.1 is not. Self-signed certificates are the correct fit for an isolated lab: confirmed by testing with curl -vk, which completed a full TLS 1.3 handshake against the proxy once self-signed certificates were enabled, returning a certificate whose CN matched the proxy domain.

Why credential capture targets the request body, not the response. The login form posts email and password as application/x-www-form-urlencoded data in the POST /login request body — this is the only place those values exist in plaintext on the wire, so the urlencoded capture engine reading from: request_body is the correct mechanism, confirmed directly in the campaign's event log.

Why the session capture targets the response's Set-Cookie header. The l1_session cookie is issued by the target application in the response to a successful POST /login, not in the request — the cookie capture engine reads it from there. This is the value that actually keeps the browser authenticated, independent of the credentials that produced it; it is what Session Sushi later needs to replay the session.

access: mode: private as an anti-scanning control. Confirmed through direct curl testing: a request to the proxy's root path with no valid recipient identifier returned a generic 404 page not found from Phishing Club itself, not from the proxied target. This indicates the AiTM proxy will not reveal the phished page at all unless the request carries a valid, campaign-bound recipient token — a deliberate control to keep the live phishing page hidden from automated scanners, link-preview bots, and anyone probing the domain without a valid lure link.

What I Learned

• Credentials and session cookies are captured from different parts of the HTTP exchange. Credentials live in the request body of the login POST; the session cookie lives in the response headers after a successful login. A capture configuration needs both directions covered.

• A session cookie is a complete authentication bypass on its own. Once l1_session was imported into a clean browser profile, no password was needed at all — the cookie alone was sufficient to reach the authenticated dashboard.

• Domain names in AiTM tooling should always be lowercase. Browsers never send a Host header in anything but lowercase, so any case mismatch in the proxy configuration silently breaks matching.

• A "page not found" from the AiTM platform can be a feature, not a bug. Before assuming a broken proxy mapping, it's worth checking whether an access-control setting (like private mode) is intentionally hiding the page from non-campaign traffic.

• curl --resolve is a fast way to isolate DNS, TLS, and routing issues from browser-specific behavior — it let me confirm TLS handshake success, response codes, and exact response bodies independently of browser caching or extension interference.

Defensive Takeaways

• Session cookie attributes alone do not stop AiTM. HttpOnly, Secure, and SameSite=Lax prevent JavaScript-based theft and most cross-site attacks, but they do nothing against a reverse-proxy AiTM attack, because the victim is talking directly to the attacker's server, which legitimately receives the Set-Cookie response and can simply read it.

• Phishing-resistant MFA is the actual mitigation. FIDO2/WebAuthn binds the authentication ceremony to the origin the browser is actually talking to, so a proxied domain cannot complete it on the victim's behalf — unlike OTP or push-based MFA, which an AiTM proxy can relay through transparently.

• Monitor for anomalous domains resembling internal or SaaS login portals. Certificate Transparency log monitoring (e.g. via crt.sh) can surface newly issued certificates for lookalike domains before a campaign goes live.

• Session/token lifetime and binding matter more than cookie flags. Shortening session lifetimes and binding sessions to additional signals (IP consistency checks, device fingerprinting, re-authentication for sensitive actions) reduces the value of a stolen session cookie even if one is captured.

Conclusion

This first lab established the full AiTM loop end to end: a proxy configuration that captures both credentials and a live session cookie, and a replay step that proves the stolen session is immediately usable without ever touching the victim's password again. Most of the real learning came from the troubleshooting along the way — TLS configuration, Start URL correctness, access-mode behavior, and domain case-sensitivity — all things that don't show up until you actually run the attack against a live proxy. The next lab in this series builds on this foundation with a more complex authentication flow.