zeoday/cobaltstrike4.5_cdf-1Version 4.5 de Cobalt Strike cra/quer, suppression de la signature Checksum8, bypass BeaconEye, correction de la fuite du stage dans le chemin d'erreur, ajout de l'authentification à deux facteurs TOTP, correction de CVE-2022-39197, etc.
Crack de cobaltstrike version 4.5, suppression de la signature checksum8, bypass de BeaconEye, correction de la fuite de stage par chemin erroné, ajout de la vérification à double facteur TOTP, ajout de l'affichage chiffré des noms d'utilisateur, correction du bug de dérivation foreign de la version 4.5, modification du nom du fichier de configuration du client, etc.
Crack de cobalt strike 4.5
Crack de cobaltstrike 4.5
[TOC]
Cet outil ainsi que le contenu de cet article sont réservés à la recherche en sécurité. L'utilisateur assume l'entière responsabilité légale et toute responsabilité connexe résultant de l'utilisation de cet outil et du contenu de cet article ! L'auteur n'assume aucune responsabilité légale ! Si vous commettez un quelconque acte illégal lors de l'utilisation de cet outil et du contenu de cet article, vous assumez seul les conséquences qui en découlent ; nous n'assumons aucune responsabilité légale ni conjointe. Dans le cas contraire, veuillez ne pas installer ni utiliser cet outil. Votre utilisation de cet outil ou toute autre manifestation expresse ou implicite d'acceptation du présent accord sera considérée comme votre lecture et votre acceptation des termes du présent accord. Lors de l'utilisation de cet outil pour des recherches en sécurité, vous devez vous assurer que cette activité est conforme aux lois et règlements et que vous avez obtenu les autorisations nécessaires. N'utilisez pas cet outil sur des cibles non autorisées.
Oui, je suis de retour, en continuité avec l'original cobaltstrike4.4_cdf : https://github.com/lovechoudoufu/about_cobaltstrike4.4_cdf Cette fois-ci, il s'agit de la version 4.5. La version 4.4 précédente a été supprimée par GitHub ; je suppose que ce projet sera également supprimé d'ici peu ~.
Il est recommandé de rejoindre le groupe Telegram (小飞机) ; les futures mises à jour et projets pourront être téléchargés depuis le groupe après leur suppression :
Avant utilisation, veuillez vérifier soigneusement le hash du fichier jar de la version correspondante.
Processus de certification (exemple avec la 4.3) : la version 4.5 a été légèrement modifiée à la fin.
Clés de déchiffrement officielles des différentes versions :
4.0 1be5be52c6255c33558e8a1cb667cb06
4.1 80e32a742060b884419ba0c171c9aa76
4.2 b20d487addd4713418f2d5a3ae02a7a0
4.3 3a4425490f389aeec312bdd758ad2b99
4.4 5e98194a01c6b48fa582a6a9fcbb92d6
cobaltstrike.auth : fichier de clé d'authentification, chiffré RSA, contenu après déchiffrement :
4.3
-54, -2, -64, -45, //文件头
0, 77, //后续长度
1, -55, -61, 127, //证书时间限制29999999（永久）
0, 0, 0, 1, //watermark（水印）
43, //版本
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
À chaque nouvelle version, la longueur correspondante augmente de 17 et la clé s'allonge de 17 octets.
Dans aggressor/Aggressor.class, License.checkLicenseGUI(new Authorization()); lance la certification de licence :
Dans License.checkLicenseGUI, isValid, isPerpetual, isExpired, isAlmostExpired déterminent si la licence est valide ou expirée :
La classe Authorization gère le fichier cobaltstrike.auth : elle lit le contenu du fichier et appelle AuthCrypto().decrypt pour le traiter :
Dans AuthCrypto（）, le constructeur appelle load() ; la fonction load() effectue une vérification md5 sur resources/authkey.pub, puis récupère la clé publique RSA :
Dans decrypt(), _decrypt est appelé pour déchiffrer le contenu du fichier cobaltstrike.auth avec la clé publique RSA, le résultat étant affecté au tableau var2, puis converti via DataParser et affecté à var3 ; la méthode readInt() récupère les quatre premiers octets de var3 pour identifier l'en-tête du fichier (-889274181 pour les versions 3.x ; -889274157 pour les versions 4.x). Ensuite, readShort() récupère deux octets de var3 comme longueur et les affecte à var5, puis var6 = var3.readBytes(var5) récupère le contenu de cette longueur, l'affecte à var6 et le retourne :
Le tableau arrayOfByte2 obtenu dans la classe Authorization correspond au contenu après suppression des six premiers octets. Le traitement du tableau arrayOfByte2 se poursuit : quatre nombres sont d'abord récupérés et affectés à i, puis quatre nombres sont affectés à watermark, puis un nombre est affecté à b1 ; on vérifie que b1 est inférieur à 43 et que i est égal à 29999999. Dans common/ListenerConfig, si watermark vaut 0, un filigrane de détection antivirus est ajouté :
Après avoir supprimé les 6 premiers octets, puis les 9 octets correspondant à i, watermark et b1, il reste les clés des versions 4.0 à 4.3, de la forme : 16, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20 :
byte b2 = dataParser.readByte(); //获取1位，即16
byte[] arrayOfByte3 = dataParser.readBytes(b2); //获取16位，为4.0的key
byte b3 = dataParser.readByte(); //获取1位，即16
byte[] arrayOfByte4 = dataParser.readBytes(b3); //获取16位，为4.1的key
byte b4 = dataParser.readByte(); //获取1位，即16
byte[] arrayOfByte5 = dataParser.readBytes(b4); //获取16位，为4.2的key
byte b5 = dataParser.readByte(); //获取1位，即16
byte[] arrayOfByte6 = dataParser.readBytes(b5); //获取16位，为4.3的key赋值给arrayOfByte6
Dans la classe Authorization, la méthode SleevedResource.Setup est appelée pour traiter arrayOfByte6. Dans SleevedResource, la clé est définie comme clé de déchiffrement AES et HmacSHA256 ; dans _readResource, this.data.decrypt(arrayOfByte1); effectue l'appel de déchiffrement, le contenu déchiffré étant les fichiers dll de /sleeve/ :
Dans SleeveSecurity, la clé de déchiffrement AES et HmacSHA256 est définie ; une valeur de hachage de 256 octets est calculée à partir de la valeur transmise, dont les octets 0-16 servent de clé AES et les octets 16-32 de clé HmacSHA256 :
Sans la clé correspondante, il est impossible de déchiffrer les dll du dossier sleeve ; lors de la connexion au serveur, le message d'erreur [Sleeve] Bad HMAC s'affiche :
Pour la partie déchiffrement hmac, voir : Crack de Cobaltstrike 4 — Je m'attribue moi-même une licence
La clé d'un crack réussi est donc la clé correspondant à la version de CS.
Selon la description officielle, la version 4.5 renforce la sécurité de la licence, et c'est bien le cas.
Nous devons donc déchiffrer le fichier auth divulgué pour voir ce qui a été ajouté :
Après l'emplacement de la clé 4.5, une chaîne supplémentaire apparaît : il s'agit du watermarkHash ajouté dans cette version :
Le watermarkHash est lié à la génération du beacon et aux dll du dossier sleeve ; sans lui ou s'il est incorrect, le beacon ne peut pas se connecter. L'éditeur peut probablement remonter à la source de la fuite grâce à ce watermarkHash.
Commentez les autres codes et codez en dur le paramètre affecté après le déchiffrement RSA de AuthCrypto().decrypt :
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};
Principe de Javaagent : https://www.cnblogs.com/rickiyang/p/11368932.html
Outil de crack de référence : https://github.com/Twi1ight/CSAgent
Le cœur du crack reste la clé correspondant à la version de CS.
Dans beacon/BeaconData, la valeur de la méthode shouldPad est fixée à false :
Nouveau piège caché dans la 4.4
(L'analyse de la certification de licence a été faite avec la 4.3 comme exemple ; en passant à la 4.4, on constate que le programme se ferme à l'exécution : il existe un nouveau piège caché)
Outre le exit précédent lié à this.shouldPad, une vérification .class a été ajoutée dans common/Helper ; il suffit de la commenter :
Une vérification .class a été ajoutée dans common/Starter ; il suffit de la commenter :
Une vérification .class a été ajoutée dans common/Starter2 ; il suffit de la commenter :
Une vérification .class a été ajoutée dans beacon/CommandBuilder : (ce piège est vraiment vicieux — après 4 heures de connexion continue entre le client et le teamserver, les commandes ne peuvent plus être exécutées ; comme je n'avais jamais dépassé cette durée, je ne l'avais jamais remarqué, ggg)
Nouveaux pièges cachés dans la 4.5
La version 4.5 ajoute tout un tas de pièges cachés visant Javaagent ; ceux qui craquent en décompilant le fichier jar peuvent les ignorer ; il suffit de rechercher javaagent et de les modifier un par un :
Une fois ces points supprimés, on peut à nouveau faire du sport d'équipe.
Je ne m'attarderai pas sur la signature checksum8, mais il est tout de même nécessaire de la modifier pour éviter d'être détecté par nmap et les moteurs de recherche d'espace.
Dans BeaconPayload, modifiez la valeur XOR par une nouvelle valeur :
N'importe quel nombre décimal convient ; il faudra ensuite utiliser la valeur hexadécimale correspondante dans les dll.
Utilisez CrackSleeve pour déchiffrer les dll : https://github.com/ca3tie1/CrackSleeve/
javac -encoding UTF-8 -classpath cobaltstrike.jar CrackSleeve.java)java -classpath cobaltstrike.jar;./ CrackSleeve decode) # à exécuter en ligne de commande WindowsAppuyez sur Alt+T pour rechercher le mot-clé : 2Eh
Modifiez directement la valeur XOR : cliquez d'abord sur Change byte pour trouver 2E et le modifier, puis Apply pathes to input file pour enregistrer. (N'oubliez pas d'enregistrer)
Les dll à modifier : beacon.dll、beacon.x64.dll、dnsb.dll、dnsb.x64.dll、pivot.dll、pivot.x64.dll、extc2.dll、extc2.x64.dll（les nouveaux rl100k.dll de la 4.5 doivent également être modifiés）
Ensuite, réchiffrez les dll avec CrackSleeve ; enfin, placez les dll du répertoire encode dans le répertoire du projet Idea puis recompilez et reconditionnez.
Lors des tests, l'URI reste accessible, mais son contenu ne peut plus être déchiffré par les scripts nmap ; de même, cela permet d'échapper à la reconnaissance des moteurs de recherche d'espace :
Outre la modification de la valeur XOR, on peut aussi https://mp.weixin.qq.com/s?__biz=MzA3MDY2NjMxMA==&mid=2247484641&idx=1&sn=014f6c4ad5343e3f5034c33dffa66f26&chksm=9f3815c8a84f9cde1c7493ff29cfc89c0474fec48ede52be618727e7b9a5ab321c4743e1a44c&mpshare=1&scene=23&srcid=1202NA46yt71CvD3BMGKS10c&sharer_sharetime=1606892728447&sharer_shareid=ff83fe2fe7db7fcd8a1fcbc183d841c4#rd remplacer l'algorithme checksum8, mais cela ne permet plus qu'un accès à une URI fixe, nécessite un profile pour fonctionner, et chaque modification d'URI exige un nouveau packaging. Chaque méthode a ses avantages et ses inconvénients.
L'idée de modification pour supprimer les signatures BeaconEye provient de ce lien ; les octets à modifier pour les versions 4.3 et 4.4 sont les suivants.
Utilisez CrackSleeve pour déchiffrer les dll : https://github.com/ca3tie1/CrackSleeve/
Placez cobaltstrike.jar et CrackSleeve.java dans le même dossier
Compilez (javac -encoding UTF-8 -classpath cobaltstrike.jar CrackSleeve.java)
Déchiffrez le fichier (java -classpath cobaltstrike.jar;./ CrackSleeve decode) # à exécuter en ligne de commande Windows
4.3 clé 58, 68, 37, 73, 15, 56, -102, -18, -61, 18, -67, -41, 88, -83, 43, -103 4.4 clé 94, -104, 25, 74, 1, -58, -76, -113, -91, -126, -90, -87, -4, -69, -110, -42
Adresse : 10009FBB
6A 00 à modifier en 6A 09 (00 peut être remplacé par n'importe quelle valeur)
Adresse : 000000001800186C3
Dans beacon.x64.dll, l'instruction est xor edx, edx ; à modifier en mov edx, esi
Adresse : 1000A0B9
6A 00 à modifier en 6A 09 (00 peut être remplacé par n'importe quelle valeur)
Adresse : 000000018001879B
Dans beacon.x64.dll, l'instruction est xor edx, edx ; à modifier en mov edx, esi
Pour réchiffrer, utilisez : java -classpath cobaltstrike.jar;./ CrackSleeve encode
Adresse : 1000A65D
Adresse : 000000018000CA3F
(Les nouveaux rl100k.dll de la 4.5 doivent également être modifiés)
La méthode consiste simplement à ajouter une vérification de / sur l'URI : si l'URI ne commence pas par /, répondre 404 :
Modification 4.4
Modification 4.3
Afin d'éviter que le mot de passe TOTP ou le nom de connexion à CS ne fuient dans le journal des événements (Event Log), le champ name est affiché via MD5 salé ; après modification :
Ajout de la vérification à double facteur TOTP pour renforcer la connexion et empêcher que le mot de passe ne soit dérobé par force brute.
Côté teamserver, un lien de QR code TOTP a été ajouté dans la sortie du teamserver :
(Avant de supprimer nohup.out, pensez à copier le QR code ; à chaque démarrage du teamserver, un nouveau QR code est généré, il faut donc scanner à nouveau à chaque démarrage du teamserver)
Ouvrez dans un navigateur (nécessite un VPN), scannez le QR code avec Google Authenticator ou un validateur TOTP, ou copiez la clé après secret%3D et configurez-la dans le validateur :
Côté connect, host, port et password restent identiques à avant ; dans user, les six derniers chiffres correspondent au code dynamique TOTP et permettent la connexion :
Si le code dynamique TOTP n'est pas renseigné ou est incorrect, un avertissement s'affiche :
Remarque : si vous n'avez pas de téléphone sous la main, vous pouvez utiliser une extension de navigateur avec fonction TOTP ou écrire un simple script python pour générer le code TOTP.
L'erreur suivante est déclenchée lors d'un spawn avec windows/foreign/reverse_http(s) :
Cette version ajoute l'opération getScalar de Custom dans ScListener, mais ne tient pas compte du cas foreign, ce qui provoque l'erreur car var1.customDLL et customFileName sont vides :
La correction provisoire consiste à retourner directement le shellcode lorsque le payload est de type foreign ; si cette méthode présente d'autres bugs, veuillez signaler via les issues :
Après correction, cela fonctionne normalement :
Pour empêcher que la configuration ne soit lue par des pots de miel MySQL, le nom du fichier de configuration du client CS n'est plus celui par défaut ; un nom de fichier de 11 caractères est généré (11 caractères issus du md5 de l'adresse MAC).
