When creating a command-and-control infrastructure, it is common for the callbacks to not communicate directly to the attacker’s C2 server. Many times, they will go through a compromised webpage, or a fake site used as a redirector. A redirector is basically a server that will take requests and forward them to another address, such as the real malicious server. This is to hide the underlying attacker address if the C2 traffic is ever discovered.
Have you ever analyzed a web address that was flagged as malicious, only to see a seemingly benign or a 404-error page? This may indicate that the page is not malicious or no longer existing, but it could also indicate the page is being used as a redirector/proxy.
Apache, Nginx, and other web servers have the ability to proxy/redirect traffic when desired conditions are met. This is useful from an attacking perspective as it can add an extra layer of obfuscation to an analyst observing the traffic.
To demonstrate this, we set up a public facing Apache server at domain “pc-tech.pro” as a redirector and configured the .htaccess file to proxy or redirect traffic based on different “rules”. This can be done through Apache’s mod_rewrite.
What the above .htaccess file does, is that every web request to our domain will be redirected or proxied based on the RewriteConditions. The logic of this file is as follows:
1) If the requested URL is any of:
2) The user-agent string is:
- “Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko”
3) Proxy traffic to http://184.108.40.206 (our Cobalt Strike server) at the requested URL
4) Return a 302 (Found) response and redirect to https://computertechpro.net (some other legitimate site) at the requested URL
To demonstrate how these rules work, we added a plugin to a Firefox web browser to change the user-agent in the requests. We then hosted a file on our Cobalt Strike attacker server to show what conditions need to be met to observe it.
Modifying for C2 traffic
Within Cobalt Strike’s malleable C2 framework, fields such as the user-agent and callback URLs can be modified based on the infrastructure needs. For this specific configuration, the malleable C2 user-agent was set to match that of our Apache mod_rewrite rules, as well as the URLs used for GET and POST requests.
The below Wireshark capture is from the Cobalt Strike payload being executed. The user-agent and the requested URL match that of the Apache webserver configuration, so the server responds with a 200 (OK) code and our traffic is proxied to our Cobalt Strike C2 server. The resulting beacon can be seen below.
*pc-tech.pro is located at IP 220.127.116.11*
The source IP address can be seen as 18.104.22.168, which is our Apache server.
The following Wireshark capture is that of a browser requesting the same URL, but as the user-agent string is not correct, the Apache webserver returns a 302-redirect response, and forwards the session to “computertechpro.net”. As this page does not exist, a 404-error page is returned.
Below is a diagram which illustrates the above concept on a high-level.
This example is meant to be an introduction to the concept of redirection to hide C2 infrastructure. These tactics can become much more complex based on how complex the rule sets on the redirectors are.
These tactics can also be used in the instance of compromised domains. An attacker could compromise a legitimate website and modify the server configuration files to redirect certain users to malicious addresses. If this is a trusted site, it may not return as malicious on threat feeds or other intelligence.