Von einem kompromittierten Server gesicherte Dateien zeichnen einen Qilin-Angriff nach — von der Sammlung aus Exchange-Postfächern über die Zerstörung der Backups und das Ausrollen eines Wipers bis zu den ersten gemeldeten Ausführungen der Ransomware.

Zusammenfassung

Im Juli 2026 entdeckten wir einen Mirror eines öffentlich zugänglichen Directory Listings unter 43.204.2.142:8888. Der Mirror umfasst 55.080 Dateien mit einem Gesamtvolumen von rund 3,8 GB und bildet offenbar das Home-Verzeichnis des root-Kontos auf einem Linux-Server ab. Er enthält offensives Tooling, Command-Histories, SSH-Material, C2-Dokumentation, abgelegte Daten der Opferorganisation, einen Qilin-Encryptor sowie Reports, die das Deployment-Framework des Affiliates erzeugt hat.

Der Server war nicht einfach ein anonymer C2-Host. Artefakte in .bash_history, .ssh/ und der Anwendungsumgebung weisen ihn als bei AWS gehosteten Server einer weiteren, legitimen Organisation aus, die wir als VICTIM-B bezeichnen. Bis Juni 2026 hatte ein Qilin-Affiliate root-Zugriff erlangt und nutzte das System für Operationen gegen einen europäischen Fertigungsbetrieb, den wir VICTIM-A nennen.

Die VICTIM-A-Dateien dokumentieren die Schlussphase des Angriffs:

• Fünf Skripte für Exchange Web Services (EWS) nutzten Impersonation für ausgewählte Führungskräfte, durchsuchten deren Postfächer und riefen Nachrichten und Anhänge über einen SOCKS-Proxy ab.
• veeam_kill.py zielte auf Veeam-Dienste, Backup-Repositories, Volume Shadow Copies, den Windows-Backup-Katalog und die Konfigurationsdatenbank von Veeam.
• deadman.py bereitete einen zeitgesteuerten Wiper für 37 namentlich hinterlegte Systeme vor. Der Trigger ließ sich wahlweise als permanente WMI-Event-Subscription installieren oder per Group Policy domänenweit ausrollen.
• deploy_locker.py kopierte einen opferspezifischen Qilin-Encryptor in einer festgelegten Reihenfolge auf 37 Systeme.
• Am 5. Juni erzeugte Reports führen 29 Hosts mit abgelegtem Payload, acht Ausführungsversuche und drei Systeme auf, für die das Tool eine Verschlüsselungswirkung meldete.

Wir ordnen den Encryptor und das Deployment-Paket mit hoher Sicherheit Qilin zu. Ebenfalls mit hoher Sicherheit bewerten wir, dass der Server von VICTIM-B kompromittiert und zur Unterstützung der Operation genutzt wurde. Die vorliegenden Dateien identifizieren den Affiliate nicht. Sie lassen ebenso wenig erkennen, wie VICTIM-A ursprünglich kompromittiert wurde oder in welchem Endzustand sich jedes betroffene System befand.

Abbildung 1: Offen zugänglicher Index des Root-Verzeichnisses von VICTIM-B mit offensivem Tooling, abgelegten Daten, C2-Komponenten und Qilin-Deployment-Artefakten.

Umfang der Analyse

Diese Analyse beruht auf einer statischen Untersuchung des Verzeichnis-Mirrors; es wurde kein Payload ausgeführt. Wo möglich, verglichen wir Quellcode, Datei-Hashes, SQLite-Einträge, Shell-History und eingebettete Zeitstempel.

Sofern nicht anders angegeben, beziehen sich alle Artefaktpfade in diesem Artikel auf das gespiegelte Root-Verzeichnis. Die bereinigten Ausschnitte in den Abbildungen erhalten den relevanten Control Flow und die Strings, ersetzen jedoch opferspezifische Werte.

