zeoday/cobaltstrike4.5_cdf-1CobaltStrike versione 4.5 crackata, rimozione della caratteristica checksum8, bypass di BeaconEye, correzione della perdita del percorso che espone lo stage, aggiunta dell'autenticazione a due fattori TOTP, correzione di CVE-2022-39197, ecc.
Crack della versione 4.5 di cobaltstrike, rimozione delle caratteristiche checksum8, bypass di BeaconEye, correzione della perdita di stage tramite percorsi errati, aggiunta dell'autenticazione a due fattori TOTP, aggiunta della visualizzazione del nome utente crittografato, correzione del bug di derivazione errata di foreign nella versione 4.5, modifica del nome del file di configurazione del client, ecc.
Crack di cobalt strike 4.5
Crack di cobaltstrike 4.5
[TOC]
Questo strumento e il contenuto dell'articolo sono destinati esclusivamente alla ricerca sulla sicurezza. L'utente si assume tutte le responsabilità legali e correlate derivanti dall'uso di questo strumento e del contenuto dell'articolo! L'autore non si assume alcuna responsabilità legale! Se durante l'utilizzo di questo strumento e del contenuto dell'articolo si verificano attività illegali, l'utente deve assumersi le conseguenze corrispondenti. Non ci assumeremo alcuna responsabilità legale o congiunta. In caso contrario, non installare né utilizzare questo strumento. Il tuo utilizzo o qualsiasi altra forma esplicita o implicita di accettazione di questo accordo costituisce la tua accettazione e accettazione dei termini di questo accordo. Quando si utilizza questo strumento per la ricerca sulla sicurezza, assicurati che l'attività sia conforme alle leggi e ai regolamenti e di aver ottenuto autorizzazioni sufficienti. Non utilizzare su obiettivi non autorizzati.
Sì, sono tornato, continuando la linea di cobaltstrike4.4_cdf originale: https://github.com/lovechoudoufu/about_cobaltstrike4.4_cdf Questa volta è la versione 4.5. Il precedente 4.4 è stato rimosso da github; probabilmente anche questo progetto verrà cancellato a breve.
Si consiglia di unirsi al gruppo dell'aeroplano; successivi aggiornamenti e progetti possono essere scaricati dal gruppo dopo la rimozione:
Prima dell'uso, verificare attentamente l'hash del jar corrispondente alla versione.
Processo di autenticazione del certificato (esempio con 4.3): la versione 4.5 ha leggere modifiche alla fine.
Chiavi di decrittazione ufficiali per varie versioni:
4.0 1be5be52c6255c33558e8a1cb667cb06
4.1 80e32a742060b884419ba0c171c9aa76
4.2 b20d487addd4713418f2d5a3ae02a7a0
4.3 3a4425490f389aeec312bdd758ad2b99
4.4 5e98194a01c6b48fa582a6a9fcbb92d6
cobaltstrike.auth file di chiave di autenticazione, crittografato con RSA. Contenuto decrittato:
4.3
-54, -2, -64, -45, // intestazione file
0, 77, // lunghezza successiva
1, -55, -61, 127, // limite temporale del certificato 29999999 (perpetuo)
0, 0, 0, 1, // watermark (filigrana)
43, // versione
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
Ad ogni aggiornamento di versione, la lunghezza corrispondente aumenta di 17 e la chiave aumenta di 17 byte.
In aggressor/Aggressor.class, License.checkLicenseGUI(new Authorization()); avvia l'autenticazione della licenza:
License.checkLicenseGUI utilizza isValid, isPerpetual, isExpired, isAlmostExpired per determinare se la licenza è valida o scaduta:
La classe Authorization gestisce il file cobaltstrike.auth: legge il contenuto e chiama AuthCrypto().decrypt per elaborarlo:
Nel costruttore AuthCrypto(), viene chiamato load(), che esegue un controllo MD5 su resources/authkey.pub e ottiene la chiave pubblica RSA:
Nel metodo decrypt(), viene chiamato _decrypt per decrittare il contenuto del file cobaltstrike.auth con la chiave pubblica RSA e assegnato all'array var2, poi convertito con DataParser per assegnare a var3. Il metodo readInt() ottiene i primi quattro byte di var3 per determinare l'intestazione del file (-889274181 per versione 3.x; -889274157 per versione 4.x). Successivamente, readShort() legge due byte come lunghezza e assegna a var5, poi var6 = var3.readBytes(var5) legge un array di quella lunghezza e lo restituisce come var6:
Nella classe Authorization, l'array arrayOfByte2 ottenuto è il contenuto dopo aver rimosso i primi sei byte. Si continua l'elaborazione di arrayOfByte2: prima si ottengono quattro numeri e li si assegna a i, poi quattro numeri a watermark, poi un numero a b1, si verifica che b1 sia minore di 43, che i sia uguale a 29999999. In common/ListenerConfig, quando watermark è 0, viene aggiunta una filigrana di rilevamento antivirus:
Dopo aver rimosso i primi 6 byte, poi i 9 byte di i, watermark e b1, ciò che rimane sono le chiavi dalla versione 4.0 alla 4.3: struttura 16, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20:
byte b2 = dataParser.readByte(); // ottiene 1 byte, cioè 16
byte[] arrayOfByte3 = dataParser.readBytes(b2); // ottiene 16 byte, che è la chiave per 4.0
byte b3 = dataParser.readByte(); // ottiene 1 byte, cioè 16
byte[] arrayOfByte4 = dataParser.readBytes(b3); // ottiene 16 byte, che è la chiave per 4.1
byte b4 = dataParser.readByte(); // ottiene 1 byte, cioè 16
byte[] arrayOfByte5 = dataParser.readBytes(b4); // ottiene 16 byte, che è la chiave per 4.2
byte b5 = dataParser.readByte(); // ottiene 1 byte, cioè 16
byte[] arrayOfByte6 = dataParser.readBytes(b5); // ottiene 16 byte, che è la chiave per 4.3, assegnata a arrayOfByte6
Nella classe Authorization, viene chiamato il metodo SleevedResource.Setup su arrayOfByte6. In SleevedResource, la chiave viene impostata come chiave di decrittazione AES/HmacSHA256. Nel metodo _readResource, viene chiamato this.data.decrypt(arrayOfByte1); per decrittare il contenuto, che sono i file DLL in /sleeve/:
In SleeveSecurity, la chiave di decrittazione AES/HmacSHA256 viene impostata utilizzando il valore passato per calcolare un digest di 256 bit, poi i primi 0-16 byte diventano la chiave AES e i byte 16-32 diventano la chiave HmacSHA256:
Se la chiave corrispondente non viene ottenuta, non è possibile decrittare i DLL nella cartella sleeve. Quando ci si connette al server, viene visualizzato l'errore [Sleeve] Bad HMAC:
Per la parte relativa alla decrittazione HMAC, fare riferimento a: Cobaltstrike 4 cracking: mi rilascio la licenza da solo
Pertanto, la chiave per completare il crack è la chiave corrispondente alla versione di CS.
Secondo la documentazione ufficiale, la versione 4.5 ha aumentato la sicurezza della licenza, ed è effettivamente così.
Quindi dobbiamo decrittare il file auth trapelato per vedere cosa è stato aggiunto:
Dopo la posizione della chiave della versione 4.5 c'è una stringa aggiuntiva. Questo extra è il watermarkHash aggiunto in questa versione:
watermarkHash è correlato alla generazione di beacon e ai DLL nella cartella sleeve. Senza di esso o con uno errato, non è possibile ottenere una connessione. Probabilmente, ufficialmente possono risalire alla fonte della fuga tramite questo watermarkHash.
Commentare altro codice e scrivere direttamente i parametri passati dopo la decrittazione RSA da 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};
Principio di Javaagent: https://www.cnblogs.com/rickiyang/p/11368932.html
Strumento di crack di riferimento: https://github.com/Twi1ight/CSAgent
Il nucleo del crack resta la chiave corrispondente alla versione di CS.
In beacon/BeaconData, impostare il valore del metodo shouldPad su false:
Nuova backdoor nella versione 4.4
(In precedenza, abbiamo analizzato l'autenticazione della licenza usando la versione 4.3. Passando alla 4.4, abbiamo scoperto che il programma si arresta in modo anomalo, indicando una nuova backdoor.)
Rispetto al precedente exit di this.shouldPad, è stato aggiunto un controllo .class in common/Helper; commentare:
È stato aggiunto un controllo .class in common/Starter; commentare:
È stato aggiunto un controllo .class in common/Starter2; commentare:
È stato aggiunto un controllo .class in beacon/CommandBuilder: (questa backdoor è subdola: dopo 4 ore di connessione continua tra client e teamserver, non è possibile eseguire comandi. Non l'avevamo mai scoperta perché non eravamo mai stati connessi così a lungo. maledetta)
Nuova backdoor nella versione 4.5
La versione 4.5 ha aggiunto una serie di backdoor contro javaagent; se si decompila il jar e si effettua il cracking, si possono ignorare. Cercare specificamente javaagent e modificarle una per una:
Rimuovendo questi punti, possiamo di nuovo fare attività di gruppo.
Non entrerò nei dettagli sulla caratteristica checksum8. Per evitare di essere rilevati da nmap e motori di scansione spaziale, è necessario modificarla.
In BeaconPayload, modificare il valore XOR con uno nuovo:
Qualsiasi numero decimale va bene; nei DLL successivi, usare il corrispondente numero esadecimale.
Usare CrackSleeve per decrittare i DLL: https://github.com/ca3tie1/CrackSleeve/
cobaltstrike.jar e CrackSleeve.java insieme.javac -encoding UTF-8 -classpath cobaltstrike.jar CrackSleeve.java)java -classpath cobaltstrike.jar;./ CrackSleeve decode) # eseguire su riga di comando WindowsPremere Alt+T per la ricerca per parola chiave: 2Eh
Modificare direttamente il valore XOR. Prima usare "Change byte" per trovare 2E e modificarlo, poi "Apply pathes to input file" per salvare. (Non dimenticare di salvare)
DLL da modificare: beacon.dll, beacon.x64.dll, dnsb.dll, dnsb.x64.dll, pivot.dll, pivot.x64.dll, extc2.dll, extc2.x64.dll (4.5 ha aggiunto alcuni rl100k.dll che vanno anch'essi modificati)
Poi usare CrackSleeve per crittografare i DLL. Infine, mettere i DLL dal percorso encode nella directory del progetto idea e ricompilare per creare il pacchetto.
Test: l'URI di test è ancora accessibile, ma il contenuto non può più essere decrittato dagli script nmap; allo stesso modo, si può evitare il riconoscimento dai motori di scansione spaziale:
Oltre a modificare il valore XOR, si può anche (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) modificare l'algoritmo checksum8, ma questo consente solo URI fissi; richiede l'uso di un profilo e ogni modifica dell'URI richiede un nuovo pacchetto. Ogni metodo ha i suoi pro e contro.
L'idea per rimuovere le caratteristiche di beaconeye proviene da link, usando come esempio le versioni 4.3 e 4.4. I byte da modificare sono i seguenti.
Usare CrackSleeve per decrittare i DLL: https://github.com/ca3tie1/CrackSleeve/
cobaltstrike.jar e CrackSleeve.java insieme.javac -encoding UTF-8 -classpath cobaltstrike.jar CrackSleeve.java)java -classpath cobaltstrike.jar;./ CrackSleeve decode) # eseguire su riga di comando WindowsChiave 4.3: 58, 68, 37, 73, 15, 56, -102, -18, -61, 18, -67, -41, 88, -83, 43, -103 Chiave 4.4: 94, -104, 25, 74, 1, -58, -76, -113, -91, -126, -90, -87, -4, -69, -110, -42
Indirizzo: 10009FBB
Modificare 6A 00 in 6A 09 (00 in qualsiasi valore)
Indirizzo: 000000001800186C3
In beacon.x64.dll, l'istruzione è xor edx, edx; modificare in mov edx, esi
Indirizzo: 1000A0B9
Modificare 6A 00 in 6A 09 (00 in qualsiasi valore)
Indirizzo: 000000018001879B
In beacon.x64.dll, l'istruzione è xor edx, edx; modificare in mov edx, esi
Crittografare di nuovo usando: java -classpath cobaltstrike.jar;./ CrackSleeve encode
Indirizzo: 1000A65D
Indirizzo: 000000018000CA3F
(4.5 ha aggiunto alcuni rl100k.dll che vanno anch'essi modificati)
Il metodo consiste nell'aggiungere un controllo / all'URI; se non inizia con /, restituire 404:
Modifica per la versione 4.4:
Modifica per la versione 4.3:
Per evitare la fuga della password TOTP o del nome di accesso a cs nel registro eventi, il campo name viene visualizzato con MD5 salato. Dopo la modifica, appare così:
Aggiunta dell'autenticazione a due fattori TOTP per rafforzare l'accesso e prevenire il cracking delle password.
Lato teamserver, nell'output di teamserver è stato aggiunto un collegamento al codice QR TOTP:
(Prima di eliminare nohup.out, ricordare di copiare il QR code. Ogni avvio di teamserver genera un nuovo QR code, quindi ogni volta che si avvia il server è necessario scansionare di nuovo.)
Aprire il browser (è necessario un proxy) e usare Google Authenticator o un'app TOTP per scansionare il codice QR, oppure copiare la chiave dopo secret%3D e configurarla nell'app:
Lato connect, host, port e password rimangono come prima; in user, gli ultimi sei caratteri sono il numero dinamico TOTP per connettersi:
Se il numero TOTP non viene inserito o è errato, viene visualizzato:
Nota: a volte non si ha un telefono; si può usare un'estensione del browser per TOTP o scrivere un semplice codice Python per generare il codice TOTP.
Durante lo spawn con windows/foreign/reverse_http(s) si verifica il seguente errore:
In questa versione, in ScListener è stata aggiunta un'operazione getScalar relativa a Custom, ma non è stato considerato il caso di foreign, causando l'errore con var1.customDLL e customFileName vuoti:
La correzione temporanea consiste nel restituire direttamente shellcode quando il payload è foreign. Se ci sono altri bug, si possono segnalare tramite issues:
Dopo la correzione, funziona correttamente:
Per evitare che i database MySQL honeypot leggano la configurazione, il nome del file di configurazione del client cs non è più predefinito; viene generato un nome di file di 11 caratteri (11 caratteri dell'MD5 dell'indirizzo MAC).
