Evilginx 2

About Evilginx 2 - Next Generation of Phishing Attack and Bypass 2FA written in Go
   Evilginx2 is a Man-In-The-Middle Attack Framework used for phishing login credentials along with session cookies, which in turn allows to bypass 2-Factor Authentication protection.

   This tool is a successor to Evilginx, released in 2017, which used a custom version of nginx HTTP server to provide man-in-the-middle functionality to act as a proxy between a browser and phished website. Present version is fully written in GO as a standalone application, which implements its own HTTP and DNS server, making it extremely easy to set up and use.

Phishing 2.0:
   What if it was possible to lure the victim not only to disclose his/her username and password, but also to provide the answer to any 2FA challenge that may come after the credentials are verified? Intercepting a single 2FA answer would not do the attacker any good. Challenge will change with every login attempt, making this approach useless.

   After each successful login, website generates an authentication token for the user's session. This token (or multiple tokens) is sent to the web browser as a cookie and is saved for future use. From that point, every request sent from the browser to the website will contain that session token, sent as a cookie. This is how websites recognize authenticated users after successful authentication. They do not ask users to log in, every time when page is reloaded.

   This session token cookie is pure gold for the attacker. If you export cookies from your browser and import them into a different browser, on a different computer, in a different country, you will be authorized and get full access to the account, without being asked for usernames, passwords or 2FA tokens.

   This is what it looks like, in Evilginx 2, when session token cookie is successfully captured:

   Now that we know how valuable the session cookie is, how can the attacker intercept it remotely, without having physical access to the victim's computer?

   Common phishing attacks rely on creating HTML templates which take time to make. Most work is spent on making them look good, being responsive on mobile devices or properly obfuscated to evade phishing detection scanners.

   Evilginx takes the attack one step further and instead of serving its own HTML lookalike pages, it becomes a web proxy. Every packet, coming from victim's browser, is intercepted, modified and forwarded to the real website. The same happens with response packets, coming from the website; they are intercepted, modified and sent back to the victim. With Evilginx there is no need to create your own HTML templates. On the victim side everything looks as if he/she was communicating with the legitimate website. User has no idea idea that Evilginx sits as a man-in-the-middle, analyzing every packet and logging usernames, passwords and, of course, session cookies.

   You may ask now, what about encrypted HTTPS connection using SSL/TLS that prevents eavesdropping on the communication data? Good question. Problem is that the victim is only talking, over HTTPS, to Evilginx server and not the true website itself. Evilginx initiates its own HTTPS connection with the victim (using its own SSL/TLS certificates), receives and decrypts the packets, only to act as a client itself and establish its own HTTPS connection with the destination website, where it sends the re-encrypted packets, as if it was the victim's browser itself. This is how the trust chain is broken and the victim still sees that green lock icon next to the address bar, in the browser, thinking that everyone is safe.

   When the victim enters the credentials and is asked to provide a 2FA challenge answer, they are still talking to the real website, with Evilginx relaying the packets back and forth, sitting in the middle. Even while being phished, the victim will still receive the 2FA SMS code to his/her mobile phone, because he/she is talking to the real website (just through a relay).

   After the 2FA challenge is completed by the victim and the website confirms its validity, website generates the session token, which it returns in form of a cookie. This cookie is intercepted by Evilginx and saved. Evilginx determines that authentication was a success and redirects the victim to any URL it was set up with (online document, video etc.).

   At this point the attacker holds all the keys to the castle and is able to use the victim's account, fully bypassing 2FA protection, after importing the session token cookies into his web browser.

   Be aware that: Every sign-in page, requiring the user to provide their password, with any form of 2FA implemented, can be phished using this technique!

Disclaimer about Evilginx 2
   Kuba Gretzky very much aware that Evilginx can be used for nefarious purposes. This work is merely a demonstration of what adept attackers can do. It is the defender's responsibility to take such attacks into consideration and find ways to protect their users against this type of phishing attacks. Evilginx should be used only in legitimate penetration testing assignments with written permission from to-be-phished parties.

Video demo about Evilginx 2 - Next Generation of Phishing Attack and Bypass 2FA written in Go: https://vimeo.com/281220095

Write-up
   If you want to learn more about this phishing technique, I've published an extensive blog post about evilginx2 here:
   https://breakdev.org/evilginx-2-next-generation-of-phishing-2fa-tokens