Namen der Opferorganisationen, Domains, Konten, Zugangsdaten, interne Adressen, personenbezogene Daten und Verhandlungsdetails haben wir redigiert. Die öffentliche IP behalten wir bei, weil sie für retrospektives Hunting nützlich ist. Sie gehörte jedoch zu kompromittierter Infrastruktur und sollte nicht als Infrastruktur des Akteurs behandelt werden. Cloud-Adressen können außerdem bereinigt oder neu vergeben werden.

Wir verwenden den Begriff Affiliate für den Operator dieser Deployment-Umgebung. Die Dateien belegen weder die Identität dieser Person noch ihr Verhältnis zu den Entwicklern von Qilin oder ihre Rolle bei der Entwicklung des Encryptors.

Ein kompromittierter Server als Staging-System

Die IP-Adresse 43.204.2.142 gehörte VICTIM-B, nicht zwingend dem Qilin-Affiliate. Die Dateien beschreiben eine EC2-Instanz in der AWS-Region ap-south-1. Die Aktivität unter dem root-Konto zeigt, dass der Operator sowohl die Cloud-Umgebung als auch die auf dem Server betriebene Industrieanwendung untersuchte.

Artefakt	Befund
.ssh/id_rsa.pub	Ein RSA-4096-Schlüssel mit dem Kommentar root@BELIIOT, zuletzt geändert am 2. Juni 2026 um 18:21:11 UTC
.ssh/authorized_keys	Der ursprüngliche AWS-ubuntu-Schlüssel sowie vier zusätzliche autorisierte Schlüssel
.bash_history	Abfragen an 169.254.169.254, Einsicht in /home/ubuntu/.bash_history, S3-Enumeration sowie SQL-Abfragen gegen Tabellen der Industrieanwendung wie systemconfigurationinfo, plantlevelconfigurationinfo und deviceconfig
.mysql_history	Kommandos, die Logs bereinigten und das Datenbank-Logging deaktivierten; Urheberschaft und Absicht bleiben unklar
.viminfo	Frühere Bearbeitungen von SSH- und Tomcat-Konfigurationsdateien; sie können ebenso auf Administration wie auf Persistenz hindeuten

Die Unterscheidung in den letzten beiden Zeilen ist wesentlich. Das Deaktivieren des SQL-Loggings kann bösartig sein, ebenso gut aber im Rahmen einer Notfallwartung der Datenbank erfolgen. Auch eine Änderung an sshd_config ist für sich genommen kein Angriffsindiz. Ab Juni 2026 verdichten sich die Hinweise: Neues Material für root-Zugriff, ein Callback-Dienst, Zugangsdaten der Opferorganisation, offensives Tooling und C2-Konfiguration laufen auf demselben Host zusammen.

In der Gesamtschau belegen diese Artefakte, dass ein Angreifer den Server von VICTIM-B mit root-Rechten kontrollierte und als Staging- und C2-System nutzte. Eine frühere Kompromittierung ist möglich, doch die Einträge aus 2024 und 2025 lassen sich nicht zuverlässig von legitimer Administration trennen. Um Weg und Zeitpunkt des Initial Access zu bestimmen, wären Authentifizierungslogs, CloudTrail, Systems-Manager-Aufzeichnungen und VPC Flow Logs erforderlich.

Abbildung 2: Shell-History des root-Kontos mit EC2-Metadatenabfragen, S3-Enumeration, Einsicht in die History anderer Benutzer und Datenbank-Reconnaissance in der Industrieanwendung.

Identifikation des Qilin-Encryptors

Das Verzeichnis enthält reichlich Qilin-bezogenes Material, doch die Zuordnung stützt sich nicht auf Datei- oder Ordnernamen, sondern auf den Encryptor selbst.

winbuild/pain.exe ist eine 4.921.344 Byte große PE32-Anwendung mit folgendem SHA-256-Hash:

e1b041fee6bf591a96d135e101577214cfce0bb145c5ba1ba1064103d5d5d2c0

Statische Strings und die eingebettete Konfiguration liefern vier voneinander unabhängige Bezüge zu Qilin:

1.  Die Ransom Note nennt Qilin und enthält die öffentlichen Blog-Adressen der Gruppe.

2.  Das Binary stellt die passwortgeschützte Kommandozeilenschnittstelle von Qilin bereit, darunter –password, –spread und –spread-vcenter.

3.  Die Konfiguration enthält eine opferspezifische Unternehmenskennung, die Ransom Note, die Dateiendung, eine Service-Kill-List sowie Zugangsdaten für Lateral Movement. Diese Werte veröffentlichen wir nicht.

4.  Eingebettetes PowerShell nutzt VMware PowerCLI und SSH, um den Zugriff auf ESXi zu verändern, einen Linux-Payload zu übertragen und ihn auf den Hypervisor-Hosts auszuführen.

Der Qilin-Software-Eintrag bei MITRE dokumentiert Varianten für Windows, Linux und ESXi, Implementierungen in Rust und Go, passwortgeschützte Ausführung sowie Funktionen für Lateral Movement. Zusammen mit der Ransom Note und der opferspezifischen Konfiguration stützen diese Merkmale eine Zuordnung zu Qilin mit hoher Sicherheit.

Der eingebettete password_hash prüft den an –password übergebenen Wert, bevor der Encryptor startet. Er ist kein Verschlüsselungsschlüssel und lässt sich nicht zur Entschlüsselung betroffener Dateien verwenden.

Rekonstruierter Zeitverlauf bei VICTIM-A

Die folgende Tabelle trennt, was die Artefakte zeitlich belegen, von dem, was sich daraus ableiten lässt. Alle Zeitangaben in UTC.

Datum und Uhrzeit	Beleg	Einordnung
21.–30. Mai	In exfil/ liegen zehn datumsgestempelte Veeam-Konfigurationsbackups	Belegt, dass tägliche Backup-Artefakte gesammelt wurden; nicht jedoch, dass die Sammlung einmal pro Tag erfolgte
30. Mai	Artefakte aus Lohnbuchhaltung, ERP, Endpoint-Management, HR, Verzeichnisdienst und Exchange-Enumeration weisen zeitlich dicht beieinanderliegende Änderungszeitstempel auf	Daten wurden auf dem kompromittierten Server abgelegt; Übertragungsweg und ursprünglicher Erfassungszeitpunkt sind nicht erhalten
2. Juni, 03:02:04	.sysmon_listener.py und sysmonitor.service tragen denselben Änderungszeitstempel	Der TCP-Callback-Dienst wurde abgelegt oder aktualisiert
2. Juni, 06:55:47	Erster Callback, umgerechnet aus dem serverlokalen Zeitstempel des Listeners	Eine VICTIM-A zugeordnete Quelle erreichte TCP/4444
3. Juni, 06:12–15:54	Fünf EWS-Skripte zum Durchsuchen der Postfächer von Führungskräften wurden angelegt	Tooling für die gezielte Postfachsammlung wurde entwickelt oder verändert
4. Juni, 04:20–04:55	veeam_kill.py, deadman.py, deploy_locker.py und pain.exe tragen Änderungszeitstempel innerhalb eines Fensters von 35 Minuten	Der Affiliate legte Tooling für Backup-Zerstörung, Wiper und Ransomware gemeinsam ab
5. Juni, 04:14:45	Erster Deployment-Report: 36 Hosts im Scope, 35 über SMB erreichbar, 29 mit abgelegtem Payload, keine Ausführung	Das Framework meldete, dass der Encryptor auf 29 Hosts kopiert, aber noch nicht gestartet worden war
5. Juni, 05:09:28	Zweiter Report: acht Ausführungsversuche und drei gemeldete Impact-Prüfungen	Das Framework meldete, dass die Ausführung der Ransomware begonnen hatte
5. Juni, 05:19–16:26	Vier Verifikationsreports weisen 26, 26, 34 bzw. 33 nicht erreichbare Hosts aus	Die Verfügbarkeit verschlechterte sich; die Reports belegen jedoch nicht, dass sämtliche Ausfälle durch die Ransomware verursacht wurden
9. Juni, 12:00	Voreingestellte Arm-Deadline im Usage-Text von deadman.py	Eine geplante Wiper-Deadline; kein Beleg dafür, dass WMI-Subscriptions installiert oder ausgelöst wurden
22. Juni, 21:50:55	Letzte mtime einer Callback-Datei im gesicherten Listener-Bestand	Der letzte erhaltene Callback — nicht zwingend das Ende des Zugriffs

