C2Looper: Wie die Windows-Backdoor für Ransomware-Angriffe eingesetzt werden könnte

C2Looper ist eine neu identifizierte, in Rust entwickelte Backdoor für Windows. Sie verschafft Angreifern einen ersten Zugriff auf ein System, ermöglicht die Ausführung von Befehlen, die Aufklärung des Hosts und das Nachladen weiterer Schadsoftware. Zscaler ThreatLabz entdeckte die Malware-Familie im Juli 2026 und bewertet ihren Einsatz durch einen Ransomware-nahen Akteur als wahrscheinlich. Das ist jedoch keine bestätigte Zuordnung zu einer bestimmten Gruppe. Auch der mutmaßliche Verbreitungsweg wird nur mit niedriger bis mittlerer Sicherheit eingeschätzt.

Besonders auffällig ist die Weiterentwicklung der Infrastruktur: Frühere Samples kommunizieren mit einem herkömmlichen Command-and-Control-Server über regelmäßige Klartext-HTTP-Anfragen. Eine neuere Variante nutzt dagegen GitHub-Repositories für Befehle, Statusmeldungen und Ergebnisse. Für Sicherheitsteams entstehen dadurch zwei unterschiedliche Suchmuster.

Warum C2Looper für den Schutz vor Ransomware relevant ist

C2Looper selbst wird nicht als Ransomware beschrieben. Die Funktionen passen vielmehr zur Vorbereitungsphase eines Angriffs: Ein Operator kann Befehle ausführen, Informationen über den Rechner sammeln, Dateien herunterladen und weitere Payloads installieren. Ein solcher Zugriff kann dazu dienen, sich im Netzwerk festzusetzen und eine spätere Ransomware-Attacke vorzubereiten.

Die derzeit verfügbaren Berichte belegen keine eindeutige öffentliche Zuordnung zu einer namentlich bekannten Ransomware-Gruppe. Ähnlichkeiten mit anderer Malware-Infrastruktur sollten daher als Ermittlungsansätze gelten – nicht als Beweis für gemeinsame Urheber oder eine gemeinsame operative Kontrolle.

So arbeiten die beiden C2Looper-Varianten

Frühere Version: Direkte Steuerung per HTTP

Ältere Samples kommunizieren über unverschlüsseltes HTTP mit einem von den Angreifern kontrollierten Server und verwenden JSON-basierte Befehle. Sie fragen den Server offenbar in sehr kurzen Abständen ab – in einigen Berichten ist von ungefähr einer Sekunde die Rede. Dieses regelmäßige Verhalten kann auf Endpunkten und im Netzwerk ein markantes Erkennungssignal erzeugen.

Der Beacon der Malware identifiziert das Opfer unter anderem anhand des Windows-Benutzernamens, des DNS-Hostnamens, der Prozess-ID des laufenden C2Looper-Prozesses und einer Bot-ID, die aus Hostname und Benutzername abgeleitet wird. Die Meldung wird an den Pfad /api/beacon gesendet; Befehlsausgaben übermittelt die Backdoor an /api/result/.

Der unterstützte Befehlssatz gibt dem Angreifer praktische Kontrolle über das infizierte System. Dazu gehören:

• die Ausführung beliebiger Shell- und Systembefehle,
• die Aufklärung des Hosts,
• das Herunterladen von Dateien sowie
• Updates der Backdoor und das Nachladen weiterer Payloads.

Besonders bemerkenswert ist der Update-Mechanismus. Über den Befehl upload kann C2Looper eine portable ausführbare Datei von einer vom Operator vorgegebenen URL abrufen und als DLL im lokalen OneDrive-Verzeichnis des Benutzers speichern. Anschließend kann die Malware den OneDrive-Prozess beenden und eine legitime OneDrive-Datei dazu missbrauchen, die abgelegte Bibliothek per DLL-Sideloading zu laden. In den beschriebenen Samples hieß die Datei wtsapi32.dll und lag unter %LocalAppData%\\Microsoft\\OneDrive.

