The phishing harvester. Stealing account credentials with Evilginx 2

Today, we are going to examine Evilginx 2, a reverse proxy toolkit. We will also find out how to use it to bypass two-factor authentication and steal Instagram login credentials. Finally, we will build and launch a combat server, tweak it, and go phishing!

Deceptive maneuvers

Major online services use two-factor authentication to protect users’ accounts. Two-factor authentication requires the user to enter a one-time code in addition to the login and password. The one-time code can be sent by a text message, delivered as a push notification, generated with an authenticator app using the TOTP protocol, or made up in countless other ways ranging from lists of codes printed on good old paper to biometric smartcards. Up until recently, two-factor authentication was considered a secure antitheft system, but now hackers can bypass it using special tools.

One of such tools is Evilginx 2, a reverse proxy server and ready-to-use MiTM attack framework designed to bypass two-factor authentication. Nearly everything in it is automated. So, how does it work?

Generally speaking, performing a successful attack requires the phisher to penetrate between the victim and the Web site the victim is trying to login to; intercept the login credentials, and identify and save the session cookies. This task is relatively simple if we deal with the standard HTTP authentication. But since all major websites have migrated to HTTPS and started using two-factor authentication, some very new methods had to be developed.

Evilginx 2 has a superpower: it can create signed certificates for fake sites using the client of Let’s Encrypt, a free and automated certificate authority. This enables the attacker to use HTTPS and adorn the phishing site with a green lock in the address line. As a result, the fake is visually undistinguishable from the original (at least, at first glance). Furthermore, Evilginx 2 automatically identifies and intercepts valid cookies. This feature is the key element of a successful attack.

Then phisher’s wits come into play. For instance, once you have access to a single account, you can use that account to create a group or a mailing list where you invite the victim’s contacts to vote in some contest. The victim’s contacts follow your link and sign in while you collect their credentials. Wash, rinse, and repeat; the attack scope increases at an exponential rate.

History of the evil proxy

The creator of this utility is a Polish ethical hacker Kuba Gretzky kgretzky. Evilginx was first mentioned in his blog as early as on April 6, 2017.

Initially, Gretzky’s work was based on these two modules of the popular web server Nginx: sub_filter and proxy_pass. In Evilginx, the first module blocks victim’s access to the real server, while the second one transmits intercepted requests to that server and back. From the very beginning, the program was positioned as a tool able to breach protection based on two-factor authentication.

The developer was invited to deliver a speech at WarCon 2018 and attracted the attention of Kevin Mitnick. Mitnick wrote about Evilginx, giving it excellent publicity. As a result, the utility started quickly gaining popularity. By June 2018, two versions have been released, 1.0 and 1.1.

At WarCon 2018, Kuba Gretzky has also met the white hat hacker Simone Margaritelli, Chief Research Architect at Zimperium, publishing his studies under the nickname evilsocket. Margaritelli introduced Gretzky to the Go language and inspired him to rewrite Evilginx in it. A year later, the completely revamped Evilginx 2 was released. The project has evolved from the “MiTM through Nginx” concept to “Evilginx 2 w/o Nginx. Pure Go, and pure evil”. This was the first milestone in its history.

The second milestone was the release of the open-source Modlishka project. At that time, the main difficulty faced by the users of Evilginx 2 was traffic proxying. The hacker had to create numerous filters dynamically substituting legitimate links with phishing ones. This was done through trial and error, making the code extremely sophisticated.

Kuba Gretzky saw the URL substitution mechanism used in Modlishka. It turned out that there was no need to create tons of filters. All the hacker had to do was adding the Web site domain once and writing general traffic substitution rules. This is how components of phishlets (ready-to-use scripts imitating the structure of popular sites) have been invented. Today, we are going to use Evilginx 2.3.1 in our study.

Evilginx 2 vs Modlishka

My previous article was dedicated to Modlishka, which is yet another tool designed to bypass two-factor authentication. At that time, the program had no automated solution for HTTPS, and suffered from certificate generation problems. The hacker had to tighten this screw manually. In addition, only one phishing site could be launched on a Modlishka server; so, the scope of attacks was limited.

