mirror of
https://github.com/wikiZ/RedGuard
synced 2026-06-08 18:18:32 +00:00
Compare commits
11 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
 风起
|
588f3faecc | ||
|
风起
|
82c96c807b | ||
|
风起
|
72b3607167 | ||
|
风起
|
818b98bf55 | ||
|
风起
|
fde5465503 | ||
|
风起
|
febd771e03 | ||
|
风起
|
fbbdd73c8f | ||
|
风起
|
cdd932df83 | ||
|
风起
|
5348ff449a | ||
|
风起
|
b910109b0c | ||
|
风起
|
88fc891a83 |
@@ -1,3 +1,7 @@
|
||||
## [24.06.18.2001] - 2024-06-18
|
||||
### Update
|
||||
- Optimized the problem of requesting regional restriction matching errors
|
||||
|
||||
## [23.08.21.0113] - 2023-08-21
|
||||
### Added
|
||||
- Custom Delete Response Fields
|
||||
|
||||
@@ -80,6 +80,55 @@ In the case of using your own certificate, modify the HasCert parameter in the c
|
||||
HasCert = false
|
||||
```
|
||||
|
||||
### Forged TLS certificates
|
||||
|
||||
When deploying a Domain fronting to hide C2 traffic, the accelerated domain name does not have HTTPS certificate information by default. This is obviously problematic, so you need to pay attention to configuring the certificate when configuring the domain name. This is also the default basis for determining whether the sample is domain front-end traffic.
|
||||
|
||||
|
||||
|
||||
[^Tencent Cloud]: Content Delivery Network Certificate Configuration
|
||||
|
||||
I believe that everyone will have some questions after reading this, **How to obtain the configured certificate? If you use your own application for the certificate, it will not meet the anonymity effect we expect.** Here you can use the cloned certificate for configuration. Taking Tencent Cloud as an example, it was found in the test that it would not verify the validity of the custom uploaded certificate. We can use the same certificate as the actual site of the accelerated domain name to forge it. Although the forged certificate cannot communicate when replacing the default certificate of CS under normal circumstances, it will not verify the validity when deployed on the cloud service provider CDN full-site acceleration and RedGuard, and C2 interactive traffic can communicate normally.
|
||||
|
||||
**The following is the existing project address on Github**
|
||||
|
||||
```bash
|
||||
https://github.com/virusdefender/copy-cert
|
||||
```
|
||||
|
||||
Although the certificate on the front-end traffic side of the sample domain has been resolved, from the perspective of large-scale network mapping, our C2 server is still exposed to the outside world and may still be detected and associated with the real C2 server. At this time, RedGuard can be used to modify the fronting default certificate of C2 to achieve anonymity.
|
||||
|
||||
|
||||
|
||||
[^intelligence information]: TLS Certificates
|
||||
|
||||
The above is the effect of the forged certificate of the C2 server. It can be seen that it is credible and not expired in the intelligence of the Threatbook community. The main way to obtain the digital certificate is to extract and update it in real time during sample analysis in the cloud sandbox, but it is obviously not effectively verified. The status value only verifies the expiration time. The certificate trust verification should only be based on whether normal communication can be achieved.
|
||||
|
||||
It should be noted that Threatbook intelligence does not mark the SNI and HOST addresses of sample requests with certificate intelligence. This is actually to prevent false positives. I think this is correct. As an important basis for assisting researchers in analysis, threat intelligence is better to be incomplete than to point to the wrong direction, which will cause misjudgment in subsequent analysis. If configuring certificates for full-site acceleration is to forge certificates for communication traffic, then configuring the pre-response certificate of RedGuard C2 is to forge the behavioral characteristics of the real C2 server deployed on the public network to achieve anti-mapping effects, which is very necessary.
|
||||
|
||||
Extract the certificate serial number: `55e6acaed1f8a430f9a938c5`, and perform HEX encoding to obtain the TLS certificate fingerprint: `26585094245224241434632730821`
|
||||
|
||||
| IP | Port | Protocol | Service | Country | City | Title | Time |
|
||||
| :------------: | :--: | :------: | :----------: | :-----: | :----: | :-------------------: | :--------: |
|
||||
| 103.211.xx.90 | 443 | https | Apache httpd | China | Suzhou | 百度图片-发现多彩世界 | 2023-08-28 |
|
||||
| 223.113.xx.207 | 443 | https | JSP3 | China | Xuzhou | 403 Forbidden | 2023-08-28 |
|
||||
| 223.112.xx.48 | 443 | https | JSP3 | China | Xuzhou | 403 Forbidden | 2023-08-28 |
|
||||
| 223.113.xx.40 | 443 | https | JSP3 | China | Xuzhou | 403 Forbidden | 2023-08-28 |
|
||||
| 223.113.xx.31 | 443 | https | JSP3 | China | | 405 Not Allowed | 2023-08-28 |
|
||||
| 223.113.xx.206 | 443 | https | JSP3 | China | Xuzhou | 403 Forbidden | 2023-08-28 |
|
||||
|
||||
**Search Result Amount: 2291**
|
||||
|
||||
Through cyberspace mapping, 2,291 independent IP addresses were discovered, and verification confirmed that they all had TLS certificates belonging to Baidu. It is difficult to determine whether it is malicious communication based solely on the communication traffic. However, the TLS certificates for the domain front-end + C2 front-end traffic facilities were forged, successfully interfering with space mapping and threat intelligence, causing incorrect information association, making the attacker's traffic characteristics more realistic, and achieving the purpose of forging normal communication traffic.
|
||||
|
||||
|
||||
|
||||
[^RedGuard]: RG asset using the default certificate
|
||||
|
||||
Even if there is no hidden forwarding processing before the C2 traffic front-end facility, it is best to change the certificate for RedGuard. By default, any fingerprint library formed by the fingerprint identification of common components currently used in cyberspace mapping uses the **behavior** of the default configuration characteristics of common components for identification. Different groups may show different unique characteristics during these customization processes. Of course, the formation of fingerprints requires a certain understanding of the target component, so as to extract the default characteristics of the target and form an associated fingerprint. Here, the behavioral characteristics of the RG certificate are used for cyberspace mapping, which is associated with a large number of RG nodes deployed on the public network.
|
||||
|
||||
**It is not surprising that the author was able to extract the fingerprint, but it is still recommended that RedGuard users modify the default certificate information and be a professional hacker:)**
|
||||
|
||||
## RedGuard Parameters
|
||||
|
||||
```bash
|
||||
@@ -190,9 +239,50 @@ Another interception method is DROP, which directly closes the HTTP communicatio
|
||||
|
||||
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.
|
||||
|
||||
### Hijacking site responses
|
||||
|
||||
I believe that many users will be interested in **hijacking response**. The general principle is that when the client initiates a request to the real C2 server, since it does not meet the inbound rules, the C2 server will obtain the specified normal site and return its response information. Therefore, from the effect request end, it seems to be interacting with the IP service, but in fact, the intermediate C2 server is used as a proxy server to interact with the normal site, and it is difficult to find abnormalities. If it meets the inbound request, the traffic request will be forwarded to the real C2 service listening port for interaction, and the real listening port has been filtered by the cloud firewall, allowing only local access, and it cannot be directly accessed from the outside. **So from the perspective of external port opening, only the HTTP/S port is open, and in a sense, this is indeed the online port of C2.**
|
||||
|
||||
|
||||
|
||||
[^Traffic flow diagram]: C2 server traffic interaction process
|
||||
|
||||
In the cyberspace mapping data, the HTTP/S open port response code of the IP is 200, not a 307 jump, which is more authentic.
|
||||
|
||||
|
||||
|
||||
The HTTPS certificate has the same effect as the forged certificate mentioned above, and both are fingerprints of real certificates.
|
||||
|
||||
|
||||
|
||||
I believe that many red teams will widely use concealment methods such as cloud functions/domain fronting in the process of fighting projects. However, in today's offensive and defensive confrontation, the above two concealment methods have a fatal problem, that is, they can directly connect to the C2 service. The result is undoubtedly that when we grasp the cloud function address or the interactive IP/HOST of the domain fronting, we can directly access the C2 listening service and prove that it is an attack facility.
|
||||
|
||||
|
||||
|
||||
**Since the traffic can directly reach C2, it is worth considering whether the security device can perform CS scanning on the traffic that does not match the SNI and HOST to identify whether it is malicious traffic. The same is true for cloud functions or sandbox environments. In addition to the sample side, there can also be more traffic-level analysis processes.**
|
||||
|
||||
After the hijacking response, direct access to the HTTP service can interact with the website normally, but Cscan cannot scan out the sample information because the traffic cannot reach the real C2 listener. Normal C2 interaction is possible only when the characteristics of traffic initiation are met. However, there is a problem. The C2 scanning script needs to comply with the inbound rules, which puts a certain test on the coding ability of the blue team analysts. The currently public scanning script is in the form of Nmap.
|
||||
|
||||
|
||||
|
||||
## JA3 fingerprint recognition cloud sandbox analysis traffic
|
||||
|
||||
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.
|
||||
JA3 provides a more recognizable fingerprint for encrypted communications between clients and servers. It uses TLS fingerprints to identify TLS negotiations between malicious clients and servers, thereby achieving the effect of associating malicious clients. This fingerprint is easy to generate on any platform using MD5 encryption and is currently widely used in threat intelligence. For example, it can be seen in sample analysis reports of some sandboxes to prove the correlation between different samples.
|
||||
|
||||
If we can master the JA3(S) of the C2 server and the malicious client, even if the traffic is encrypted and the IP address or domain name of the C2 server is unknown, we can still identify the TLS negotiation between the malicious client and the server through TLS fingerprinting. **I believe that everyone can think of this after seeing this, which is also a measure to deal with traffic forwarding concealment methods such as domain fronting, reverse proxy, and cloud function. Through the sandbox execution sample identification and C2 communication TLS negotiation and generate JA3(S) fingerprints, which can be applied to threat intelligence to achieve auxiliary tracing.**
|
||||
|
||||
I announced this technology in 2022. When testing the micro-step sandbox environment, I found that although the number of egress IPs requesting interaction was small, it was not accurate to identify the sandbox by IP, and this was a feature that was easily changed, but its JA3 fingerprint was unique in the same system environment. Later, I received feedback that the sandbox had completed fingerprint randomization, but recent tests have found that it has not been fully implemented. I still hope to face the problem of fingerprints on the traffic side.
|
||||
|
||||
- **Threatbook Sandbox Currently mainly the following JA3 fingerprints:**
|
||||
- 55826aa9288246f7fcafab38353ba734
|
||||
|
||||
From the perspective of the cloud sandbox, by monitoring the traffic interaction between the sample and the C2 server, the JA3(S) fingerprint is generated to identify the malicious client and thus make an association. Thinking in reverse, as a traffic control facility in front of C2, we can also perform such operations to obtain the JA3 fingerprint of the client request. By debugging different sandbox environments, these JA3 fingerprints are obtained to form a fingerprint library, thereby forming a basic interception strategy.
|
||||
|
||||
Imagine that in the process of staged Trojan interaction, the loader will first pull the shellcode of the remote address. Then, when the traffic identifies that the request meets the cloud sandbox characteristics of the JA3 fingerprint library, it will intercept the subsequent requests. If the shellcode cannot be obtained, the entire loading process cannot be completed, and the sandbox naturally cannot fully analyze it. If the environment is a stageless Trojan, then the sandbox analysis will also not be able to be finally uploaded to the C2 server. I believe everyone has woken up from a sleep and found a lot of long-timed sandbox records hanging on the C2. Of course, in an ideal state, we can identify different sandbox environments, which mainly depends on the reliability of the fingerprint library.
|
||||
|
||||
During the test, I found that after adding the JA3 fingerprint of ZoomEye GO language request library to the fingerprint library and monitoring the RG request traffic, most of the requests triggered the basic interception of the JA3 fingerprint library feature. Here I guess that the underlying language of the surveying and mapping product is part of the scanning task implemented in GO language. Through a link, the scanning logic composed of different underlying languages finally completed the entire scanning task. This also explains why the scanning of some surveying and mapping products triggered the JA3 fingerprint interception feature of the GO language request library. **The recognition rule principle is the same as that of the cloud sandbox fingerprint. Both use the uniqueness of the request client environment and the request library. Unlike the PC side, the request environment of these products will basically not be changed at will, which also enables us to grasp its traffic side fingerprint and intercept**, so can we think about whether the security device can use the JA3 fingerprint of the active detection traffic as the basis for interception? Of course, when the business traffic is large, there may be a certain amount of false alarms. Here we only propose theoretically feasible product requirements.
|
||||
|
||||
**P.S. Users can also upload samples to the sandbox to obtain and verify their JA3 fingerprints and add them to the fingerprint library. It should be noted that it is meaningless if the sandbox only changes the JA3 fingerprint to not the above fingerprint. What really needs to be solved is that each time the sandbox performs dynamic analysis, it is not the same fingerprint, and its changes need to meet the requirements of not repeating as much as possible. If the repetition rate is high, it will still be used as a fingerprint.**
|
||||
|
||||
Currently supports the identification and interception of the threatbook cloud sandbox as an effect demonstration
|
||||
|
||||
@@ -300,7 +390,7 @@ The profile written by 风起 is recommended to use:
|
||||
|
||||
## Custom Delete Response Fields
|
||||
|
||||
In Cobalt Strike 4.7+, Teamserver automatically removes the Content-Encoding header without any notification, potentially causing a malleable http-(get|post).server violation. For example, there is no Content-type in the CS Server response packet, but after being forwarded by RedGuard, the Content-Type is added to the header of the response packet, which causes cf to cache the page, causing interference.
|
||||
In Cobalt Strike 4.7+, Teamserver automatically removes the Content-Encoding header without any notification, potentially causing a malleable http-(get|post).server violation. Moreover, if there is no Content-type in the CS Server response message, but after being forwarded by RedGuard, the Content-Type is added to the response message header, causing cf to cache the page and causing interference.
|
||||
|
||||
After RedGuard 23.08.21, the function of customizing the header of the response packet has been added. Users can customize and delete the header information in the response packet by modifying the configuration file to solve the problem of incorrect parsing.
|
||||
|
||||
@@ -354,46 +444,6 @@ Because RedGuard’s configuration file is a hot configuration, we don’t need
|
||||
|
||||
# 0x04 Case Analysis
|
||||
|
||||
## Cyberspace Search Mapping
|
||||
|
||||
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.
|
||||
|
||||
|
||||
|
||||
**Mapping Platform - Hijack Response Intercept Mode Effect:**
|
||||
|
||||
|
||||
|
||||
**Surveying and mapping platform - effect of redirection interception:**
|
||||
|
||||
|
||||
|
||||
## Domain fronting
|
||||
|
||||
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.
|
||||
|
||||
## Edge Node
|
||||
|
||||
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.
|
||||
|
||||
|
||||
|
||||
## CobaltStrike
|
||||
|
||||
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.
|
||||
@@ -441,6 +491,135 @@ RedGuard received the request:
|
||||
|
||||
|
||||
|
||||
## Cyberspace Search Mapping
|
||||
|
||||
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.
|
||||
|
||||
|
||||
|
||||
**Mapping Platform - Hijack Response Intercept Mode Effect:**
|
||||
|
||||
|
||||
|
||||
**Surveying and mapping platform - effect of redirection interception:**
|
||||
|
||||
|
||||
|
||||
## Domain fronting
|
||||
|
||||
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.
|
||||
|
||||
## Honeypot malicious trap
|
||||
|
||||
**The principle of malicious honeypot trapping mainly relies on the hijacking response or redirection function of RG traffic guidance, which guides analysts who are evaluating C2 facilities to the address of the honeypot sandbox. In the hijacking response state, RG will direct request traffic that does not meet the inbound rules to the honeypot assets.** When encountering some more powerful honeypots (such as those that capture operator mobile phone numbers), the client will initiate a request according to the response of the target site and be hijacked by jsonp to obtain relevant information.
|
||||
|
||||
Imagine that when analysts directly access the C2 online port, they will be directed to the honeypot asset, which will undoubtedly cause disturbance to the analysts. The analysts are maliciously directed to request the honeypot asset, and the honeypot monitoring end captures the relevant information of the blue team analysts and traces the error. If the analysis target is wrong from the beginning, how can you get a good result? This will undoubtedly cause serious internal friction for the defense team.
|
||||
|
||||
**Here is a set of ZoomEye fingerprints associated with honeypot assets:**
|
||||
|
||||
```bash
|
||||
(iconhash:"9fd6f0e56f12adfc2a4da2f6002fea7a" (title:"然之协同" +"iframe" +">v.ignoreNotice")) ("/static/js/2.ca599e2d.chunk.js?t=" +title:"OA办公系统") ("data.sloss.xyz/get_code.js?access") ("/monitordevinfo/common.js") (app:"honeyport" +country:china +after:"2022-08-22")
|
||||
```
|
||||
|
||||
|
||||
|
||||
The way to achieve this effect is very simple, you only need to change the relevant key values in the RG configuration file.
|
||||
|
||||
```bash
|
||||
# RedGuard interception action: redirect / reset / proxy (Hijack HTTP Response)
|
||||
drop_action = proxy
|
||||
# URL to redirect to
|
||||
Redirect = https://market.baidu.com
|
||||
```
|
||||
|
||||
**P.S. I believe everyone knows how to configure it without explanation:)**
|
||||
|
||||
This method is a kind of cunning trick, which is more reflected in the idea. If it is further utilized, the honeypot capture function can be deployed in the C2 front-end traffic control facility and then interactive traffic can be directed. The effect is that the client's browser cache data can be obtained just like a traditional honeypot. However, I personally feel that in the public version, it may not be meaningful to apply it to the current attack and defense confrontation. It is meaningless for the attacker to capture the social information of the blue team analyst and then trace it. Of course, taking a step back, this may make the analysis of C2 samples more dangerous. When the attacker of the black and gray industries can obtain the virtual identity of the analyst, if the virtual and real identities can be converted, it is still relatively dangerous. **So I think that future research and analysis should be more cautious and vigilant.**
|
||||
|
||||
## C2 traffic based on edge node link interaction
|
||||
|
||||
In the attack and defense confrontation scenario, most unit networks are still border-based defense. Here we consider a scenario where the external servers in the DMZ area are often configured with relevant access policies in a normal business environment. At this time, when the external servers at the edge can access the network but cannot directly access the intranet host, the PC or related servers in the intranet do not directly access the public network, but can access the business servers in the DMZ area, then I can use the host of the edge node as an RG node to transfer the intranet online traffic to our C2 facilities. Does it sound very similar to the conventional proxy transfer online? However, this is just a form of display of the skill implementation. Let's continue to look at more TIPS.
|
||||
|
||||
|
||||
|
||||
When we take down an edge host during the management process, assuming that we have taken over the Shell permissions, we will deploy RG on this server as our front-end node **(in actual scenarios, configuration files are hard-coded in the program, and even the Trojan horse and RG are combined into the same program)**.
|
||||
|
||||
**The configuration file is as follows:**
|
||||
|
||||
|
||||
|
||||
For the specific configuration, we mainly focus on the arrows. **The arrow 1 above is the HOST domain name for the interaction between the intranet host and the edge node**. It is recommended to set the relevant intranet domain name according to the specific scenario of the target unit. Imagine the traffic interaction between two hosts in the intranet about the intranet domain name. Does BT have the courage to directly cut off the interactive traffic? Of course, if they can determine that it is malicious interactive traffic. **The arrow 2 points to the setting of the conventional domain frontend**. This key-value pair, the key corresponds to the online HOST and the value corresponds to the proxy address. Here we can set it to any HTTPS domain name using the same CDN manufacturer **(CDN node IP is also OK, remember to bring http(s):// protocol).**
|
||||
|
||||
EdgeHost is the domain name used by our cloud service provider's domain frontend, which is also the domain name used by the RG edge node when interacting with C2 through the CDN node. Yes, RG will modify the HOST domain name of the legitimate request and modify it to the cloud service CDN domain name that can communicate normally.
|
||||
|
||||
EdgeTarget is the domain name for intranet interaction, which needs to be the same as arrow 1. Only traffic requested by the domain name set here by HOST will be considered legitimate, and RG will be further modified to the cloud service CDN domain name for subsequent communication.
|
||||
|
||||
**Here we summarize:**
|
||||
|
||||
That is, the interaction between the edge node and the host in the intranet is through the set intranet domain name. When the Trojan initiates a request to the edge node of the RG, it will determine whether the request traffic HOST is the intranet domain name set in the configuration file. If it is in compliance, it is considered legitimate. The RG will modify the HOST to the cloud service provider CDN domain name set by the EdgeHost for subsequent communication and transfer the traffic to the C2 server, achieving full concealment and high obfuscation of the entire link. Imagine that the intranet domain name interacts with the edge node with the intranet domain name, but the edge node further changes the actual interactive proxy address and interactive HOST, achieving an asymmetric interactive information between the two hosts, making tracing more difficult and difficult to investigate.
|
||||
|
||||
|
||||
|
||||
**Interaction traffic between edge nodes and intranet hosts, as shown in the figure above**
|
||||
|
||||
Another advantage of this approach is that in the cloud sandbox environment, since our interactive IP is customized according to the intranet, it is impossible for the sandbox to perform connectivity correlation analysis on the intranet IP during analysis.
|
||||
|
||||
|
||||
|
||||
One thing to note when configuring is that the HOST for the Trojan request should be:
|
||||
|
||||
- **HOST: Intranet domain name (set in the RG configuration file)**
|
||||
- **IP: Intranet IP of edge host**
|
||||
- **Online port: 443 (matches the http(s) listening port in the RG configuration file)**
|
||||
- **Listening port: the port where C2 is actually online**
|
||||
|
||||
The C2 listener settings are as follows:
|
||||
|
||||
|
||||
|
||||
In contrast to the request, the HOST of the C2 listener should be the CDN domain name of the cloud service provider, as long as the final traffic can be transferred to the C2 server.
|
||||
|
||||
Intranet node interaction traffic, as shown in the figure below, it can be seen that the intranet IP in the DMZ area normally accesses port 443. It is not surprising that the intranet server or PC is connected to the business system in the DMZ area.
|
||||
|
||||
|
||||
|
||||
The interactive traffic of the edge host is shown in the figure. In actual scenarios, there will not be a large number of TIME_WAIT. Here, I set the heartbeat packet sleep to 0 for testing. It is safer to set a larger heartbeat packet jitter and sleep time in actual scenarios. And I personally think that HTTP traffic is not used in actual scenarios. Isn't plain text traffic a waste of time? So generally this port will not be opened. We will change the RG file name to Tomcat, Apache, Nginx, etc. to make the interaction look more confusing.
|
||||
|
||||
|
||||
|
||||
Regarding the heartbeat packet jitter and sleep time, you can simply set the following fields in the Malleable C2 Profile file.
|
||||
|
||||
```bash
|
||||
set sleeptime "3000";
|
||||
set jitter "20";
|
||||
```
|
||||
|
||||
If you do not set it, an abnormal heartbeat packet alarm may appear. Of course, in most cases, researchers will think it is a false alarm and ignore it. However, for the sake of safety, it is recommended to configure it so that it will not cause an abnormal heartbeat packet alarm. At that time, it was tested by 360 NDR equipment, and the specific effect is as follows:
|
||||
|
||||
|
||||
|
||||
As for HTTPS traffic, any traffic monitoring device on the market cannot censor traffic. Current monitoring devices are essentially sensitive word matching. Even in a certain manufacturer's equipment data packet detection competition, it is required to use plaintext packets, which makes people wonder whether RTs really interact with plaintext traffic in actual combat scenarios? In addition to the asymmetric interactive information mentioned above, the biggest advantage of this method is that the RG node is placed at the edge node to achieve front-end traffic control, thus giving it the same functional effect as a regular RG.
|
||||
|
||||
The back-end nodes of the RG nodes are transformed into CDN nodes to forward to the C2 server. In conventional scenarios, the front-end nodes of the domains are all used as the first-layer request nodes, and the edge hosts are put online after the RG. The interaction between the business system in the DMZ area and the public network CDN IP also looks so harmonious. In this process, neither the intranet host nor the edge host directly interacts with our C2, which is also the elegance of this advanced concealment technique.
|
||||
|
||||
**Of course, in addition to the above-mentioned advantages over netsh and iptables proxy transfer, simple configuration and the absence of configuration records are also one of the advantages.**
|
||||
|
||||
# 0x05 Loading
|
||||
|
||||
Thank you for your support. RedGuard will continue to improve and update it. I hope that RedGuard can be known to more security practitioners. The tool refers to the design ideas of RedWarden.
|
||||
@@ -456,6 +635,7 @@ Thank you for your support. RedGuard will continue to improve and update it. I h
|
||||
> <https://isc.n.cn/m/pages/live/index?channel_id=iscyY043&ncode=UR6KZ&room_id=1981905&server_id=785016&tab_id=253>
|
||||
>
|
||||
> Exchange C2 traffic based on boundary node links
|
||||
>
|
||||
> <https://www.anquanke.com/post/id/278140>
|
||||
>
|
||||
> Analysis of cloud sandbox flow identification technology
|
||||
@@ -465,6 +645,10 @@ Thank you for your support. RedGuard will continue to improve and update it. I h
|
||||
> Realization of JARM Fingerprint Randomization Technology
|
||||
>
|
||||
> <https://www.anquanke.com/post/id/276546>
|
||||
>
|
||||
> C2 Infrastructure Threat Intelligence Countermeasures
|
||||
>
|
||||
> <https://paper.seebug.org/3022/>
|
||||
|
||||
**Kunyu: <https://github.com/knownsec/Kunyu>**
|
||||
|
||||
|
||||
+94
-92
@@ -1,92 +1,94 @@
|
||||
/**
|
||||
* @Author 风起
|
||||
* @contact: onlyzaliks@gmail.com
|
||||
* @File: ipLookUp.go
|
||||
* @Time: 2022/5/5 9:13
|
||||
**/
|
||||
|
||||
package core
|
||||
|
||||
import (
|
||||
"bytes"
|
||||
"encoding/json"
|
||||
"fmt"
|
||||
"regexp"
|
||||
"strings"
|
||||
|
||||
"RedGuard/lib"
|
||||
|
||||
"github.com/tidwall/gjson"
|
||||
)
|
||||
|
||||
// IPLookup IP origin,API is defined to extract relevant information
|
||||
type ipLookup struct {
|
||||
allowStatus int // API http request status code
|
||||
hasCount int // Check if the first character of location is in English
|
||||
body string // Get THE API response body JSON data
|
||||
Tag string // The json data Tag
|
||||
location string // Restrict the geographical location of the online
|
||||
}
|
||||
|
||||
var (
|
||||
_apiUrl = []string{
|
||||
// Chinese Users IP API
|
||||
"https://sp0.baidu.com/8aQDcjqpAAV3otqbppnN2DJv/api.php?query=%s&co=&resource_id=6006",
|
||||
// IP API for users in other countries
|
||||
"https://ipapi.co/%s/json/",
|
||||
}
|
||||
logger = lib.Logger() // logger output model
|
||||
)
|
||||
|
||||
// IPLookUp returns true if Check whether the IP address is the same as the owning place
|
||||
// @param ip string Specify IP address
|
||||
// @param location string Specify location
|
||||
// NOTE: other countries Server You are advised to set location to English
|
||||
// This will prioritize IP API that are more efficient for you
|
||||
func IPLookUp(location, ip string) (state bool) {
|
||||
var IPLook ipLookup
|
||||
for _, url := range _apiUrl {
|
||||
// Check preferentially invoked
|
||||
if IPLook.hasCount != 1 {
|
||||
// Check that the first character of location is in English
|
||||
if regexp.MustCompile("[a-zA-Z]").MatchString(location[0:1]) {
|
||||
// Other countries IP API are preferentially invoked if conditions are met
|
||||
url, IPLook.hasCount = _apiUrl[1], 1
|
||||
}
|
||||
} else {
|
||||
url = _apiUrl[0] // preferentially invoked Chinese Users IP API
|
||||
}
|
||||
|
||||
// Get json data for the IP API response body
|
||||
IPLook.allowStatus, IPLook.body = lib.HTTPRequest(fmt.Sprintf(url, ip))
|
||||
if IPLook.allowStatus == 200 {
|
||||
// Select the response JSON tag when json data is available
|
||||
if url == _apiUrl[0] {
|
||||
IPLook.Tag = `data.#.location` // Chinese Users IP API Tag
|
||||
break
|
||||
}
|
||||
IPLook.Tag = `city`
|
||||
IPLook.location += gjson.Get(IPLook.body, `region`).String()
|
||||
break
|
||||
}
|
||||
}
|
||||
// Check for valid JSON data
|
||||
if gjson.Valid(IPLook.body) {
|
||||
// Extracting JSON data
|
||||
result := gjson.Get(IPLook.body, IPLook.Tag)
|
||||
if result.Exists() {
|
||||
for _, name := range result.Array() {
|
||||
IPLook.location += name.String()
|
||||
}
|
||||
var prettyJSON bytes.Buffer
|
||||
// Format output JSON data
|
||||
_ = json.Indent(&prettyJSON, []byte(IPLook.body), "", "\t")
|
||||
logger.Emergency(string(prettyJSON.Bytes()))
|
||||
// Check whether the IP address is the same as the specified location
|
||||
if strings.Contains(strings.ToLower(IPLook.location), strings.ToLower(location)) {
|
||||
return true // The query result is true
|
||||
}
|
||||
}
|
||||
}
|
||||
return false
|
||||
}
|
||||
/**
|
||||
* @Author 风起
|
||||
* @contact: onlyzaliks@gmail.com
|
||||
* @File: ipLookUp.go
|
||||
* @Time: 2022/5/5 9:13
|
||||
**/
|
||||
|
||||
package core
|
||||
|
||||
import (
|
||||
"bytes"
|
||||
"encoding/json"
|
||||
"fmt"
|
||||
"regexp"
|
||||
"strings"
|
||||
|
||||
"RedGuard/lib"
|
||||
|
||||
"github.com/tidwall/gjson"
|
||||
)
|
||||
|
||||
// IPLookup IP origin,API is defined to extract relevant information
|
||||
type ipLookup struct {
|
||||
allowStatus int // API http request status code
|
||||
hasCount int // Check if the first character of location is in English
|
||||
body string // Get THE API response body JSON data
|
||||
Tag string // The json data Tag
|
||||
location string // Restrict the geographical location of the online
|
||||
}
|
||||
|
||||
var (
|
||||
_apiUrl = []string{
|
||||
// Chinese Users IP API
|
||||
"https://sp0.baidu.com/8aQDcjqpAAV3otqbppnN2DJv/api.php?query=%s&co=&resource_id=6006",
|
||||
// IP API for users in other countries
|
||||
"https://ipapi.co/%s/json/",
|
||||
}
|
||||
logger = lib.Logger() // logger output model
|
||||
)
|
||||
|
||||
// IPLookUp returns true if Check whether the IP address is the same as the owning place
|
||||
// @param ip string Specify IP address
|
||||
// @param location string Specify location
|
||||
// NOTE: other countries Server You are advised to set location to English
|
||||
// This will prioritize IP API that are more efficient for you
|
||||
func IPLookUp(location, ip string) (state bool) {
|
||||
var IPLook ipLookup
|
||||
for _, url := range _apiUrl {
|
||||
// Check preferentially invoked
|
||||
if IPLook.hasCount != 1 {
|
||||
// Check that the first character of location is in English
|
||||
if regexp.MustCompile("[a-zA-Z]").MatchString(location[0:1]) {
|
||||
// Other countries IP API are preferentially invoked if conditions are met
|
||||
url, IPLook.hasCount = _apiUrl[1], 1
|
||||
}
|
||||
} else {
|
||||
url = _apiUrl[0] // preferentially invoked Chinese Users IP API
|
||||
}
|
||||
|
||||
// Get json data for the IP API response body
|
||||
IPLook.allowStatus, IPLook.body = lib.HTTPRequest(fmt.Sprintf(url, ip))
|
||||
if IPLook.allowStatus == 200 {
|
||||
// Select the response JSON tag when json data is available
|
||||
if url == _apiUrl[0] {
|
||||
IPLook.Tag = `data.#.location` // Chinese Users IP API Tag
|
||||
break
|
||||
}
|
||||
IPLook.Tag = `city`
|
||||
IPLook.location += gjson.Get(IPLook.body, `region`).String()
|
||||
break
|
||||
}
|
||||
}
|
||||
// Check for valid JSON data
|
||||
if gjson.Valid(IPLook.body) {
|
||||
// Extracting JSON data
|
||||
result := gjson.Get(IPLook.body, IPLook.Tag)
|
||||
if result.Exists() {
|
||||
for _, name := range result.Array() {
|
||||
IPLook.location += name.String()
|
||||
}
|
||||
var prettyJSON bytes.Buffer
|
||||
// Format output JSON data
|
||||
_ = json.Indent(&prettyJSON, []byte(IPLook.body), "", "\t")
|
||||
logger.Emergency(string(prettyJSON.Bytes()))
|
||||
// Check whether the IP address is the same as the specified location
|
||||
for _, location := range strings.Split(location, ",") {
|
||||
if strings.Contains(strings.ToLower(IPLook.location), strings.ToLower(location)) {
|
||||
return true // The query result is true
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
return false
|
||||
}
|
||||
|
||||
+229
-44
@@ -59,7 +59,7 @@ chmod +x ./RedGuard&&./RedGuard
|
||||
|
||||
cert的配置选项主要是针对样本与C2前置设施的HTTPS流量交互证书的配置信息，proxy主要用于配置反向代理流量中的控制选项，具体使用会在下面进行详细讲解。
|
||||
|
||||
在流量的交互中使用的SSL证书会生成在RedGuard执行所在目录下的cert-rsa/目录下，可以通过修改配置文件进行工具的基础功能启停**(证书的序列号是根据时间戳生成的，不用担心被以此关联特征)**。如果你想要使用自己的证书，只需要重命名为ca.crt和ca.key覆盖在cert-rsa/目录下即可。
|
||||
在流量的交互中使用的SSL证书会生成在RedGuard执行所在目录下的cert-rsa/目录下，可以通过修改配置文件进行工具的基础功能启停 **(证书的序列号是根据时间戳生成的，不用担心被以此关联特征)**。如果你想要使用自己的证书，只需要重命名为ca.crt和ca.key覆盖在cert-rsa/目录下即可。
|
||||
|
||||
```bash
|
||||
openssl x509 -in ca.crt -noout -text
|
||||
@@ -78,6 +78,55 @@ openssl x509 -in ca.crt -noout -text
|
||||
HasCert = false
|
||||
```
|
||||
|
||||
### 伪造TLS证书
|
||||
|
||||
在部署域前置隐匿C2流量时，默认情况下加速的域名是不具备HTTPS证书信息的，这样显然是存在问题的，所以配置域名时需要注意对证书进行配置，这也是判断样本是否为域前置流量的默认依据。
|
||||
|
||||
|
||||
|
||||
[^腾讯云]: 内容分发网络证书配置
|
||||
|
||||
相信看到这里，大家会有所疑问，**配置的证书怎么获得？如果使用自己申请证书是不符合我们预期想达到的隐匿效果。** 这里可以使用克隆的证书进行配置，以腾讯云为例，测试中发现其不会对自定义上传的证书进行校验有效性，我们可以使用与加速域名实际站点相同的证书进行伪造。虽然伪造的证书在正常情况下替换CS的默认证书是无法通信的，但是在云服务厂商CDN全站加速和RedGuard上面部署是不会进行校验有效性并且可以正常通信C2交互流量。
|
||||
|
||||
**以下为Github已有项目地址**
|
||||
|
||||
```bash
|
||||
https://github.com/virusdefender/copy-cert
|
||||
```
|
||||
|
||||
尽管样本域前置流量侧的证书已经解决，但是站在大网测绘的角度来看，我们的C2服务器仍然暴露于外，依然可能被探测到真实C2服务器并实现关联，这时就可以通过RedGuard修改C2的前置默认证书实现隐匿。
|
||||
|
||||
|
||||
|
||||
[^微步社区情报信息]: 数字证书
|
||||
|
||||
以上即为C2服务器伪造的证书效果，可以看到在微步社区的情报中是可信且未过期的状态，而其获取数字证书的主要途径也是在云沙箱进行样本分析时进行提取并实时更新的，但是显然没有经过有效校验，状态值仅对失效时间进行验证，证书可信验证应该是只以是否能够正常通信作为判断依据。
|
||||
|
||||
需要注意的是，微步情报并不会对样本请求的SNI及HOST的地址进行标注证书情报，这其实也是出于防止出现误报的考量，**我认为这是正确的，作为辅佐研判人员分析的重要依据，威胁情报宁可不全，也最好不要出现错误指向，对后续分析造成误判。** 如果说在全站加速配置证书是伪造通信流量的证书，那么配置RedGuard C2的前置响应证书就是为了针对部署于公网的真实C2服务器的行为特征进行伪造，以实现抗测绘的效果，这是十分必要的。
|
||||
|
||||
提取证书序列号：`55e6acaed1f8a430f9a938c5`，进行HEX编码得到TLS证书指纹为：`26585094245224241434632730821`
|
||||
|
||||
| IP | Port | Protocol | Service | Country | City | Title | Time |
|
||||
| :------------: | :--: | :------: | :----------: | :-----: | :----: | :-------------------: | :--------: |
|
||||
| 103.211.xx.90 | 443 | https | Apache httpd | China | Suzhou | 百度图片-发现多彩世界 | 2023-08-28 |
|
||||
| 223.113.xx.207 | 443 | https | JSP3 | China | Xuzhou | 403 Forbidden | 2023-08-28 |
|
||||
| 223.112.xx.48 | 443 | https | JSP3 | China | Xuzhou | 403 Forbidden | 2023-08-28 |
|
||||
| 223.113.xx.40 | 443 | https | JSP3 | China | Xuzhou | 403 Forbidden | 2023-08-28 |
|
||||
| 223.113.xx.31 | 443 | https | JSP3 | China | | 405 Not Allowed | 2023-08-28 |
|
||||
| 223.113.xx.206 | 443 | https | JSP3 | China | Xuzhou | 403 Forbidden | 2023-08-28 |
|
||||
|
||||
**Search Result Amount: 2291**
|
||||
|
||||
通过网络空间测绘发现2291个独立IP，进行验证确定均为百度所属TLS证书，如果单从通信流量来看是比较难判断是否为恶意通信的，而上面针对域前置+C2前置流量设施的TLS证书进行了伪造，成功对空间测绘与威胁情报实现了干扰，造成了错误的信息关联，使得攻击者的流量特征更加逼真，实现了伪造正常通信流量的目的。
|
||||
|
||||
|
||||
|
||||
[^RedGuard]: 使用默认证书的RG资产
|
||||
|
||||
哪怕在C2流量前置设施之前不存在隐匿转发的处理，也最好对RedGuard进行更改证书。默认状态下，任何目前在网络空间测绘里常用的通用组件指纹识别形成的指纹库就是利用了通用组件默认配置特征这个**行为**来进行识别的，在这些自定义过程中不同的群体又可能表现出不一样的独有特征。当然，指纹的形成需要对目标组件具有一定理解，从而提取出目标的默认特征，形成关联指纹。这里利用RG证书表现的行为特征进行网络空间测绘，关联到了大量部署在公网的RG节点。
|
||||
|
||||
**作者能够提取出该指纹不足为奇，但是依然建议RedGuard用户修改的默认证书信息，做一个专业的Hacker:)**
|
||||
|
||||
## RedGuard Usage
|
||||
|
||||
```bash
|
||||
@@ -166,7 +215,7 @@ Usage of ./RedGuard:
|
||||
|
||||
- **reset**：立即终止 TCP 连接。
|
||||
- **proxy**：从另一个网站获取响应，以尽可能接近地模仿克隆/劫持的网站。
|
||||
- **redirect**：重定向到指定网站返回HTTP状态码302，对重定向的网站无要求。
|
||||
- **redirect**：重定向到指定网站返回HTTP状态码307，对重定向的网站无要求。
|
||||
|
||||
```bash
|
||||
# RedGuard interception action: redirect / rest / proxy (Hijack HTTP Response)
|
||||
@@ -189,9 +238,51 @@ Redirect = https://360.net
|
||||
|
||||
可以看到，没有获取到HTTP响应码，C2前置流量控制对非法请求直接close响应，在网络空间测绘的探测中，DROP的方式可以实现隐藏端口开放情况的作用，具体效果可以看下面的案例分析。
|
||||
|
||||
### 劫持站点响应
|
||||
|
||||
相信不少用户对**劫持响应**会比较感兴趣，大概原理为当客户端对真实的C2服务器发起请求时，由于不符合入站规则，所以C2服务器会获取指定的正常站点并返回其响应信息，所以从效果请求端来看好像是与该IP进行服务交互，但是实际是以中间C2服务器为代理服务器与正常站点进行交互，很难发现异常。而如果符合入站请求时，则会将流量请求转发至真实的C2服务监听端口进行交互，而真实监听端口已经被云防火墙过滤，仅允许本机访问，从外部是无法直接访问的。**所以从外部端口开放情况来看仅开放了该HTTP/S端口，而某种意义来说这也确实为C2的上线端口。**
|
||||
|
||||
|
||||
|
||||
[^流量示意图]: C2服务器流量交互过程
|
||||
|
||||
在网络空间测绘数据中，该IP的HTTP/S开放端口响应码为200，不是302跳转，更加具有真实性。
|
||||
|
||||
|
||||
|
||||
HTTPS证书与上述伪造证书效果相同，均为真实证书的指纹。
|
||||
|
||||
|
||||
|
||||
相信不少红队在打项目的过程中，都会广泛的使用云函数/域前置一类的隐匿手段，但是在今天的攻防对抗的博弈中，上述两种隐匿手段均存在一个致命的问题，就是可以直接连通C2服务，而这些导致结果无疑就是当我们掌握到云函数地址或者域前置的交互IP/HOST即可直接访问C2监听服务并证明其为攻击设施。
|
||||
|
||||
|
||||
|
||||
**由于流量可以直接到达C2，那么这里不妨思考一下，安全设备针对SNI与HOST不相符的流量是否可以进行CS扫描来识别是否为恶意流量，云函数或者沙箱环境也为同理，除去样本侧也可以多一些流量层面的分析过程。**
|
||||
|
||||
而当进行劫持响应后，直接访问HTTP服务是可以正常网站交互的，但是Cscan是无法扫描出样本信息的，因为流量无法到达真实的C2监听器，只有当满足流量发起的特征时才可以正常C2交互，但是这就存在一个问题，C2扫描的脚本需要符合入站规则，这对蓝队分析人员的代码能力也就具有了一定考验，目前公开的扫描脚本为Nmap形式的。
|
||||
|
||||
|
||||
|
||||
## JA3指纹识别云沙箱分析流量
|
||||
|
||||
RedGuard目前已支持基于JA3指纹识别云沙箱的功能，可以对云沙箱环境下发起的网络请求进行识别并拦截，防止以此其进行后续的通联性分析，从而进一步影响C2设施安全性。
|
||||
JA3为客户端与服务器之间的加密通信提供了识别度更高的指纹，通过 TLS 指纹来识别恶意客户端和服务器之间的 TLS 协商，从而实现关联恶意客户端的效果。该指纹使用MD5加密易于在任何平台上生成，目前广泛应用于威胁情报，例如在某些沙箱的样本分析报告可以看到以此佐证不同样本之间的关联性。
|
||||
|
||||
如果可以掌握 C2 服务器与恶意客户端的JA3(S)，即使加密流量且不知道 C2 服务器的 IP 地址或域名，我们仍然可以通过 TLS 指纹来识别恶意客户端和服务器之间的 TLS 协商。**相信看到这里大家就能想到，这也正是对付域前置、反向代理、云函数等流量转发隐匿手段的一种措施，通过沙箱执行样本识别与C2之间通信的 TLS 协商并生成JA3(S)指纹，以此应用于威胁情报从而实现辅助溯源的技术手段。**
|
||||
|
||||
该技术在2022年的时候我就已经公布，在测试微步沙箱环境时发现，其请求交互的出口IP虽然数量不大，但是通过IP识别沙箱并不准确，并且这是很容易改变的特征，但是其在相同系统环境下JA3指纹是唯一的。后续得到反馈称沙箱已完成指纹随机化，但是近期通过测试发现仍没有完全实现，还是希望可以正视流量侧指纹的问题。
|
||||
|
||||
**目前主要为以下JA3指纹：**
|
||||
|
||||
- 55826aa9288246f7fcafab38353ba734
|
||||
|
||||
在云沙箱的立场上，通过监控样本与C2服务器之间流量交互生成JA3(S)指纹识别恶意客户端从而进行关联，而我们逆向思考，同样作为C2前置的流量控制设施，我们也可以进行这样的操作获取客户端请求的JA3指纹，通过对不同沙箱环境的调试获取这些JA3指纹形成指纹库从而形成基础拦截策略。
|
||||
|
||||
设想在分阶段木马交互的过程中，加载器会首先拉取远程地址的shellcode，那么在流量识别到请求符合JA3指纹库的云沙箱特征时，就会进行拦截后续请求。那么无法获取shellcode不能完成整个加载过程，沙箱自然不能对其完整的分析。如果环境是无阶段的木马，那么沙箱分析同样无法最终上线到C2服务器上，想必大家都有睡一觉起来C2上挂了一大堆超时已久的沙箱记录吧，当然理想状态下我们可以对不同沙箱环境进行识别，这主要也是依赖于指纹库的可靠性。
|
||||
|
||||
在测试的过程中，我发现在指纹库添加ZoomEye GO语言请求库的JA3指纹后监测RG请求流量情况，大部分的请求均触发了JA3指纹库特征的基础拦截，这里我猜测该测绘产品底层语言是以GO语言实现的部分扫描任务，通过一条链路，不同底层语言组成的扫描逻辑最终完成了整个扫描任务，这也就解释了部分测绘产品的扫描为什么触发了GO语言请求库的JA3指纹拦截特征。**而其与云沙箱指纹的识别规则原理是相同，均利用了请求客户端环境及请求库的唯一性，区别于PC端，这些产品的请求环境基本上是不会随意更改的，这也导致了我们能够掌握到其流量侧指纹并拦截**，那么是否可以思考安全设备是否可以把主动探测流量的JA3指纹作为拦截依据？当然，当业务流量较大时可能会有一定的误报，这里仅提出理论上可实施的产品需求。
|
||||
|
||||
**P.S.读者也可以自行上传样本至沙箱中获取并验证其JA3指纹添加至指纹库，需要注意的是，如果沙箱仅更改JA3指纹不为上述指纹是没有意义的，真正需要解决的是每次沙箱动态分析时均不为同一指纹，而其变化需要满足尽可能的不重复，如果重复率较高依然会被作为指纹使用。**
|
||||
|
||||
目前支持针对微步云沙箱的识别拦截作为效果演示
|
||||
|
||||
@@ -299,7 +390,7 @@ MalleableFile = /root/cobaltstrike/Malleable.profile
|
||||
|
||||
## 自定义删除响应字段
|
||||
|
||||
在 Cobalt Strike 4.7+ 中，Teamserver 会在没有任何通知的情况下自动删除 Content-Encoding 标头，从而可能导致违反可延展http-(get|post).server。例如CS Server响应包中没有Content-type，但经过了RedGuard转发后，在响应包Header添加了Content-Type，然后导致cf对这个页面进行了缓存，造成了干扰。
|
||||
在 Cobalt Strike 4.7+ 中，Teamserver 会在没有任何通知的情况下自动删除 Content-Encoding 标头，从而可能导致违反可延展http-(get|post).server。而且如果CS Server响应报文中没有Content-type，但经过RedGuard转发后，在响应报文头中添加了Content-Type，导致cf缓存页面，造成干扰。
|
||||
|
||||
在RedGuard 23.08.21版本后增加了自定义响应包Header头的功能，用户可以通过修改配置文件的方式进行自定义删除的响应包中的Header信息，以解决错误解析的问题。
|
||||
|
||||
@@ -353,46 +444,6 @@ http-get "listen2" {
|
||||
|
||||
# 0x04 案例分析
|
||||
|
||||
## 空间测绘
|
||||
|
||||
如下图所示，当我们的拦截规则设置为DROP的时候，空间测绘系统探针会对我们反向代理端口的/目录进行几次探测，理论上测绘发送的请求包就是伪造成正常的流量所示。但是当尝试几次因为请求包特征不符合RedGuard的放行要求，所以均被Close HTTP响应。最终展现在测绘平台上的效果也就是认为反向代理端口未开放。
|
||||
|
||||
|
||||
|
||||
下图所示的流量也就是当拦截规则设置为Redirect时，我们会发现当测绘探针收到响应后会继续对我们进行目录扫描，UserAgent为随机，看起来符合正常流量的请求，但是也都成功被拦截了。
|
||||
|
||||
|
||||
|
||||
**测绘平台 - 劫持响应拦截方式效果：**
|
||||
|
||||
|
||||
|
||||
**测绘平台 - 重定向拦截方式效果：**
|
||||
|
||||
|
||||
|
||||
## 域前置
|
||||
|
||||
RedGuard是支持域前置的，在我看来一共有两种展现形式，一种是利用传统的域前置方式，在全站加速回源地址中设置为我们反向代理的端口即可实现。在原有的基础上给域前置增加了流量控制的功能，并且可以根据我们设置的重定向到指定URL使其看起来更像是真的。需要注意HTTPS HOST头RedGuard设置的要与全站加速的域名一致才可以。
|
||||
|
||||
|
||||
|
||||
在单兵作战中，我建议可以使用上述方式，而在团队任务中，也可以通过自建“域前置”的方式来实现。
|
||||
|
||||
|
||||
|
||||
在自建域前置中，保持多个反向代理端口一致，HOST头一致指向后端真实的C2服务器监听端口。而这种方式，可以很好的隐藏我们的真实C2服务器，而反向代理的服务器可以通过配置防火墙仅开放代理端口即可。
|
||||
|
||||
|
||||
|
||||
这里可以通过多个节点服务器实现，在CS监听器HTTPS上线IP配置多个我们的节点IP。
|
||||
|
||||
## 边缘节点
|
||||
|
||||
RedGuard 22.08.03更新了边缘主机上线设置-自定义内网主机交互域名，而边缘主机使用域前置CDN节点交互。达到了两台主机之间交互信息的不对称，使溯源难度更大，难以排查。
|
||||
|
||||
|
||||
|
||||
## CobaltStrike上线
|
||||
|
||||
如果说上面的这种方式有一个问题就是，实际上线的C2服务器是不能通过防火墙直接拦截掉的，因为在反向代理中实际进行负载均衡请求的是云服务器厂商IP进行的。
|
||||
@@ -440,6 +491,135 @@ RedGuard接收到请求：
|
||||
|
||||
|
||||
|
||||
## 空间测绘
|
||||
|
||||
如下图所示，当我们的拦截规则设置为DROP的时候，空间测绘系统探针会对我们反向代理端口的/目录进行几次探测，理论上测绘发送的请求包就是伪造成正常的流量所示。但是当尝试几次因为请求包特征不符合RedGuard的放行要求，所以均被Close HTTP响应。最终展现在测绘平台上的效果也就是认为反向代理端口未开放。
|
||||
|
||||
|
||||
|
||||
下图所示的流量也就是当拦截规则设置为Redirect时，我们会发现当测绘探针收到响应后会继续对我们进行目录扫描，UserAgent为随机，看起来符合正常流量的请求，但是也都成功被拦截了。
|
||||
|
||||
|
||||
|
||||
**测绘平台 - 劫持响应拦截方式效果：**
|
||||
|
||||
|
||||
|
||||
**测绘平台 - 重定向拦截方式效果：**
|
||||
|
||||
|
||||
|
||||
## 域前置
|
||||
|
||||
RedGuard是支持域前置的，在我看来一共有两种展现形式，一种是利用传统的域前置方式，在全站加速回源地址中设置为我们反向代理的端口即可实现。在原有的基础上给域前置增加了流量控制的功能，并且可以根据我们设置的重定向到指定URL使其看起来更像是真的。需要注意HTTPS HOST头RedGuard设置的要与全站加速的域名一致才可以。
|
||||
|
||||
|
||||
|
||||
在单兵作战中，我建议可以使用上述方式，而在团队任务中，也可以通过自建“域前置”的方式来实现。
|
||||
|
||||
|
||||
|
||||
在自建域前置中，保持多个反向代理端口一致，HOST头一致指向后端真实的C2服务器监听端口。而这种方式，可以很好的隐藏我们的真实C2服务器，而反向代理的服务器可以通过配置防火墙仅开放代理端口即可。
|
||||
|
||||
|
||||
|
||||
这里可以通过多个节点服务器实现，在CS监听器HTTPS上线IP配置多个我们的节点IP。
|
||||
|
||||
## 蜜罐恶意诱捕
|
||||
|
||||
**蜜罐恶意诱捕的原理主要是依赖于RG流量导向的劫持响应or重定向功能，将研判C2设施的分析者导向蜜罐沙箱的地址，在劫持响应的状态下，RG会将不符合入站规则的请求流量导向蜜罐资产中**，而碰到一些比较厉害的蜜罐（例如抓取运营商手机号那种），客户端就会依照目标站点的响应发起请求被jsonp劫持到相关信息。
|
||||
|
||||
试想，当分析人员对C2上线端口直接访问就会被导向至蜜罐资产，造成的结果无疑就是对分析人员造成了扰乱，而分析人员被恶意导向请求蜜罐资产，蜜罐监测端则捕获到蓝队分析人员的相关信息从而错误溯源。如果从开始分析目标就是错误的，又怎么会得到好的结果，无疑对防守队伍造成了严重的内耗。
|
||||
|
||||
**这里给大家提供一组关联蜜罐资产的ZoomEye指纹：**
|
||||
|
||||
```bash
|
||||
(iconhash:"9fd6f0e56f12adfc2a4da2f6002fea7a" (title:"然之协同" +"iframe" +">v.ignoreNotice")) ("/static/js/2.ca599e2d.chunk.js?t=" +title:"OA办公系统") ("data.sloss.xyz/get_code.js?access") ("/monitordevinfo/common.js") (app:"honeyport" +country:china +after:"2022-08-22")
|
||||
```
|
||||
|
||||
|
||||
|
||||
而实现这一效果的方式非常简单，仅需更改RG配置文件相关键值即可。
|
||||
|
||||
```bash
|
||||
# RedGuard interception action: redirect / reset / proxy (Hijack HTTP Response)
|
||||
drop_action = proxy
|
||||
# URL to redirect to
|
||||
Redirect = https://market.baidu.com
|
||||
```
|
||||
|
||||
**P.S.相信不解释大家也知道该怎么配置:)**
|
||||
|
||||
该方式算是一种奇淫巧计吧，更多的是体现在思路上，如果进一步利用就可以在C2前置流量控制设施部署蜜罐捕获的功能然后再进行交互流量导向，效果也就是如传统蜜罐一样能够获取客户端的浏览器缓存数据。但是个人感觉在公开版本中，应用于现阶段的攻防对抗可能意义不大，攻击者捕获得到蓝队分析人员的社交信息再进行溯源是无意义的操作。当然退一步来想，这或许会让C2样本的分析更加危险，当黑灰产的攻击者能够获取得到分析人员的虚拟身份后，如果能够做到虚实身份的转换，那么还是比较危险的。**所以我认为，以后的研判分析应该更加谨慎，提高警惕意识。**
|
||||
|
||||
## 基于边界节点链路交互C2流量
|
||||
|
||||
在攻防对抗场景下，目前大部分单位网络仍然是边界化防御，这里我们思考一个场景就是当处于DMZ区域的对外服务器在进行正常的业务环境下，往往都会配置相关出入网策略，这时当边缘的对外服务器能够出入网但不能直接访问内网主机，内网的PC或者相关服务器不直接访问公网，但是能够访问DMZ区域的业务服务器，这时我就可以将边缘节点的主机作为一个RG节点，将内网上线流量中转至我们的C2设施上，是不是听起来与常规的代理中转上线很像？但是，这只是技巧实现的一种展现形式，更多的TIPS我们继续往下看。
|
||||
|
||||
|
||||
|
||||
当我们在打点的过程中拿下一台边缘主机，假设我们已经接管了Shell权限，这时我们将RG部署在这台服务器上以此作为我们的前置节点 **（实战场景下，配置文件都是写死在程序中的，甚至将木马与RG结合为同一个程序**。
|
||||
|
||||
**配置文件如下：**
|
||||
|
||||
|
||||
|
||||
具体实现的相关配置我们主要关注箭头所指的地方即可，**上面的箭头1为内网主机与边缘节点交互的HOST域名**，这里建议根据目标单位具体场景设置相关内网域名，试想一下内网中两台主机关于内网域名的流量交互，BT有没有魄力直接切断交互流量呢，当然如果他们能够判断出是恶意交互流量的话。**箭头2所指就是常规域前置的设置**，这一个键值对，键对应的是上线的HOST而值则对应了代理的地址，这里我们可以设置为任意使用了相同CDN厂商的HTTPS域名即可 **（CDN节点IP也可以的，记得带上http(s)://协议即可**。
|
||||
|
||||
EdgeHost即为我们云服务厂商的域前置所使用域名，也就是RG边缘节点通过CDN节点至C2交互时所使用的域名，是的，RG会修改合法请求过来的HOST域名并修改为能够正常通信的云服务CDN域名。
|
||||
|
||||
EdgeTarget是内网交互的域名，与箭头1需要相同，也只有HOST为这里设置的域名请求的流量才会被认为是合法的，RG才会进一步修改为云服务CDN域名从而进行后续通信。
|
||||
|
||||
**这里我们总结一下：**
|
||||
|
||||
就是边缘节点与内网之间主机的交互即通过设置的内网域名，当木马发起请求至RG的边缘节点，会判断请求流量HOST是否为配置文件中设置的内网域名，如果符合则认为是合法的RG会修改HOST为EdgeHost设置的云服务厂商CDN域名进行后续通信将流量中转至C2服务器，实现了整个链路的全隐匿高度混淆。试想一下，内网域名与边缘节点交互的是内网域名，然而边缘节点又进一步更改了实际交互的代理地址及交互HOST，达到了两台主机之间交互信息的不对称，使溯源难度更大，难以排查。
|
||||
|
||||
|
||||
|
||||
**边缘节点与内网主机交互流量，如上图所示**
|
||||
|
||||
这样方式还有一个好处就是针对云沙箱环境下，由于我们的交互IP是根据内网定制化的，那么沙箱在分析时不可能针对内网IP进行连通性关联分析。
|
||||
|
||||
|
||||
|
||||
在配置的时候需要注意一点，就是木马请求时的HOST应该是：
|
||||
|
||||
- **HOST：内网域名（RG配置文件中的设置的）**
|
||||
- **IP：边缘主机内网IP**
|
||||
- **上线端口：443（与RG配置文件http(s)监听端口匹配）**
|
||||
- **监听端口：C2实际上线的端口**
|
||||
|
||||
C2监听器设置如下：
|
||||
|
||||
|
||||
|
||||
与请求相对的是C2监听器的HOST应该是云服务厂商CDN域名，只要最终流量能够中转到C2服务器即可。
|
||||
|
||||
内网节点交互流量，如下图可以看到正常的对DMZ区域的内网IP访问了443端口，内网服务器或者PC与DMZ区域的业务系统有连接也不足为奇吧。
|
||||
|
||||
|
||||
|
||||
边缘主机的交互流量如图所示，实际场景下不会有大量的TIME_WAIT，这里因为为了测试我把心跳包sleep设置为了0，实战场景下设置较大的心跳包抖动以及sleep时间是比较稳妥地。并且个人觉得实战场景下没有使用HTTP流量的，明文流量这不是给态感白给吗哈哈？所以一般这一端口是不会开启的，我们再将RG的文件名改成Tomcat、Apache，Nginx之类的使其交互看起来更加迷惑一些。
|
||||
|
||||
|
||||
|
||||
说到了心跳包抖动跟sleep时间的问题，直接在Malleable C2 Profile文件中设置以下字段即可。
|
||||
|
||||
```bash
|
||||
set sleeptime "3000";
|
||||
set jitter "20";
|
||||
```
|
||||
|
||||
如果不进行设置的话，则可能出现异常心跳包告警，当然多数情况下研判人员都会认为是误报从而忽略，但是为了稳妥起见，建议配置一下就不会引起异常心跳包的告警了，当时是通过360 NDR设备测试的，具体效果如下：
|
||||
|
||||
|
||||
|
||||
而对于HTTPS的流量，市面上任何一个流量监测设备都是无法审查流量的，目前的监测设备本质上都是敏感词匹配，甚至于某个厂商设备数据包检测的比赛中，要求使用明文包，不禁让人怀疑在实战场景下真的会有RT用明文流量交互吗？而除了上面讲到的交互信息不对称，这种方式最大的好处就是将RG节点放置到了边缘节点从而实现前置流量控制，从而赋予与常规RG相同的功能效果。
|
||||
|
||||
而RG节点的后置节点变为了CDN节点转发至C2服务器，常规场景下域前置都是作为第一层请求节点的，而边缘主机上线则放置到了RG之后实现上线，DMZ区域的业务系统与公网CDN IP交互看起来也是那么的和谐。而在这个过程中，内网主机以及边缘主机都没有直接与我们的C2进行交互，也是这种高级隐匿手法优雅所在。
|
||||
|
||||
**当然除了上面提到比之netsh、iptables代理中转上线更好的因素之外，简易的配置以及不存在配置记录也是优点之一。**
|
||||
|
||||
# 0x05 Loading
|
||||
|
||||
感谢各位用户的支持，RedGuard也会坚持进行完善更新的，希望 RedGuard 能够让更多安全从业者所知，工具参考了RedWarden的设计思想。
|
||||
@@ -455,6 +635,7 @@ RedGuard接收到请求：
|
||||
> https://isc.n.cn/m/pages/live/index?channel_id=iscyY043&ncode=UR6KZ&room_id=1981905&server_id=785016&tab_id=253
|
||||
>
|
||||
> 基于边界节点链路交互C2流量
|
||||
>
|
||||
> https://www.anquanke.com/post/id/278140
|
||||
>
|
||||
> 云沙箱流量识别技术剖析
|
||||
@@ -464,6 +645,10 @@ RedGuard接收到请求：
|
||||
> JARM指纹随机化技术实现
|
||||
>
|
||||
> https://www.anquanke.com/post/id/276546
|
||||
>
|
||||
> C2 基础设施威胁情报对抗策略
|
||||
>
|
||||
> https://paper.seebug.org/3022/
|
||||
|
||||
**Kunyu: https://github.com/knownsec/Kunyu**
|
||||
|
||||
|
||||
Reference in New Issue
Block a user