Latest / Cybersecurity Business with Fexingo: Security Companies, Breaches, and Enterprise Defense / How Security Teams Are Using Adversary-in-the-Middle Attacks to Test Phishing Defenses
Transcript
- Lucas: So there is a type of phishing attack that scares CISOs more than almost anything right now — and it doesn't steal your password. It steals your session cookie in real time, live, while you're logged in. Luna: Right — the adversary-in-the-middle attack. I've seen it called AiTM for short. And it's basically a proxy that sits between the user and the real website, capturing everything, including the multi-factor authentication token. Lucas: Exactly. The attacker sets up a reverse proxy that looks like your company's Okta or Azure AD login page. The user types their credentials, completes the MFA push or the TOTP code, and the proxy forwards all of that to the real service. The service sends back a session cookie, and the proxy captures it. The attacker now has a valid session without needing to reuse the password or MFA. Luna: And that session cookie is good until it expires — sometimes hours or even days. So the attacker can just replay it from their own browser and they're inside your network as if they were that user. Lucas: Correct. And the scary part is that traditional phishing simulations don't test for this. Most corporate phishing programs send a fake email, and if the user clicks the link and enters their credentials on a training site, they get flagged. But that training site is a static page — it doesn't proxy the real login flow. So users learn 'don't enter your password,' but they don't learn to recognize a page that asks for both password and MFA in a way that feels exactly like the real thing. Luna: So some security teams are now doing the opposite — they're deploying their own adversary-in-the-middle phishing simulations. They're essentially red-teaming their own users with the same tools attackers use. Lucas: That's the shift. Tools like EvilGinx and Modlishka have been around for a few years, and they're open source. Originally built for attackers, but now defenders are standing up their own instances to run controlled tests. The goal isn't to punish users who fall for it — it's to measure whether your conditional access policies actually block the session replay. Luna: Can you give me a concrete example of what they find? I imagine a lot of companies think their MFA is enough, but this attack exposes gaps. Lucas: Yeah. I talked to a CISO at a mid-sized healthcare company who ran an AiTM simulation in Q1 this year. They targeted a group of fifty employees in finance and IT. Twenty-one clicked the link and completed the full login, including MFA. That's a forty-two percent success rate for the simulated attacker. But the real finding came next: the red team tried to replay those twenty-one session cookies from a different IP address — outside the corporate VPN — and nine of them worked. The company had conditional access policies that required MFA from unknown locations, but because the session was already authenticated, the policy didn't re-trigger. Luna: So the MFA was done, but the session token itself didn't carry any location binding. That's a classic gap — session tokens are often treated as 'already verified' so they skip the second check. Lucas: Right. And Microsoft's 2025 Digital Defense Report noted a hundred and forty-six percent increase in adversary-in-the-middle attacks year over year. Attackers are moving to this because it bypasses the most common MFA implementations. So defenders are now adjusting — some are deploying token binding, where the session is cryptographically tied to the device or network. Others are shortening session lifetimes or requiring step-up authentication for sensitive actions. Luna: And the simulation itself — how do you run it without freaking out the whole company? I mean, you're essentially conducting a real attack. Lucas: That's the sensitive part. You need explicit approval from the CISO and legal, and a clear communication plan. Most teams run it as a 'no-blame' exercise — users who fall for it get an immediate training nudge, not a reprimand. And the proxy is configured to only capture the session cookie temporarily for testing, then discard it. You're not actually exfiltrating data. Luna: But the proxy itself — if it's not secured properly — could be a liability. If an attacker compromises your testing infrastructure, they could harvest real credentials. Lucas: That's a real concern. Best practice is to run the proxy in an isolated cloud environment with no production access, and to expire all captured sessions within minutes. Some teams even use a separate tenant for the simulated login page so it never touches the real corporate identity provider. Luna: So the goal is to find the policy holes, not to trick users. But I wonder — does this change the way you train employees? Because the classic advice is 'never click links in emails,' but an AiTM page looks almost identical to the real login. Lucas: It does. And that's why some security awareness programs are shifting from 'don't click' to 'verify the URL even after you've logged in.' Because the proxy often leaves a subtle sign — the URL might have a different subdomain or a missing hyphen. But it's hard. Attackers use certificate-valid HTTPS, so the padlock shows green. Users have been trained to trust the padlock. Luna: Yeah, the padlock is almost meaningless against a well-configured proxy. They can get a valid TLS certificate for their phishing domain. So the real defense has to be at the infrastructure level — conditional access, token binding, short session timeouts. Lucas: Exactly. And more CISOs are starting to require phishing-resistant MFA — like FIDO2 security keys or passkeys — which are immune to proxy attacks because the private key never leaves the device. But rolling that out to tens of thousands of users is a multi-year effort. In the meantime, AiTM simulation gives you a way to test your current controls. Luna: And it's not just for large enterprises. I talked to a startup CISO who used a simple EvilGinx setup on a $20-a-month VPS to test their fifty-person company. They found that their VPN requirement wasn't enforced for web apps accessed via single sign-on. So a stolen session could bypass the VPN entirely. Lucas: That's a great example. The simulation cost almost nothing but revealed a critical policy gap. And that's the kind of finding that justifies the program. I think we'll see more security teams building this into their regular red team rotation — maybe quarterly, not just once a year. Luna: Before we go further — you know, this episode is exactly the kind of practical conversation that listener support keeps alive. If you've gotten something out of these deep dives, a couple of dollars a month makes a real difference. It's the reason we don't run ads. You can find us at buy me a coffee dot com slash fexingo. Just a thought, because we want to keep bringing you these tactical insights. Lucas: Yeah, and it genuinely helps. So, back to the policy side — one of the interesting things is that AiTM simulation also tests your incident response. If a user reports the phishing email, do you have a process to quickly block the domain and check for any compromised sessions? That's another layer the test reveals. Luna: Right — the human element plus the technical response. So you're not just testing the user, you're testing the whole chain: detection, reporting, containment. Lucas: Exactly. And some teams are now combining AiTM simulations with session detection tools. For example, if the red team replays a stolen cookie, the SOC should get an alert for anomalous login — like a user logging in from a new city within minutes. If they don't, that's a detection gap. Luna: So the simulation doubles as a test for your behavioral analytics? That's smart. Lucas: It is. And I think that's where the industry is heading — treating red team exercises as a way to validate the entire defense chain, not just user awareness. AiTM attacks are going to keep evolving, but so are the tools to simulate them. Luna: And for listeners who want to start — any recommendations on open source frameworks? EvilGinx is the most common, but there's also Modlishka and Muraena. Lucas: EvilGinx is probably the easiest to set up for a basic test. It has a good community and documentation. Modlishka is more advanced — it handles multi-page flows and can even proxy JavaScript. I'd start with EvilGinx, run it in a sandboxed environment, and get comfortable with the logging before involving real users. Luna: And never, ever point it at your production environment without a full risk assessment. That's the one rule. Lucas: Absolutely. Isolate everything. But done right, it's one of the most effective ways to understand how an attacker would actually breach your defenses today. Because they're not just stealing passwords anymore — they're stealing sessions.