A Hunt How-To: Detecting RedGuard C2 Redirector

If you’re like me, you’ve likely read multiple reports on network intrusions involving a “standard” deployment of Cobalt Strike (or your favorite framework) and the difficulties defenders encountered in detecting the deployed malware and denying adversary infrastructure from communicating with their networks. A redirector further complicates IR efforts by hiding the actual C2 server.

This blog post will provide tips and a practical example of detecting RedGuard, a popular open-source redirector built to work with any exploitation framework but built explicitly with Cobalt Strike in mind.

Note: Blocking redirector infrastructure does not mean you’ve blocked the C2 server. Detecting these servers does, however, give us additional insight into their use and possible pivot points to the controller.

What’s A Redirector?

Blue Teamers have improved drastically at creating signatures for and burning adversary infrastructure. Hunt, Censys, and Shodan are just a few sites that actively detect and track some of the more well-known and not-so-famous malware and post-exploitation tools.

As the name implies, a redirector server directs requests to the C2 server if it meets specific criteria or away from it to throw off investigators. I’ll provide a quick example below to explain the concept better.

Figure 1: Simplified example of a C2 redirector

If redirectors were absent from the communications between the target and C2, it would be trivial for defenders to find and block the malicious server. Since my design skills aren’t the best, we’ll extend the explanation below of how traffic forwarding or redirecting assists operators.

• At its most basic level, a redirector is a proxy server that filters specific requests to the C2 server or another destination.
• In the above example, our fictitious implant on the target host will connect to the redirector while our C2 listens for incoming traffic from a specific port.
• If the implant is configured to connect to the redirector on port 4444, RedGuard (or a similar tool) will forward that traffic to the controller, which listens for incoming redirector connections. A firewall rule should be in place to deny all other outgoing traffic from the C2.
• Different flavors of redirectors come with varying configuration options; some filter traffic by the time of day, deny specific IPs and reroute them, allow only certain User-Agents to connect to the C2, etc.

Below is an example of what defenders, scanners, etc., would see when making network requests to a RedGuard server (IP: 45[.]136[.]14[.]85)

Figure 2: Example HTTP response for RedGuard

RedGuard Overview

Figure 3: RedGuard readme: https[:]//github.com/wikiZ/RedGuard

As we’ve already covered the purpose of a redirector, I’ll only highlight some of what makes RedGuard attractive for red teamers and adversaries alike (from RedGuard Github).

• Prevent malware sample analysis by identifying cloud sandboxes based on JA3 fingerprint libraries.
• A malleable C2 Profile parser capable of validating inbound HTTP/S requests strictly against a malleable profile and dropping outgoing packets in case of violation (supports Malleable Profiles 4.0+).
• Random TLS JARM fingerprints are updated each time RedGuard is started to prevent this from being used to authenticate C2 infrastructure.

With such an extensive readme, I’ll leave it as a challenge to the reader to become familiar with every feature of RedGuard. If you haven’t guessed yet, as this is an open-source tool, we will use GitHub to review the project’s code and devise rules or signatures to track the RedGuard redirector.

Let’s Hunt!

When investigating an open-source RAT, redirector, or other tool in GitHub, it's best to start with the configuration file or look for references to HTML or HTTP responses. From here, we can gather information about the makeup of the server, which will assist in developing a signature to hunt with.

RedGuard servers and many more are being tracked in near real-time and are available to users now. See Figure 4 below for a snippet of the infrastructure we are seeing.

Figure 4: Snippet of RedGuard servers tracked in Hunt

Scrolling down not too far from the introductory paragraph of the tool, we stumble upon a list of default arguments for RedGuard, as seen in Figure 5 below.

Figure 5: RedGuard default arguments

The usage example provides us with a wealth of information we can immediately use to construct queries to identify RedGuard. Some of the more interesting items we can extract are:

• Certificate Common Name is “*.aliyun[.]com”.
• The default ports are 80 & 443.
• TLS cert Locality is “HangZhou.”
• TLS cert organization is “Alibaba (China) Technology Co., Ltd.”
• The redirect location is https[:]//360[.]net (not shown).
• Cobalt Strike is the preset C2 server type (not shown).

With that information, we have a default certificate of:

C=CN,L=HangZhou,O=Alibaba (China) Technology Co., Ltd.,CN=*.aliyun.com

Assuming you are logged in and familiar with GitHub, we can use the search bar to look for additional artifacts associated with the previously identified certificate.

Figure 6: RedGuard config file containing default DNS names

We’ve finally found the configuration file, but there’s not much new information that we didn’t discuss above. However, on line 5, a handful of hostnames are also set for the user, which could help create a detection query.

Whenever I encounter an interesting TLS certificate, I first check its prevalence online.

Figure 7: Hunt results for RedGuard certificate

Infrastructure hunting starts with many results (likely some false positives) and filters down to a more manageable number containing the servers we seek. We’ll need to add some of the default information we covered earlier to create a more robust query.

This tool redirects traffic, but we haven’t yet covered which type of HTTP redirection we are dealing with. Let’s head back to the repository and see what we can find.

Figure 8: RedGuard Handler. go source code

The HTTP status code for a temporary redirect is 307. Combined with everything we’ve found so far, this information is enough to build a query to detect RedGuard's default usage.

Let’s step back and recap all possible indicators for our detection query:

• Default Aliyun certificate + DNS names.
• Default ports 80 & 443.
• Redirection Location → https[:]//360[.]net
• HTTP 307 Temporary Redirect

You’ll notice I underlined “default” above. The ease of access to the source code of open-source projects also means adversaries can access the code and change items (ports, redirect location, certificates, etc.) at will.

The bulleted items will only detect lazy adversaries, and something as simple as changing the port would cause defenders to lose sight of additional infrastructure. To combat this, let’s remove some defaults from our search. Below is a highly simplified pseudo query that should help bring everything home.

Query: “HTTP status code equals 307 AND HTTP location response header equals * AND TLS certificate common name equals *.aliyun[.]com “

Of course, we can add items to our query, like the Content-Type, Date, and Content-Length headers, though the latter two are subject to change. Adding the “Temporary Redirect” HREF tag from the body of the page would also help us narrow down our results. Make sure you save your queries somewhere and annotate the results for each version you try.

Conclusion

In this post, we lightly touched on the purpose of a C2 redirector and how it prevents red teamers and adversaries from needing to expose their command and control infrastructure to the world. We also looked at RedGuard, an open-source tool with many configuration options. A pseudo query was created to cast a wider net of the redirector servers instead of only finding those using the absolute defaults.

There are many other redirection options on GitHub, such as RedWarden and BounceBack, just to name a few. Apply for a Hunt account today, and let us know what additional redirectors you would like to see tracked on the platform.

Get a Free Demo Today