RedWarden: Flexible CobaltStrike Malleable Redirector

by do son · May 21, 2021

RedWarden – Flexible CobaltStrike Malleable Redirector

Red Teaming business has seen several different great ideas on how to combat incident responders and misdirect them while offering resistant C2 redirectors network at the same time.

This work combines many of those great ideas into a one, lightweight utility, mimicking Apache2 in it’s roots of being a simple HTTP(S) reverse-proxy.

Combining Malleable C2 profiles understanding, knowledge of bad IP addresses pool, and a flexibility of easily adding new inspection and misrouting logic – resulted in having a crafty repellent for IR inspections.

Should any invalid inbound packet reach RedWarden – you can redirect, reset or just proxy it away!

Abstract

This program acts as an HTTP/HTTPS reverse-proxy with several restrictions imposed upon inbound C2 HTTP requests selecting which packets to direct to the Teamserver and which to drop, similarly to the .htaccess file restrictions mandated in Apache2’s mod_rewrite.

RedWarden was created to solve the problem of IR/AV/EDRs/Sandboxes evasion on the C2 redirector layer. It’s intended to supersede classical Apache2 + mod_rewrite setups used for that purpose.

Features:

Malleable C2 Profile parser able to validate inbound HTTP/S requests strictly according to malleable’s contract and drop outlaying packets in case of violation (Malleable Profiles 4.0+ with variants covered)
Ability to unfilter/repair unexpected and unwanted HTTP headers added by interim systems such as proxies and caches (think CloudFlare) in order to conform to a valid Malleable contract.
Integrated curated massive blacklist of IPv4 pools and ranges known to be associated with IT Security vendors
Grepable output log entries (in both Apache2 combined access log and custom RedWarden formats) useful to track peer connectivity events/issues
Ability to query connecting peer’s IPv4 address against IP Geolocation/whois information and confront that with predefined regular expressions to rule out peers connecting outside of trusted organizations/countries/cities etc.
Built-in Replay attacks mitigation enforced by logging accepted requests’ MD5 hashsums into a locally stored SQLite database and preventing requests previously accepted.
Allows to define ProxyPass statements to pass requests matching specific URL onto other Hosts
Support for multiple Teamservers
Support for many reverse-proxying Hosts/redirection sites giving in a randomized order – which lets load-balance traffic or build more versatile infrastructures
Can repair HTTP packets according to expected malleable contract in case some of the headers were corrupted in traffic
Sleepless nights spent on troubleshooting “why my Beacon doesn’t work over CloudFlare/CDN/Domain Fronting” are over now thanks to detailed verbose HTTP(S) requests/responses logs

The RedWarden takes Malleable C2 profile and teamserver’s hostname:port on its input. It then parses supplied malleable profile sections to understand the contract and pass through only those inbound requests that satisfied it while misdirecting others.

Sections such as http-stager, http-get, http-post and their corresponding URIs, headers, prepend/append patterns, User-Agent is all used to distinguish between legitimate beacon’s request and unrelated Internet noise or IR/AV/EDRs out of bound packets.

The program benefits from the marvelous known bad IP ranges coming from curi0usJack and the others.

Using an IP address blacklisting along with known bad keywords lookup through Reverse-IP DNS queries and HTTP headers inspection brings the reliability to considerably increase redirector’s resiliency to the unauthorized peers wanting to examine attacker infrastructures.

Invalid packets may be misrouted according to three strategies:

redirect: Simply redirect peers to other websites, such as Rick Roll.
reset: Kill TCP connection straightaway.
proxy: Fetch a response from another website, to mimic cloned/hijacked website as closely as possible.

This configuration is mandated in a configuration file:

#

# What to do with the request originating not conforming to Beacon, whitelisting or 

# ProxyPass inclusive statements: 

#   - 'redirect' it to another host with (HTTP 301), 

#   - 'reset' a TCP connection with connecting client

#   - 'proxy' the request, acting as a reverse-proxy against specified action_url 

#       (may be dangerous if client fetches something it shouldn't supposed to see!)

#

# Valid values: 'reset', 'redirect', 'proxy'. 

#

# Default: redirect

#

drop_action: redirect

The below example shows the outcome of redirect to https://googole.com: