State-of-the-art phishing: MFA bypass

State-of-the-art phishing: MFA bypass

  • Cybercriminals are bypassing multi-factor authentication (MFA) using adversary-in-the-middle (AiTM) attacks via reverse proxies, intercepting credentials and authentication cookies. 
  • The developers behind Phishing-as-a-Service (PhaaS) kits like Tycoon 2FA and Evilproxy have added features to make them easier to use and harder to detect.
  • WebAuthn, a passwordless MFA solution using public key cryptography, prevents password transmission and nullifies server-side authentication databases, offering a robust defense against MFA bypass attacks. 
  • Despite its strong security benefits, WebAuthn has seen slow adoption. Cisco Talos recommends that organizations reassess their current MFA strategies in light of these evolving phishing threats.  

State-of-the-art phishing: MFA bypass

For the past thirty years, phishing has been a staple in many cybercriminals’ arsenals. All cybersecurity professionals are familiar with phishing attacks: Criminals impersonate a trusted site in an attempt to social engineer victims into divulging personal or private information such as account usernames and passwords. In the early days of phishing, it was often enough for cybercriminals to create fake landing pages matching the official site, harvest authentication credentials and use them to access victims’ accounts.  

Since that time, network defenders have endeavored to prevent these types of attacks using a variety of techniques. Besides implementing strong anti-spam systems to filter phishing emails out of users’ inboxes, many organizations also conduct simulated phishing attacks on their own users to train them to recognize phishing emails. These techniques worked for a time, but as phishing attacks have become more sophisticated and more targeted, spam filters and user training have become less effective. 

At the root of this problem is the fact that usernames are often easy to guess or discover, and people are generally very bad at using strong passwords. People also tend to re-use the same weak passwords across many different sites. Cybercriminals, armed with a victim’s username and password, will often attempt credential stuffing attacks, and log into many different sites using the same username/password combination. 