Phishlet Masters - Hall of Fame
   Please thank the following contributors for devoting their precious time to deliver us fresh phishlets! (in order of first contributions)
   @cust0msync - Amazon, Reddit
   @white_fi - Twitter

Install and Run Evilginx 2:
   You can either use a precompiled binary package for your architecture or you can compile evilginx2 from source.

   You will need an external server where you'll host your evilginx2 installation. I personally recommend Digital Ocean and if you follow my referral link, you will get an extra $10 to spend on servers for free.

   Evilginx runs very well on the most basic Debian 8 VPS.

   Installing from source
      In order to compile from source, make sure you have installed GO of version at least 1.10.0 (get it from here) and that $GOPATH environment variable is set up properly (def. $HOME/go).

      After installation, add this to your ~/.profile, assuming that you installed GO in /usr/local/go:
export GOPATH=$HOME/go
export PATH=$PATH:/usr/local/go/bin:$GOPATH/bin
Then load it with source ~/.profiles.

      Now you should be ready to install evilginx2. Follow these instructions:
sudo su
apt-get install git make
go get -u github.com/kgretzky/evilginx2
cd $GOPATH/src/github.com/kgretzky/evilginx2 && make

      You can now either run evilginx2 from local directory like:
      sudo ./bin/evilginx -p ./phishlets/

      or install it globally:
sudo make install
sudo evilginx

      Instructions above can also be used to update evilginx2 to the latest version.

Using Evilginx 2 - Next Generation of Phishing Attack and Bypass 2FA written in Go
   IMPORTANT! Make sure that there is no service listening on ports TCP 443, TCP 80 and UDP 53. You may need to shutdown Apache or Nginx and any service used for resolving DNS that may be running. Evilginx2 will tell you on launch if it fails to open a listening socket on any of these ports.

   By default, evilginx2 will look for phishlets in ./phishlets/ directory and later in /usr/share/evilginx/phishlets/. If you want to specify a custom path to load phishlets from, use the -p <phishlets_dir_path> parameter when launching the tool.

Usage of ./evilginx:
  -debug
        Enable debug output
  -developer
        Enable developer mode (generates self-signed certificates for all hostnames)
  -p string
        Phishlets directory path

   You should see Evilginx2 logo with a prompt to enter commands. Type help or help <command> if you want to see available commands or more detailed information on them.

Getting started with Evilginx:
   To get up and running, you need to first do some setting up.

   At this point I assume, you've already registered a domain (let's call it yourdomain.com) and you set up the nameservers (both ns1 and ns2) in your domain provider's admin panel to point to your server's IP (e.g. 10.0.0.1):
ns1.yourdomain.com = 10.0.0.1
ns2.yourdomain.com = 10.0.0.1

   Set up your server's domain and IP using following commands:
config domain yourdomain.com
config ip 10.0.0.1

   Now you can set up the phishlet you want to use. For the sake of this short guide, we will use a LinkedIn phishlet. Set up the hostname for the phishlet (it must contain your domain obviously):
      phishlets hostname linkedin my.phishing.hostname.yourdomain.com

   And now you can enable the phishlet, which will initiate automatic retrieval of LetsEncrypt SSL/TLS certificates if none are locally found for the hostname you picked: phishlets enable linkedin

   Your phishing site is now live. Think of the URL, you want the victim to be redirected to on successful login and get the phishing URL like this (victim will be redirected to https://www.google.com):
      phishlets get-url linkedin https://www.google.com

   Running phishlets will only respond to tokenized links, so any scanners who scan your main domain will be redirected to URL specified as redirect_url under config. If you want to hide your phishlet and make it not respond even to valid tokenized phishing URLs, use phishlet hide/unhide <phishlet> command.

   You can monitor captured credentials and session cookies with: sessions

   To get detailed information about the captured session, with the session cookie itself (it will be printed in JSON format at the bottom), select its session ID: sessions <id>

   The captured session cookie can be copied and imported into Chrome browser, using EditThisCookie extension.

   Important! If you want evilginx2 to continue running after you log out from your server, you should run it inside a screen session.

How to protect yourself?
   There is one major flaw in this phishing technique that anyone can and should exploit to protect themselves - the attacker must register their own domain.

   By registering a domain, attacker will try to make it look as similar to real, legitimate domain as possible. For example if the attacker is targeting Facebook (real domain is facebook.com), they can, for example, register a domain faceboook.com or faceb00k.com, maximizing their chances that phished victims won't spot the difference in the browser's address bar.

   That said - always check the legitimacy of website's base domain, visible in the address bar, if it asks you to provide any private information. By base domain I mean the one that precedes the top-level domain.

   As an example, imagine this is the URL and the website, you arrived at, asks you to log into Facebook:
      https://en-gb.facebook.cdn.global.faceboook.com/login.php

   The top-level domain is .com and the base domain would be the preceeding word, with next . as a separator. Combined with TLD, that would be faceboook.com. When you verify that faceboook.com is not the real facebook.com, you will know that someone is trying to phish you.

   As a side note - Green lock icon seen next to the URL, in the browser's address bar, does not mean that you are safe!

   Green lock icon only means that the website you've arrived at, encrypts the transmission between you and the server, so that no-one can eavesdrop on your communication. Attackers can easily obtain SSL/TLS certificates for their phishing sites and give you a false sense of security with the ability to display the green lock icon as well.

   Figuring out if the base domain you see is valid, sometimes may not be easy and leaves room for error. It became even harder with the support of Unicode characters in domain names. This made it possible for attackers to register domains with special characters (e.g. in Cyrillic) that would be lookalikes of their Latin counterparts. This technique recieved a name of a homograph attack.

   As a quick example, an attacker could register a domain facebooĸ.com, which would look pretty convincing even though it was a completely different domain name (ĸ is not really k). It got even worse with other Cyrillic characters, allowing for ebаy.com vs ebay.com. The first one has an Cyrillic counterpart for a character, which looks exactly the same.

   Major browsers were fast to address the problem and added special filters to prevent domain names from being displayed in Unicode, when suspicious characters were detected.

   If you are interested in how it works, check out the IDN spoofing filter source code of the Chrome browser.

   Now you see that verifying domains visually is not always the best solution, especially for big companies, where it often takes just one employee to get phished and allow attackers to steal vast amounts of data.

   This is why FIDO Alliance introduced U2F (Universal 2nd Factor Authentication) to allow for unphishable 2nd factor authentication.

   In short, you have a physical hardware key on which you just press a button when the website asks you to. Additionally it may ask you for account password or a complementary 4 digit PIN. The website talks directly with the hardware key plugged into your USB port, with the web browser as the channel provider for the communication.

   What is different with this form of authentication, is that U2F protocol is designed to take the website's domain as one of the key components in negotiating the handshake. This means that if the domain in the browser's address bar, does not match the domain used in the data transmission between the website and the U2F device, the communication will simply fail. This solution leaves no room for error and is totally unphishable using Evilginx method.

   Citing the vendor of U2F devices - Yubico (who co-developed U2F with Google):

"With the YubiKey, user login is bound to the origin, meaning that only the real site can authenticate with the key. The authentication will fail on the fake site even if the user was fooled into thinking it was real. This greatly mitigates against the increasing volume and sophistication of phishing attacks and stops account takeovers.
Credits: Huge thanks to Simone Margaritelli (@evilsocket) for bettercap and inspiring me to learn GO and rewrite the tool in that language!"

   It is important to note here that Markus Vervier (@marver) and Michele Orrù (@antisnatchor) did demonstrate a technique on how an attacker can attack U2F devices using the newly implemented WebUSB feature in modern browsers (which allows websites to talk with USB connected devices). It is also important to mention that Yubico, the creator of popular U2F devices YubiKeys, tried to steal credit for their research, which they later apologized for.

   You can find the list of all websites supporting U2F authentication here.

   Coinciding with the release of Evilginx 2, WebAuthn is coming out in all major web browsers. It will introduce the new FIDO2 password-less authentication standard to every browser. Chrome, Firefox and Edge are about to receive full support for it.

   To wrap up - if you often need to log into various services, make your life easier and get a U2F device! This will greatly improve your accounts' security.

License: Evilginx2 is made by Kuba Gretzky (@mrgretzky) and it's released under GPL3 license.

Download Evilginx 2: https://github.com/kgretzky/evilginx2