PHISHING USERS USING EVILGINX AND BYPASSING 2FA

Original text by Austin Downing

Phishing Users using Evilginx and Bypassing 2FA

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.

sudo rm /etc/resolv.conf

sudo ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf

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

[internal IP] ourdomain.com

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.

Реклама

Modlishka — An Open Source Phishing Tool With 2FA Authentication

Original text by Lydecher black


Modlishka — An Open Source Phishing Tool With 2FA Authentication

Modlishka is a flexible and powerful reverse proxy, that will take your phishing campaigns to the next level (with minimal effort required from your side).
Enjoy 🙂

Features
Some of the most important ‘Modlishka’ features :

  • Support for majority of 2FA authentication schemes (by design).
  • No website templates (just point Modlishka to the target domain — in most cases, it will be handled automatically).
  • Full control of «cross» origin TLS traffic flow from your victims browsers.
  • Flexible and easily configurable phishing scenarios through configuration options.
  • Pattern based JavaScript payload injection.
  • Striping website from all encryption and security headers (back to 90’s MITM style).
  • User credential harvesting (with context based on URL parameter passed identifiers).
  • Can be extended with your ideas through plugins.
  • Stateless design. Can be scaled up easily for an arbitrary number of users — ex. through a DNS load balancer.
  • Web panel with a summary of collected credentials and user session impersonation (beta).
  • Written in Go.

Action
«A picture is worth a thousand words»:
Modlishka in action against an example 2FA (SMS) enabled authentication scheme:

Note: google.com was chosen here just as a POC.

Installation
Latest source code version can be fetched from here (zip) or here (tar).
Fetch the code with ‘go get’ :

$ go get -u github.com/drk1wi/Modlishka

Compile the binary and you are ready to go:

$ cd $GOPATH/src/github.com/drk1wi/Modlishka/
$ make
# ./dist/proxy -h


Usage of ./dist/proxy:
      
  -cert string
     base64 encoded TLS certificate
  
  -certKey string
     base64 encoded TLS certificate key
  
  -certPool string
     base64 encoded Certification Authority certificate
  
  -config string
     JSON configuration file. Convenient instead of using command line switches.
  
  -credParams string
       Credential regexp collector with matching groups. Example: base64(username_regex),base64(password_regex)

  -debug
     Print debug information
  
  -disableSecurity
     Disable security features like anti-SSRF. Disable at your own risk.
  
  -jsRules string
     Comma separated list of URL patterns and JS base64 encoded payloads that will be injected. 
  
  -listeningAddress string
     Listening address (default "127.0.0.1")
  
  -listeningPort string
     Listening port (default "443")
  
  -log string
     Local file to which fetched requests will be written (appended)
  
  -phishing string
     Phishing domain to create - Ex.: target.co
  
  -plugins string
     Comma seperated list of enabled plugin names (default "all")
  
  -postOnly
     Log only HTTP POST requests
  
  -rules string
     Comma separated list of 'string' patterns and their replacements. 
  
  -target string
     Main target to proxy - Ex.: https://target.com
  
  -targetRes string
     Comma separated list of target subdomains that need to pass through the  proxy 
  
  -terminateTriggers string
     Comma separated list of URLs from target's origin which will trigger session termination
  
  -terminateUrl string
     URL to redirect the client after session termination triggers
  
  -tls
     Enable TLS (default false)
  
  -trackingCookie string
     Name of the HTTP cookie used to track the victim (default "id")
  
  -trackingParam string
     Name of the HTTP parameter used to track the victim (default "id")

Usage

  • Check out the wiki page for a more detailed overview of the tool usage.
  • FAQ (Frequently Asked Questions)
  • Blog post

Credits
Thanks for helping with the code go to Giuseppe Trotta (@Giutro)