Nemesis

demain, je pousse une mise à jour, changement de licence et aussi quelques nouveaux monstres contre les voleurs de données.

outil Windows que j'ai créé parce que j'en avais marre de regarder des forks de jlaive dans des échantillons de malwares sans rien de public pour les déchiqueter au moment de l'exécution.

en bref, c'est un moniteur de processus .NET qui accroche le CLR au niveau natif, suit les chargements d'assembly réflexifs et vide automatiquement les PE directement depuis la mémoire. Il vérifie également l'intégrité d'AMSI et d'ETW par rapport aux binaires originaux sur disque tout en détectant les techniques de contournement telles que le patch de chaîne clr.dll et l'utilisation directe de LoadFromBuffer.

où trouver des échantillons ? je recommande de jeter un œil à https://tria.ge (pas une pub) et tu peux télécharger n'importe quel échantillon que tu veux et filtrer par famille.

pourquoi ce nom ?

vous vous demandez peut-être, pourquoi le nom Nemesis ? parce qu'il représente exactement le but de l'outil. un nemesis est quelque chose qui se présente comme un défi constant ou une chute pour un adversaire et c'est l'idée derrière ce projet. dans la mythologie grecque, Nemesis était l'esprit de la rétribution divine, celle qui rendait la pareille à quiconque devenait trop arrogant ou se croyait intouchable. un peu ironique pour un malware qui se vante d'être "fud" si vous voulez mon avis.

pourquoi ça existe

