Evilginx3: A Favorite Tool for Many Red Teamers
As part of our authorized engagements, customers often request us to simulate phishing for session tokens, which can bypass Multi-Factor Authentication. The Evilginx series by Kuba Gretzky has been an all-time favorite for many Red Teamers.
Some challenges we often face when deploying Evilginx3 include various operational security aspects and flaws that could increase detections. This post will discuss a few issues we'll overcome by configuring Evilginx3 to work with CloudFlare.
If we're not lucky and get detected during infrastructure setup, it could create massive distress to the Red Team, who are often very time-constrained and have limited resources to conduct an assessment. Some techniques discussed can be repurposed and deployed using redirectors or other technologies.
Operational Security Challenges with Evilginx3
An example of operational security issues observed when using Evilginx3 include:
Evilginx Header submitted within requests to the origin server that is being proxied.
Evilginx Server IP address (leaked to origin) that is hosting the Evilginx software. When the server connects to the origin, it will inevitably leak its IP address to the origin server - revealing its location.
Evilginx Server IP address (leaked to the internet) that is hosting the Evilginx software. When setting up the name server, the DNS requests are resolved through the Evilginx software, resulting in the same IP address for multiple subdomains. The design could be fingerprinted to identify potential Evilginx servers.
Evilginx Server IP address and hostnames (leaked to the internet) are requested in succession within a short period over LetsEncrypt through the combination of common subdomain combinations used by public phishlets.
We'll review how to defeat some of these issues and challenges when deploying Evilginx3.
Overcoming Challenges
1. Evilginx Header
A simple code modification can be made to overcome the Evilginx Header existing in the requests to the origin server. If you haven't taken the Evilginx Mastery course, we highly recommend you do so. Found here: https://academy.breakdev.org/evilginx-mastery. After going through the course, you'll most likely read the source code and see areas where the IOC has been baked to help defenders identify the traffic.
Daniel Underhay from Aura Infosec has published an Evilginx3 deployment script that removes the X-Evilginx header indicator: https://gist.github.com/dunderhay/d5fcded54cc88a1b7e12599839b6badb.
2. Evilginx Server IP address (leaked to origin)
To prevent the Evilginx server from leaking its IP address to the origin, it's possible to fix it in various ways. We've picked out two of the most obvious ways to discuss here - using a VPN from the server or setting up a proxy.
VPN from the server
Set up a VPN client connection from the Evilginx server so that all traffic goes through a VPN service. Before the proxy feature was identified, we used OpenVPN in the past, and it worked great to mask the traffic so that the IP address could be changed whenever needed.
Setting up a proxy
Use the 'proxy' command in Evilginx to display the proxy settings:
Setting up a proxy also helps give your server an IP address of the target location, which could help if the IP address or region is shown to the user.
To set up the proxy:
proxy type http
proxy address <your server>
proxy port <your port / 8080>
proxy username <username for your exposed proxy server>
proxy password <password for your exposed proxy server>
proxy enableRestart Evilginx for it to take effect.
Other tips or considerations: you could set up an HTTP or SOCKS proxy that will utilize and rotate over a couple of hundred servers to distribute the traffic across many IP addresses.
3. Evilginx Server IP address (leaked to the internet)
One essential part of the Evilginx setup process was ensuring the NS record was set to your server IP address. Let's say, for example, your IP address is 123.123.123.123. You had to set up an A record, such as ns.domain.com, to 123.123.123.123. Then, point the subdomain's (such as sub.domain.com) NS record to ns.domain.com. This would have ensured that Evilginx had control over the resolution of all subdomains under sub.domain.com, such as login.sub.domain.com. Whenever login.sub.domain.com (or any other subdomain) gets resolved, the Evilginx server will take over and respond 123.123.123.123 (as configured in the configuration).
The IP address that the Evilginx server would respond with was configured using the external_ipv4 variable using the command:
config external_ipv4 123.123.123.123The domain in which the responses would be given would be configured using:
config domain sub.domain.comDefenders can keep probing various subdomains of the configured domain, and if it resolves to the same IP address, it could raise suspicions. A way to overcome this is not to use the DNS server and block all UDP traffic to TCP port 53.
Using UFW:
sudo ufw deny proto udp to any port 53Using iptables:
sudo iptables -A INPUT -p udp --dport 53 -j DROP4. Evilginx Server IP address and hostnames (leaked to the internet)
The IP address can also be leaked using the automated LetsEncrypt SSL certificate grabber. Whenever you enable the phishlet, the Evilginx server tries to deploy SSL certificates for each subdomain by requesting it from LetsEncrypt.
Certificate transparency records can be tracked by defenders using tools like https://github.com/drfabiocastro/certwatcher, which can then be used to identify combinations of subdomains that may be suspicious. The defender can then begin scans against certain subdomains to determine if it's legitimate infrastructure. At this point, the defender could also log the server's IP address to find the Evilginx server IP address.
To overcome this issue, we recommend:
Change common subdomains used by the phishlet (if public)
Utilize a redirector
Use a wildcard SSL certificate
Change common subdomains used by the phishlet (if public)
To change the subdomains used by the phishlet, go to the YAML file and modify the following fields. Example below:
Modify the phish_sub values to unique values.
Utilize a redirector
Use a redirector to prevent leaking the IP address of your final Evilginx3 server. Software such as Apache or Nginx can be used, but we won't discuss that here.
Using CloudFlare, purchase their Total TLS and Advanced Certificate Service for around 10 USD monthly, allowing you to deploy TLS certificates for more than one subdomain level using this service. If you don't purchase the service, you'll have SSL trust issues later - such as what is shown below:
You'll have to set each subdomain up in the DNS records. However, allow CloudFlare to proxy the traffic and mask the origin IP address to prevent unauthorized access to your origin server. CloudFlare is a great solution that helps to reduce attacks against your server and can even incorporate WAF capabilities to protect against OWASP Top 10.
Something similar to the below should be set up for each DNS record:
After the subdomains are set, you can run Evilginx using self-signed certificates and debug mode using the command:
./evilginx -debug -developerPreventing Unauthorized Access to Origin Server
To take it a step further and ensure that no intruders are trying to access or attack our origin server, we can follow best practices and allow only CloudFlare traffic to connect to the origin server.
The following script found on GitHub seems to do the trick: https://gist.github.com/Manouchehri/cdd4e56db6596e7c3c5a.
for i in `curl https://www.cloudflare.com/ips-v4`; do iptables -I INPUT -p tcp -m multiport --dports http,https -s $i -j ACCEPT; done
for i in `curl https://www.cloudflare.com/ips-v6`; do ip6tables -I INPUT -p tcp -m multiport --dports http,https -s $i -j ACCEPT; done
# Avoid racking up billing/attacks
# WARNING: If you get attacked and CloudFlare drops you, your site(s) will be unreachable.
iptables -A INPUT -p tcp -m multiport --dports http,https -j DROP
ip6tables -A INPUT -p tcp -m multiport --dports http,https -j DROPAfter running the commands, try directly accessing the server from the internet based on the IP address, and you'll find that it can't be accessed anymore.
Conclusion
As always, it's a cat-and-mouse game where we're off trying to change some indicators to reduce detections. In Red Teaming, if we're easily detected, we often cannot deliver the same level of value that we could otherwise through realistic execution of attacks. Getting inside a cloud environment or viewing documents differs from telling a client, "oh, we've been detected; good job."
It's becoming increasingly difficult in the Red Team space as resources, time, and budget are often limited. At the same time, we're facing world-leading threat intelligence, EDR, and security teams who are innovating at insane speeds. Customer expectations of the Red Team being able to infiltrate and demonstrate "attacks" haven't decreased, although defense maturity is increasing rapidly.
From our experience, minor modifications to tooling, deployment, or how it's used can keep you going for another year or two. It's great to see research and tooling being released, allowing defenders to rapidly introduce new security controls and techniques to fend off such attacks.
We always preach many security best practices to customers, such as WAF, firewall rules, and other measures. These methods also work great to protect Red Team infrastructure from being attacked.
References
Evilginx3 Repository (note that the name says Evilginx2 but it's now Evilginx3): https://github.com/kgretzky/evilginx2
Evilginx Mastery: https://academy.breakdev.org/evilginx-mastery
Deployment Script by Daniel Underhay: https://gist.github.com/dunderhay/d5fcded54cc88a1b7e12599839b6badb