evilgophish is a combination Of Evilginx2 And GoPhish

As a penetration tester or red teamer, you may have heard of evilginx2 as a proxy man-in-the-middle framework capable of bypassing two-factor/multi-factor authentication. This is enticing to us to say the least, but when trying to use it for social engineering engagements, there are some issues off the bat. I will highlight the two main problems that have been addressed with this project, although some other bugs have been fixed in this version which I will highlight later.

  • Lack of tracking – evilginx2 does not provide unique tracking statistics per victim (e.g. opened email, clicked link, etc.), this is problematic for clients who want/need/pay for these statistics when signing up for a social engineering engagement.
  • Session overwriting with NAT and proxying – evilginx2 bases a lot of logic off of remote IP address and will whitelist an IP for 10 minutes after the victim triggers a lure path. evilginx2 will then skip creating a new session for the IP address if it triggers the lure path again (if still in the 10 minute window). This presents issues for us if our victims are behind a firewall all sharing the same public IP address, as the same session within evilginx2 will continue to overwrite with multiple victim’s data, leading to missed and lost data. This also presents an issue for our proxy setup, since localhost is the only IP address requesting evilginx2.

Background

This project is based on this blog and I encourage you to read it before getting started. In this setup, GoPhish is used to send emails, track opened emails, and provide a dashboard for evilginx2 campaign statistics, but it is not used for any landing pages. To provide tracking between the two, the function resposible for providing campaign results inside GoPhish has been modified to instead get clicked link event details and submitted data event details from logs related to evilginx2. Your phishing links sent from GoPhish will point to an evilginx2 lure path and evilginx2 will be used for landing pages. This provides the ability to still bypass 2FA/MFA with evilginx2, without losing those precious stats. The operator will also be informed of a submitted data event in realtime. This should ensure the operator won’t run out of time to use captured cookies, or at least be informed as soon as possible. The operator will still need to bounce over to the evilginx2 terminal to fetch the full JSON string of captured tokens/cookies.

Infrastructure Layout

  • evilginx2 will listen locally on port 8443
  • GoPhish will listen locally on port 8080
  • Apache2 will listen on port 443 externally and proxy to either local GoPhish/evilginx2 depending on the subdomain name requested. Apache2 access log file is created for both GoPhish/evilginx2 servers
    • Requests will be filtered at Apache2 layer based on redirect rules and IP blacklist configuration
      • 404 functionality for unauthorized requests is still baked into GoPhish if a request hits the GoPhish server
      • Redirect functionality for unauthorized requests is still baked into evilginx2 if a request hits the evilginx2 server

setup.sh

Assuming you have read the blog and understand how the setup works, setup.sh has been provided to automate the needed configurations for you. Once this script is run and you’ve fed it the right values, you should be ready to get started. Below is the setup help (note that certificate setup is based on letsencrypt filenames):

Usage:
setup
root domain – the root domain to be used for the campaign
evilginx2 subdomains – a space separated list of evilginx2 subdomains, can be one if only one
evilginx2 root domain bool – true or false to proxy root domain to evilginx2
gophish subdomains – a space separated list of gophish subdomains, can be one if only one
gophish root domain bool – true or false to proxy root domain to gophish
redirect url – URL to redirect unauthorized Apache requests
Pusher messages bool – true or false to setup Pusher messages to an encrypted channel
rid replacement – replace the gophish default “rid” in phishing URLs with this value
Example:
./setup.sh example.com login false “download www” false https://redirect.com/ true user_id

Redirect rules have been included to keep unwanted visitors from visiting the phishing server as well as an IP blacklist. The blacklist contains IP addresses/blocks owned by ProofPoint, Microsoft, TrendMicro, etc. Redirect rules will redirect known “bad” remote hostnames as well as User-Agent strings.

replace_rid.sh

In case you ran setup.sh once and already replaced the default RId value throughout the project, replace_rid.sh was created to replace the RId value again.

Usage:
replace_rid
previous rid – the previous rid value that was replaced
new rid – the new rid value to replace the previous
Example:
replace_rid.sh user_id client_id

Email Campaign Setup

Once setup.sh is run, the next steps are:

  • Make sure the Apache2 log file for evilginx2 exists before starting GoPhish (starting Apache2 will automatically do this)
  • Start GoPhish and configure email template (see note below about email opened tracking), email sending profile, fake landing page, and groups
  • Start evilginx2 and configure phishlet and lure
  • Ensure Apache2 server is started
  • Launch campaign from GoPhish and make the landing URL your lure path for evilginx2 phishlet
  • PROFIT
Download