Original text by Austin Downing

PHISHING USERS USING EVILGINX AND BYPASSING 2FA

Phishing is one of the largest ways that organizations are being compromised in 2019. The common recommendation is that all users should have two factor authentication (2FA) enabled on their accounts to help combat the issue of phishing. What if attackers could bypass a organizations 2FA configuration? In this blog post we will look at how to setup the tool Evilginx2 and how it can be used to phish users when conducting red team engagement or for the blue team to test against their own users.

Only a few things will be needed before you start following this guide.

• A Domain you control
• DNS for the domain you control
• AWS Free Tier Account

CONFIGURING AWS FOR EVILGINX

Evilginx2 needs a few ports opened up for it to work properly. Start by creating a new AWS security group and name it something that you are able to remember. We will need to open the following inbound ports.

• HTTP
• HTTPS
• SSH
• DNS (UDP)
• DNS (TCP)

We will also need to setup some DHCP options, these can be edited from the VPC Console. We will want to set our domain name to the internal AWS domain for the region and availability group we are planning to use. For this blog post we will be using the US-East-2 region which uses the domain name us-east-2-compute.internal. We will be using the AWS nameserver 172.31.0.2 for this demo.

After you have created your DHCP Options you will want to assign it to your VPC that you are running your evilginx2 box out of.

Now we are ready to create our EC2 instance, for this demo we will be using the Ubuntu 18.04 x64.

CONFIGURING UBUNTU FOR EVILGINX2

At this point we should have a Ubuntu 18.04 instance running with the DHCP and Security Group settings we previously configured applied. Lets login to our newly created Ubuntu machine.

After running the inaugural sudo apt update && sudo apt upgrade we are ready to install GOLang as Evilginx2 is built using GOLang. All that is needed to run the following commands.

sudo apt install golang-go

Bash

We are now ready to install Evilginx2 which can be obtained here

https://github.com/kgretzky/evilginx2/releases.

wget https://github.com/kgretzky/evilginx2/releases/download/2.3.0/evilginx_linux_x86_Latest_Version.zip



unzip evilginx_linux_x86_latest_version.zip



chmod 700 ./install.sh



sudo ./install.sh

Bash

Now that we have Evilginx2 installed we need to update some of our DNS on our instance so that Evilginx will be able to work properly. By default the AWS Ubuntu instance symlinks /etc/resolv.conf to /run/systemd/resolve/stub-resolv.conf. This configuration file has the option “EDNS0” enabled by default which our team found causes issues due to Evilginx not supporting EDNS properly.

Next we need to update our host file to point the website we are hosting at our internal IP address.

Now that we configured our local DNS settings we will need to stop the local DNS server so that Evilginx2 can take its place.

sudo systemctl stop systemd-resolved.service

Bash

If you want to only use the machine you have created to run Evilginx2 then you can permentantly disable the DNS server with the following command.

sudo systemctl disable systemd-resolved.service

None

Now that we have our system configured we need to update our external DNS records to point all traffic destined for our URL to our new server regardless of the subdomain. We will also need to create two A records for name servers ns1.ourdomain.com and ns2.ourdomain.com. We will also need to create a wildcard CNAME record to catch all subdomains using a record for *.ourdomain.com. For this demonstration we will be using the domain isO365down.com.

Once we have verified our new DNS records have propagated using NSLookup we are ready to start Evilginx2.

STARTING AND CONFIGURING EVILGINX

sudo evilginx

Bash

If everything is setup correctly you should be presented with the following screen.

To correct any errors complaining about DNS resolution make sure you replaced the sylink to /run/systemd/resolv/stub-resolv.conf with a symlink to /run/systemd/resolv/resolv.conf. If errors regarding being unable to bind on port 53 appear make sure you have stopped the systemd-resolved.service.

Now that Evilginx2 is running we can configure some basic settings needed to allow Evilginx2 to work.

To see the current configuration run the following command.

config

As you can see we do not have a domain or IP configured for our Evilginx2 instance. To configure each of those run the following commands.

config IP [external IP address]

config domain [domain you own]

None

Now that we have set the external IP and domain we are using we are ready to setup our phishlets. For this example we will be using the phishlet Outlook.

phishlets hostname [phishlet name] [subdomain.subdomain.domainyouown.com]

phishlets enable [phishlet]

Bash

After enabling the phishlet we configured, we will see that Evilginx2 reaches out to Let’s Encrypt to get a valid cert. If everything worked we should be able to run the command “phishlets” and see our domain and that our phishlet was enabled.

Now that we have enabled our phishlet we need to configure its lures.

lures create outlook

Bash

We can now see our phishlet lure and and its ID and current path by just typing “lures”

The last two things that need to be configured is our path and the URL we would like to redirect to after our target inputs a username and password.

lures edit path [ID] [path name]

lures edit redirect_url [ID] [URL]

None

Our final output should look like this.

If you want to see the full URL you have configured run the following command.

lures get-url [0]

Bash

Lets browse to our newly setup phishing site. As you can see below unless a user pays attention to the entire URL they could miss that they are not actually on Outlook.com but instead on login.outlook.com.iso365down.com/login.

BYPASSING 2FA

At this point we should have some usernames and passwords from users we have phished. We can verify this by running the command “sessions” which will list all data gathered so far. If we want more information we can run sessions [ID] and gather not only the username and password but all the session key needed to bypass 2FA.

Using the session key we capture we can the Chrome plugin EditThisCookie to import the cookie we captured and bypass 2FA for the account.

Now we have everything we need to impersonate a user and start moving laterally through systems. Happy hunting!  VDA would love to help your organization test the security of their staff with this and other advanced techniques, contact us about a pentest today.