Most of us know that multifactor authentication (MFA) is a useful tool for managing and securing passwords, and many web services integrate it into their logging in processes for both business and personal use. There is no doubt that a properly implemented MFA solution will help mitigate against brute force attacks, and credential stuffing, but MFA also has a few issues you need to consider so you are not lulled into a false sense of security.
In this blog we’ll demonstrate how MFA can be bypassed, especially if users are not paying attention during the logging in process.
Before explaining how to execute this attack, I want to explain a little bit about how it works. Basically, to gain access to 2FA-enabled accounts we don’t just need the credentials, as this wouldn’t be enough to log-in. Instead, we need to get the session cookie.
For those who don’t know what a cookie is, it’s a small piece of data that a server sends to the user’s web browser. The browser may store it and send it back with the next request to the same server. Typically, it’s used to tell if two requests came from the same browser — keeping a user logged-in, for example, it remembers stateful information for the stateless HTTP protocol. If we were able to get it, we could import the cookie into our browser and get access to the account.
There are many tools out there that we could use, but on this occasion, I’ve chosen Evilginx -v2.3. According to the author, Evilginx is a “standalone man-in-the-middle attack framework used for phishing login credentials along with session cookies, allowing for the bypass of 2-factor authentication.”
The way Evilginx works can be demonstrated in the following diagram where our server acts as the man-in-the-middle.
Now for the attack itself. If you want to try it, it won’t take you more than an hour to get everything up and running and start using it. This work is merely a demonstration of what adept attackers can do. It’s your responsibility to use it for educational purposes only or with the client’s authorisation.
The Attack
What would you need to start? Firstly, you would need a domain. You can buy very cheap ones. In my case I bought not-linkedin.info for around 4 USD. Secondly, you would need a server to host Evilginx. Personally, I used the cheapest Digital Ocean Ubuntu droplet that costs about 5USD/month. And finally, I’ve set up my DNS servers using the free version of Cloudflare. In a couple of clicks you are all set up. It’s never been easier.
Once it’s all ready, we start the tool and configure it with the domain and server information. As you can see LinkedIn is not the only available option. In addition, you can create custom phishlets and adapt every page that you want to phish.
config domain <domain>
config domain not-linkedin.info
config ip <ip>
config ip 68.183.17.1
phishlets hostname <phishlet> <domain>
phishlets hostname linkedin not-linkedin.info
phishlets enable <phishlet>
phishlets enable linkedin
To run a campaign, we should create a lure. To do that, we run the following command. We can also configure a redirect URL, but that step is not mandatory.
lures create <phishlet>
lures create linkedin
Once the lure is created, we get the phish URL. That URL is the one that we should send to the victim.
The victim would see the following page. As you can observe, the site is with HTTPS, and the look and feel is exactly the same as the original site.
If the victim enters credentials, in our console they will see:
At that time, our man-in-the-middle server would redirect the login action to the LinkedIn Server and LinkedIn is going to trigger the 2FA challenge. Once that happens, the victim will receive the text message with the one-time code.
The victim enters that code. Note that the victim is still in our fake domain.
Once that happens, we redirect the code to the LinkedIn Server who, after validating it, creates a session that we intercept. After that the victim is redirected, in this case to google.com. It can be redirected where you want or not redirected at all.
To see all captured credentials, we just run the command sessions <id>. We can observe username, password and session cookie. We copy that cookie and import it into Chrome using EditThisCookie extension.
We refresh the page and BINGO, we bypassed 2FA.
We just demonstrated that even 2FA is bypassable.
However, you should still enable it everywhere possible as it solves a lot of vulnerabilities such as weak or reusable passwords and makes account takeover more difficult. However, this post aims to demonstrate that the most important fix against phishing is not 2FA or any other technical solution. It’s user awareness that prevents phishing. Just be careful where you enter your information!
For more information, please go to the author site and tool documentation:
https://breakdev.org/evilginx-2-3-phishermans-dream/ and https://github.com/kgretzky/evilginx2/wiki/Phishlet-File-Format-(2.3.0).
For more information on Red Team Attack Simulations, contact Sekuro today to talk to an expert.
Nicolas Brahim
Principal Consultant, Sekuro
Nicolas, the Principal Consultant at Sekuro, is an individual with over a decade of experience as a cyber security enthusiast. With a strong background in offensive security and GRC, he leads the Cyber Resilience Program, providing end-to-end cyber security program management for his customers. His expert advice empowers customers, allowing them to enhance and strengthen their security posture, protecting against a dynamic cyber threat landscape. Nicolas offers a unique opportunity to improve organisation's defense strategies under the guidance of a seasoned professional.
More Articles
Selling the Strategic Imperative of Zero Trust to Your Board
In conversation with Nathan Wenzler, Chief Security Strategist at Tenable (Part 2)