To prove that users are valid, authentication systems generally rely on at least one of three authentication methods or factors: 

  • Something you know (ex. a username and password
  • Something you have (ex. a smartphone or USB key
  • Something you are (ex. your fingerprint or face recognition

In the presence of increasingly sophisticated phishing messages, using only one authentication factor, such as a username/password, is problematic. Many network defenders have responded by implementing MFA, which includes an additional factor, such as an SMS message or push notification, as an extra step to confirm a user’s identity when logging in. By including an additional factor in the authentication process, compromised usernames and passwords become much less valuable to cybercriminals. However, cybercriminals are a creative bunch, and they have devised a clever way around MFA. Enter the wild world of MFA bypass! 

How do attackers bypass MFA? 

In order to bypass MFA, attackers insert themselves into the authentication process using an adversary-in-the-middle (AiTM) attack

Typically, this is done using a reverse proxy. A reverse proxy functions as an intermediary server, accepting requests from the client before forwarding them on to the actual web servers to which the client wishes to connect.  

To bypass MFA the attacker sets up a reverse proxy and sends out phishing messages as normal. When the victim connects to the attacker’s reverse proxy, the attacker forwards the victim’s traffic onwards to the real site. From the perspective of the victim, the site they have connected to looks authentic — and it is! The victim is interacting with the legitimate website. The only difference perceptible to the victim is the location of the site in the web browser’s address bar.  

By inserting themselves in the middle of this client-server communication the attacker is able to intercept the username and password as it is sent from the victim to the legitimate site. This completes the first stage of the attack and triggers an MFA request sent back to the victim from the legitimate site. When the expected MFA request is received and approved, an authentication cookie is returned to the victim through the attacker’s proxy server where it is intercepted by the attacker. The attacker now possesses both the victim’s username/password as well as an authentication cookie from the legitimate site.

State-of-the-art phishing: MFA bypass
Figure 1. Flow diagram illustrating MFA bypass using a reverse proxy.

Phishing-as-a-Service (PhaaS) kits 

Thanks to turnkey Phishing-as-a-Service (Phaas) toolkits, almost anyone can conduct these types of phishing attacks without knowing much about what is happening under the hood. Toolkits such as Tycoon 2FA, Rockstar 2FA, Evilproxy, Greatness, Mamba 2FA and more have emerged in this space. Over time the developers behind some of these kits have added features to make them easier to use and harder to detect:

  • Phaas MFA bypass kits typically include templates for the most popular phishing targets to aid cybercriminals in the task of setting up their phishing campaigns. 
  • MFA bypass kits limit access to the phishing links to only users who possess the correct phishing URL and redirect other visitors to benign webpages.  
  • MFA bypass kits often check the IP address and/or User-Agent header of the visitor, preventing access if the IP address corresponds to a known security company/crawler or if the User-Agent indicates that it is a bot. User-Agent filters may also be used to further target the phishing attacks towards users running specific hardware/software. 
  • Reverse proxy MFA bypass kits typically inject their own JavaScript code into the pages they serve to victims to gather additional information about the visitor, and handle redirects after the authentication cookie has been stolen. These scripts are often dynamically obfuscated to prevent static fingerprinting that would allow security vendors to identify the MFA bypass attack sites. 
  • To thwart anti-phishing defenses which may automatically visit URLs contained in an email at the time it is received, there may be a short, programmable delay between when the phishing message is sent and when the phishing lure URL is activated. 
State-of-the-art phishing: MFA bypass
Figure 2. An example phishing message associated with the Tycoon 2FA phishing toolkit.

Accelerating the rise in MFA bypass attacks via reverse proxy are publicly available open-source tools, such as Evilginx. Evilginx debuted in 2017 as a modified version of the popular open-source web server nginx. Over time, the application was redesigned and rewritten in Go and implements its own HTTP and DNS server. Although it is marketed as a tool for red teams’ penetration testing needs, because it is open source, anyone can download and modify it. 

Fortunately for defenders, there are characteristics common to Evilginx deployments, as well as other AiTM MFA bypass toolkits, that can provide clues an MFA bypass attack may be in progress: 

  • Many MFA bypass reverse proxy servers are hosted on relatively newly registered domains/certificates.  
  • Capturing an authentication cookie only gives attackers access to the victim’s account for that single session. Once they have access to a victim’s account, many attackers add additional MFA devices to the account to maintain persistence. By auditing MFA logs for this kind of activity, defenders may find accounts that have fallen victim to MFA bypass attacks. 
  • By default, Evilginx phishing lure URLs have a URL path consisting of 8 mixed case letters. 
  • By default, Evilginx uses HTTP certificates obtained from LetsEncrypt. Additionally, the certificates it creates by default have an Organization set to “Evilginx Signature Trust Co.”, and a CommonName set to “Evilginx Super-Evil Root CA”. 
  • After a session authentication cookie has been intercepted by the attacker, they will typically load this cookie into their own browser to impersonate the victim. Unless the attacker is careful, for a time, there will be two different users with different User-Agents and IP addresses using the same session cookie. This may be discoverable through web logs or security products that look for things like “impossible travel”. 
  • To avoid the victim clicking a link that redirects them away from the phishing site, the Evilginx reverse proxy rewrites URLs contained in the HTML from the legitimate site. Popular phishing targets may utilize very specific URL paths, and network defenders can look for these URL paths being served from servers other than the legitimate site.  
  • Many MFA bypass reverse proxy implementations are written using Transport Layer Security (TLS) implementations that are native to that programming language. Thus, the TLS fingerprint of the reverse proxy and the legitimate website will be different.  

WebAuthn to the rescue? 

FIDO (Fast IDentity Online) Alliance and W3C  created WebAuthn (Web Authentication API) — a specification that enables MFA based on public key cryptography. WebAuthn is essentially passwordless. When a user registers for MFA using WebAuthn, a cryptographic keypair is generated. The private key is kept on the user’s device, and the corresponding public key is kept on the server.  

When a client wants to log in, they indicate this to the server who responds with a challenge. The client then signs this data and returns it to the server. The server can verify the challenge was signed using the user’s private key. No passwords are ever entered into a web form, and no passwords are transmitted over the internet. This also has the side effect of making server-side authentication databases useless to attackers. What good will stealing a public key do? 

State-of-the-art phishing: MFA bypass
Figure 3. The WebAuthn authentication process.

As an extra layer of security, WebAuthn credentials are also bound to the website origin where they will be used. For example, suppose a user clicks a link in a phishing message and navigates to an attacker-controlled reverse proxy at mfabypass.com, which is impersonating the user’s bank. The location in the web browser’s address bar will not match the location of the bank to which the credentials are bound, and the WebAuthn MFA authentication process will fail. Binding credentials to a specific origin also eliminates related identity-based attacks such as credential stuffing, where attackers try to reuse the same credentials at multiple sites. 

Although the WebAuthn specification was first published back in 2019, it has experienced relatively slow adoption. Based on authentication telemetry data from Cisco Duo for the past six months, it appears that WebAuthn MFA authentications still make up a very low percentage of all MFA authentications.  

To a certain degree, this is understandable. Many organizations may have already rolled out other types of MFA and may feel like that is enough protection. However, they may want to rethink their approach as more and more phishing attacks implement MFA bypass strategies.  

Coverage

State-of-the-art phishing: MFA bypass

Cisco Duo provides multi-factor authentication for users to ensure only those authorized are accessing your network.  

Cisco Secure Email (formerly Cisco Email Security) can block malicious emails sent by threat actors as part of their campaign. You can try Secure Email for free here

Umbrella, Cisco’s secure internet gateway (SIG), blocks users from connecting to malicious domains, IPs and URLs, whether users are on or off the corporate network. 

Cisco Secure Web Appliance (formerly Web Security Appliance) automatically blocks potentially dangerous sites and tests suspicious sites before users access them. 

Cisco Secure Network/Cloud Analytics (Stealthwatch/Stealthwatch Cloud) analyzes network traffic automatically and alerts users of potentially unwanted activity on every connected device. 

Cisco Talos Blog – ​Read More