Using a combination of Cloudflare and HTML Obfuscation, it is possible to protect your Evilginx server from being flagged as deceptive and so increase your chances of success on Red Team and Social Engineering engagements.
Anyone who has tried to run a Social Engineering campaign will at some point seen the 'Deceptive site ahead' warning.
It's frustrating to have a purchased domain burned like this and, even worse, if it occurs after emails/SMS etc. have been sent out can badly affect the OPSEC of a Red Team engagement or waste a pretext (and alert end users) of a Social Engineering engagement.
TLDR
Cloudflare's 'Under Attack Mode' can be useful as a temporary defence whilst spinning up infrastructure.
Geo-blocking connections from outside of your geographical location and that of your targets can reduce the amount of scanners and crawlers touching your infrastructure.
Using another server as a redirector in front of your Evilginx server increases the chances of your links being seen as 'not malicious' by mail filters and other protections.
Meta-refresh and HTML obfuscation can allow this server to silently redirect target users to your Evilginx server without being flagged by Google Safe Browsing and other security mechanisms.
There are a few mechanisms that can cause a site to be reported as deceptive. Google Safe Browsing leverages web browsers, crawlers, and an API to detect malicious websites. Additionally, many third parties such as Netcraft and even academic institutions use web crawlers to map out the web. SSL certificate generation is logged publicly - many 'good' and 'bad' actors use these to see new or renewed certificates which suggests a site is active. Finally, email protection such as Mimecast, Proofpoint, and Microsoft will scan any links sent to inboxes and quarantine mail containing links they deem to be malicious. This is all good news for the end user, providing much needed protection and the detections are constantly improving. However, they are not infallible and good quality security testing should aim to bypass them to ensure proper defence-in-depth is in place when conducting engagements.
This post will hopefully make the above image a thing of the past. There's nothing ground-breaking, and the techniques are useless without some excellent tooling developed by others, but it is battle-tested and it works - for the moment!
Pre-requisites
In this post I'm going to assume that you, the reader, have a level of understanding of spinning up cloud infrastructure, buying domains, and making changes to DNS. I'm also going to assume that you're either a professional (with written authorisation to perform these sort of attacks), or a student practicing them on yourself to improve. In short, do not break any laws.
You'll also need:
2 domains
2 servers (hosted in a cloud of your choosing)
A Cloudflare account (free tier works absolutely fine for this)
Setup
One of the servers will host the Evilginx application on the first domain, and the other will be used to host another webserver using another domain that will serve as a redirector and help to mask our Evilginx landing page from any link scanners that might flag it as deceptive. Here's a couple of links to setup Evilginx and an Apache service:
Evilginx
(You will also need to remove the Evilginx HTTP Header)
Apache
(Other webservers of your choice also work fine for this)
Make sure your purchased domains are now pointing at the relevant IPv4 addresses. Then, ensure both the Evilginx and 'Apache' services have the relevant SSL certificates. Evilginx does this automatically when you spin up a phishlet for the first time, and the following link is helpful if you've gone the Apache route:
Lets Encrypt
It's essential to have these SSL certificates in place before attempting to use the Cloudflare service. On an OPSEC note, having these domains and certificates in plenty of time before the engagement is also highly recommended. Many corporate firewalls and email providers will restrict or even block anything that's less than 30 days old.
Cloudflare
Note: You must have SSL certificates in place for your Evilginx server and and/or any other domains before you add Cloudflare protections as certbot will fail to generate SSL certificates once the protections are in place.
Once you have your Evilginx server (make sure you disable the phishlet as soon as it's installed the SSL certificates) and 'Apache' server up and running with domains pointed at their IPv4 it's time to give them some protection using Cloudflare.
Adding a site
Adding your domain to Cloudflare is straightforward - just click on one of the many 'Add Site' buttons on your dashboard and follow the instructions to change the Nameserver from your current Domain registrar to Cloudflare's.
The change can take a few hours, which is why I recommend doing it early in the setup process. However, even before the domain moves it is possible to make all the necessary changes needed to add some extra protection to your infrastructure.
Note: It is worth adding all of your infrastructure and domains to Cloudflare when conducting SE engagements.
Temporary Protections
Whilst setting everything else up, a good temporary solution to protect your servers is to use 'Under Attack' mode in the 'Quick Actions' tab.
This will present a JavaScript challenge to every visitor to your server as seen below:
Having this appear for genuine users is likely to reduce the effectiveness of your campaign as giving users that extra second or two to think can make the difference between credentials being entered/captured or not. It is a useful temporary measure and has a granular level of control too which is worth experimenting with:
Geo-blocking
One of the most effective protections from web scrapers and link scanners that might happen across your infrastructure is restricting access by geographical location. From observation, most scrapers (plus email link scanners) are based in the US. If you're not in the US and your target is not in the US, you can save yourself a few headaches by simply blocking traffic that is not from your location or your target users. For example, if you're in the United Kingdom and your target users are too, you can add the following rule by clicking on Security>WAF>Create Rule from the left hand menu once you click on your domain:
This can be tweaked according to your location and your target users. Remember to 'Deploy'.
Botfight
Not that it will help with genuine security bots/scanners, but the less eyes on your infrastructure the better. Security>Bots
TLS - troubleshoot
This is not a protection per se, but a quirk that I've noticed with Cloudflare. At the point of your server being proxied by Cloudflare, the service automatically changes the SSL/TLS encryption mode from Full to Flexible. If you've set up Evilginx with only port 443 open, this will break the connection. Something to watch for as it may save you a bit of time troubleshooting the issue - the setting should be as below:
The option is found at SSL/TLS>Overview
Blacklist - troubleshoot
As Cloudflare utilises load balancers, occasionally you may find a request from the server that does not contain the required lure string to reach the phishlet page. This can cause a Cloudflare IP to be blacklisted when using the 'Blacklist unauth' option in Evilginx and potentially then block genuine traffic. To reduce the chances of this happening you can run the following commands prior to building Evilginx:
$ sed -i 's/from_ip := req.RemoteAddr/from_ip := req.Header.Get("CF-Connecting-IP")/' ./core/http_proxy.go
$ sed -i 's/\(parts := strings.SplitN(req.RemoteAddr, ":", 2)\)/\/\/\1/' ./core/http_proxy.go
$ sed -i 's/remote_addr := parts\[0\]/remote_addr := req.Header.Get("CF-Connecting-IP")/' ./core/http_proxy.goYou can run these sed commands at the same time when you remove the Evilginx HTTP Header ;)
Meta Refresh
At this point, you have two servers (Apache, Evilginx) hosting two domains (domain1, domain2) that now have some basic Cloudflare protections. The next step is to use domain1 to send target users to our Evilginx server on domain2. This will ensure that the domain2 and, in turn, the Evilginx server's direct link is never shared/sent and so is not flagged as deceptive. Enter meta refresh...
Meta refresh is a HTML element that instructs the page to refresh within a given time-frame. It can also be used to fetch a new URL and, therefore, used to redirect users:
The code used to force the meta refresh would look something like the below:
This can be stored on the Apache server as the index.html. Once the target user visits domain1 they will be redirected to domain2 after a one second pause. However, there is an issue in that Google's crawlers (and other vendors) are able to follow this link and will then hit the Evilginx server meaning it will then be flagged as deceptive.
Obfuscation
In the following blog, there is a useful technique of HTML obfuscation using JavaScript:
R-Tec blog
The tool it mentions is the HTML obfuscator below, but you can also make your own for less chance of detection.
HTML Obfuscator
Using a HTML obfuscator, the previous meta refresh code on domain1's index.html will now look like this:
Scanners and scrapers will not follow the link, but the target user's web browser will.
Further Defences
Placing a meta refresh code at the domain root which redirects to the genuine site you are trying to impersonate, using .htaccess and robots.txt, and Evilginx's built in blacklist feature, can help to reduce the opportunity for web crawlers, security products, and more astute target users from inspecting your Evilginx page.
Attack in full
With everything in place, the complete attack will run as below:
The great thing about standing up additional servers and domains in front of your Evilginx server is that you can have multiple pretexts/delivery methods in use. For example, you could have a phishlet for Office 365 running on Evilginx (domain2), an email campaign that uses domain1 on an Apache server, and an SMS campaign that uses domain3 on another Apache server.
Summary
The techniques mentioned in the post will help support an effective Social Engineering/Red Team engagement by reducing the risk of the Evilginx server being detected through automated scans and web crawlers. However, an effective campaign relies heavily on other elements, particularly with regard to domains. Purchasing a good/believable domain, making sure it is at least 30 days old before using, and building its credibility/reputation by sending emails to different email accounts you own will help bypass some email protections. Finally, don't let the technical aspects get in the way of a good pretext - pretext is king when it comes to SE.
Shout out to Kuba Gretzky (@mrgretzky) for the nudge in writing this blog post, and also for creating Evilginx. I highly recommend you check out the 'Evilginx Mastery' course at https://academy.breakdev.org/evilginx-mastery if you want to learn more about Evilginx. There are some great Discord communities that are active in the form of the official 'Evilginx Mastery' server and a 'Breakdev Red' server too - get involved!
Also shout out to the OmniCyber Security Red Team - these techniques have been refined over the last few years and, as in everything we do, has been a collaborative effort throughout.