Issue

How exactly does an attacker steal a user’s “session”?

Stealing a username/password combo and using them to sign into someone else’s account is an intuitive process. But if the end user has MFA enabled on their account, signing into that account on a new device requires a code from an OTP app, alternate email, or text to their mobile phone.

Assuming the attacker hasn’t ALSO breached their alternate email or executed a SIM Swap to get direct access to the victim’s MFA method, how are they able to bypass that additional layer of security? And what might it look like in practice?

AiTM - Adversary-in-The-Middle Attacks

  • A subset of On-Path / MiTM attacks
  • Usually means the attacker manipulates traffic (rather than just collecting it)
  • Usually means the attacker is aiming to steal session tokens

Example Attack Process

Register a domain

  • Probably mimic a legit domain and employ URL hijacking / typosquatting
  • Might even be able to just get one for free with some services like Freenom - A Name for Everyone

Spin up an EC2

  • Set up an affordable, or free, EC2 (Amazon cloud computer)
  • Attach the new domain to it by point the domain A record to the cloud computer’s IP address

Install an HTTPS Certificate

  • Snag a free DV Let’s Encrypt cert to make things look extra legit
  • After all, anyone can prove “effective control” of their own domain and Amazon web server
  • IETF - ACME

Install a Reverse Proxy Framework on the EC2

The reverse proxy software intercepts traffic between the victim’s computer and the legitimate web server of a platform like Google or Microsoft

Reverse Proxy Illustration #1 Reverse Proxy Illustration #2

Popular reverse proxies for AiTM attacks:

  • Evilginx
    • A “man-in-the-middle attack framework used for phishing login credentials along with session cookies, which in turn allows to bypass 2-factor authentication protection”
    • Legit and used for penetration testing, but fully-functional as an actual attack tool, similar to…
  • EvilProxy
    • PaaS - Phishing as a Service, sold on dark web
    • Easy to deploy, good tutorials, nice GUI, user-friendly for script kiddies
  • Others
    • Modlishka
    • Necrobrowser
    • Muraena

Once they attacker has their domain and VM set up with their attack platform of choice, they need two more things to execute their attack:

Phishlet

Scrounge up a preconfigured “phishlet” to target Microsoft, Google, or some other provider’s sign-in page

Lure

Evilginx and Microsoft Sign-in Page Illustration

A malicious link in a phishing email

  • Social Engineering
  • When the victim clicks the link, they will still see the attacker’s shady URL, but the rest of the UI stylization matches the legitimate sign-in page
  • Capture both the username/password combo AND the JSON session cookie that gets generated when the victim punches in their MFA code
  • Usually those session tokens are invisible from the POV of an average end user. They live in the browser, and when the user signs back into Microsoft or Google, the browser flashes the token at the provider, like swiping a badge at an access vestibule

Result

The attacker is free to use the captured creds and session token. They can import the JSON cookie content into a browser with an extension, get into the victim’s account, add their own MFA method for persistent access, register an enterprise app, set email rules, download the mailbox contents, etc.

Sources