Blog

Bypass Two-factor Authentication with Phishing

A new phishing attack was recently disclosed at a security conference that circumvents the two-factor authentication schema deployed at many organizations. The attack uses a sophisticated way of tricking the user to authenticate with no impact to user interaction with the website. Once authenticated, the attacker will have the authorization tokens and cookies required to seamlessly act on behalf of the victim to issue anything from account modifications to password changes.

The tool is called Muraena and the seamlessness of it is that it acts like a middle-man by relaying legitimate requests to Dropbox while doing slight manipulations to trick the browser into believing the traffic is legitimate. In the scenario below, the tool was configured to work with Dropbox. Any user browsing to our internally hosted https://evil.test would think they were browsing Dropbox. An attacker could easily create a mutation of dropbox.com to trick the eye, but we decided to keep it obvious.

Below is what the victim will see when navigating to https://evil.test. This may not look exciting, but look at what happens when they sign in.

2fa-walkthrough-1023x731.gif

Figure 1: Two-factor bypass in action

Notice how the flow is uninterrupted and normal. The only noticeable differences being the substitution of evil.test for every dropbox.com request. This functionality alone makes this tool extremely dangerous as it by-passed all browser security controls.

To understand how this works, a primer on HTTP headers is required. Below is a GET request which would be the first step in the process where the victim would navigate to what they believe is Dropbox.

HTTP Request

bypass-2fa1.png

HTTP Response

bypass-2fa2.png

The server responds with the JavaScript and HTML to render the page. There are also important headers attached that are used to protect the user. The browser would see the important security headers on lines 12-16 and enforce them on the user to protect their browsing session. Muraena will sit between the user and Dropbox while reading and modifying the user’s headers to appear legitimate. The server and the user are completely unaware that the traffic is being read due to the requests being sent and received as expected.

If the server received a request to Dropbox.com but received unexpected header and body values, it would respond with an error. Muraena prevents that from occurring. Below is a detailed flow to help further understand how this works.

overview-of-phishing-flow.png

Figure 2: Two-factor attack flow

  • User navigates to evil.test which they assume is dropbox.com

  • Evil.test changes the headers and body content from the phishing domain (evil.test) to the real domain (dropbox.com). The following header and body content are replaced:

    • Headers: query string, host, origin, referrer, cookie, x-headers

    • Body: domain name, content length

  • Response from Dropbox will come to evil.test

  • The headers and body content again are modified but this time to values of evil.test. This essentially bypasses all existing security controls (HSTS, CSP, Framing, Anti Sniffing, XSS)

  • HTTP 200 OK sent to user which means the request has succeeded

Once the victim is authenticated to Dropbox, the authentication records are sent to a secondary tool called Necrobrowser. This tool will take the authentication cookies and tokens to conduct authenticated requests on the attacker’s behalf. It could be used to change passwords, and even disable the two-factor. It can do this because Muraena sits between the victim and the web server (dropbox.com) while capturing everything in between (including the credentials used to authenticate).

The one caveat to this tool is that it requires thorough understanding of the web application to determine how each request and response is handled. The tool requires a customized configuration to identify which headers, parameters and body content needs to be modified for each request and response. Without this information, this tool would be not work as intended. This means that every site can be affected given an attacker takes the required time to configure the tool.

At Packetlabs, we invest time learning the ins and outs of these tools to incorporate them into our client phishing campaigns. We believe that every new attack that has the potential to affect our clients needs to be explored in order to help prevent a legitimate attack.

Featured Posts

See All

December 10 - Blog

Hardware Token Protocols

Hardware token protocols: what are they, and what role do they play in your organization's cybersecurity? In today's article, our ethical hackers outline the most common hardware token protocols.

October 24 - Blog

Packetlabs at SecTor 2024

Packetlabs is thrilled to have been a part of SecTor 2024. Learn more about our top takeaway's from this year's Black Hat event.

September 27 - Blog

What is InfoStealer Malware and How Does It Work?

InfoStealer malware plays a key role in many cyber attacks, enabling extortion and lateral movement via stolen credentials. Learn the fundamentals about InfoStealers in this article.

Packetlabs Company Logo
    • Toronto | HQ
    • 401 Bay Street, Suite 1600
    • Toronto, Ontario, Canada
    • M5H 2Y4
    • San Francisco | HQ
    • 580 California Street, 12th floor
    • San Francisco, CA, USA
    • 94104