Der 30 Zeilen lange Python-Listener liefert einen schmalen, aber nützlichen Nachweis fortdauernden Zugriffs. Er bindet sich an 0.0.0.0:4444, protokolliert Quelladresse und lokale Zeit und verwirft die empfangenen Daten. Der Mirror enthält 4.273 Callback-Dateien mit 4.798 Verbindungseinträgen von einer einzigen Adresse bei VICTIM-A. Diese Artefakte belegen wiederholte TCP-Konnektivität. Sie lassen weder den verbindenden Prozess erkennen noch belegen sie, dass Kommandos ausgeführt wurden.

Abbildung 3: Quellcode von .sysmon_listener.py, einem TCP/4444-Listener, der eingehende Verbindungen protokolliert und die empfangenen Daten verwirft.

Der Dateiname führt in die Irre: .sysmon_listener.py hat nichts mit Sysmon von Sysinternals zu tun. Warum der Operator ihn wählte, geht aus den vorliegenden Artefakten nicht hervor.

Abbildung 4: Vom Listener erzeugte Callback-Artefakte mit 4.798 TCP-Verbindungen in 4.273 Dateien.

Gezielte Sammlung aus Exchange-Postfächern

In der nächsten Phase konzentrieren sich die VICTIM-A-Artefakte auf die gezielte Sammlung von Postfachinhalten. Fünf Python-Skripte setzen Postfach-Discovery, Nachrichtensuche und das Abrufen von Anhängen um, indem sie rohe SOAP-Requests an EWS senden. Alle verwenden denselben hartkodierten SOCKS5-Proxy unter 127.0.0.1:11080, dasselbe — hier redigierte — Domänenkonto und eine deaktivierte TLS-Zertifikatsprüfung. Der Header ExchangeImpersonation wählt für jeden Request das Zielpostfach aus:

<t:ExchangeImpersonation>
  <t:ConnectingSID>
    <t:SmtpAddress>[REDACTED-MAILBOX]</t:SmtpAddress>
  </t:ConnectingSID>
</t:ExchangeImpersonation>

Abbildung 5: EWS-Keyword-Scanner mit SOCKS5-Proxying, Exchange-Impersonation und serverseitigen FindItem-Suchen.

Microsoft dokumentiert, dass Exchange-Impersonation einem Service Account erlaubt, im Namen eines anderen Benutzers zu handeln, und in den betroffenen Exchange-Versionen die Rolle ApplicationImpersonation voraussetzt. Microsoft weist zudem darauf hin, dass der Zugriff unter dem Konto protokolliert wird, dessen Identität übernommen wurde — was die Aufklärung erschweren kann. Siehe Configure impersonation und Control access to EWS.

Die Sammlung erfolgte gezielt, nicht wahllos:

Artefakt	Beobachtetes Verhalten
ews_pull.py	Ruft aktuelle Nachrichten aus ausgewählten Postfächern von Führungskräften ab
ews_accounting.py	Ruft aktuelle Nachrichten aus dem Buchhaltungspostfach ab
ews_cfo_attach.py und ews_cfo_property_attach.py	Laden Anhänge zu bestimmten Elementen des CFO-Postfachs herunter
ews_cfo_keyword_scan.py	Führt serverseitige Substring-Suchen über Inbox und Sent Items aus
exfil/cfo_keyword_scan.txt	Hält die zurückgelieferten Trefferzahlen fest, darunter 177 für private bank, 129 für Luxembourg sowie jeweils 76 für trust und holding

Der Scanner definiert 144 Keyword-Einträge, davon 141 eindeutig. Sie decken Banking, Rechts- und Steuerthemen, Immobilien, Familiennamen und Unternehmenstransaktionen ab. Für jeden Begriff sendet er einen FindItem-Request mit serverseitigen Contains-Restrictions auf Betreff- und Body-Feld und liest anschließend TotalItemsInView aus. Damit konnte der Affiliate ein Postfach zunächst anhand der Trefferzahlen priorisieren, bevor er entschied, welche Inhalte abgerufen werden sollten.

Die Auswahl der Postfächer und die Suchbegriffe deuten auf das Sammeln finanzieller und persönlicher Informationen hin, die eine Erpressung stützen könnten. Skripte und gespeicherte Ausgaben belegen die Suchen und deren Trefferzahlen, nicht jedoch den Download jeder passenden Nachricht oder jedes Anhangs.

Wiederherstellung ausschalten, Wiper vorbereiten

Mit der nächsten Gruppe von Skripten verschiebt sich der Schwerpunkt von der Sammlung hin zur Vorbereitung der Impact-Phase. Vier Python-Programme greifen auf dasselbe Muster für Remote-Ausführung zurück: Authentifizierung über SMB/RPC, Anlegen eines kurzlebigen Windows-Dienstes, Ausführung eines Kommandos, Abholen einer Statusdatei über ADMIN$ und Löschen des Dienstes. Je nach Programm beginnen die Dienstnamen mit VKill, WinMnt, LDep oder AvChk.

av_check.py und av_check2.py

Vor dem Ausrollen des destruktiven Toolings erfasste der Affiliate für eine hartkodierte Host-Liste den Stand der Endpoint-Security. av_check.py führt ein zusammengesetztes Discovery-Kommando remote aus; av_check2.py prüft den Dienststatus unauffälliger über MS-SCMR.

Abbildung 6: av_check.py iteriert über die hartkodierte Zielliste, führt CHECK_CMD aus und serialisiert die geparsten Ergebnisse nach JSON.

Für jedes Ziel nutzt av_check.py Impacket-DCE/RPC über die Named Pipe svcctl, bindet sich an das MS-SCMR-Interface und legt einen On-Demand-Dienst an, dessen Name sich aus AvChk und dem letzten IP-Oktett des Ziels zusammensetzt. Der Dienst führt das übergebene Kommando aus und wird nach der Ausführung wieder entfernt.

Abbildung 7: scm_exec() legt über Impacket-MS-SCMR-Aufrufe einen temporären AvChk*-Dienst an, startet ihn und entfernt ihn wieder.

Das Kommando prüft die ESET-Dienste ekrn und ERAAgent, sucht nach Listenern auf TCP/2222, fragt die Microsoft-Defender-Dienste WinDefend und WdNisSvc ab und liest Defender-Richtlinie, Ausnahmen sowie den Status von Echtzeitschutz und Tamper Protection aus. Die Ausgabe wird nach C:\Windows\Temp\avchk.txt umgeleitet und über ADMIN$ abgeholt.

Abbildung 8: Kommando zur Erfassung der Endpoint-Security — abgefragt werden ESET, Microsoft Defender, TCP/2222, Ausnahmen und der Status der Tamper Protection.

av_check2.py verzichtet auf Remote-Kommandoausführung. Das Skript ruft OpenServiceW und QueryServiceStatus für die in SVC_NAMES hinterlegten Dienstnamen auf und wertet ESET als vorhanden, wenn ekrn oder ERAAgent läuft, Microsoft Defender bei laufendem WinDefend und Microsoft Defender for Endpoint bei laufendem Dienst Sense.