Beim DLL-Sideloading wird Schadcode neben einer vertrauenswürdigen ausführbaren Datei platziert. Diese lädt die Bibliothek anschließend im Rahmen ihres normalen Verhaltens. Für die Abwehr ist deshalb nicht allein entscheidend, dass OneDrive installiert ist. Verdächtig wird es vor allem, wenn eine legitime OneDrive-Datei eine unerwartete DLL aus einem ungewöhnlichen oder vom Benutzer beschreibbaren Verzeichnis lädt.

Verschleierung in älteren Samples

C2Looper entschlüsselt Zeichenketten zur Laufzeit per XOR, wobei Berichten zufolge ein wiederverwendeter Schlüssel mit einer Länge von acht Byte zum Einsatz kommt. Außerdem löst die Malware Windows-APIs dynamisch über LoadLibrary und GetProcAddress auf. Dadurch kann eine rein statische Analyse weniger aussagekräftig sein; das Gewicht verlagert sich auf Verhaltensdaten aus Endpoint-Detection-and-Response-Systemen (EDR).

Neuere Version: GitHub als Kommandozentrale

Eine neuere C2Looper-Version ersetzt die klassische Server-Kommunikation durch GitHub-Repositories. Diese dienen laut den vorliegenden Berichten der Befehlsübermittlung, dem Beaconing, der Aufnahme von Ergebnissen und – bei der neueren Variante – auch der Ablage payloadbezogener Daten.

Jeder infizierte Rechner erhält dabei ein eigenes Verzeichnis im Repository. Die Malware liest die Anweisungen aus cmd.json, führt die darin angeforderte Aktion aus und schreibt das Ergebnis in result.json im selben Verzeichnis. Für den Operator entsteht so ein einfaches, dateibasiertes Verfahren zum Verteilen von Befehlen und Einsammeln von Antworten, ohne einen eigenen C2-Server betreiben zu müssen.

Die Nutzung von GitHub kann einfache Blockierstrategien erschweren, weil der Dienst auch von Entwicklern und Unternehmen legitim verwendet wird. Sinnvoller ist eine verhaltensbasierte Prüfung: Sicherheitsteams sollten regelmäßige Repository- oder API-Zugriffe von Endpunkten untersuchen, die normalerweise keinen solchen Zugriff benötigen, und verdächtige JSON-Aktivitäten pro Host von genehmigten Entwicklungs- oder CI/CD-Prozessen unterscheiden.

Der Wechsel zu GitHub und die in neueren Samples beschriebenen zusätzlichen Funktionen zur Payload-Ausführung deuten darauf hin, dass C2Looper weiterentwickelt wird.

Mutmaßliche Verbreitung über ClickFix-Täuschungen

ThreatLabz schätzt mit niedriger bis mittlerer Sicherheit, dass C2Looper über eine mehrstufige ClickFix-Infektionskette verbreitet werden könnte. Bei solchen Kampagnen sieht das Opfer beispielsweise eine gefälschte Verifizierungsaufforderung, eine angebliche Browser-Fehlermeldung, ein CAPTCHA oder einen Hinweis auf ein vermeintliches Systemproblem. Anschließend soll es einen Befehl kopieren und in PowerShell, das Windows-Dialogfeld „Ausführen“ oder eine andere Kommandozeile einfügen.

Damit wird die Interaktion des Benutzers zu einem wichtigen Ansatzpunkt für Prävention und Erkennung. Eine Website oder Browsermeldung sollte niemals verlangen, dass Nutzer zur Verifizierung oder Reparatur Befehle in PowerShell, Windows Terminal oder „Ausführen“ einfügen.

Berichte über Vishing-Angriffe über Microsoft Teams und den Missbrauch von Quick Assist gehören in den größeren Kontext solcher Social-Engineering-Methoden. Die vorliegenden Belege beweisen jedoch nicht, dass jede dieser Kampagnen C2Looper verbreitet hat. Diese Überschneidungen sollten daher als plausibler Kontext und nicht als bestätigte Zuordnung behandelt werden.

Was Verteidiger überwachen sollten

Organisationen müssen nicht jedes Tool und jeden Dienst pauschal blockieren, der mit der Malware in Verbindung gebracht wird. Wertvoller ist die Suche nach einer Kombination auffälliger Verhaltensweisen:

