Crack da versão 4.5 do CobaltStrike, remove a característica checksum8, ignora o BeaconEye, corrige o vazamento de caminho de erro do stage, adiciona verificação de dois fatores TOTP, corrige CVE-2022-39197 entre outros.
crack da versão cobaltstrike4.5, remoção da característica checksum8, bypass BeaconEye, correção de vazamento de stage por caminho incorreto, adição de verificação de dois fatores TOTP, adição de exibição criptografada do nome de usuário, correção do bug de derivação foreign na versão 4.5, modificação do nome do arquivo de configuração do cliente, etc.
Crack do cobalt strike 4.5
Crack do cobaltstrike 4.5
[TOC]
Esta ferramenta e o conteúdo do artigo são exclusivamente para pesquisa de segurança. O usuário assume todas as responsabilidades legais e relacionadas decorrentes do uso desta ferramenta e do conteúdo do artigo! O autor não assume nenhuma responsabilidade legal! Se você tiver qualquer conduta ilegal ao usar esta ferramenta e o conteúdo do artigo, você deve arcar com as consequências correspondentes por conta própria, e não assumiremos nenhuma responsabilidade legal ou solidária. Caso contrário, não instale nem use esta ferramenta. Seu uso ou qualquer outra forma explícita ou implícita de aceitação deste acordo será considerado como tendo lido e concordado com os termos deste acordo. Ao usar esta ferramenta para pesquisa de segurança, você deve garantir que a conduta esteja em conformidade com as leis e regulamentos e que tenha obtido autorização suficiente. Não use em alvos não autorizados.
Sim, estou de volta, continuando o original cobaltstrike4.4_cdf: https://github.com/lovechoudoufu/about_cobaltstrike4.4_cdf Desta vez é a versão 4.5. O 4.4 anterior foi removido pelo GitHub, e é provável que este projeto também seja excluído em breve.
Recomenda-se entrar no grupo do Telegrama, para que atualizações futuras e outros projetos removidos possam ser baixados do grupo:
Antes de usar, verifique cuidadosamente o hash do arquivo jar da versão correspondente.
Processo de certificação de licença (exemplo da 4.3): A versão 4.5 tem pequenas alterações no final.
Chaves de descriptografia oficiais de cada versão:
4.0 1be5be52c6255c33558e8a1cb667cb06
4.1 80e32a742060b884419ba0c171c9aa76
4.2 b20d487addd4713418f2d5a3ae02a7a0
4.3 3a4425490f389aeec312bdd758ad2b99
4.4 5e98194a01c6b48fa582a6a9fcbb92d6
Arquivo de chave de autenticação cobaltstrike.auth, criptografado com RSA, conteúdo descriptografado:
4.3
-54, -2, -64, -45, // cabeçalho do arquivo
0, 77, // comprimento subsequente
1, -55, -61, 127, // limite de tempo do certificado 29999999 (permanente)
0, 0, 0, 1, // watermark (marca d'água)
43, // versão
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
A cada atualização de versão, o comprimento correspondente aumenta em 17, e a chave aumenta em 17 bytes.
Em aggressor/Aggressor.class, License.checkLicenseGUI(new Authorization()); inicia a verificação de licença:
Em License.checkLicenseGUI, isValid, isPerpetual, isExpired, isAlmostExpired determinam se a licença é válida e se expirou:
A classe Authorization processa o arquivo cobaltstrike.auth, lê o conteúdo e chama AuthCrypto().decrypt para processá-lo:
No construtor AuthCrypto(), chama load(), que calcula o MD5 de resources/authkey.pub e obtém a chave pública RSA:
Em decrypt(), chama _decrypt para descriptografar o conteúdo do arquivo cobaltstrike.auth com a chave pública RSA, atribuindo o resultado ao array var2. Depois, usa DataParser para converter e atribuir a var3. O método readInt() obtém os primeiros quatro bits de var3 para verificar o cabeçalho do arquivo (-889274181 para versão 3.x; -889274157 para versão 4.x). Então, em var3, readShort() obtém dois bits como comprimento atribuído a var5, e var6 = var3.readBytes(var5) obtém o conteúdo desse comprimento e o atribui a var6, que é retornado:
Na classe Authorization, o array arrayOfByte2 obtido é o conteúdo após a remoção dos primeiros seis bits. Continua processando arrayOfByte2: primeiro obtém quatro números atribuídos a i, depois quatro números atribuídos a watermark, depois um número atribuído a b1. Verifica se b1 é menor que 43 e se i é igual a 29999999. Em common/ListenerConfig, verifica se watermark é 0, o que adiciona uma marca d'água de detecção de antivírus:
Após remover os primeiros seis bits, remove também os nove bits de i, watermark e b1. O restante é a chave das versões 4.0 a 4.3, com estrutura: 16, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20:
byte b2 = dataParser.readByte(); // obtém 1 byte, ou seja, 16
byte[] arrayOfByte3 = dataParser.readBytes(b2); // obtém 16 bytes, a chave da versão 4.0
byte b3 = dataParser.readByte(); // obtém 1 byte, ou seja, 16
byte[] arrayOfByte4 = dataParser.readBytes(b3); // obtém 16 bytes, a chave da versão 4.1
byte b4 = dataParser.readByte(); // obtém 1 byte, ou seja, 16
byte[] arrayOfByte5 = dataParser.readBytes(b4); // obtém 16 bytes, a chave da versão 4.2
byte b5 = dataParser.readByte(); // obtém 1 byte, ou seja, 16
byte[] arrayOfByte6 = dataParser.readBytes(b5); // obtém 16 bytes, a chave da versão 4.3 atribuída a arrayOfByte6
Na classe Authorization, chama o método SleevedResource.Setup para processar arrayOfByte6. Em SleevedResource, define a chave como chave de descriptografia AES e HmacSHA256. Em _readResource, chama this.data.decrypt(arrayOfByte1); para descriptografar, e o conteúdo descriptografado são os arquivos DLL em /sleeve/:
Em SleeveSecurity, define a chave de descriptografia AES e HmacSHA256, calcula um resumo de 256 bits usando o valor passado, depois usa os bits 0-16 como chave AES e bits 16-32 como chave HmacSHA256:
Se a chave correspondente não for obtida, não será possível descriptografar as DLLs na pasta sleeve. Ao conectar ao servidor, será exibido o erro [Sleeve] Bad HMAC:
A parte da descriptografia HMAC pode ser consultada em: Cobaltstrike 4破解之 我自己给我自己颁发license
Portanto, a chave para o crack é obter a chave correspondente à versão do CS.
De acordo com a descrição oficial, a versão 4.5 adicionou segurança à licença. De fato:
Então, precisamos descriptografar o arquivo auth vazado para ver o que há de novo:
Após a posição da chave da versão 4.5, há uma string adicional. Esses bytes extras são o watermarkHash adicionado nesta versão:
O watermarkHash está relacionado à geração do beacon e às DLLs na pasta sleeve. Sem ele ou com ele incorreto, não é possível obter conexão. Provavelmente, os desenvolvedores podem rastrear a origem do vazamento através desse watermarkHash.
Comente outras partes do código e fixe o parâmetro atribuído após a descriptografia RSA em 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};
Princípio do Javaagent: https://www.cnblogs.com/rickiyang/p/11368932.html
Ferramenta de crack de referência: https://github.com/Twi1ight/CSAgent
O núcleo do crack ainda exige a chave correspondente à versão do CS.
Em beacon/BeaconData, defina o valor do método shouldPad como false:
Nova armadilha na versão 4.4
(Anteriormente, usamos a versão 4.3 como exemplo para análise da licença. Ao mudar para a 4.4, descobrimos que o programa saía, indicando uma nova armadilha.)
Além do exit do this.shouldPad, foi adicionada uma verificação de classe em common/Helper. Basta comentar:
Foi adicionada uma verificação de classe em common/Starter. Basta comentar:
Foi adicionada uma verificação de classe em common/Starter2. Basta comentar:
Foi adicionada uma verificação de classe em beacon/CommandBuilder (essa armadilha é bem traiçoeira: após 4 horas de conexão contínua entre cliente e servidor, os comandos não podem ser executados; como nunca conectamos por tanto tempo, não descobrimos antes):
Nova armadilha na versão 4.5
A versão 4.5 adicionou um monte de armadilhas para o Javaagent. Quem descompila o jar para fazer o crack pode ignorá-las; basta pesquisar por "javaagent" e modificar cada ocorrência:
Removendo esses pontos, podemos voltar a operar em equipe.
A característica checksum8 não será detalhada. Para evitar ser escaneado pelo nmap e por mecanismos de busca espacial, é necessário modificá-la.
Em BeaconPayload, altere o valor do XOR para um novo número:
Qualquer número decimal serve; depois, no DLL, altere para o número hexadecimal correspondente.
Use o CrackSleeve para descriptografar o DLL: https://github.com/ca3tie1/CrackSleeve/
cobaltstrike.jar e o CrackSleeve.java juntos.javac -encoding UTF-8 -classpath cobaltstrike.jar CrackSleeve.java)java -classpath cobaltstrike.jar;./ CrackSleeve decode) # Execute no terminal WindowsPressione Alt+T para pesquisar a palavra-chave: 2Eh
Modifique diretamente o valor do XOR. Primeiro, clique em "Change byte", encontre 2E e modifique. Depois, clique em "Apply patches to input file" para salvar (não se esqueça de salvar).
DLLs que precisam ser modificadas: beacon.dll, beacon.x64.dll, dnsb.dll, dnsb.x64.dll, pivot.dll, pivot.x64.dll, extc2.dll, extc2.x64.dll (as novas rl100k.dll da versão 4.5 também precisam ser modificadas)
Em seguida, use o CrackSleeve para criptografar novamente o DLL. Por fim, coloque os DLLs do diretório encode no diretório do projeto IDEA e recompile o pacote.
Após o teste, o URI ainda pode ser acessado, mas o conteúdo não pode mais ser descriptografado pelo script nmap, evitando também a detecção por mecanismos de busca espacial:
Além de modificar o valor do XOR, também é possível alterar o algoritmo checksum8 (conforme referência: 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) – mas isso fixa o URI, exigindo o uso de perfil, e cada alteração de URI exige reempacotamento. Cada método tem seus prós e contras.
A ideia para remover a característica do BeaconEye veio do link. Tomando como exemplo as versões 4.3 e 4.4, os bytes que precisam ser modificados são os seguintes.
Use o CrackSleeve para descriptografar o DLL: https://github.com/ca3tie1/CrackSleeve/
cobaltstrike.jar e o CrackSleeve.java juntos.javac -encoding UTF-8 -classpath cobaltstrike.jar CrackSleeve.java)java -classpath cobaltstrike.jar;./ CrackSleeve decode) # Execute no terminal WindowsChave da versão 4.3: 58, 68, 37, 73, 15, 56, -102, -18, -61, 18, -67, -41, 88, -83, 43, -103 Chave da versão 4.4: 94, -104, 25, 74, 1, -58, -76, -113, -91, -126, -90, -87, -4, -69, -110, -42
Endereço: 10009FBB
Altere 6A 00 para 6A 09 (substitua 00 por qualquer valor)
Endereço: 000000001800186C3
No beacon.x64.dll, a instrução é xor edx, edx. Altere para mov edx, esi
Endereço: 1000A0B9
Altere 6A 00 para 6A 09 (substitua 00 por qualquer valor)
Endereço: 000000018001879B
No beacon.x64.dll, a instrução é xor edx, edx. Altere para mov edx, esi
Use a recriptografia: java -classpath cobaltstrike.jar;./ CrackSleeve encode
Endereço: 1000A65D
Endereço: 000000018000CA3F
(As novas DLLs rl100k.dll da versão 4.5 também precisam ser modificadas)
O método é adicionar uma verificação de / no URI. Se não começar com /, responder com 404:
Modificação na versão 4.4:
Modificação na versão 4.3:
Para evitar o vazamento da senha TOTP ou do nome de login no Event Log, o campo name é exibido com um MD5 com sal. Após a modificação:
Foi adicionada a verificação de dois fatores TOTP para aumentar a segurança do login e evitar que a senha seja descoberta por força bruta.
No lado do teamserver, foi adicionado um link para o QR code TOTP na saída do teamserver:
(Antes de excluir o nohup.out, lembre-se de copiar o QR code. Cada vez que o teamserver é iniciado, um novo QR code é gerado; portanto, é necessário escanear novamente a cada inicialização.)
Abra no navegador (precisa de VPN) e use o Google Authenticator ou um verificador TOTP para escanear o QR code. Ou copie a chave após secret%3D e configure no verificador:
No lado do connect, o host, porta e senha permanecem os mesmos. No campo user, os últimos seis dígitos devem ser o número dinâmico do TOTP para conectar:
Se o número dinâmico do TOTP não for preenchido ou estiver incorreto, será exibida uma mensagem:
Observação: Quando não houver celular disponível, você pode usar um plugin de TOTP no navegador ou criar um pequeno código Python para gerar o TOTP.
Ao usar windows/foreign/reverse_http(s) para spawn, ocorre o seguinte erro:
Nesta versão, foi adicionada uma operação getScalar relacionada a Custom em ScListener, mas não foi considerado o caso foreign, resultando em erro quando var1.customDLL e customFileName estão vazios:
A correção temporária é verificar se o payload é foreign e, nesse caso, retornar diretamente o shellcode. Se houver outros bugs com esse método, reporte via issues:
Após a correção, o uso normal é restaurado:
Para evitar que a configuração seja lida por honeypots MySQL, o nome do arquivo de configuração do cliente do CS não é mais padrão: ele gera um nome de arquivo com 11 caracteres (11 dígitos do MD5 do endereço MAC).
