CrowdStrike gab die koordinierte Zerschlagung des Glassworm-Botnets bekannt – eine groß angelegte Operation, die Softwareentwickler über kompromittierte Open-Source-Pakete, bösartige VSCode-Erweiterungen und manipulierte GitHub-Repositories ins Visier nahm.
Die gemeinsam mit Google und der Shadowserver Foundation durchgeführte Operation störte die Infrastruktur des Botnets und unterband die Kommunikation zwischen den Betreibern und infizierten Systemen.
„Gemeinsam mit Google und der Shadowserver Foundation haben wir alle vier Command-and-Control-Kanäle (C2) von Glassworm gleichzeitig getroffen“, sagte CrowdStrike in seinem Beitrag über die Operation.
Die wichtigsten Erkenntnisse aus der Zerschlagung des Glassworm-Botnets
- CrowdStrike, Google und die Shadowserver Foundation haben das Glassworm-Botnet aus der Software-Lieferkette lahmgelegt
- Die Kampagne nahm Entwickler über bösartige VSCode-Erweiterungen, npm-/Python-Pakete und manipulierte GitHub-Repositories ins Visier
- Glassworm nutzte eine dezentrale C2-Infrastruktur einschließlich Solana, BitTorrent DHT, Google Calendar und VPS-Servern
- Berichten zufolge wurden mehr als 300 GitHub-Repositories mithilfe gestohlener Entwicklerzugangsdaten kompromittiert
- Die Malware nahm Windows-, macOS- und Linux-Systeme ins Visier und verfügte über Funktionen zum Diebstahl von Zugangsdaten und für den Fernzugriff
Die Glassworm-Kampagne im Überblick
Die Glassworm-Kampagne verdeutlicht, dass Angreifer Softwareentwickler und die umfassendere Software-Lieferkette.
Da Entwickler häufig über privilegierten Zugriff auf Repositories, Cloud-Plattformen und Bereitstellungspipelines verfügen, kann die Kompromittierung eines einzigen Entwicklerkontos Angreifern einen Weg eröffnen, bösartigen Code über vertrauenswürdige Software-Ökosysteme zu verbreiten.
Wie Glassworm Entwickler ins Visier nahm
Laut CrowdStrike nutzten die Betreiber von Glassworm mehrere Verbreitungsmechanismen, um ihre Reichweite in Entwicklerumgebungen und Open-Source-Ökosystemen zu maximieren.
Die Kampagne verbreitete trojanisierte VSCode-Erweiterungen über den OpenVSX-Marktplatz, die als legitime Entwicklertools getarnt waren, darunter Codeformatierer und Dienstprogramme für die Produktivität.
Berichten zufolge nahmen die bösartigen Erweiterungen neben VSCode selbst mehrere weitere Entwicklungsumgebungen ins Visier, darunter Cursor, VSCodium, Windsurf und Positron.
Die Betreiber kompromittierten außerdem npm- und Python-Pakete, indem sie bösartige Skripte nach der Installation einbetteten, die während der Installation von Abhängigkeiten automatisch ausgeführt werden sollten.
Berichten zufolge wurden mehr als 300 GitHub-Repositories mithilfe gestohlener Entwicklerzugangsdaten manipuliert, um bösartigen Code in vertrauenswürdige Repositories und Standard-Branches einzuschleusen.
Die Malware befiel Windows-, macOS- und Linux-Systeme und enthielt ein auf Node.js basierendes Fernzugriffstool namens GlasswormRAT.
Laut CrowdStrike ermöglichte die Malware den Diebstahl von Zugangsdaten, Persistenz, das Sammeln von Informationen und den Fernzugriff auf kompromittierten Entwicklersystemen.
Die C2-Infrastruktur von Glassworm im Überblick
Die Infrastruktur von Glassworm war zudem darauf ausgelegt, herkömmlichen Störversuchen standzuhalten, indem sie gleichzeitig auf mehrere dezentrale Command-and-Control-Kanäle (C2) setzte.
Laut CrowdStrike speicherte ein Kommunikationsmechanismus Serverinformationen in Memo-Feldern von Transaktionen auf der Solana-Blockchain und schuf damit effektiv ein öffentliches Dead-Drop-System, das gegen herkömmliche Methoden zur Zerschlagung resistent ist.
Ein anderer nutzte das BitTorrent Distributed Hash Table (DHT)-Netzwerk, um Konfigurationsdaten über eine Peer-to-Peer-Infrastruktur ohne zentralen Ausfallpunkt abzurufen.
Die Malware nutzte außerdem Titel von Google-Calendar-Terminen, um Base64-kodierte C2-Pfade zu speichern, und unterhielt gleichzeitig herkömmliche, auf VPS gehostete Server für die Auslieferung von Payloads in der letzten Phase und die operative Steuerung.
Diese mehrschichtige Architektur schuf Redundanz über Blockchain-Dienste, Peer-to-Peer-(P2P)-Netzwerke, Cloud-Plattformen und herkömmliche Hosting-Anbieter hinweg, sodass die Betreiber auch bei einer Unterbrechung eines Kommunikationskanals widerstandsfähig blieben.
Wie CrowdStrike das Botnet lahmlegte
CrowdStrike wies darauf hin, dass alle vier Command-and-Control-Kanäle gleichzeitig gestört werden mussten, um das Botnet effektiv zu deaktivieren und die Kommunikation mit infizierten Systemen zu unterbinden.
Das Unternehmen erklärte, die Betreiber hätten ihre Tools von JavaScript auf Rust und Zig weiterentwickelt und gleichzeitig auf weitere Entwicklerplattformen ausgeweitet.
So lässt sich das Risiko für die Software-Lieferkette senken
Da Angriffe auf die Software-Lieferkette weiterhin Entwicklerumgebungen und Open-Source-Ökosysteme ins Visier nehmen, sind Unternehmen gezwungen, die Sicherheitskontrollen in Build-Pipelines, Repositories und Workflows für das Abhängigkeitsmanagement zu stärken.
- Entwicklerumgebungen, CI/CD-Pipelines und Repositories auf ungewöhnliche Paketaktivitäten überwachen – etwa auf nicht autorisierte Änderungen und verdächtiges Authentifizierungsverhalten.
- Erweiterungen und Abhängigkeiten vor der Installation validieren, unnötige Pakete von Drittanbietern beschränken und nach Möglichkeit private Artefakt-Repositories verwenden.
- MFA, Zugriffsrechte nach dem Least-Privilege-Prinzip, Branch-Schutz, signierte Commits und Kontrollen für privilegierten Zugriff für Entwickler- und Administratorkonten durchsetzen.
- Code-Signaturprüfungen, Software Composition Analysis (SCA), SBOM-Transparenz und die Überwachung der Dateiintegrität implementieren, um bösartige oder anfällige Komponenten zu identifizieren.
- Entwickler- und Build-Umgebungen von Produktivsystemen trennen und gleichzeitig unnötige ausgehende Verbindungen zu öffentlichen Paket-Ökosystemen beschränken.
- Transparenz und verhaltensbasierte Erkennungsfunktionen auf Endpunkten stärken und so Entwicklerarbeitsplätze auf Datendiebstahl, Persistenz und verdächtige Build-Aktivitäten überprüfen.
- Pläne für die Reaktion auf Sicherheitsvorfälle, Eindämmung und Wiederherstellung regelmäßig testen – auch im Hinblick auf Kompromittierungen der Software-Lieferkette, bösartige Pakete und Einbrüche in Repositories.
In ihrer Gesamtheit können diese Maßnahmen Unternehmen dabei helfen, ihre Angriffsfläche in der Software-Lieferkette zu verringern und ihre betriebliche Widerstandsfähigkeit zu stärken.
Die wachsende Bedrohung für die Software-Lieferkette
Die Glassworm-Operation steht für eine umfassendere Entwicklung, bei der Angreifer zunehmend vertrauenswürdige Software-Ökosysteme und Entwicklerinfrastrukturen ins Visier nehmen.
Open-Source-Repositories, Paketregistries und CI/CD-Umgebungen bleiben attraktive Ziele, da ein einziges kompromittiertes Paket oder Entwicklerkonto Tausende nachgelagerte Nutzer und Systeme beeinträchtigen kann.
Die Erkennung allein wird bei Angriffen auf die Lieferkette zunehmend weniger wirksam, da sich bösartige Pakete und Abhängigkeiten über automatisierte Entwicklungsworkflows rasch verbreiten können, bevor sie identifiziert werden.
CrowdStrike betonte, dass proaktive Maßnahmen zur Störung der Angreifer und die branchenübergreifende Zusammenarbeit immer wichtiger werden, um Risiken für die Lieferkette zu verringern und widerstandsfähige Bedrohungsinfrastrukturen zu stören.
Angesichts der Risiken, die mit vertrauenswürdigen Software-Ökosystemen verbunden sind, setzen einige Unternehmen auf Zero-Trust-Lösungen , um Zugriffskontrollen und Segmentierung zu stärken sowie die Sicherheit von Entwicklerumgebungen insgesamt zu verbessern.