• Häufige Klartext-HTTP-Beacons: Ungewöhnlich regelmäßigen JSON-POST-Datenverkehr untersuchen, insbesondere Anfragen an Pfade wie /api/beacon und /api/result/, wenn gleichzeitig ein neu beobachteter oder verdächtiger Prozess aktiv ist.
• Auffällige GitHub-Aktivität: Endpunktzugriffe auf GitHub-Repositories oder APIs prüfen, die einem regelmäßigen Muster folgen oder pro Host Verzeichnisse mit cmd.json und result.json verwenden. GitHub sollte nicht undifferenziert blockiert werden; legitime Entwicklungs- und Automatisierungsabläufe müssen berücksichtigt werden.
• OneDrive-DLL-Sideloading: Alarmieren, wenn eine legitime OneDrive-Datei aus einem ungewöhnlichen Benutzerpfad ausgeführt wird, eine DLL aus einem angrenzenden beschreibbaren Verzeichnis lädt oder unerwartete Tochterprozesse startet.
• Befehlsausführung und Systemaufklärung: EDR-Telemetrie auf verdächtige PowerShell- und cmd.exe-Aktivität, Befehle aus dem „Ausführen“-Dialog, Systemabfragen, gestaffelte Downloads und Shell-Ausführung durch bislang unbekannte Dateien auswerten.
• Verhaltensmuster der Rust-Backdoor: Dynamische API-Auflösung, verschlüsselte Zeichenketten, Netzwerk-Polling und das Nachladen von Payloads gemeinsam betrachten, statt sich auf ein einzelnes Dateimerkmal zu verlassen.

Prioritäten für die Prävention

Technische Kontrollen sollten mit Maßnahmen gegen Social Engineering kombiniert werden. Wo es die betrieblichen Anforderungen erlauben, sollten Unternehmen die von Benutzern gestartete Ausführung von PowerShell, Skripthosts, unsignierten Dateien und Programmen aus beschreibbaren Benutzerverzeichnissen einschränken oder kontrollieren. Application Allowlisting kann zusätzlich verhindern, dass heruntergeladene Payloads ausgeführt werden.

Mitarbeitende und Helpdesk-Teams sollten ausdrücklich geschult werden: Befehle aus Websites, CAPTCHAs, Browser-Fehlerseiten oder unaufgeforderten Supportkontakten dürfen niemals einfach kopiert und ausgeführt werden. Fernwartungssoftware sollte nur über freigegebene Abläufe, verifizierte Supportkanäle, starke Authentifizierung, Sitzungsprotokollierung und eine zeitnahe Prüfung ungewöhnlicher Sitzungen verwendet werden.

Netzwerksegmentierung, das Prinzip der geringsten Rechte, Multifaktor-Authentifizierung, eine zügige Aktualisierung internetexponierter Systeme sowie getestete Offline- oder unveränderbare Backups können die Folgen eines Erstzugriffs begrenzen. Zeigt ein Endpunkt verdächtiges Beaconing, Shell-Aktivität oder DLL-Sideloading, sollte er umgehend isoliert werden. Gleichzeitig sollten EDR- und Netzwerkprotokolle sowie – sofern angemessen – Arbeitsspeicher forensisch gesichert werden.

Fazit

Die Bedeutung von C2Looper liegt in seiner Entwicklung von einer vergleichsweise einfachen HTTP-Backdoor zu einem flexibleren Implantat, das GitHub-Repositories als operative Infrastruktur nutzt. Remote-Shell, Systemaufklärung, Datei-Downloads und Update-Funktionen machen die Malware zu einem plausiblen Zugangswerkzeug für Ransomware-bezogene Eindringversuche. Die Beweislage rechtfertigt jedoch eine vorsichtige Einschätzung und keine definitive Attribution.

Der wirksamste Schutz besteht aus ClickFix-resistenten Benutzerabläufen und einer verhaltensbasierten Suche nach ungewöhnlicher Befehlsausführung, OneDrive-DLL-Sideloading, extrem regelmäßigem HTTP-Polling und nicht erklärbarer GitHub-Repository-Aktivität.