{
	"id": "33821fed-e166-48bb-a270-68d1bd3f612e",
	"created_at": "2026-04-06T00:19:28.548875Z",
	"updated_at": "2026-04-10T03:21:06.858461Z",
	"deleted_at": null,
	"sha1_hash": "68b8335d3044ce38fc04ad3fafae562a15d4eec3",
	"title": "Combatting Incident Responders with Apache mod_rewrite",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 66241,
	"plain_text": "Combatting Incident Responders with Apache mod_rewrite\r\nBy Jeff Dimmock\r\nPublished: 2016-04-12 · Archived: 2026-04-05 13:56:53 UTC\r\nAny phishing campaign involving an active incident response element usually requires some evasive steps to\r\nprolong its longevity. This often includes being stealthier, performing anti-forensics actions, or avoiding certain\r\ntradecraft altogether. Phishing is no different, and is often the most ‘vulnerable’ part of a campaign from an active\r\nIR perspective. Using a distributed infrastructure built with independent components helps reduce the risk of the\r\noverall architecture being blocked, but individual phishing campaigns are likely to be caught and blocked\r\nthroughout the duration. The longer we can stretch out the usability of each of those campaigns, the better our\r\nchances of gaining access.\r\nUsing Apache mod_rewrite rules, we can rewrite potential incident responder or security appliance requests to an\r\ninnocuous website or the target’s real website. While the methods discussed below won’t stave off a concerted\r\ninvestigation, it will hopefully make the malicious website pass the ‘sniff test’ with recipients and lower level help\r\ndesk or incident responders.\r\nIt’s important to note that these techniques could prevent valid phishing victims from reaching your malicious\r\nwebsite. You will need to weigh the risks of losing out on potential clicks against the risks posed by the target’s\r\nincident responders.\r\nBlock Common IR User Agents\r\nBlocking common incident responder or security appliance user agents is an easy way to reject a swath of traffic\r\nhitting your malicious website. I watch my web server’s Apache access logs like a hawk while a phishing\r\ncampaign is active. It usually doesn’t take long before web crawlers and security appliances start making GET\r\nrequests. That traffic is normal for web servers, but we don’t really want our malicious website being crawled,\r\nclassified, and archived when we’re trying to be stealthy.\r\nAdd the following ruleset to the top of any ruleset already in place, below the RewriteEngine On line, to redirect\r\nany blank or provided user agents to an alternate location. If you identify the security products your target uses\r\nand think it is performing heuristic analysis on the page for filtering purposes, you can additionally add a separate\r\ncopy of these rules to match the product(s) and proxy the request to the alternate site, rather than redirect.\r\nRewriteCond %{HTTP_USER_AGENT} \"wget|curl|HTTrack|crawl|google|bot|b\\-o\\-t|spider|baidu\" [NC,OR]\r\nRewriteCond %{HTTP_USER_AGENT} =\"\"\r\nRewriteRule ^.*$ http://COMPANYDOMAIN.com/404.html/? [L,R=302]\r\nLine by line explanation:\r\nIf the request's user agent matches any of the provided keywords, ignoring case. OR\r\nIf the request's user agent is blank\r\nhttps://bluescreenofjeff.com/2016-04-12-combatting-incident-responders-with-apache-mod_rewrite/\r\nPage 1 of 4\n\nChange the entire request to http://COMPANYDOMAIN.com/404.html/ and drop any query_strings from original\r\nrequest. Do not evaluate further rules and redirect the user, changing their address bar.\r\nAs mentioned in my first post about mod_rewrite, placing this ruleset in a .htaccess file allows changes to be\r\nmade on the fly without needing to restart the Apache service. We can make adjustments as the campaign\r\nprogresses if we notice more user agents that should be filtered. For a lengthy list of common user agents, check\r\nout useragentstring.com.\r\nIP Filtering\r\nIP filtering provides the ability to selectively proxy requests or redirect the user based upon the originating IP\r\naddress. We can monitor the Apache logs and modify filtering rules throughout the phishing campaign’s\r\nexecution.\r\nWhitelisting\r\nIP whitelisting is an option if you can determine the IP addresses or ranges from which the targets will originate.\r\nFor straight whitelisting, use the following ruleset:\r\nRewriteEngine On\r\nRewriteCond %{REMOTE_ADDR} ^100\\.0\\.0\\. [OR]\r\nRewriteCond %{REMOTE_ADDR} ^100\\.0\\.1\\.\r\nRewriteRule ^.*$ http://TEAMSERVER-IP%{REQUEST_URI} [P]\r\nRewriteRule ^.*$ http://COMPANYDOMAIN.com/404.html/? [L,R=302]\r\nLine by line explanation:\r\nEnable the rewrite engine\r\nIf the requestor's IP address starts with 100.0.0, ; OR\r\nIf the requestor's IP address starts with 100.0.1,\r\nChange the entire request to serve the original request path from the teamserver's IP, and keep the user's address\r\nbar the same (obscure the teamserver's IP).\r\nIf the above conditions are not met, change the entire request to http://COMPANYDOMAIN.com/404.html and\r\ndrop any query strings from the original request. Do not evaluate further rules and redirect the user, changing their\r\naddress bar.\r\nIn this example, any user visiting from 100.0.0.0/24 and 100.0.1.0/24 will have the original URI request proxied\r\nto the teamserver. Visitors from other IPs will be redirected to companydomain.com/404.html.\r\nDoing a simple whitelist will also block any users trying to load the page from a non-corporate IP, such as coffee\r\nshop, home, or mobile device. To slightly alleviate this risk, we can add a RewriteCond line to match requests\r\nfrom mobile user agents and allow those requests to access our site:\r\nRewriteEngine On\r\nRewriteCond %{HTTP_USER_AGENT} \"android|blackberry|googlebot-mobile|iemobile|ipad|iphone|ipod|opera\r\nmobile|palmos|webos\" [NC,OR]\r\nhttps://bluescreenofjeff.com/2016-04-12-combatting-incident-responders-with-apache-mod_rewrite/\r\nPage 2 of 4\n\nRewriteCond %{REMOTE_ADDR} ^100\\.0\\.0\\. [OR]\r\nRewriteCond %{REMOTE_ADDR} ^100\\.0\\.1\\.\r\nRewriteRule ^.*$ http://TEAMSERVER-IP%{REQUEST_URI} [P]\r\nRewriteRule ^.*$ http://REDIRECTION-URL.com/? [L,R=302]\r\nBlacklisting\r\nBlacklisting is inherently a reactive control, but can be useful on later phish campaigns after IR and control\r\nproduct’s IPs have been identified. The ruleset is just flipping the last two lines so that the RewriteCond matches\r\nare redirected instead of proxied to the teamserver:\r\nRewriteEngine On\r\nRewriteCond %{REMOTE_ADDR} ^100\\.0\\.0\\. [OR]\r\nRewriteCond %{REMOTE_ADDR} ^100\\.0\\.1\\.\r\nRewriteRule ^.*$ http://REDIRECTION-URL.com/? [L,R=302]\r\nRewriteRule ^.*$ http://TEAMSERVER-IP%{REQUEST_URI} [P]\r\nTime-Based Filtering\r\nTo reduce the risk of off-hours IR loading our malicious site, we can use the time-based server variables built into\r\nmod_write. For example, if we wanted to limit users to only load our site during business hours:\r\nRewriteEngine On\r\nRewriteCond %{TIME_HOUR}%{TIME_MIN} \u003e0600\r\nRewriteCond %{TIME_HOUR}%{TIME_MIN} \u003c2000\r\nRewriteRule ^.*$ http://TEAMSERVER-IP%{REQUEST_URI} [P]\r\nRewriteRule ^.*$ http://REDIRECTION-URL.com/? [L,R=302]\r\nLine by line explanation:\r\nEnable the rewrite engine\r\nIf the request time (hour and minute) is greater than 0600 server local time, AND\r\nIf the request time (hour and minute) is less than 2000 server local time,\r\nChange the entire request to serve the original request path from the teamserver's IP, and keep the user's address\r\nbar the same (obscure the teamserver's IP).\r\nIf the above conditions are not met, change the entire request to http://REDIRECTION-URL.com/ and drop any\r\nquery strings from the original request. Do not evaluate further rules and redirect the user, changing their address\r\nbar.\r\nAny requests received between the hours of 6am and 8pm are proxied to our malicious site. Any requests received\r\noutside that time range are redirected. Time calculation is based upon the server’s locale settings. Use the date\r\ncommand to verify the time zone before configuring this ruleset.\r\nWe can also filter based on the day of the week with the %{TIME_WDAY} server variable. The regex uses 0 - 6 to\r\nrepresent Sunday through Saturday. To match days, use \u003c, \u003e, or = in the regex portion of the RewriteCond line.\r\nhttps://bluescreenofjeff.com/2016-04-12-combatting-incident-responders-with-apache-mod_rewrite/\r\nPage 3 of 4\n\nFor example, the following RewriteCond rule matches Monday through Friday:\r\nRewriteCond %{TIME_WDAY} \u003e0\r\nRewriteCond %{TIME_WDAY} \u003c6\r\nSummary\r\nApache mod_rewrite provides a wealth of powerful features we can use to make a phishing campaign more\r\nresilient to detection. We can filter requests based upon a number of properties, including user agent, source IP,\r\nand time. By redirecting or proxying those requests to an innocuous website we increase the chances that the\r\ninvestigator or security appliance will disregard the phish and continue allowing access.\r\nStrengthen Your Phishing with Apache mod_rewrite Posts\r\nStrengthen Your Phishing with Apache mod_rewrite and Mobile User Redirection\r\nInvalid URI Redirection\r\nOperating System Based Redirection with Apache mod_rewrite\r\nCombatting Incident Responders with Apache mod_rewrite\r\nExpire Phishing Links with Apache RewriteMap\r\nResources\r\nmod-rewrite-cheatsheet.com\r\nOfficial Apache 2.4 mod_rewrite Documentation\r\nApache mod_rewrite Introduction\r\nAn In-Depth Guide to mod_rewrite for Apache\r\nSource: https://bluescreenofjeff.com/2016-04-12-combatting-incident-responders-with-apache-mod_rewrite/\r\nhttps://bluescreenofjeff.com/2016-04-12-combatting-incident-responders-with-apache-mod_rewrite/\r\nPage 4 of 4",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://bluescreenofjeff.com/2016-04-12-combatting-incident-responders-with-apache-mod_rewrite/"
	],
	"report_names": [
		"2016-04-12-combatting-incident-responders-with-apache-mod_rewrite"
	],
	"threat_actors": [],
	"ts_created_at": 1775434768,
	"ts_updated_at": 1775791266,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/68b8335d3044ce38fc04ad3fafae562a15d4eec3.pdf",
		"text": "https://archive.orkl.eu/68b8335d3044ce38fc04ad3fafae562a15d4eec3.txt",
		"img": "https://archive.orkl.eu/68b8335d3044ce38fc04ad3fafae562a15d4eec3.jpg"
	}
}