mirror of
https://github.com/wikiZ/RedGuard
synced 2026-06-08 18:18:32 +00:00
Update README.md
This commit is contained in:
@@ -88,7 +88,7 @@ When deploying a Domain fronting to hide C2 traffic, the accelerated domain name
|
|||||||
|
|
||||||
[^Tencent Cloud]: Content Delivery Network Certificate Configuration
|
[^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.
|
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**
|
**The following is the existing project address on Github**
|
||||||
|
|
||||||
@@ -241,7 +241,7 @@ It can be seen that the C2 front flow control directly close response to illegal
|
|||||||
|
|
||||||
### Hijacking site responses
|
### 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. **
|
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.**
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
@@ -259,7 +259,7 @@ I believe that many red teams will widely use concealment methods such as cloud
|
|||||||
|
|
||||||

|

|
||||||
|
|
||||||
**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. **
|
**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.
|
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.
|
||||||
|
|
||||||
@@ -269,7 +269,7 @@ After the hijacking response, direct access to the HTTP service can interact wit
|
|||||||
|
|
||||||
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.
|
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. **
|
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.
|
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.
|
||||||
|
|
||||||
@@ -282,7 +282,7 @@ Imagine that in the process of staged Trojan interaction, the loader will first
|
|||||||
|
|
||||||
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.
|
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. **
|
**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
|
Currently supports the identification and interception of the threatbook cloud sandbox as an effect demonstration
|
||||||
|
|
||||||
@@ -527,7 +527,7 @@ This can be achieved through multiple node servers, and configure multiple IPs o
|
|||||||
|
|
||||||
## Honeypot malicious trap
|
## 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.
|
**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.
|
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.
|
||||||
|
|
||||||
@@ -550,7 +550,7 @@ Redirect = https://market.baidu.com
|
|||||||
|
|
||||||
**P.S. I believe everyone knows how to configure it without explanation:)**
|
**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. **
|
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
|
## C2 traffic based on edge node link interaction
|
||||||
|
|
||||||
@@ -558,13 +558,13 @@ In the attack and defense confrontation scenario, most unit networks are still b
|
|||||||
|
|
||||||

|

|
||||||
|
|
||||||
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)**.
|
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:**
|
**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).**
|
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.
|
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.
|
||||||
|
|
||||||
@@ -618,7 +618,7 @@ As for HTTPS traffic, any traffic monitoring device on the market cannot censor
|
|||||||
|
|
||||||
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.
|
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. **
|
**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
|
# 0x05 Loading
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user