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:
