You Can’t See Me – Protecting Your Phishing Infrastructure

By Red Siege | January 10, 2024

By: Mike Saunders, Principal Security Consultant

If you’re a red teamer, you may know the pain of spending hours building your phishing infrastructure, setting up your phishing sites and landing pages, tweaking your campaign, only to have your infrastructure burned to the ground before you even get started because of an intrepid defender or an automated scanning service like Netcraft. Protecting your infrastructure is a critical component to a successful campaign, but it doesn’t have to be overwhelming. Here are a few simple steps you can take to begin protecting your infrastructure from prying eyes.

While we’re going to discuss using Apache mod_rewrite to protect your phishing site here, these techniques can be adapted to protect your C2 infrastructure as well. A well-crafted set of mod_rewrite rules can keep the prying eyes of automated scanners away from your infrastructure, preventing these services from alerting your target before you’ve had a chance to start your campaign. The general approach is to write a ruleset that will shun known user agents and IP ranges associated with these automated services and redirect them to an inert landing page or redirect them to another site entirely.


Setting Up Apache mod_rewrite

Apache’s mod_rewrite isn’t enabled by default. Use the following command to enable mod_rewrite on your Apache server:

sudo a2enmod rewrite

Restart your Apache server to load the rewrite module with the following command:

sudo systemctl restart apache2

Mod_rewrite rules get placed in a file; I’ll be using the name redirect.rules here. While redirect rules can be loaded via an .htaccess file, I’ll be enabling and consuming those rules by modifying the Apache configuration file. For this example, we’ll assume the Apache configuration file is /etc/apache2/sites-available/000-default.conf. I need to add the following lines inside the VirtualHost definition to tell Apache to enable the rewrite engine and load the rules.

RewriteEngine On
Include /etc/apache2/redirect.rules


Setting Up Rules – IPs

At the beginning of your redirect.rules, you need to define the redirect target – that is, the location where the visiting browser or crawler will be redirected to. This may be an inert landing page on your phishing infrastructure, a redirect to your target’s website, or another website altogether. In the example below, I’ve defined the REDIR_TARGET to be Google , causing the requester to be redirected to Google if there’s a rule match. I’ll also tell mod_rewrite to turn the rewrite engine on and set the rewrite options to inherit.

RewriteEngine On
RewriteOptions Inherit

Now it’s time to define some rules. In the example below, we define a rewrite condition using Apache expression syntax. -R 'a.b.c.d/x' tells mod_rewrite to match the REMOTE_ADDR – that is to say the remote IP address connecting to your web server. This format allows for specifying a single IP or matching an IP to a subnet. Each rule for an IP-based match should end in [OR]. Failing to put [OR] at the end of each rule will cause your ruleset to fail open, exposing your infrastructure, and generally causing a bad day.

RewriteCond expr "-R 'a.b.c.d/x'" [OR]

A good starting point for your ruleset is Jason Lang’s gist of known IP ranges. Brandon Scholet has put together a script, get_cloud_ips, that will grab the IP addresses associated with many known cloud infrastructure providers as well as the IPs provided in Jason Lang’s ruleset.


Setting Up Rules – User Agents

Once we have a list of IPs we’d like to block, it’s a good idea to block requests based on the HTTP user agent string. To block requests from the Google Googlebot, we’d write a rule that looks like the example below. Note that in addition to the [OR], we’ve added NC, which tells mod_rewrite to do a case-insensitive match on the user agent string.

RewriteCond %{HTTP_USER_AGENT} ^.*Googlebot.*$ [OR,NC]

Since cloud provider IP ranges change frequently, it’s also a good idea to try to block services based on their DNS names. In the example rule below, we block requests from any IP range that has a reverse DNS entry matching the known Exchange Online DNS format.

RewriteCond %{REMOTE_HOST} ^.*$ [OR,NC]

Rather than building the list of user agents and remote host names manually, you can use the list provided by the EvilGoPhish project. Note that there are a few rules in this list that omit the required [OR] statement. If you don’t fix these errors, your ruleset will fail open and expose your infrastructure.


Putting it All Together

Once you’ve assembled your rules, ensure that the final rule in your ruleset does not contain an [OR] statement. Apache will fail to start correctly due to this error. The final line of your rules file will contain a RewriteRule directive that tells mod_rewrite where to redirect the requester to if any of the previous conditions resulted in a match. In the example below, the uncommented redirect rule will redirect the requester to the host defined in the REDIR_TARGET, which we previously defined as Google

# Redirect anything that matches above
RewriteRule ^.*$ %{REQUEST_SCHEME}://${REDIR_TARGET}/ [QSD,L,R=303]

When doing payload phishing, you may want to redirect to an inert payload instead of redirecting to a different site. We can accomplish this easily by following the example below.

# Rewrite URL to server an inert file on the server
RewriteRule ^.*$ /inertfile.pdf? [L,R=303]

Let’s take a look at what it looks like in action. We want to see what the phishing site will look like to our target, so we load it in a browser. In the example below, we’re going to spoof the Microsoft365 login page.


Phishing Landing Page

Phishing Landing Page


We want to make sure our phishing site is protected from “Mike’s Totally Super Threat Intelligence Service,” so we’ll create a simple rule that matches their user agent and redirects them to an inert landing page.

RewriteCond %{HTTP_USER_AGENT} ^MikesThreatIntelligencebot.*$ [NC]
# Redirect anything that matches above
RewriteRule ^.*$ %{REQUEST_SCHEME}:/inert.html [QSD,L,R=303]


Request Redirected to Inert Landing Page

Request Redirected to Inert Landing Page


Protecting your phishing infrastructure is crucial for a successful campaign, but it doesn’t have to be difficult. You can use freely available resources to implement a shield for your infrastructure in just a few minutes.


About Mike Saunders, Principal Security Consultant:

Mike Saunders

Principal Consultant

Mike Saunders is Red Siege Information Security’s Principal Consultant. Mike has over 25 years of IT and security expertise, having worked in the ISP, banking, insurance, and agriculture businesses. Mike gained knowledge in a range of roles throughout his career, including system and network administration, development, and security architecture. Mike is a highly regarded and experienced international speaker with notable cybersecurity talks at conferences such as DerbyCon, Circle City Con, SANS Enterprise Summit, and NorthSec, in addition to having more than a decade of experience as a penetration tester. You can find Mike’s in-depth technical blogs and tool releases online and learn from his several offensive and defensive-focused SiegeCasts. He has been a member of the NCCCDC Red Team on several occasions and is the Lead Red Team Operator for Red Siege Information Security.


Connect on Twitter & LinkedIn

Adventures in Shellcode Obfuscation! Part 1: Overview

By Red Siege | June 17, 2024

by Mike Saunders, Principal Security Consultant This blog is the first in a series of articles on methods for obfuscating shellcode. I’ll be focusing on how to obfuscate shellcode to […]

Learn More
Adventures in Shellcode Obfuscation! Part 1: Overview

Essential Steps for Management to Maximize the Value of a Penetration Test Report

By Red Siege | June 3, 2024

by Tim Medin, CEO Penetration testing is a critical component of a well-rounded cybersecurity strategy. Penetration testing identifies vulnerabilities before malicious actors can exploit them. However, the true value of […]

Learn More
Essential Steps for Management to Maximize the Value of a Penetration Test Report

Fun With JWT X5u

By Red Siege | May 30, 2024

by Senior Security Consultant Douglas Berdeaux On a recent web application penetration test engagement, I came across a JSON Web Token (JWT) that contained an x5u header parameter. I almost […]

Learn More
Fun With JWT X5u

Find Out What’s Next

Stay in the loop with our upcoming events.