Nemesis

amanhã vou lançar uma atualização, mudando a licença e também algumas novidades contra roubadores de dados.

ferramenta para windows que fiz porque me cansei de olhar para forks do jlaive em amostras de malware sem nada público para realmente desmontá-los em tempo de execução.

resumindo, é um monitor de processos .net que hooka o clr na camada nativa, rastreia cargas reflexivas de assembly e extrai automaticamente os pes diretamente da memória. também verifica a integridade do amsi e etw em relação aos binários originais no disco enquanto detecta técnicas de bypass como patch de string em clr.dll e uso direto de LoadFromBuffer.

onde encontrar amostras? recomendo dar uma olhada em https://tria.ge (não é propaganda) e você pode baixar qualquer amostra que quiser e filtrar por família

por que o nome?

você deve estar se perguntando, por que o nome nemesis?

porque representa exatamente o propósito da ferramenta. uma nemesis é algo que se apresenta como um desafio constante ou a ruína de um oponente, e essa é a ideia por trás deste projeto.

na mitologia grega, nemesis era o espírito da retribuição divina, aquela que aplicava o castigo a qualquer um que se tornasse muito arrogante ou pensasse que era intocável. um pouco na cara para malwares que se gabam de serem "fud", se você me perguntar.

por que isso existe

sou analista de malware. se você faz esse trabalho (hobby para mim) por tempo suficiente, começa a ver as mesmas cadeias de loaders repetidamente, especialmente desde que o jlaive (também chamado de crybat) explodiu e todo script kiddie o forkou.

o padrão é estupidamente simples, mas irritante pra caramba de lidar:

something.bat  →  obfuscated powershell  →  csharp stub  →  your actual payload

você clica duas vezes num .bat que parece salada de palavras. cmd inicia o powershell com uma muralha de lixo. o powershell descriptografa/descomprime um stub .net (aes, gzip, base64). esse stub faz patch no amsi + etw, carrega reflexivamente o exe/dll real na memória, e pronto, nada amigável chega ao disco de forma útil.

isso me incomodava. não existe uma ferramenta pública boa voltada para combater essa cadeia específica, hookando onde o payload .net realmente se materializa, extraindo-o antes que o processo se destrua, capturando os patches de amsi/etw que esses stubs sempre fazem. então construí o nemesis.

não é uma bala de prata. não vai substituir sua sandbox. mas te dá algo real para executar contra um .bat suspeito numa máquina de teste e realmente extrair artefatos.

o que ele realmente faz

launcher (Launcher.exe)

• cria seu alvo suspenso (exe, bat, cmd, tanto faz)
• injeta Nemesis.dll antes da thread principal executar
• espera o nemesis dizer que está pronto
• retoma. se o alvo gerar processos filhos do powershell, o launcher pode injetar neles também

nemesis dll (Nemesis.dll)

• hooka caminhos de carregamento do clr que stubs estilo jlaive realmente usam:
  • nLoadImage
  • nLoadFile
  • AssemblyNative::LoadFromBuffer (padrão resolvido a partir de nLoadImage)
• quando um pe reflexivo aparece na memória -> enfileira um dump para %TEMP%\Nemesis_dumps
• compara exports ao vivo de amsi.dll / ntdll.dll com as cópias em disco (captura o clássico patch ret em AmsiScanBuffer / EtwEventWrite)
• a verificação do amsi também olha as strings .rdata do clr quando o clr é carregado (alguns bypasses fazem patch nelas, há um ótimo artigo da vxug sobre isso chamado: 2024-11-21 - New AMSI Bypss Technique Modifying CLRDLL in Memory.pdf)
• loga no console (colorido) + %TEMP%\Nemesis.log também tem para evitar problemas com o console sendo, digamos, estranho :D

basicamente: deixe a cadeia do bat executar, capture o payload onde o crypter realmente o carrega, e registre os truques de evasão ao longo do caminho.

Prova:

build

precisa de visual studio 2022+ com c++ desktop + masm (x64).

abra Nemesis.slnx, escolha Release | x64, compile a solução.

executar em um alvo real

este é o caso de uso real: aponte para um bat suspeito e veja o que sai:

cd x64\Release
.\Launcher.exe "C:\caminho\para\suspeito.bat"

argumentos extras após -- são passados para o alvo:

.\Launcher.exe myapp.exe -- --alguma-flag

caminho personalizado da dll:

.\Launcher.exe --dll C:\caminho\Nemesis.dll myapp.exe

artefatos:

• logs → %TEMP%\Nemesis.log
• pes extraídos → %TEMP%\Nemesis_dumps

o que o nemesis é / não é

é:

• um auxiliar de análise em tempo de execução para crypters estilo jlaive (cadeias bat → ps1 → csharp)
• útil numa vm de laboratório quando você tem uma amostra e quer dumps de memória + telemetria amsi/etw
• aberto para outros analistas usarem, estenderem, reclamarem

não é:

• um substituto de edr
• garantido de capturar todas as variantes de forks (ofuscações mudam, novos bypasses, ex. amsi/etw sem patch porque não foi feito para isso ainda e pretendo mudar isso no futuro; talvez isso se torne um toolkit de linguagem gerenciada)

notas

• apenas x64 para os detours asm do clr no momento
• hosts do cmd.exe frequentemente não têm clr, então o nemesis sinaliza "pronto" de qualquer forma e o launcher não trava; o trabalho real acontece quando o powershell/dotnet aparece
• a reconstrução falha com LNK1104? algo ainda carregou nemesis.dll, mate o alvo e reconstrua
• pwsh.exe ruído do vcpkg durante a build é inofensivo, ignore

leitura adicional (o ecossistema jlaive)

se você quiser entender contra o que está lutando:

• Trend Micro sobre BatCloak / Jlaive — o bolo em camadas bat → ps1 → csharp
• Fortinet sobre ScrubCrypt — o sucessor irritante do jlaive, se você tiver curiosidade sobre qual era a pequena diferença do scrubcrypt, era o fato de que eles canalizavam comandos com o sinal de pipe no .bat, funciona muito bem...
• Unprotect.it — ScrubCrypt — detalhamento da técnica
• https://github.com/backdoorskid/ClrAmsiScanPatcher - encontra a string .net como mencionado anteriormente, recomendo ler aquele .pdf :)

aviso legal

ao usar o nemesis você aceita isso. é fornecido como está sem garantia — você assume todo o risco.

você é o único responsável pelo uso lícito e autorizado (vms de laboratório, sistemas próprios, permissão explícita). na extensão máxima permitida por lei, os autores e zypherion.tech se isentam de toda responsabilidade por quaisquer danos, perdas ou reivindicações legais decorrentes do uso ou uso indevido. veja LICENSE para termos completos.

licença

uso não comercial / pessoal / pesquisa / hobby → PolyForm Noncommercial 1.0.0

uso comercial (venda, produto pago, saas, trabalho para clientes, etc.) → você precisa de uma licença separada. a polyform noncommercial não cobre isso.

me procure se quiser uma licença comercial:

[[email protected] / @wd6g(discord) / telegram: @ZypherionTechnologies]

todo

nota rápida: preciso verificar o compilemethod e corrigi-lo; por enquanto não é tão necessário, pois os crypters geralmente não o usam... já que eles têm que usar asm.load(...) também me lembro que preciso verificar as strings rdata, pois infelizmente não testei isso direito... não faça um PR com código idiota, por favor. Você não pode hookar backends n(Nativos) como nLoadImage normalmente, você tem que preservar registradores e é apenas meh, por isso usamos asm.