Analysten von Solar 4RAYS haben eine bislang undokumentierte Backdoor namens IDFKA aufgedeckt, die in langanhaltenden, zielgerichteten Angriffen auf russische Telekommunikationsunternehmen eingesetzt wurde. Die Schadsoftware blieb in der Infrastruktur eines IT-Dienstleisters und mehrerer Kunden mindestens zehn Monate unentdeckt – ein typisches Muster für Cyberspionage gegen kritische Infrastrukturen.
Ungewöhnliche PostgreSQL-Aktivität legt komplexe Angriffskette offen
Der Vorfall wurde Ende Mai 2025 entdeckt, als Sicherheitsteams anormale Aktivität in einer PostgreSQL-Datenbank eines IT-Subunternehmens der Telekom-Branche registrierten. Unter dem Konto einer privilegierten Servicekennung wurden SQL-Befehle ausgeführt, die sich klar von regulären Administrationsaufgaben unterschieden. Solche Muster gelten in der Praxis häufig als Indikator, dass Angreifer eine Datenbank als Einstiegspunkt und zur Persistenz im Netzwerk missbrauchen.
Die anschließende Untersuchung zeigte, dass die Infrastruktur gleichzeitig von zwei voneinander unabhängigen Gruppen kompromittiert war: der bekannten, in Ostasien verorteten Spionagegruppe Snowy Mogwai und dem weniger erforschten Cluster NGC5081. Keine Überschneidungen in C2-Servern, unterschiedliche Verschleierungstechniken und teils getrennt infizierte Systeme sprechen klar gegen eine koordinierte Operation. Den neuen Backdoor-Schädling IDFKA setzten ausschließlich die Akteure von NGC5081 ein, zusätzlich zu dem bereits bekannten Tool Tinyshell.
Technisches Profil der Rust-Backdoor IDFKA
IDFKA wurde laut Analyse komplett neu entwickelt und in Rust implementiert. Rust-basierte Malware ist im professionellen Angriffssektor zunehmend verbreitet, da der Sprachstandard robuste, speichersichere und plattformübergreifende Binärdateien ermöglicht. Für Analysten erschweren moderne Rust-Toolchains sowohl statische als auch dynamische Analysen signifikant – ein Trend, den auch neuere Kampagnen mit Rust-basierten Ransomware-Familien bestätigen.
Eigener L4-Protokollstack und verschlüsselte Nutzlast
Eine der auffälligsten Eigenschaften von IDFKA ist ein eigener Kommunikations-Stack auf Layer 4, der direkt auf IP aufsetzt. Dadurch umgeht die Backdoor klassische Intrusion-Detection-Systeme, die vor allem auf bekannte Protokolle wie TCP, UDP oder HTTP ausgerichtet sind. Die eigentliche Schadfunktion ist mit AES im ECB-Modus verschlüsselt; zur Entschlüsselung ist eine spezielle Umgebungsvariable TRM64CFG erforderlich. Ohne diese Variable bleibt die Binärdatei für Forensiker weitgehend intransparent, was die Analyse außerhalb des Originalkontexts erheblich erschwert.
Zur Steuerung unterstützt IDFKA eine mehrgleisige C2-Kommunikation, darunter TCP/UDP, ICMP, HTTP sowie proprietäre Protokolle. Diese Redundanz erhöht die Resilienz der Angriffsinfrastruktur: Wird ein Kanal durch Filter oder Signaturen blockiert, können die Angreifer auf alternative Transportwege ausweichen. Vergleichbare Mehrkanal-Ansätze werden auch in hochentwickelten Plattformen wie GoblinRAT beobachtet.
Spionagefunktionen: Netzaufklärung und Diebstahl von Zugangsdaten
Funktionsseitig deckt IDFKA das typische Spektrum moderner Post-Exploitation- und Spionagewerkzeuge ab. Die Malware ermöglicht die remote Steuerung infizierter Systeme, das Scanning interner Netzsegmente, automatisierte Brute-Force-Angriffe auf SSH-Zugänge sowie den Diebstahl von Anmeldedaten. Für letzteren Zweck nutzt IDFKA unter anderem ptrace, um Prozesse zu überwachen, sowie eBPF, um Aktivitäten und Netzwerkverkehr direkt im Kernel abzugreifen. Branchenberichte – etwa der Verizon Data Breach Investigations Report – bestätigen, dass gerade die Kombination aus Credential-Diebstahl und lateraler Bewegung einer der Haupttreiber erfolgreicher Spionageangriffe ist.
Tarnmechanismen und langanhaltende Präsenz in der Infrastruktur
Besonderen Wert legten die Angreifer auf Unauffälligkeit und minimale Artefakte. IDFKA tarnte sich als reguläre Linux-Systemdienste und platzierte sich in Standardpfaden für ausführbare Dateien. Bemerkenswert ist, dass bewusst auf Autostart-Mechanismen verzichtet wurde. In vielen kritischen Umgebungen werden Server jahrelang nicht neu gestartet – eine einmal platzierte Backdoor bleibt so aktiv, ohne zusätzliche Spuren im System zu hinterlassen.
Der älteste gefundene IDFKA-Build stammt aus November 2024, forensische Artefakte deuten jedoch auf eine Erstkompromittierung bereits im September 2024 hin. Die Angreifer manipulierten systematisch Logdateien, darunter wtmp und lastlog, und löschten gezielt Einträge, um Authentifizierungs- und Sitzungsverläufe zu verschleiern. In Summe ermöglichte dieses Vorgehen NGC5081 ein mindestens zehnmonatiges, unentdecktes Verweilen in den Netzen des Dienstleisters und mehrerer Telekom-Kunden.
Angriff auf Telekom-Datenbanken und Einordnung der Bedrohungslage
Wenige Tage nach der Installation von IDFKA im Netzwerk des IT-Partners kompromittierten die Angreifer den PostgreSQL-Cluster eines ersten Telekommunikationsunternehmens, im April 2025 folgte ein weiterer Betreiber. Damit erhielten sie Zugriff auf Kundendatenbanken und Metadaten zu Telefonverbindungen. Auch wenn bislang keine technisch belegbare Massenexfiltration vorliegt, bedeutet schon der Lesezugriff auf solche Daten ein erhebliches Risiko: Von gezielten Social-Engineering-Kampagnen bis hin zu nachrichtendienstlich relevanter Kommunikationsanalyse reichen hier mögliche Folgeszenarien.
Zum Zeitpunkt der Veröffentlichung des Berichts waren die C2-Server von NGC5081 weiterhin aktiv und Konfigurationen im September 2025 aktualisiert worden. Dies legt nahe, dass IDFKA ein aktives Werkzeug im Arsenal dieser Gruppe bleibt. Die Überschneidung von Infrastrukturkomponenten mit Tinyshell sowie verschiedene technische Indikatoren sprechen für einen ostasiatischen Ursprung, ohne dass eine eindeutige staatliche oder kriminelle Zuordnung möglich wäre – ein generelles Problem moderner Angriffsattribution.
Empfehlungen: Wie sich ähnliche Rust-Backdoors in kritischen Netzen erkennen lassen
Für Telekommunikationsanbieter und deren Dienstleister bestätigen die Erkenntnisse mehrere zentrale Sicherheitsprinzipien. Erstens erfordert die Nutzung privilegierter Konten – insbesondere Service- und Datenbankkonten – strikte Zugriffskontrollen, Audit-Logs und regelmäßige Überprüfung ungewöhnlicher Abfragen. Zweitens sollten Security-Teams Anomalie-Erkennung auf Datenbank-, System- und Netzwerkebene einsetzen, um atypische Nutzung von Protokollen oder selbstgebauten L4-Mechanismen sichtbar zu machen. Drittens ist eine schnelle Umsetzung veröffentlichter Indikatoren kompromittierter Systeme (IoCs) und YARA-Regeln entscheidend, um bestehende Kompromittierungen aufzuspüren.
Der Fall IDFKA verdeutlicht, wie professionell entwickelte, Rust-basierte Malware mit eigenem Protokollstack, Kernel-naher Überwachung via eBPF und ausgefeilter Logmanipulation langfristig unter dem Radar bleiben kann. Organisationen mit kritischer Infrastruktur sollten ihre Überwachungs- und Härtungsmaßnahmen konsequent ausbauen, Angriffsübungen (Purple Teaming) durchführen und ihre Incident-Response-Prozesse regelmäßig testen. Wer diese Praktiken etabliert, reduziert signifikant die Wahrscheinlichkeit, dass hochentwickelte Backdoors wie IDFKA über Monate hinweg unentdeckt in sensiblen Netzsegmenten operieren können.