Evilginx 2 does not have such shortfalls. This ‘phishing harvester’ allows you to steal credentials from several services simultaneously (see below). In addition, the solution used for certificate generation literally gives you a free reign. In my opinion, Evilginx 2 is a few steps ahead of Modlishka thanks to its smart approach and the general user-friendliness.

Several versions of the program have already been released, and its development continues. For instance, JS injections have been added in the last updates. With a JS injection, you can inject your own scripts in JavaScript into the traffic. The scripts will be executed on the victim’s machine.

Normally, hacking utilities are written in Linux, but Evilginx 2 is also available for Windows and as a Dockerfile. Surprisingly, but it works well on Windows, while the installation is even easier in comparison with Linux. You just download the archive, unpack it into any folder, and launch the executable file. This portable utility can be copied on a flash drive and launched on any Windows-based system from Windows 7 and up. It neither requires installation nor leaves traces in the registry.

The .yml file can be edited in Notepad.

Now it is time to do some practice. Sorry, Windows fans, but I am going to do this on Linux.

Preparing combat server

Our goal is to launch an Evilginx 2 server online and hijack credentials of several users on a popular social network.

First, we need a Virtual Dedicated Server (VDS) meeting the minimum system requirements. I had a single core with 1 GB of RAM, 30 GB disk space, a ‘white’ IP address, and Ubuntu Server 16.04 onboard. Of course, it is necessary to register a domain name mapped to this IP address. The problem is that this cannot be done for free on Freenom. We need not just one domain name, but a domain zone delegated to us. It can be purchased from a provider, for instance, Domain.com. When you purchase a domain, you get access to DNS administration (i.e. settings for the DNS zone responsible for your domain and its subdomains). Therefore, you can either map the domain name to the IP address using the DNS A record or create subdomains to be used in your attack.

On our new server, we install the development framework for the Go language. This framework is required because Evilginx is written in Go.

sudo add-apt-repository ppa:longsleep/golang-backports
sudo apt-get update
sudo apt-get install golang-go
export GOPATH=$HOME/go
export PATH=$PATH:/usr/local/go/bin:$GOPATH/bin

To check whether everything is running well:

go env

GOPATH must be set and clearly visible.

Now it is time to install Evilginx 2

apt-get install git make
go get -u github.com/kgretzky/evilginx2
cd $GOPATH/src/github.com/kgretzky/evilginx2
make
make install

Prior to the launch, it is necessary to check whether ports 80 are 443 open. They are required for traffic proxying. I assumed they should be available on a newly installed OS, but I was wrong: Apache was listening on port 80. As a result, the system was unable to generate certificates automatically.

netstat -antp

After releasing the required ports, we can launch Evilginx 2 by typing its name in the console: evilginx.

However, if we try to enter the phishing site right away by simply typing its domain name, the program would redirect us to YouTube. This action is set by default, and we have to configure settings for our reverse proxy first. To view the settings, type config.

The domain field should contain the name of our phishing domain, while IP is its IP address. The redirect_url field indicates the domain name the victim will be redirected to after following the original link. These parameters can be set using the following commands:

config domain yourDomain.com
config ip yourIP

Now it is time to look at our phishing station more closely. Its work is based on the two primary elements:

Phishlets – configuration files determining the main Evilginx operation rules. They specify inter alia authorization identification parameters, properties of cookie sessions, and other phishing data. These files are stored in the <program_path>\Phishlets folder, and have the .yaml extension. Thirteen phishlets have already been created for the most popular websites; apparently, this number is going to increase soon. Most importantly, every hacker can write custom phishlets for personal use. There are two phishlet file formats slightly differing by their syntax and possibilities for versions 2.2.0 and 2.3.0; so far, both of them are supported. A detailed description is available for each version.

In addition to phishlets, Evilginx uses lures, i.e. functions generating URLs and proxying the traffic inside the host system in order to redirect the victim to a phishing site created by the hacker.

