Der Glassworm-Botnet stellt einen Wendepunkt bei der Bekämpfung hochentwickelter Supply-Chain-Angriffe dar. Was diesen Fall besonders macht, ist die technische Cleverness der Infrastruktur: Statt auf traditionelle C2-Server zu verlassen, integrierten die Angreifer Blockchain-Technologie und dezentralisierte Netzwerke. Dies sollte jeden Versuch eines Takedowns frustrieren — eine Strategie, die lange aufging.
Die Angreifer platzierten zunächst bösartige Erweiterungen in OpenVSX und VS Code, die Kryptowallet-Schlüssel und Entwickleranmeldeinformationen auslas. Später dehnten sich die Attacken auf GitHub-Repositories und npm-Pakete aus. Besonders tückisch war eine Strategie in späteren Wellen: Dutzende scheinbar harmlose Extensions wurden mit dormanten Malware-Komponenten präpariert, die nach einem Softwareupdate aktiviert werden sollten.
Warum die gleichzeitige Abschaltung entscheidend war
Wie CrowdStrike erläutert, hätte die Zerschlagung eines einzelnen C2-Kanals wenig gebracht. Die Infrastruktur war so konzipiert, dass die Angreifer ihren Datenverkehr flexibel zwischen mehreren Kanälen umleiten konnten — ein klassisches Fail-Over-Szenario. Erst die simultane Blockierung aller vier Kanäle machte eine effektive Disruption möglich. Seitdem beaconing alle kompromittierten Maschinen zur IP-Adresse 164.92.88.210, die von CrowdStrike betrieben wird.
Empfehlungen für Betroffene
Organisationen, besonders Softwarehersteller und Entwicklungs-Teams, sollten sofort nach dieser IP-Adresse in ihren Netzwerkprotokollen suchen. CrowdStrike hat zudem YARA-Regeln veröffentlicht, die eine Überprüfung verdächtiger Systeme ermöglichen. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) dürfte diese Indikatoren ebenfalls in seine Warnsysteme aufnehmen.
Dieser Fall zeigt, wie kritisch Supply-Chain-Security ist. Die Attacken zielten nicht auf klassische Endnutzer, sondern auf Entwickler — mit dem Ziel, über manipulierte Code-Abhängigkeiten Tausende nachgelagerte Systeme zu kompromittieren. Für deutsche Unternehmen mit Entwickler-Teams gilt: Die regelmäßige Überprüfung von IDE-Erweiterungen, die Verifizierung von npm-Paketabhängigkeiten und das Monitoring von unerwarteten Netzwerkverbindungen sind jetzt wichtiger denn je.