Apache mod_rewrite provides conditional redirection and obfuscation to a red teamer’s infrastructure. I’ve previously written about mod_rewrite in a few posts. In this post, I will cover a few quick tricks you can use in conjunction with techniques from my earlier posts while phishing or red teaming.

Be sure you read the first-time setup instructions for mod_rewrite to configure your server to work properly.

Payload Hot-Swapping

We’ve all been in a situation where, just after sending out a large phishing batch, we realize that some aspect of the payload doesn’t work in the target environment. Previously, the batch would be burned. With mod_rewrite, we can create a ruleset to redirect requests for the original payload and redirect it to a new payload.

Let’s say our original payload, BonusesAndSalaries2017.hta, didn’t work and we want to replace it with BonusesAndSalaries2017.lnk. We could use the following htaccess ruleset:

Line by line explanation:

Delete the original payload and put the above ruleset in an htaccess file in the web root of the server hosting the original payload. While this technique works as a reaction a phishing issue, it also works proactively. By using a generic link (such as /BonusesAndSalaries2017) in the email, you can quickly modify the third line of the htaccess file to serve up your next payload.

Payload File Extension Obfuscation

Similar to payload hot-swapping, we can use mod_rewrite to help our phishing email look more believable to targets and email security appliances by hiding our payload’s true file extension. Imagine we are going to use an lnk payload, but want end-users to think they’re clicking on a link to a Word document. If our email used the <a> tags to obfuscate the link, a mouse-over or copy and paste thwarts the plan. Not to mention the fact that display text that doesn’t match the hyperlink destination raises your score in many spam filters.

Line by line explanation:

The mod_rewrite ruleset will redirect our docx link to the lnk and trigger a download in the end-user’s browser.

Here is a demo of this ruleset in action:

404 Redirection

In my post Invalid URI Redirection with Apache mod_rewrite, I covered a method of redirecting invalid URI requests to a chosen page. That method involves manually specifying allowed URIs, regardless of files present in the web directory on your server.

We can accomplish a similar function by redirecting all requests for nonexistent resources (404s) to a different page:

If you are only using your Apache server for redirection this is a quick method of filtering requests for invalid URIs. But, keep in mind that Apache will serve any valid files requested

Block Non-Standard HTTP Methods

Just as pentesters will use non-standard HTTP methods to gather intelligence from a target server, incident responders can use these HTTP methods against our infrastructure. To reduce that risk, we can allow GET and POST requests and redirect all others with the following ruleset:

Line by line explanation:

Summary

Apache mod_rewrite provides a multitude of functionality that is useful for offensive security assessments. With the mod_rewrite techniques covered in this post, we can conditionally redirect web requests to obfuscate our backend infrastructure and point incident responders in the wrong direction. The techniques covered in this post can be combined with other previously covered techniques to even greater effect.

Resources

• mod-rewrite-cheatsheet.com
• Official Apache 2.4 mod_rewrite Documentation
  • Apache mod_rewrite Introduction
• An In-Depth Guide to mod_rewrite for Apache