je suis analyste de malwares. si vous faites ce métier (c'est un hobby pour moi) assez longtemps, vous commencez à voir les mêmes chaînes de chargeurs encore et encore, surtout depuis que jlaive (aussi appelé crybat) a explosé et que tous les script kiddies l'ont fork.

le motif est stupide simple mais sacrément agaçant à traiter :

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

vous double-cliquez sur un .bat qui ressemble à une salade de mots. cmd lance powershell avec un mur de bazar. powershell déchiffre/décompresse un stub .NET (aes, gzip, base64). ce stub patche amsi + etw, charge réflexivement le vrai exe/dll en mémoire, et vous avez terminé, rien de sympathique n'atteint jamais le disque sous une forme utile.

ça m'a irrité. il n'existe pas vraiment de bon outil public destiné à lutter contre cette chaîne spécifique en accrochant l'endroit où la charge utile .NET se matérialise réellement, en la vidant avant que le processus ne se consume, en attrappant les patches amsi/etw que ces stubs font toujours. alors j'ai construit nemesis.

pas une solution miracle. ça ne va pas remplacer votre sandbox. mais ça vous donne quelque chose de réel à exécuter contre un .bat suspect sur une machine de test et à en extraire des artefacts.

ce qu'il fait réellement

launcher (Launcher.exe)

• crée votre cible en suspension (exe, bat, cmd, peu importe)
• injecte Nemesis.dll avant que le thread principal ne s'exécute
• attend que nemesis annonce qu'il est prêt
• reprend. si la cible génère des processus powershell enfants, le launcher peut aussi les injecter

nemesis dll (Nemesis.dll)

• accroche les chemins de chargement du CLR que les stubs de style jlaive atteignent réellement :
  • nLoadImage
  • nLoadFile
  • AssemblyNative::LoadFromBuffer (pattern resolved off nLoadImage)
• quand un PE réflexif apparaît en mémoire -> met en file d'attente un dump vers %TEMP%\Nemesis_dumps
• compare les exports en direct de amsi.dll / ntdll.dll avec les copies sur disque (attrape le patch classique ret sur AmsiScanBuffer / EtwEventWrite)
• la vérification AMSI regarde aussi les chaînes .rdata du CLR quand le CLR est chargé (certains contournements patchent celles-ci à la place, il y a un super article vxug là-dessus appelé 2024-11-21 - New AMSI Bypss Technique Modifying CLRDLL in Memory.pdf )
• journalise sur la console (en couleur) + %TEMP%\Nemesis.log il a aussi pour éviter les problèmes avec la console qui est, disons, bizarre :D

en gros : laissez la chaîne bat s'exécuter, attrapez la charge utile là où le crypter la charge réellement, et enregistrez les astuces d'évasion en chemin.

Preuve :

compilation

nécessite Visual Studio 2022+ avec Bureau C++ + masm (x64).

ouvrez Nemesis.slnx, choisissez Release | x64, compilez la solution.

exécution sur une cible réelle

c'est le cas d'utilisation réel, pointez-le vers un bat suspect et voyez ce qui en sort :

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

extra args after -- get passed to the target:

.\Launcher.exe myapp.exe -- --some-flag

custom dll path:

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

artefacts :

• journaux → %TEMP%\Nemesis.log
• PE vidés → %TEMP%\Nemesis_dumps

ce que nemesis est / n'est pas

est :

• un assistant d'analyse au moment de l'exécution pour les crypter de style jlaive (chaînes bat → ps1 → csharp)
• utile sur une VM de labo quand vous avez un échantillon et que vous voulez des dumps en mémoire + télémétrie amsi/etw
• ouvert pour que d'autres analystes l'utilisent, l'étendent, se plaignent

n'est pas :

• un remplacement d'EDR
• garanti d'attraper toutes les variantes de fork (changements d'obscurcissement, nouveaux contournements, ex. amsi/etw sans patch car ce n'est pas fait pour ça pour l'instant et je prévois de changer ça à l'avenir peut-être que cela deviendra une sorte de toolkit en langage managé)

notes

• x64 uniquement pour les détours asm du clr pour l'instant
• les hôtes cmd.exe n'ont souvent pas de signaux clr prêts de toute façon, donc le launcher ne se bloque pas, le vrai travail se fait quand powershell/dotnet apparaît
• la recompilation échoue avec LNK1104 ? quelque chose a encore nemesis.dll chargé, tuez la cible et recompilez
• le bruit vcpkg de pwsh.exe pendant la compilation est inoffensif, ignorez-le

lectures complémentaires (l'écosystème jlaive)

si vous voulez comprendre contre quoi vous vous battez :

• Trend Micro sur BatCloak / Jlaive — le gâteau en couches bat → ps1 → csharp
• Fortinet sur ScrubCrypt — le successeur agaçant de jlaive si ça t'intéresse, la petite différence avec scrubcrypt était qu'ils pipaient les commandes avec le symbole pipe dans .bat ça marche plutôt bien...
• Unprotect.it — ScrubCrypt — analyse de la technique
• https://github.com/backdoorskid/ClrAmsiScanPatcher - trouve la chaîne .net comme mentionné avant, je recommande de lire ce fichier .pdf :)

avertissement

en utilisant nemesis, vous acceptez ceci. il est fourni en l'état sans garantie — vous assumez tous les risques.

vous êtes seul responsable d'une utilisation légale et autorisée (VM de laboratoire, systèmes possédés, autorisation explicite). dans toute la mesure permise par la loi, les auteurs et zypherion.tech déclinent toute responsabilité pour tout dommage, perte ou réclamation légale découlant de l'utilisation ou de la mauvaise utilisation. voir LICENSE pour les conditions complètes.

licence

utilisation non commerciale / personnelle / recherche / hobby → PolyForm Noncommercial 1.0.0

utilisation commerciale (vente, produit payant, SaaS, travail client, etc.) → vous avez besoin d'une licence séparée. polyform noncommercial ne couvre pas cela.

contactez-moi si vous voulez une licence commerciale :

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

à faire

note rapide : je dois examiner compilemethod et le corriger pour l'instant ce n'est pas vraiment nécessaire car les crypters ne l'utilisent généralement pas du tout... puisqu'ils doivent utiliser asm.load(...) ça me rappelle aussi que je dois vérifier rdata str car je ne l'ai pas encore testé correctement malheureusement... ne faites pas de PR avec un code stupide s'il vous plaît, vous ne pouvez pas hook les backends n(Native) par exemple nLoadImage normalement vous devez préserver les registres et c'est juste bof, c'est pourquoi nous utilisons asm.