Abbildung 9: av_check2.py fragt den Status der Dienste von ESET, Defender und Sense über MS-SCMR ab, ohne einen Remote-Dienst anzulegen.

veeam_kill.py

Das Veeam-Skript geht wenig subtil vor. Es adressiert einen namentlich hinterlegten Backup-Server, den wir hier redigiert haben, und baut eine Kommandokette auf, die

• zehn Veeam-Dienste stoppt;
• V:\Backup, V:\VeeamBackup, E:\Backup und D:\Backup löscht;
• vssadmin delete shadows /all /quiet und wbadmin delete catalog -quiet ausführt;
• versucht, die Datenbank VeeamBackup über VEEAMSQL2016, VEEAMSQL und lokale SQL-Instanzen zu entfernen; und
• die Veeam-Dienste auf disabled setzt.

Abbildung 10: Kommandokette von veeam_kill.py gegen Veeam-Dienste, Repositories, Shadow Copies, den Backup-Katalog und die Konfigurationsdatenbank.

Diese Aktionen entsprechen T1490 Inhibit System Recovery. Das Durchprobieren von drei SQL-Instanznamen erlaubte es dem Skript, ohne Kenntnis der genauen Veeam-Datenbankkonfiguration zu arbeiten. Wir fanden weder Endpoint-Telemetrie noch ein authentifiziertes Abschlussprotokoll, das belegt, dass die Löschung des Repositories oder der Datenbank erfolgreich war.

deadman.py

Während veeam_kill.py auf die Wiederherstellung zielt, bereitet deadman.py einen zweiten destruktiven Pfad vor: einen zeitgesteuerten Wiper-Orchestrator. Das Skript enthält 37 hartkodierte Ziele, gegliedert in Wellen — 30 erhalten den vollständigen Payload, sieben ältere Systeme eine reduzierte Variante. Über die Kommandozeilenmodi kann der Affiliate den Trigger installieren, prüfen, neu terminieren oder entfernen. Ein fünfter Modus rollt ihn per Group Policy aus.

Abbildung 11: deadman.py legt die Wiper-Komponenten über ADMIN$ ab und ruft den Installer über einen kurzlebigen WinMnt*-Dienst auf.

Abbildung 12: smb_connect() baut mit hartkodierten Domänen-Zugangsdaten eine authentifizierte Impacket-SMB-Sitzung auf.

Für jedes Ziel authentifiziert sich do_arm() über SMB, schreibt die Ausgabe von wipe_cmd() nach ADMIN$\Temp\hcr.cmd, lädt hcr_arm.ps1 hoch und ruft den Installer über einen temporären WinMnt*-Dienst auf.

Der Payload-Builder wählt zwischen einem vollständigen und einem Legacy-Profil. Beide Varianten entfernen ESET-Dienste, löschen Backup-Artefakte und nutzen powershell.exe oder reg.exe, um die Löschung von ntoskrnl.exe sowie der auf dem Datenträger liegenden Registry-Hives SAM und SYSTEM für den nächsten Bootvorgang einzureihen. Das vollständige Profil nimmt zusätzlich die Hives SOFTWARE und SECURITY, die Boot Configuration Data, EFI-Dateien und den Rohinhalt der Datenträger ins Visier.

Abbildung 13: wipe_cmd() erzeugt die Full- und Legacy-Payloads gegen Wiederherstellungsartefakte, Registry-Hives, Boot-Dateien, EFI-Daten und Datenträger auf Rohebene.

Der temporäre Dienst dient nur der Auslieferung. Der Installer legt eine permanente WMI-Event-Subscription unter root\subscription an:

WMI-Objekt	Name und Funktion
__EventFilter	SCMHealthCheck wertet Win32_LocalTime im 60-Sekunden-Takt aus
CommandLineEventConsumer	SCMHealthRemediation führt cmd.exe /c C:\Windows\Temp\hcr.cmd aus
__FilterToConsumerBinding	Verbindet den zeitbasierten Filter mit dem Command Consumer

Die Subscription bleibt nach dem Ende des Installers im WMI-Repository bestehen und übersteht Neustarts. Da die WQL-Bedingung nur Jahr, Monat, Tag und Stunde auswertet, wird eine Deadline wie 12:30 bereits um 12:00 aktiv. Sie stützt sich zudem auf die lokale Uhr des jeweiligen Hosts und kann wiederholt auslösen, solange die Bedingung erfüllt bleibt.

Beim Auslösen deaktiviert der vollständige Payload Wiederherstellungsmechanismen, entfernt Backup-Artefakte, reiht die Löschung von Registry-Hives, ntoskrnl.exe und BCD-Dateien ein, löscht EFI-Daten, schreibt 4 MB Nullen an den Anfang von PhysicalDrive0 bis PhysicalDrive7 und erzwingt einen Neustart. Bei Legacy-Zielen entfällt die Schleife zum direkten Überschreiben der Datenträger; der Backup-Server erhält zusätzliche Kommandos zum Abbau von Veeam. Der Quellcode implementiert diese destruktiven Aktionen, er belegt jedoch nicht, dass Schreibzugriffe auf Datenträger oder Löschungen auf irgendeinem Ziel tatsächlich abgeschlossen wurden.

Der Modus gpo eröffnet einen domänenweiten Deployment-Pfad über eine erzwungene GPO mit dem Namen Windows Health Compliance. Er legt Payload und Startskript in SYSVOL ab, sodass Domänenmitglieder bei der Richtlinienverarbeitung dieselbe permanente WMI-Subscription anlegen. Dabei handelt es sich um den Missbrauch regulärer Group-Policy-Administration, nicht um die Ausnutzung einer GPO-Schwachstelle.

Die Artefakte belegen, dass der Affiliate einen Wiper für den Einsatz auf einzelnen Hosts oder domänenweit vorbereitete. Sie zeigen nicht, wie viele WMI-Subscriptions installiert wurden, ob Clients die GPO verarbeiteten oder ob die Deadline am 9. Juni auf irgendeinem System erreicht wurde.

Staging und Ausführung des Qilin-Encryptors

Nachdem die Wiederherstellung ins Visier genommen und der Wiper vorbereitet war, wandte sich der Affiliate dem Locker zu. deploy_locker.py und deadman.py enthalten dieselben 37 Ziele. Das Deployment-Skript kopiert pain.exe nach C:\Windows\Temp\svcmon.exe und startet die Datei über temporäre LDep*-Dienste. Kommentare in der Zielliste setzen den Backup-Server an die erste Stelle, gefolgt von Systemen, auf denen kein ESET vermutet wurde, dann weiteren Servern und Hypervisoren, schließlich dem Management-Server der Sicherheitslösung und den Domain Controllern. Die Reihenfolge legt den Deployment-Plan des Affiliates offen; sie belegt jedoch nicht, dass alle 37 Systeme erreicht wurden.

Abbildung 14: deploy_locker.py steuert das wellenbasierte Ablegen und Ausführen des Qilin-Encryptors.

Abbildung 15: run_wave() trennt Upload und Ausführung des Payloads und protokolliert Fehlschläge je Host.

Abbildung 16: upload_locker() kopiert den Encryptor über ADMIN$ in den Staging-Pfad auf dem Ziel.

Abbildung 17: Hartkodierte Payload-Pfade, die pain.exe im Windows-Temp-Verzeichnis des Ziels in svcmon.exe umbenennen.

