Der Autor entwickelte aktiv einen Loader, der als „Kiss Loader“ bezeichnet wird und zum Zeitpunkt der Analyse zuvor nicht beobachtet worden war und offenbar ein neu entwickeltes Werkzeug darstellt, das eine potenziell aufkommende Bedrohung repräsentiert. Er verwendet unter anderem Techniken wie Early-Bird-APC-Injection. Die Erfahrung war sowohl spannend als auch bemerkenswert, da die Grenze zwischen Analyst und Gegner kurzzeitig verschwamm.
Bevor wir auf diese ungewöhnliche Begegnung eingehen, ist es wichtig, zunächst das Sample zu untersuchen, das uns dorthin geführt hat.
Technische Analyse: Überblick
Um das Verhalten des Samples zu vereinfachen, habe ich die Ausführung in einen mehrstufigen Ablauf unterteilt, wie in Abbildung 1 dargestellt. Das Diagramm hebt die wichtigsten Phasen der Ausführung hervor.
Initialer Zugriff und WebDAV-Bereitstellung
Die Infektion beginnt mit einer Windows-Internetverknüpfungsdatei (DKM_DE000922.pdf.url), die die Ausführung auslöst und eine Verbindung zu einer entfernten WebDAV-Ressource herstellt, die über einen TryCloudflare-Tunnel gehostet wird. TryCloudflare ist ein Cloudflare-Dienst, der temporäre öffentliche Tunnel zu lokal gehosteten Diensten erstellt, ohne dass eine Domainregistrierung oder dedizierte Infrastruktur erforderlich ist. Dies ermöglicht es dem Angreifer, Payloads dynamisch zu hosten und zu verändern.
Ausführungs-Trigger und Skriptausführung
Unter den Dateien im WebDAV-Verzeichnis befindet sich eine sekundäre Verknüpfung (DKM_DE80KS0095283.pdf.url), die als PDF-Dokument getarnt ist und eine Benutzerinteraktion zur Ausführung erfordert. Nach der Auslösung startet diese Verknüpfung ein WSH-Skript, das in eine JScript-Komponente übergeht. Dieser geschichtete Ausführungsablauf ermöglicht ein kontrolliertes Staging des Payloads, während die direkte Exposition späterer Phasen minimiert wird.
Payload-Abruf und Staging
Die JScript-Komponente ruft ein Batch-Skript ab und führt es aus, das für die Orchestrierung der nächsten Schritte verantwortlich ist. Dazu gehört das Anzeigen eines Täuschungs-PDFs für den Benutzer, das Einrichten von Persistenz durch das Platzieren eines Batch-Skripts im Autostart-Ordner des Benutzers sowie das Herunterladen zusätzlicher Payload-Komponenten.
Loader-Bereitstellung, Shellcode-Entschlüsselung und Ausführung
Das abgerufene Archiv enthält einen Python-basierten Loader, der vom Bedrohungsakteur als „Kiss Loader“ bezeichnet wird und zur Entschlüsselung von Payloads eingesetzt wird. Entschlüsselungsschlüssel werden aus JSON-Konfigurationsdateien bezogen, wodurch der Payload bis zur Laufzeit verborgen bleibt. Der Shellcode wurde mit Donut erzeugt, einem Open-Source-Tool, das positionsunabhängigen Shellcode für die In-Memory-Ausführung von .NET-Assemblies erzeugt. Um die Analyse zu beschleunigen, nutzte ich einen dedizierten Donut-Decryptor und -Extractor, der es mir ermöglichte, die eingebetteten Payloads aus den BIN-Dateien wiederherzustellen. Einer der Payloads wurde von unserem System als VenomRAT identifiziert, der auch einer AsyncRAT-Variante ähnelt (Siehe hier und auch in einem unserer früheren Blogartikel zu AsyncRAT), während der andere ein durch .NET Reactor geschütztes Dienstprogramm war. Diese Komponenten werden anschließend zur Ausführung vorbereitet, und diese Phase stellt den Übergang vom Staging zur aktiven Kompromittierung dar.
Prozessinjektion
Die finale Ausführung wird durch Injektion in einen legitimen Prozess (explorer.exe) unter Verwendung einer Early-Bird-APC-Technik erreicht, wie in Abbildung 2 dargestellt. Der Loader erstellt den Zielprozess in einem angehaltenen Zustand, wodurch verhindert wird, dass sein Haupt-Thread sofort ausgeführt wird.
Anschließend reserviert er Speicher im Zielprozess mit ausführbaren Berechtigungen und schreibt den entschlüsselten Shellcode in den reservierten Bereich. Anstatt einen neuen Thread zu erstellen, reiht der Loader einen Asynchronous Procedure Call (APC) in den primären Thread des angehaltenen Prozesses ein.
eim Fortsetzen des Threads wird der eingereihte APC ausgeführt, bevor der Prozess mit der normalen Ausführung beginnt, wodurch der injizierte Shellcode im Kontext eines vertrauenswürdigen Prozesses ausgeführt wird, was die Tarnung verbessert und die Erkennung erschwert.
Wichtige Beobachtung
Sowohl die unterstützende Infrastruktur als auch die zugehörigen Skripte von Kiss Loader befanden sich zum Zeitpunkt der Analyse noch in der Entwicklung. Das exponierte WebDAV-Verzeichnis wies keine Zugriffsbeschränkungen auf, was es mir ermöglichte, seine Inhalte direkt aufzulisten und abzurufen. Ich stellte außerdem fest, dass die Dateien er kürzlich bereitgestellt worden waren, da ich sie erstmals am 10. März identifizieren konnte (siehe Abbildung 3).
Darüber hinaus zeigen die Skripte, insbesondere der „Kiss Loader“, deutliche Anzeichen einer fortlaufenden Entwicklung. Dies wird durch die Einbindung von Testwerkzeugen und Hilfsfunktionen deutlich, die zur Validierung von Payloads und zur Simulation von Ausführungsszenarien vorgesehen sind (siehe Abbildung 4).
![Python code section titled “LAB TESTING UTILITIES” defining a class LabTester with methods for shellcode validation and payload creation. It includes printed messages like “[-] Shellcode too small,” “[] Detected Meterpreter-like shellcode,” “[] Detected x64 shellcode,” and “[*] Detected x86 shellcode,” and a method create_test_payload() returning a byte sequence for a “calc.exe” payload.](/fileadmin/web/general/images/blog/2026/03/KissLoader_Figure_4.png)
Der Code enthält außerdem umfangreiche Inline-Kommentare, die zentrale Routinen wie Entschlüsselung und Prozessinjektion beschreiben und schrittweisen Kontext für die Logik liefern. Der Detailgrad dieser Kommentare könnte auf die Verwendung automatisierter, unterstützter Codegenerierung während der Entwicklung hindeuten (siehe Abbildung 5).
![Python script header with shebang “#!/usr/bin/env python3” and text “KISS Loader - Early Bird APC Injection for Lab Testing” plus usage line “python loader.py -p payload.bin [-k keys.json] [-t target.exe]”. It shows sections “DECRYPTION” and “INJECTION,” comments like “Simple XOR decryption” and “Load XOR key from JSON file,” and a class EarlyBirdInjector with notes about creating a suspended process and allocating memory, followed by a banner “KISS Loader - Lab Testing Edition Early Bird APC Injection.”](/fileadmin/web/general/images/blog/2026/03/KissLoader_Figure_5.png)
Darüber hinaus erzeugt der Loader eine ausführliche Ausgabedarstellung während der Ausführung und zeigt detaillierte Laufzeitinformationen wie das Laden des Payloads, den Entschlüsselungsstatus, die Prozesserstellung und die Injektionsschritte an. Dieses Maß an Ausgabe ist typischerweise mit Test- oder Debugging-Phasen verbunden (siehe Abbildung 6).
Begegnung mit dem Bedrohungsakteur
Da die über WebDAV gehosteten Ressourcen weiterhin aktiv und zugänglich waren, führte ich die Verknüpfungsdatei in einer kontrollierten Analyseumgebung aus, um ihr beabsichtigtes Verhalten zu simulieren und den gesamten Ausführungsablauf zu beobachten. Unter Verwendung der im Batch-Skript angegebenen Parameter fuhr ich mit der Entschlüsselung des eingebetteten Shellcodes fort. Beim Versuch, den entschlüsselten Payload zu dumpen, fühlte sich jedoch sofort etwas seltsam an. Die Eingabeaufforderung wurde plötzlich beendet, gefolgt vom abrupten Herunterfahren der von mir geöffneten Analysetools—Notepad++, Process Explorer und System Informer.
Dann begann sich der Cursor von selbst zu bewegen. Ich versuchte, die Eingabeaufforderung erneut zu öffnen, aber jeder Versuch wurde sofort beendet. In diesem Moment hielt ich inne, nahm die Hände von der Tastatur und hob sie sogar an, um zu bestätigen, dass ich nicht mit dem System interagierte. Der Cursor bewegte sich weiter und zeigte eindeutig, dass das Verhalten nicht vom Benutzer initiiert war.
Diese Erkenntnis war sowohl bemerkenswert als auch unerwartet. Da dies meine erste Begegnung mit „Kiss Loader“ war, war ich motiviert, mehr darüber zu erfahren und zu überprüfen, ob die beobachtete Aktivität lediglich zufällig oder das Ergebnis eines gezielten Fernzugriffs war. Um dies zu testen, führte ich das Sample erneut in derselben kontrollierten Umgebung aus und ließ ein Notepad-Fenster mit einer einfachen Nachricht geöffnet: „Hello! Are you the author of this malware?“
Ich ließ das System laufen.
Nach etwa einer Stunde erschien eine Antwort, wie in Abbildung 7 dargestellt.
![Screenshot of a Notepad window titled “Untitled - Notepad” showing a chat between “Analyst:” and “Threat Actor:” about malware, including lines like “Hello! Are you the author of this malware?” and “early bird injection.” The conversation mentions locations such as “malawi and you” and “I am from [redacted],” and includes questions about payloads, malware development, and how the injection technique works.](/fileadmin/web/general/images/blog/2026/03/KissLoader_Figure_7.png)
Die Nachricht war kurz und informell, bestätigte jedoch, was ich vermutet hatte. Auf das System wurde aktiv zugegriffen. Was folgte, war ein unerwarteter Austausch. Die Person auf der anderen Seite wirkte neugierig, fast gesprächig, stellte Fragen zu meinen Tools und ob ich ein Analyst sei. An einem Punkt erkannte er die Natur seiner eigenen Arbeit an, bezeichnete sie schlicht als „the malware“ und gab zu, sie in verschiedenen Formen zu entwickeln, während er mit unterschiedlichen Techniken experimentierte.
Im weiteren Verlauf des Gesprächs lenkte ich es auf technische Details. Auf die Frage nach der Injektionsmethode identifizierte der Bedrohungsakteur diese als „early bird injection“, was mit meiner vorherigen Analyse des Verhaltens des Loaders übereinstimmte. Die Diskussion zeigte auch, dass sich die Malware noch in der Entwicklung befand, was frühere Beobachtungen sowohl aus der Infrastruktur als auch aus dem Code selbst bestätigte. Es ist selten, während einer aktiven Entwicklungsphase direkt mit einem Bedrohungsakteur zu interagieren, und noch seltener, eine Bestätigung spezifischer Techniken in Echtzeit zu erhalten.
Der Austausch war kurz. Nach einigen Antworten hörte der Bedrohungsakteur auf zu reagieren und stellte auch bei späteren Versuchen keine Verbindung mehr her.
Dennoch hinterließ die Begegnung einen bleibenden Eindruck.
Fazit
Wir untersuchen Malware oft als Artefakte, reduziert auf Datenpunkte zur Erkennung und Korrelation. Doch hinter jedem Befehl und jeder Verbindung steht ein Mensch, der beobachtet, sich anpasst und manchmal mehr preisgibt als beabsichtigt. Dieser Fall zeigt, dass Analyse nicht immer einseitig ist. Die Trennlinie zwischen Analyst und Gegner kann unerwartet dünn werden und bloße Beobachtung plötzlich in Interaktion verwandeln.
Über die technischen Erkenntnisse hinaus bekräftigt dies ein zentrales Prinzip: Analyse muss in einer kontrollierten und isolierten Umgebung stattfinden, wie in unserem Umgang mit diesem Fall gezeigt. Wir analysieren nicht nur Code; manchmal stehen wir den Personen dahinter gegenüber.
IoC - Liste
6abd118a0e6f5d67bfe1a79dacc1fd198059d8d66381563678f4e27ecb413fa7 | DKM_DE000922.pdf.url |
e8f83d67a6b894399fad774ac196c71683de9ddca3cf0441bb95318f5136b553 | oa.wsh |
549c1f1998f22e06dde086f70f031dbf5a3481bd3c5370d7605006b6a20b5b0b | ccv.js |
6d62b39805529aefe0ac0270a0b805de6686d169348a90866bf47a07acde2284 | gg.bat |
b4525711eafbd70288a9869825e5bb3045af072b5821cf8fbc89245aba57270a | pol.bat |
e8dbdab0afac4decce1e4f8e74cc1c1649807f791c29df20ff72701a9086c2a0 | vwo.zip |
5cab6bf65f7836371d5c27fbfc20fe10c0c4a11784990ed1a3d2585fa5431ba6 | so.py |
20a585c4d153f5f551aaa509c8c1fa289fa6f964fe53f241ef9431a9390b3175 | tv.bin |
6a7c3029cd4f7ffe9a24ea5d696e1f612ada91b5a5ca5b28d4972d9c772051fd | t.json |
665f44b5a46947ad4fdac34a2dca4cf52b3e7e21cfa3bd0fc3ef10bd901ad651 | ov.bin |
b3737f621eb2ee6d784a6b9d695b890a5f22ee69e96058c99d9048b479451fbd | a.json |
130ca411a3ef6c37dbd0b1746667b1386c3ac3be089c8177bc8bee5896ad2a02 | decrypted ov.bin (VenomRAT) |
2b40a8a79b6cf90160450caaad12f9c178707bead32bcc187deb02f71c25c354 | decrypted tv.bin (Kryptik) |
