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

Using Microsoft Dev Tunnels for C2 Redirection

By Red Siege | April 9, 2024

by Justin Palk, Senior Security Consultant   As penetration testers, we’re always on the lookout for new ways to get our command-and-control (C2) traffic out of a client’s network, evading […]

Learn More
Using Microsoft Dev Tunnels for C2 Redirection

SSHishing – Abusing Shortcut Files and the Windows SSH Client for Initial Access

By Red Siege | April 1, 2024

By: Alex Reid, Current Red Siege Intern   In the April 2018 release of Windows 10 version 1803, Microsoft announced that the Windows OpenSSH client would ship and be enabled […]

Learn More
SSHishing – Abusing Shortcut Files and the Windows SSH Client for Initial Access

Navigating Active Directory Security with EDD

By Red Siege | March 21, 2024

Tool developed by: Chris Truncer   Leverage EDD for Advanced Offensive Strategies EDD serves as a critical tool for offensive security professionals, enhancing domain reconnaissance with .NET efficiency. It facilitates a […]

Learn More
Navigating Active Directory Security with EDD

Find Out What’s Next

Stay in the loop with our upcoming events.