zeoday/cobaltstrike4.5_cdf-1CobaltStrike 4.5 Version geknackt, Entfernung der Checksum8-Eigenschaften, Umgehung von BeaconEye, Behebung von Stage-Leck durch fehlerhafte Pfade, Hinzufügen von TOTP-Zwei-Faktor-Authentifizierung, Behebung von CVE-2022-39197 usw.
Crack der CobaltStrike 4.5-Version, Entfernung des Checksum8-Merkmals, Umgehung von BeaconEye, Behebung des Stage-Leaks durch fehlerhafte Pfade, Hinzufügen der TOTP-Zwei-Faktor-Authentifizierung, verschlüsselte Benutzernamenanzeige, Behebung des Bugs bei der Foreign-Ableitung in Version 4.5, Änderung des Client-Konfigurationsdateinamens usw.
Cobalt Strike 4.5 Crack
cobaltstrike4.5 Crack
[TOC]
Dieses Tool sowie der Artikelinhalt dienen ausschließlich der Sicherheitsforschung. Der Benutzer trägt die alleinige Verantwortung für alle rechtlichen und damit verbundenen Konsequenzen, die sich aus der Nutzung dieses Tools und des Artikelinhalts ergeben! Der Autor übernimmt keine rechtliche Haftung! Sollten Sie bei der Nutzung dieses Tools oder des Artikelinhalts illegale Handlungen vornehmen, tragen Sie die entsprechenden Konsequenzen selbst. Wir übernehmen keine rechtliche Haftung oder Nebenpflichten. Falls Sie dem nicht zustimmen, installieren und nutzen Sie das Tool bitte nicht. Durch Ihre Nutzung oder jede andere ausdrückliche oder stillschweigende Zustimmung zu dieser Vereinbarung erklären Sie sich damit einverstanden, die Bedingungen dieser Vereinbarung gelesen und akzeptiert zu haben. Bei der Nutzung dieses Tools für Sicherheitsforschung müssen Sie sicherstellen, dass Ihr Handeln den geltenden Gesetzen und Vorschriften entspricht und Sie ausreichend autorisiert sind. Verwenden Sie das Tool nicht gegen nicht autorisierte Ziele.
Ja, ich bin zurück und führe das ursprüngliche cobaltstrike4.4_cdf fort: https://github.com/lovechoudoufu/about_cobaltstrike4.4_cdf Diesmal ist es Version 4.5. Die vorherige Version 4.4 wurde von GitHub gelöscht. Vermutlich wird auch dieses Projekt bald gelöscht.
Es wird empfohlen, der Telegram-Gruppe beizutreten. Zukünftige Updates und Projekte können nach der Löschung aus der Gruppe heruntergeladen werden:
Überprüfen Sie vor der Verwendung sorgfältig den Hash des entsprechenden Version-JAR-Pakets.
Zertifikatsauthentifizierungsprozess (am Beispiel 4.3): Version 4.5 wurde leicht geändert.
Offizielle Entschlüsselungsschlüssel für jede Version:
4.0 1be5be52c6255c33558e8a1cb667cb06
4.1 80e32a742060b884419ba0c171c9aa76
4.2 b20d487addd4713418f2d5a3ae02a7a0
4.3 3a4425490f389aeec312bdd758ad2b99
4.4 5e98194a01c6b48fa582a6a9fcbb92d6
cobaltstrike.auth – Authentifizierungsschlüsseldatei, RSA-verschlüsselt, entschlüsselter Inhalt:
4.3
-54, -2, -64, -45, // Dateiheader
0, 77, // Folgende Länge
1, -55, -61, 127, // Zertifikat-Zeitlimit 29999999 (permanent)
0, 0, 0, 1, // Watermark
43, // Version
16, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20,
16, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20,
16, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20,
16, 58, 68, 37, 73, 15, 56, -102, -18, -61, 18, -67, -41, 88, -83, 43, -103
Bei jedem neuen Update wird die entsprechende Länge um 17 erhöht und der Schlüssel um 17 Bytes verlängert.
In aggressor/Aggressor.class beginnt die Lizenzprüfung mit License.checkLicenseGUI(new Authorization());:
In License.checkLicenseGUI wird isValid, isPerpetual, isExpired und isAlmostExpired verwendet, um zu prüfen, ob die Lizenz gültig oder abgelaufen ist:
Die Klasse Authorization verarbeitet die Datei cobaltstrike.auth. Sie liest den Dateiinhalt und ruft AuthCrypto().decrypt zur Verarbeitung auf:
Im Konstruktor von AuthCrypto() wird load() aufgerufen. Die Funktion load() prüft den MD5 von resources/authkey.pub und ruft den öffentlichen RSA-Schlüssel ab:
In decrypt() wird _decrypt mit dem Inhalt der cobaltstrike.auth-Datei aufgerufen. Der RSA-entschlüsselte Inhalt wird dem Array var2 zugewiesen, dann mit DataParser in var3 konvertiert. Mit readInt() werden die ersten vier Bytes von var3 als Dateiheader geprüft (-889274181 für 3.x; -889274157 für 4.x). Dann wird mit readShort() eine Zwei-Byte-Länge als var5 gelesen und mit var6 = var3.readBytes(var5) die entsprechenden Bytes abgerufen und zurückgegeben:
In der Authorization-Klasse wird das erhaltene Array arrayOfByte2 nach Entfernen der ersten sechs Bytes weiterverarbeitet: zuerst werden vier Byte als i, dann vier Byte als watermark und ein Byte als b1 gelesen. Es wird geprüft, ob b1 < 43 und ob i == 29999999. In common/ListenerConfig wird geprüft, ob watermark 0 ist, um eine Antiviren-Wasserzeichenerkennung zu aktivieren:
Nach Entfernen der ersten sechs Bytes und der neun Bytes für i, watermark und b1 bleibt der Schlüssel für die Versionen 4.0 bis 4.3 übrig, mit der Struktur: 16, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20:
byte b2 = dataParser.readByte(); // 1 Byte => 16
byte[] arrayOfByte3 = dataParser.readBytes(b2); // 16 Byte => 4.0-Schlüssel
byte b3 = dataParser.readByte(); // 1 Byte => 16
byte[] arrayOfByte4 = dataParser.readBytes(b3); // 16 Byte => 4.1-Schlüssel
byte b4 = dataParser.readByte(); // 1 Byte => 16
byte[] arrayOfByte5 = dataParser.readBytes(b4); // 16 Byte => 4.2-Schlüssel
byte b5 = dataParser.readByte(); // 1 Byte => 16
byte[] arrayOfByte6 = dataParser.readBytes(b5); // 16 Byte => 4.3-Schlüssel, zugewiesen an arrayOfByte6
In der Authorization-Klasse wird SleevedResource.Setup mit arrayOfByte6 aufgerufen. In SleevedResource wird der Schlüssel als AES- und HmacSHA256-Entschlüsselungsschlüssel festgelegt. In _readResource wird this.data.decrypt(arrayOfByte1) zur Entschlüsselung aufgerufen, um die DLL-Dateien aus /sleeve/ zu entschlüsseln:
In SleeveSecurity wird der AES- und HmacSHA256-Entschlüsselungsschlüssel festgelegt. Aus dem übergebenen Wert wird ein 256-Bit-Hash berechnet, die Bytes 0-15 als AES-Schlüssel und Bytes 16-31 als HmacSHA256-Schlüssel verwendet:
Ohne den passenden Schlüssel können die DLLs im sleeve-Ordner nicht entschlüsselt werden. Bei der Verbindung zum Server erscheint dann die Fehlermeldung [Sleeve] Bad HMAC:
Der HMAC-Entschlüsselungsteil kann hier nachgelesen werden: Cobaltstrike 4 Crack: Ich verleihe mir selbst eine Lizenz
Der Schlüssel für die entsprechende CS-Version ist also entscheidend für den Crack.
Laut offizieller Beschreibung wurde in Version 4.5 die Sicherheit der Lizenz erhöht – das stimmt:
Wir müssen die durchgesickerte auth-Datei entschlüsseln, um zu sehen, was hinzugekommen ist:
Nach der Position des 4.5-Schlüssels befindet sich ein zusätzlicher Block. Dabei handelt es sich um den in dieser Version neu eingeführten watermarkHash:
watermarkHash hängt mit der Beacon-Erzeugung und den DLLs im sleeve-Ordner zusammen. Ohne ihn oder bei einem Fehler kann kein Beacon online gehen. Vermutlich kann der Hersteller über diesen watermarkHash die Quelle des Lecks zurückverfolgen.
Anderen Code auskommentieren und die Parameter, die nach der RSA-Entschlüsselung in AuthCrypto().decrypt zugewiesen werden, fest codieren:
byte[] var4 = {1, -55, -61, 127, 0, 1, -122, -96, 45, 16, 27, -27, -66, 82, -58, 37, 92, 51, 85, -114, -118, 28, -74, 103, -53, 6, 16, -128, -29, 42, 116, 32, 96, -72, -124, 65, -101, -96, -63, 113, -55, -86, 118, 16, -78, 13, 72, 122, -35, -44, 113, 52, 24, -14, -43, -93, -82, 2, -89, -96, 16, 58, 68, 37, 73, 15, 56, -102, -18, -61, 18, -67, -41, 88, -83, 43, -103, 16, 94, -104, 25, 74, 1, -58, -76, -113, -91, -126, -90, -87, -4, -69, -110, -42, 16, -13, -114, -77, -47, -93, 53, -78, 82, -75, -117, -62, -84, -34, -127, -75, 66, 0, 0, 0, 24, 66, 101, 117, 100, 116, 75, 103, 113, 110, 108, 109, 48, 82, 117, 118, 102, 43, 86, 89, 120, 117, 119, 61, 61};
Prinzip von Javaagent: https://www.cnblogs.com/rickiyang/p/11368932.html
Referenz-Crack-Tool: https://github.com/Twi1ight/CSAgent
Der Kern des Cracks ist immer noch der Schlüssel der entsprechenden CS-Version.
In beacon/BeaconData wird der Rückgabewert der Methode shouldPad fest auf false gesetzt:
Neue versteckte Fallen in 4.4
(Zuvor wurde am Beispiel von 4.3 die Lizenzprüfung analysiert. Beim Wechsel zu 4.4 stellte sich heraus, dass das Programm mit einer neuen versteckten Falle beendet wurde.)
Zusätzlich zu this.shouldPad mit exit wurde in common/Helper eine .class-Prüfung hinzugefügt – einfach auskommentieren:
In common/Starter wurde eine .class-Prüfung hinzugefügt – auskommentieren:
In common/Starter2 wurde eine .class-Prüfung hinzugefügt – auskommentieren:
In beacon/CommandBuilder wurde eine .class-Prüfung hinzugefügt (diese Falle war besonders heimtückisch: Nach 4 Stunden ununterbrochener Verbindung zwischen Client und Teamserver konnten keine Befehle mehr ausgeführt werden. Da ich noch nie so lange verbunden war, habe ich sie nicht entdeckt, ggg):
Neue versteckte Fallen in 4.5
Version 4.5 enthält eine Reihe von Fallen speziell gegen Javaagent. Wer das JAR direkt dekompiliert und den Code ändert, kann sie ignorieren. Einfach nach javaagent suchen und nacheinander anpassen:
Wenn diese Stellen entfernt sind, kann wieder gemeinsam gearbeitet werden.
Das Checksum8-Merkmal wird nicht näher erläutert. Es ist dennoch sinnvoll, es zu ändern, um eine Erkennung durch nmap und Suchmaschinen für Netzwerkgeräte zu vermeiden.
In BeaconPayload wird der XOR-Wert durch einen neuen ersetzt:
Eine beliebige Dezimalzahl. In den DLLs muss die entsprechende Hexadezimalzahl verwendet werden.
Verwenden Sie CrackSleeve, um die DLLs zu entschlüsseln: https://github.com/ca3tie1/CrackSleeve/
cobaltstrike.jar und CrackSleeve.java zusammen ab.javac -encoding UTF-8 -classpath cobaltstrike.jar CrackSleeve.java).java -classpath cobaltstrike.jar;./ CrackSleeve decode) # Windows-BefehlszeileDrücken Sie Alt+T und suchen Sie nach dem Schlüsselwort: 2Eh
Ändern Sie direkt den XOR-Wert. Verwenden Sie Change Byte, um 2E zu finden und zu ändern, dann Apply patches to input file, um zu speichern. (Vergessen Sie nicht zu speichern.)
Zu ändernde DLLs: beacon.dll, beacon.x64.dll, dnsb.dll, dnsb.x64.dll, pivot.dll, pivot.x64.dll, extc2.dll, extc2.x64.dll (Die in 4.5 neu hinzugekommenen rl100k.dll müssen ebenfalls geändert werden).
Verschlüsseln Sie dann die DLLs mit CrackSleeve neu. Legen Sie anschließend die DLLs aus dem encode-Verzeichnis in das IntelliJ-Projektverzeichnis und kompilieren Sie das JAR neu.
Obwohl die Test-URI immer noch erreichbar ist, kann der Inhalt nicht mehr mit nmap-Skripten entschlüsselt werden. Ebenso wird die Erkennung durch Suchmaschinen für Netzwerkgeräte umgangen:
Alternativ zur Änderung des XOR-Werts kann auch der Checksum8-Algorithmus geändert werden (siehe hier. Das führt jedoch dazu, dass die URI fest vorgegeben ist und nur mit einem Profil verwendet werden kann. Außerdem muss das JAR bei jeder Änderung der URI neu gepackt werden – jede Methode hat Vor- und Nachteile.
Die Idee zur Entfernung des BeaconEye-Merkmals stammt aus diesem Link. Am Beispiel von 4.3 und 4.4 sind folgende Byte-Änderungen erforderlich.
Verwenden Sie CrackSleeve, um die DLLs zu entschlüsseln: https://github.com/ca3tie1/CrackSleeve/
cobaltstrike.jar und CrackSleeve.java zusammen ab.javac -encoding UTF-8 -classpath cobaltstrike.jar CrackSleeve.java).java -classpath cobaltstrike.jar;./ CrackSleeve decode) # Windows-Befehlszeile4.3-Schlüssel: 58, 68, 37, 73, 15, 56, -102, -18, -61, 18, -67, -41, 88, -83, 43, -103 4.4-Schlüssel: 94, -104, 25, 74, 1, -58, -76, -113, -91, -126, -90, -87, -4, -69, -110, -42
Adresse: 10009FBB
6A 00 ändern in 6A 09 (00 durch beliebigen Wert ersetzen)
Adresse: 000000001800186C3
In beacon.x64.dll wird der Befehl xor edx, edx geändert in mov edx, esi
Adresse: 1000A0B9
6A 00 ändern in 6A 09 (00 durch beliebigen Wert ersetzen)
Adresse: 000000018001879B
In beacon.x64.dll wird der Befehl xor edx, edx geändert in mov edx, esi
Erneute Verschlüsselung: java -classpath cobaltstrike.jar;./ CrackSleeve encode
Adresse: 1000A65D
Adresse: 000000018000CA3F
(Die in 4.5 neu hinzugekommenen rl100k.dll müssen ebenfalls geändert werden)
Die Methode besteht darin, in der URI eine Prüfung auf / einzufügen. Wenn die URI nicht mit / beginnt, wird ein 404 zurückgegeben:
Änderung für 4.4:
Änderung für 4.3:
Um zu verhindern, dass TOTP-Passwörter oder Login-Namen im Event Log durchsickern, wird das name-Feld mit MD5 + Salt angezeigt. Nach der Änderung sieht es so aus:
Es wurde eine TOTP-Zwei-Faktor-Authentifizierung hinzugefügt, um die Anmeldung zu verstärken und Brute-Force-Angriffe auf Passwörter zu verhindern.
Auf der Teamserver-Seite wird in der Teamserver-Ausgabe ein QR-Code-Link für TOTP angezeigt:
(Entfernen Sie vor dem Löschen der nohup.out-Datei den QR-Code. Jeder Start des Teamservers generiert einen neuen QR-Code, daher muss bei jedem Start neu gescannt werden.)
Öffnen Sie den Link im Browser (ggf. mit Proxy). Scannen Sie den QR-Code mit Google Authenticator oder einem TOTP-Verifizierer. Alternativ können Sie den Schlüssel nach secret%3D kopieren und im Verifizierer konfigurieren:
Auf der Connect-Seite bleiben host, port und password unverändert. Im Feld user werden die letzten sechs Ziffern als dynamische TOTP-Zahl angegeben, um die Verbindung herzustellen:
Wenn keine oder eine falsche TOTP-Zahl eingegeben wird, erscheint eine Fehlermeldung:
Hinweis: Falls kein Smartphone verfügbar ist, kann ein Browser-Plugin mit TOTP-Funktion oder ein einfaches Python-Skript für TOTP verwendet werden.
Beim Spawnen mit windows/foreign/reverse_http(s) tritt folgender Fehler auf:
In dieser Version wurde in ScListener eine getScalar-Operation für Custom hinzugefügt, aber der Fall foreign wurde nicht berücksichtigt. Dadurch sind var1.customDLL und customFileName leer, was den Fehler verursacht:
Die vorläufige Lösung besteht darin, bei einem foreign-Payload direkt das Shellcode zurückzugeben. Sollte diese Methode andere Fehler verursachen, können Sie Issues melden:
Nach der Behebung funktioniert es wieder normal:
Um zu verhindern, dass das Konfigurationsprofil von MySQL-Honeypots ausgelesen wird, wird der Standardname der Client-Konfigurationsdatei nicht mehr verwendet. Stattdessen wird ein 11-stelliger Dateiname generiert (11 Zeichen aus dem MD5 der MAC-Adresse).
