Nemesis

morgen wird ein Update gepusht, die Lizenz geändert und ein paar neue Methoden gegen Datendiebe hinzugefügt.

Ein Windows-Tool, das ich gebaut habe, weil ich es leid war, in Malware-Samples ständig auf Jlaive-Forks zu starren, ohne etwas Öffentliches zu haben, um sie zur Laufzeit tatsächlich auseinanderzunehmen.

Kurz gesagt, es ist ein .NET-Prozessmonitor, der die CLR auf nativer Ebene hookt, reflektierende Assembly-Ladungen verfolgt und automatisch PEs direkt aus dem Speicher dumped. Es prüft auch die AMSI- und ETW-Integrität gegen die ursprünglichen Dateien auf der Festplatte und erkennt Umgehungstechniken wie clr.dll-String-Patching und direkte LoadFromBuffer-Nutzung.

Wo findet man Samples? Ich empfehle einen Blick auf https://tria.ge (keine Werbung) und du kannst jedes beliebige Sample herunterladen und nach einer Familie filtern.

Warum der Name?

Du fragst dich vielleicht, warum der Name Nemesis?

Weil er den genauen Zweck des Tools repräsentiert. Eine Nemesis ist etwas, das eine ständige Herausforderung oder den Untergang für einen Gegner darstellt – und das ist die Idee hinter diesem Projekt.

In der griechischen Mythologie war Nemesis der Geist der göttlichen Vergeltung, diejenige, die jedem die Quittung gab, der zu arrogant wurde oder glaubte, unantastbar zu sein. Ein kleiner Seitenhieb auf Malware, die damit angibt, "FUD" zu sein, wenn du mich fragst.

Warum es das gibt

Ich bin Malware-Analyst. Wenn du diesen Job (bei mir Hobby) lange genug machst, siehst du immer wieder dieselben Loader-Ketten, besonders seit Jlaive (auch Crybat genannt) explodiert ist und jeder Script-Kiddie es geforkt hat.

Das Muster ist dumm einfach, aber verdammt nervig:

irgendwas.bat  →  obfuskiertes PowerShell  →  CSharp-Stub  →  dein eigentliches Payload

Du doppelklickst eine .bat, die aussieht wie Buchstabensalat. CMD startet PowerShell mit einer Wand aus Müll. PowerShell entschlüsselt/dekomprimiert einen .NET-Stub (AES, GZip, Base64). Dieser Stub patcht AMSI + ETW, lädt reflektiv die echte EXE/DLL in den Speicher, und schon ist es vorbei – nichts Freundliches landet jemals in brauchbarer Form auf der Platte.

Das hat mich gestört. Es gibt kein wirklich gutes öffentliches Tool, das gegen diese spezielle Kette vorgeht – Hooking, wo sich das .NET-Payload tatsächlich materialisiert, Dumping bevor der Prozess sich selbst frisst, Erkennen der AMSI/ETW-Patches, die diese Stubs immer machen. Also habe ich Nemesis gebaut.

Kein Allheilmittel. Wird deine Sandbox nicht ersetzen. Aber es gibt dir etwas Reales, das du gegen eine verdächtige .bat auf einer Testmaschine laufen lassen und tatsächlich Artefakte herausziehen kannst.

Was es tatsächlich tut

Launcher (Launcher.exe)

• Erstellt dein Ziel suspendiert (exe, bat, cmd, was auch immer)
• Injiziert Nemesis.dll bevor der Hauptthread läuft
• Wartet, bis Nemesis meldet, dass es bereit ist
• Setzt fort. Wenn das Ziel PowerShell-Kinder spawned, kann der Launcher diese ebenfalls injizieren

Nemesis-DLL (Nemesis.dll)

• Hookt CLR-Ladepfade, die Jlaive-artige Stubs tatsächlich treffen:
  • nLoadImage
  • nLoadFile
  • AssemblyNative::LoadFromBuffer (Muster über nLoadImage aufgelöst)
• Wenn ein reflektives PE im Speicher auftaucht → stellt einen Dump in %TEMP%\Nemesis_dumps in die Warteschlange
• Vergleicht Live-Exporte von amsi.dll / ntdll.dll mit den Kopien auf der Platte (fängt den klassischen ret-Patch auf AmsiScanBuffer / EtwEventWrite)
• AMSI-Check untersucht auch die CLR .rdata-Strings, wenn die CLR geladen ist (einige Bypässe patchen diese stattdessen – es gibt ein großartiges VXUG-Papier dazu: 2024-11-21 - New AMSI Bypss Technique Modifying CLRDLL in Memory.pdf)
• Loggt auf die Konsole (farbig) + %TEMP%\Nemesis.log. Es hat auch , um Probleme mit einer etwas eigenartigen Konsole zu vermeiden :D

