Nemesis

domani rilascio un aggiornamento, cambio licenza e anche qualche nuovo mons contro i data stealer.

strumento windows che ho creato perché ero stanco di guardare fork di jlaive nei campioni di malware senza nulla di pubblico per smontarli davvero a runtime.

in breve, è un monitor di processi .net che aggancia il clr a livello nativo, tiene traccia dei caricamenti riflessivi degli assembly e scarica automaticamente i PE direttamente dalla memoria. verifica anche l'integrità di AMSI e ETW rispetto ai binari originali su disco, rilevando tecniche di bypass come il patching di stringhe in clr.dll e l'uso diretto di LoadFromBuffer.

dove trovare campioni? consiglio di dare un'occhiata a https://tria.ge (non è una pubblicità) e puoi scaricare qualsiasi campione che vuoi filtrando per famiglia.

perché questo nome?

ti starai chiedendo, perché il nome nemesis?

perché rappresenta esattamente lo scopo dello strumento. una nemesi è qualcosa che rappresenta una sfida costante o la rovina per un avversario, ed è questa l'idea alla base del progetto.

nella mitologia greca, Nemesis era lo spirito della punizione divina, colei che infliggeva la giusta ricompensa a chiunque diventasse troppo arrogante o si credesse intoccabile. un po' azzeccato per malware che si vantano di essere "fud", se me lo chiedi.

perché esiste

sono un analista di malware. se fai questo lavoro (per me è un hobby) abbastanza a lungo, inizi a vedere sempre le stesse catene di loader, specialmente da quando jlaive (chiamato anche crybat) è esploso e ogni script kiddie lo ha forkato.

lo schema è stupidamente semplice ma fastidioso da gestire:

something.bat  →  obfuscated powershell  →  csharp stub  →  il tuo payload reale

fai doppio clic su un .bat che sembra un'insalata di parole. cmd avvia powershell con un muro di spazzatura. powershell decifra/decomprime uno stub .net (aes, gzip, base64). quello stub patch a AMSI + ETW, carica riflessivamente il vero exe/dll in memoria, e il gioco è fatto: niente di utile finisce mai su disco in una forma utilizzabile.

questo mi dava fastidio. non esiste un pubblico strumento valido per combattere questa specifica catena di hooking nel punto in cui il payload .net si concretizza, scaricandolo prima che il processo si autodistrugga, intercettando le patch AMSI/ETW che questi stub fanno sempre. così ho costruito nemesis.

Non è un proiettile d'argento. Non sostituirà la tua sandbox. Ma ti dà qualcosa di concreto da eseguire su un .bat sospetto in una macchina di test e tirare fuori artefatti.

cosa fa effettivamente

launcher (Launcher.exe)

• crea il target sospeso (exe, bat, cmd, qualsiasi cosa)
• inietta Nemesis.dll prima che il thread principale venga eseguito
• attende che nemesis segnali di essere pronto
• riprende l'esecuzione. se il target genera processi powershell figli, il launcher può iniettarli anch'essi

nemesis dll (Nemesis.dll)

• aggancia i percorsi di caricamento del clr che gli stub stile jlaive usano effettivamente:
  • nLoadImage
  • nLoadFile
  • AssemblyNative::LoadFromBuffer (pattern risolto partendo da nLoadImage)
