pwn1sher/frostbyteCombina injeção de AppDomain Manager com incorporação de shellcode em binários assinados para evadir detecção de EDR/AV em payloads de red team.
Nos últimos dias, venho experimentando a técnica de injeção de gerenciador de AppDomain e tive um sucesso razoável com ela em meus engajamentos anteriores de Red Team contra certos EDRs. Embora seja realmente boa para vetor de acesso inicial, quis lançar uma POC que ajudará a ocultar seu shellcode em outro lugar. Chega de arquivos DLL com shellcode embutido!
Embora seja uma técnica excelente quando usada de forma independente, quando combinada com uma técnica de entrega como enviar um C# ClickOnce dentro de um arquivo ISO/ZIP/VHD/VHDX, o real problema é que 1 em cada 10 vezes a DLL do appdomain era detectada por heurísticas de IA/ML do AV/EDR. Isso porque o arquivo DLL precisa ser descartado no disco antes de inicializar o appdomain. Ignorando os carregamentos remotos de DLL por enquanto (caminhos UNC no .config), a DLL do appdomain conteria o shellcode e eu sentia fortemente que essa é a razão para uma provável detecção estática, pois o restante do código, que são chamadas WINAPI, pode ser resolvido dinamicamente e bem ofuscado.
Eu queria aprimorar essa técnica em termos de minimizar o que a DLL inicialmente conteria. Comecei descartando shellcode criptografado em um arquivo separado no disco junto com a DLL injetora, mas então me deparei com este incrível blog da Checkpoint sobre a Campanha do Zloader
Versão resumida: Podemos incorporar dados arbitrários em alguns campos dentro do PE de forma que não quebre a assinatura do arquivo. Assim, nossos dados serão embutidos e o executável ainda permanecerá assinado digitalmente.
Mais informações sobre isso - https://www.blackhat.com/docs/us-16/materials/us-16-Nipravsky-Certificate-Bypass-Hiding-And-Executing-Malware-From-A-Digitally-Signed-Executable-wp.pdf
Então a ideia é incorporar um stub de shellcode criptografado em um executável assinado conhecido e ainda assim conseguir mantê-lo assinado, como o malware Zloader fez. Ao fazer isso, a DLL do AppDomain Manager não conterá mais o shellcode dentro de si, mas terá apenas a lógica para analisar o shellcode do binário PE que o carrega, para descriptografar e executar como uma thread separada. Fazer isso pode diminuir a taxa de detecção estática da DLL enquanto seu shellcode está bem colocado dentro de um binário assinado.
Eu estava tentando conseguir isso adulterando manualmente as amostras do ZLoader que obtive do VirusTotal, mas depois descobri um projeto que já implementava todas essas técnicas muito bem - Sigflip. Nesta POC, aproveitei o código do loader do SigFlip para construir a DLL do AppDomain e o injetor SigFlip para incorporar o shellcode criptografado em nosso executável C#.
Grandes blocos de shellcode, como o shellcode sem estágio do Cobalt Strike, não residirão mais em uma DLL não assinada no disco, independentemente das técnicas de ofuscação/codificação usadas. A DLL fica mais limpa, menor e mais furtiva, com código mínimo, reduzindo assim as chances de detecção.
SigFlip.exe -i "Z:\ZLoader\CasPol.exe" "Z:\ZLoader\x64-stageless.bin" "Z:\ZLoader\update.exe" "S3cretK3y"update.exe, que será um PE assinado digitalmente com shellcode criptografado embutido.csc /target:library /out:test.dll test.csEsta POC é apenas uma ideia que tive em mente para unir duas técnicas de evasão de defesa totalmente diferentes, que ajudariam a mim e a outros Red Teamers a construir melhores payloads de execução inicial para suas operações. Este projeto usa a injeção de AppDomain Manager como exemplo, mas essa ideia é aplicável para outras técnicas de injeção também, como - DLL SideLoading, DLL Hijacking, etc.
Créditos totais a med0x2e, esta POC é construída com base em seu projeto SigFlip