Im Grunde: Lass die Bat-Kette laufen, fang das Payload dort, wo der Crypter es tatsächlich lädt, und protokolliere die Ausweichtricks auf dem Weg.

Proof:

Build

Du benötigst Visual Studio 2022+ mit C++-Desktop und MASM (x64).

Öffne Nemesis.slnx, wähle Release | x64, baue die Lösung.

Ausführen gegen ein echtes Ziel

Dies ist der eigentliche Anwendungsfall: Richte es auf eine verdächtige Bat und sieh, was herausfällt:

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

Zusätzliche Argumente nach -- werden an das Ziel übergeben:

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

Benutzerdefinierter DLL-Pfad:

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

Artefakte:

• Logs → %TEMP%\Nemesis.log
• Gedumpte PEs → %TEMP%\Nemesis_dumps

Was Nemesis ist / nicht ist

Ist:

• Ein Laufzeitanalyse-Helfer für Jlaive-artige Crypter (Bat → PS1 → CSharp-Ketten)
• Nützlich in einer Labor-VM, wenn du ein Sample hast und In-Memory-Dumps plus AMSI/ETW-Telemetrie willst
• Offen für andere Analysten zum Nutzen, Erweitern, Meckern

Ist nicht:

• Ein EDR-Ersatz
• Garantiert, jede Fork-Variante zu fangen (Obfuskation ändert sich, neue Bypässe, z.B. patchless AMSI/ETW, da es dafür derzeit nicht gemacht ist – und ich plane, das in Zukunft zu ändern; vielleicht wird daraus ein Managed-Language-Toolkit)

Hinweise

• Nur x64 für die CLR-ASM-Detours derzeit
• CMD.exe-Hosts haben oft keine CLR – Nemesis signalisiert trotzdem Bereitschaft, der Launcher hängt nicht; die eigentliche Arbeit passiert, wenn PowerShell/.NET auftaucht
• Build schlägt fehl mit LNK1104? Irgendwas hält noch Nemesis.dll geladen – töte das Ziel und baue neu
• pwsh.exe-Vcpkg-Rauschen während des Builds ist harmlos, ignoriere es

Weiterführende Literatur (das Jlaive-Ökosystem)

Wenn du verstehen willst, wogegen du kämpfst:

• Trend Micro zu BatCloak / Jlaive – der Bat → PS1 → CSharp-Schichtkuchen
• Fortinet zu ScrubCrypt – Jlaives nerviger Nachfolger; wenn du interessiert bist, was an ScrubCrypt etwas anders war: Sie haben Befehle mit dem Pipe-Zeichen in der .bat ausgegeben – funktioniert ziemlich gut...
• Unprotect.it — ScrubCrypt – Technik-Aufschlüsselung
• https://github.com/backdoorskid/ClrAmsiScanPatcher – findet den .NET-String, wie bereits erwähnt; ich empfehle, diese PDF-Datei zu lesen :)

Haftungsausschluss

Durch die Nutzung von Nemesis akzeptierst du dies. Es wird wie besehen ohne jegliche Gewährleistung bereitgestellt – du übernimmst das gesamte Risiko.

Du bist allein verantwortlich für rechtmäßige, autorisierte Nutzung (Labor-VMs, eigene Systeme, ausdrückliche Erlaubnis). Im maximal gesetzlich zulässigen Umfang lehnen die Autoren und zypherion.tech jegliche Haftung für Schäden, Verluste oder rechtliche Ansprüche ab, die aus Nutzung oder Missbrauch entstehen. Siehe LIZENZ für die vollständigen Bedingungen.

Lizenz

Nicht-kommerzielle / persönliche / Forschungs- / Hobby-Nutzung → PolyForm Noncommercial 1.0.0

Kommerzielle Nutzung (Verkauf, kostenpflichtiges Produkt, SaaS, Kundenarbeit usw.) → du benötigst eine separate Lizenz. PolyForm Noncommercial deckt das nicht ab.

Melde dich bei mir, wenn du eine kommerzielle Lizenz möchtest:

[[email protected] / @wd6g(Discord) / Telegram: @ZypherionTechnologies]

Todo

Kurze Notiz: Ich muss mir compilemethod ansehen und reparieren; derzeit wird es nicht unbedingt benötigt, da Crypte es normalerweise gar nicht verwenden ... da sie asm.load(...) verwenden müssen. Außerdem erinnert mich das daran, dass ich die .rdata-Strings überprüfen muss; habe sie leider noch nicht richtig getestet... Mach bitte keinen PR mit dummem Code. Du kannst keine N(Native)-Backends wie nLoadImage normal hooken; du musst Register erhalten und es ist einfach ätzend – deshalb verwenden wir ASM.