• quando un PE riflessivo appare in memoria -> lo accoda per lo scaricamento in %TEMP%\Nemesis_dumps
• confronta gli export live di amsi.dll / ntdll.dll con le copie su disco (intercetta la classica patch ret su AmsiScanBuffer / EtwEventWrite)
• il controllo AMSI esamina anche le stringhe .rdata del clr quando il clr è caricato (alcuni bypass le patchano invece – c'è un ottimo paper di vxug su questo: 2024-11-21 - New AMSI Bypss Technique Modifying CLRDLL in Memory.pdf)
• scrive log su console (colorata) + %TEMP%\Nemesis.log. ha anche per evitare problemi con la console che a volte è un po'... strana :D

in pratica: lascia che la catena bat faccia il suo corso, intercetta il payload nel punto in cui il crypter lo carica effettivamente, e registra i trucchi di evasione lungo il percorso.

Prova:

build

serve Visual Studio 2022+ con c++ desktop + masm (x64).

apri Nemesis.slnx, scegli Release | x64, compila la soluzione.

esecuzione su un target reale

questo è il vero caso d'uso: puntalo a un bat sospetto e guarda cosa salta fuori:

cd x64\Release
.\Launcher.exe "C:\percorso\suspicious.bat"

gli argomenti extra dopo -- vengono passati al target:

.\Launcher.exe myapp.exe -- --qualche-flag

percorso personalizzato della dll:

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

artefatti:

• log → %TEMP%\Nemesis.log
• PE scaricati → %TEMP%\Nemesis_dumps

cosa nemesis è / non è

è:

• un aiuto per l'analisi a runtime di crypter stile jlaive (catene bat → ps1 → csharp)
• utile in una vm di laboratorio quando hai un campione e vuoi dump in memoria + telemetria AMSI/ETW
• aperto ad altri analisti per usarlo, estenderlo, lamentarsene

non è:

• un sostituto di EDR
• garantito per intercettare ogni variante di fork (l'offuscamento cambia, nuovi bypass, es. patchless amsi/etw perché al momento non è progettato per quello – e ho intenzione di cambiarlo in futuro; forse questo si trasformerà in un toolkit per linguaggi gestiti)

note

• solo x64 per i detour asm del clr al momento
• gli host cmd.exe spesso non hanno clr, nemesis segnala comunque pronto così il launcher non resta in attesa; il lavoro vero avviene quando powershell/dotnet si presenta
• la ricompilazione fallisce con LNK1104? qualcosa tiene ancora caricata Nemesis.dll – uccidi il target e ricompila
• pwsh.exe e il rumore vcpkg durante la build sono innocui, ignoralo

ulteriori letture (l'ecosistema jlaive)

se vuoi capire contro cosa stai combattendo:

• Trend Micro su BatCloak / Jlaive — la torta a strati bat → ps1 → csharp
• Fortinet su ScrubCrypt — il fastidioso successore di jlaive; se ti interessa, la differenza con scrubcrypt era che usavano il pipe in .bat per incanalare comandi, funziona bene...
• Unprotect.it — ScrubCrypt — analisi delle tecniche
• https://github.com/backdoorskid/ClrAmsiScanPatcher - trova la stringa .net di cui ho parlato prima; ti consiglio di leggere quel .pdf :)

disclaimer

usando nemesis accetti quanto segue. è fornito così com'è senza garanzie — ti assumi ogni rischio.

sei l'unico responsabile per un uso lecito e autorizzato (vm di laboratorio, sistemi di proprietà, autorizzazione esplicita). nella misura massima consentita dalla legge, gli autori e zypherion.tech declinano ogni responsabilità per danni, perdite o rivendicazioni legali derivanti dall'uso o dall'abuso. vedi LICENSE per i termini completi.

licenza

uso non commerciale / personale / ricerca / hobby → PolyForm Noncommercial 1.0.0

uso commerciale (vendita, prodotto a pagamento, saas, lavoro per clienti, ecc.) → serve una licenza separata. polyform noncommercial non copre questo.

contattami se vuoi una licenza commerciale:

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

todo

nota rapida: devo esaminare compilemethod e sistemarlo; al momento non è strettamente necessario perché i crypter di solito non lo usano affatto... visto che devono usare asm.load(...) mi ricordo anche di controllare le stringhe rdata, purtroppo non le ho ancora testate bene... non inviare una PR con codice stupido, per favore. non puoi hookare i backend nativi (es. nLoadImage) normalmente – devi preservare i registri e è una seccatura, ecco perché usiamo asm.