Der Deployment-Ablauf ist zweistufig: run_wave() versucht zunächst, den Encryptor auf allen Zielen der gewählten Welle abzulegen, und startet ihn anschließend nur auf den Hosts, bei denen der Upload erfolgreich war. Die Ergebnisse je Host werden in fired, fire_fail und verwandten Statusfeldern festgehalten.

Die Deployment-Reports dokumentieren die Ausführung

Die Reports kommen im Mirror einer Live-Chronologie der Ausführung am nächsten. Zwei maschinell erzeugte Datensätze unter seceng_reports/ halten den Übergang vom Staging zur Ausführung fest:

Erzeugt (UTC)	Hosts	SMB erreichbar	Staged	Ausführungsversuche	Gemeldeter Impact	Spread-Launcher
5. Juni, 04:14:45	36	35	29	0	0	None
5. Juni, 05:09:28	36	35	29	8	3	Redigierter Domain Controller,  wmi_spread_domain_scan, ok=True

Der erste Report ist eine Momentaufnahme vor der Ausführung: Auf 29 Hosts lag der Payload bereit, gestartet wurde er auf keinem. 55 Minuten später verzeichnete das Framework acht Ausführungsversuche und drei positive Impact-Prüfungen. Es handelt sich um Ergebnisse, die der Affiliate selbst erzeugt hat, nicht um unabhängige Endpoint-Telemetrie. Sie sind jedoch der deutlichste erhaltene Beleg dafür, dass das Ransomware-Deployment vom Staging in die Ausführung überging.

Bedeutung für die Verteidigung

Vor dem Start des Encryptors erzeugte der Affiliate mehrere detektierbare Ereignisse:

1.  Ein einzelnes Konto führte über wiederholte FindItem-Aufrufe EWS-Impersonation gegen High-Value-Postfächer durch.

2.  Remote angelegte Dienste traten unter charakteristischen Präfixen auf und starteten cmd.exe aus services.exe heraus.

3.  Wiederherstellungsmechanismen, Veeam-Dienste und Sicherheitsprodukte wurden abgefragt oder verändert, bevor der Encryptor ausgerollt wurde.

4.  Permanente WMI-Objekte und eine neue, mit der Domäne verknüpfte GPO trugen plausible administrative Namen, verwiesen aber auf ungewöhnliche, destruktive Payload-Pfade.

5.  Die Qilin-Executable wurde unter dem generischen Namen svcmon.exe abgelegt.

Das offen zugängliche Verzeichnis enthält mehr als eine Sammlung von Tools. Es hält einen operativen Ablauf fest: Priorisierung von Postfächern, Discovery der Sicherheitsprodukte, Unterbinden der Wiederherstellung, Vorbereitung des Wipers und wellenbasiertes Ransomware-Deployment. Ebenso wichtig ist die verbleibende Unsicherheit — der Quellcode zeigt Fähigkeiten, die Reports des Affiliates zeigen behauptete Ergebnisse, doch eine vollständige Bestätigung der Auswirkungen auf Endpoint-Ebene liefern die gesicherten Artefakte nicht.

Hashes der untersuchten Artefakte

Artefakt	SHA-256
winbuild/pain.exe	e1b041fee6bf591a96d135e101577214cfce0bb145c5ba1ba1064103d5d5d2c0
deadman.py	71fca801f0bd88a417d71aa0be5adc0a983127a063e7…
veeam_kill.py	2ec5fa31d1a590daf96e998941ad1dff4efc290ff42e…
deploy_locker.py	4a933c387a9228056b9dc234e64210ce254c633eabaa…
av_check.py	92de01b28a3cb8c7319667635c96cfd5dc1eee73e2b7…
av_check2.py	e7225880c730d190b872b60c7f109cdb56a5c7429f48…

Die Analyse basiert auf einem im Juli 2026 gesicherten Mirror. Ausschließlich statische Analyse. Alle Zeitstempel sind auf UTC normalisiert, sofern nicht ausdrücklich als serverlokal gekennzeichnet.