Prior to going phishing, note one more thing: a hidden directory named Evilginx2 should appear in the home folder. It contains the main config (the saved set of parameters), database (hijacked credentials and sessions), and a certificate with the key. A detailed examination of the certificate shows that this is a root certificate issued for 10 years and signed as Evilginx Super-Evil Root CA. To display this information, use the command below.

openssl x509 -in ca.crt  -text

Time has come to do some real job! First, let us set up the phishlets. I am going to use a phishlet written for Instagram. To view all configs, enter the phishlets command. So far, they are empty. We add our domain to the selected config:

phishlets hostname instagram yourDomain

Then we create a lure for Instagram users:

lures create instagram

Ultimately, everything should look like on the screenshot below.

Finally, we launch one or several phishlets:

phishlets enable Instagram

What happens next? First, a certificate is generated (at this point, everything may collapse like a house of cards if ports 80 or 443 are unavailable). It is generated using the built-in Let’s Encrypt client; in other words, we get a valid certificate for a phishing domain. This solves the HTTPS connection and plausibility problems.

Second, a proxy server originally based on the popular Nginx Web server is launched. Although the current version of Evilginx is written in Go, the utility still bears its ancestral name. The system starts sniffing the traffic and filtering the contents in accordance with the phishlets’ configurations.

To view all lures, type the command lures. Can you see the table and the id column in it? To get a ready-to-use phishing link, enter lures get-url id, where id is the value from the table.

Testing the server

Prior to luring victims to our phishing server, we have to test it and specify some details. We follow the phishing link and see the Instagram login page. Everything looks authentic. We enter the login, password, and code received in a text message. Excellent, we have just played the role of the victim!

Concurrently, the server terminal shows that somebody has just visited our page. The captured logon credentials are displayed and recorded in the database. To view them, use the sessions command.

What about two-factor authentication? When the victim enters the password received in a text message, Evilginx 2 intercepts the authorization session or cookie as well. If the Evilginx displays the message “all authorization tokens intercepted!”, then the session has been successfully hijacked. To view the interception status, use the command session id.

EditThisCookie plugin can be used to import the hijacked session to the browser. Voila, we have been authorized on Instagram on behalf of the victim and do not need the login and password at all!

First victims

Time for combat testing! I sent a message with the phishing link and a phrase: “Check it out, it’s funny!” to 20 people from my contact list.

These persons knew me personally. As you know, most of us automatically trust their acquaintances. In addition, they were curious: what could be so funny? Especially taking that they saw a preview with the Instagram logo.

The idea of my attack was based on these two circumstances. Overall, 16 people out of the 20 have followed the link, and three of them entered their logins and passwords. Most probably, the rest of the victims were just too lazy to remember their credentials. They browse Instagram using the app and do not have to authenticate every time. Nobody asked me any questions, and none of the victims expressed security concerns.

The three persons have exposed their credentials, found nothing interesting on the destination website, and asked me: “What is there?” I responded: “Nothing anymore. Apparently, it was a test”. All the doubts have been dispelled. I could get access to the three accounts without passwords using the hijacked sessions. In other words, two-factor authentication was not protecting these users anymore.

Important: the majority of people view Instagram using the app; as a result, I can retain access to the hacked accounts even after the phishing attack. The authorized session continues until the user follows the phishing link again or signs out of the account. Both situations are highly unlikely. Therefore, the hacker can remain in control of the victim’s account for a long time.

Protection

I have set up and launched a test system just to check out Evilginx 2. Therefore, I neither bothered obfuscating the attack nor added any extra layers for the sake of disguise; the server was run as a bare ‘skeleton’. As you can see, even such a primitive attack can be successful.

It is difficult to suggest any technical protection against such attacks, especially taking that ‘single logon’ style authentication using social networks can be built into any website. Therefore, your primary defense would be the common sense and reasonable doubt. If you follow a link received from somebody and are prompted for credentials, an alarm bell must immediately ring in your head.