How AiTM Attack Works at the level of an HTTPsession
Before you getinto the tools, you need to understand what is happening at theprotocol level. AiTM is not a page clone or a screenshot of the loginform. This is a complete reverse proxy that condoms, whichconterifies a TLS connection on both sides.
According to MITREATT&CK, this is a combination of three tactics:Adversary-inthe-Middle (T1557), credential-access/collection), StealWeb Session Cookies (T1539), credential-access) and ModifyAuthentication Process: Multi-Factor Authentication (T1556.006,credential-access/defesting/defense/peresistence). Delivery - throughSpearphishing Link (T1566.002, initial-access).
Here’s whathappens when a typical Microsoft 365 attack:
1. The victimreceives a letter with reference. Often this is not a direct URL, buta file on a legitimate platform - SharePoint, Dropbox - with asecondary link to the attacker's proxy. Email-gateway misses becausethe primary domain is trusted.
2. Thevictim's browser raises a TLS connection with the proxy attacker.Proxy installs its own TLS connection with login.microsoftonline.com.Two separate encrypted channels - HTTPS does not save because theproxy is the endpoint of both.
3. Each HTTPrequest from the victim is predicted to a legitimate IdP. The victimsees this Microsoft login page is not a copy, but real content,passed through a proxy. Enter email, password, passes MFA-challenge(push, TOTP, SMS - no matter). All data in transit goes through theattacker’s server.
4. Aftersuccessful authentication, IdP issues a session cookie. Cookies flyback through a proxy. The attacker intercepts it before it gets tothe victim’s browser. The victim gets into his mailbox, withoutknowing anything.
5. Theattacker imports cookies into his browser - through document.cookieorCookie-Editor - and receives a fully authenticated session. MFA hasalready passed. Conditional Access sees a valid token.
The fundamentaldifference from the classic Man-in-the-Middle: MitM operates on thenetwork level (RP-spoofing, rogue AP), neutralized by TLS and MFA.AiTM works at the app level, specially sharpened to bypass MFA, andTLS does not stop it. According to Obsidian Security (WorkOS study),84% of accounts hacked through AiTM had an MFA-included – but inreality, this protection was bypassed.
Evilginx phishing- the anatomy of the leading proxy-framework
Evilginx (exposingversion - Evilginx3) - standalone application to Go, running asHTTP/HTTPS return proxy with its own DNS server. The first versionwas a nginx module, the current implementation is completelyself-sufficient: a built-in web server, automatic TLS certificatesvia Let's Encrypt and the modular configuration via phishlets.
The phishletstructure and interception logic
Phishlet - YAMLfile, which describes: which service is attacked, what subdomains toproxy, which HTTP parameters contain credentials and (the mostdelicious) which cookies are session tokens.
Sectionproxy_hosts Determines the mapping: for each legitimate Microsoftsubdomain (login.microsoftonline.com, login.live.com, www.office.com)a phishing subdomain is created. Section auth_tokens - for her sake,everything is started: here are the names of cookies forinterception. For M365, it is usually ESTSAUTH and ESTSAUTHPERSISTENTon the login.microsoftonline.com domain. Section credentialsdetermines from which POST-parameters to pull out the login andpassword - fields login and passwd in the form of authorization.
When a victimcomes to a phishing URL, Evilginx substitutes its subdomains insteadof the original ones, rewriting all links in HTML/JS-responses on thefly. The victim interacts with a real Microsoft, but through a proxy.After passing the MFA - session, the cookie is intercepted and fallsinto the Evilginx database.
Practical settingup the campaign
For deployment,you need: VPS with white IP, domain with NS records for this IP andBinarywear Evilginx. After launch, the configuration comes from thebuilt-in console.
Basic flow: teamconfig domain We set a phishing domain, config ipv4 - external IPserver. Then phishlets hostname <phishlet_name> <domain>binds phishlet to the domain, phishlets enable <phishlet_name>activates it and automatically requests a TLS certificate. For thegeneration of phishing links - lures create <phishlet_name>,after which lures get-url <lure_id> gives the URL to send tothe victim.
A typical ignitionerror is a DNS configuration curve: if the NS domain records do notindicate the Evilginx IP server, Let's Encrypt will not pass thechallenge, and phishlet will be left without a certificate. Thesecond problem is an attempt to proxy services with WebSocket (someparts of Teams, for example): Evilginx3 handles WebSocket better thanthe second version, but stability is not 100%.
Another point onwhich I wasted time: many target services check the headers Originand Referer. Evilginx processes this through a re-write in phishlet,but at a crook sub_filters authentication breaks - the victim sees anerror, the session is not established. You have to finish filteringwith your hands for a specific version of the login page ofMicrosoft, which, by the way, changes regularly.
Modlishka andMuraena - alternative phishing proxies
Evilginx is notthe only tool at the zoo. For a full understanding of the picture,you need to know the alternatives: each has its own strengths andspecific sores.
Modlishkaframework: automatic reverse proxy
Modlishka iswritten on Go and differs from Evilginx in a fundamentally differentapproach: you do not need to write phishlet for every service.Instead, Modlishka works as a “universal” reverse proxy –specify the target domain, the framework automatically prompts allthe content by rewriting the URL on the fly.
Plus, it'sobvious: the speed of deployment. The launch is reduced to -targetwith the target domain and -phishingDomain with phishing, plussetting up a TLS certificate.
The minus is alsoobvious: “universality” becomes a problem. Modlishka copes worsewith services that actively use Content Security Policy (CSP), HSTSpreload lists and strict origin check. If the target service givesCSP with a hard script-src, the content is rendered crookedly. Whenworking with Microsoft 365, I was faced with a situation whereMicrosoft JS bandals broke due to an incorrect replacement of domainlinks within the mined JS - instead of a white screen login page.Unpleasant.
Modlishka is ableto collect credentials through the analysis of POST-queries andintercept cookies, but the configuration is less granular than thatof Evilginx - you can not point out which cookies are to sessions.
Muraena PhishingProxy: Modular Approach
Muraena (developedby the Italian IB laboratory) is another Go-framework, but with anemphasis on modularity. Divided into two components: the proxy serveritself (Muraena) and the Necrobrowser Crowler, which automatesactions with the invaded sessions.
Necrobrowser - themain difference: after the cookie interception, it launches headlessbrowser, automatically imports the session and performspost-operational actions - collecting emails, creating inbox rules,downloading files with OneDrive. In fact, it is post-exploitationautomation, which in Evilginx you need to do with your hands orscript separately. Comfortable thing, if you need to demonstrate tothe customer a full impact.
Muraena uses JSONconfiguration with a description of the target domain, substitutionin content and interception rules. The approach is closer toModlishka in versatility, but with a thinner setting through replace-Patterns. In practice, Muraena works well with simple SSO portals,but on complex SPAs with dynamic loading - the same problems with CSPand CORS as Modlishka.
Comparison ofproxy-frameworks to bypass multifactor authentication
In practice, thechoice depends on the goal. The campaign against Microsoft 365 orOkta with custom authentication - Evilginx gives maximum control.Quickly validating the concept on a standard web application -Modlishka. We need post-exploitation automation - Muraena withNecrobrowser.
In most projects,I take Evilginx. Yes, the entry threshold is higher, yes, phishletsometimes has to patch up after another Microsoft update - but thepredictability of the result is worth it.
Interception ofsession tokens: what happens after the MFA
Session theft ofcookie is just the beginning. Understanding what the attacker doesfurther, critically for Red Team (bring the operation to impact), andfor the Blue Team (to detect in the early stages).
Abnormalregistration of MFA-devices. Within 30 minutes after authentication,a new MFA device is registered on the account - from an IP differentfrom the one from which the authentication was held. High-relevantAiTM indicator. In Sentinel for this purpose, a request for a tableis used AuditLogs with filtration by OperationName == "Userregistered security info" and Correlation with SigninLogs bytime window.
Creation of inboxrules. Any rule that moves emails to RSS Feeds, hidden folders orremoves them by keywords is a red flag. In Exchange Online, this isdisplayed in Unified Audit Log as an operation New-InboxRule.
Token reuse froman atypical User-Agent or IP. One session is used in parallel withtwo different IPs or with different browser fingerprints. Requiresanalytics on the SIEM side, but gives high accuracy.
Indicators ofphishing infrastructure
AiTM stocksusually live 24-72 hours. According to Sekoia, Tycoon 2FA registersdozens of new domains daily and weekly updates the anti-bot pages.Characteristic features: fresh domain registration, Let's Encryptcertificate, wildcard DNS, subdomain structure, repetitive targetservice (login.target-phishing-domain.com). If you see this in thelogs, dig further.
Protection againstbypassing multifactor authentication via AiTM
Specific measures- from the most effective to additional.
FIDO2 / passkeysis the only authentication resistant to AiTM. The hardware key(YubiKey, Titan) or platform passkey is cryptographically linked toorigin - a specific domain. When the victim is on a phishing domain,the key simply does not work: the origin does not match, thesignature is not formed. There's nothing to prosque. According to theCanadian Cyber Security Center, in tents with phishing-resistant MFAand Conditional Access to registered devices, the percentage ofsuccessful compromising through AiTM decreased from ~20% Q3 2023 to6-7% in Q2 2025.
ConditionalAccess: Managed Device Requirement. Even if the cookie is stolen, anattempt to use it with an unmanaged device attacker will fail theConditional Access check. The second most effective control afterFIDO2. Set up in Entra ID through a policy that requires compliantdevice or Hybrid Azure AD joined device.
Continuous AccessEvaluation (CAE) and short TTL. CAE allows Microsoft 365 to argue inreal time - for example, when changing IP. In practice, CAE coverageis uneven: Exchange Online is well supported, some SaaS applicationsare not. Minimization of TTL session token narrows the window ofcapabilities for the attacker, but does not close it completely.
Blocking legacyauthentication and device code flow. Both methods bypass the modernConditional Access and are often used after AiTM compromise forpersistence. Microsoft explicitly recommends disabling the devicecode flow where it is not needed. If you have it “just in case” –turn it off. The case has already come.
Monitoring.Connecting Entra ID audit logs to SIEM with alterts to: newregistration of MFA-device, creation of inbox rules, OAutth consentgrants from unverified publishers, impossible travel.
