Eine Untersuchung von Socket hat neun bösartige NuGet-Pakete mit zeitgesteuerter Sabotagelogik offengelegt. Die versteckten Routinen aktivieren sich ausschließlich in einem engen Fenster zwischen August 2027 und November 2028 und zielen auf Datenbankzugriffe in .NET sowie auf Industriekommunikation mit Siemens-PLC über die Bibliothek Sharp7. Die Pakete wurden 2023–2024 vom Nutzer shanhai666 veröffentlicht; von zwölf Paketen enthielten neun Schadfunktionalität. Zum Zeitpunkt der Entdeckung summierten sich die Downloads auf rund 9.500. Laut Socket wurden die Pakete aus NuGet entfernt; die Verbreitung in Projekten bleibt unbekannt.
Wesentliche Befunde: getarnte Schadlogik in produktivem Code
Die Autoren tarnten die Malware sorgfältig: bis zu 99 % des Codes bot legitime Funktionalität, während die schadensstiftende Logik in etwa 20 Zeilen verborgen war. Solche Mischpakete sind für statische Analysen schwerer zu erkennen und passieren häufig ein oberflächliches Code-Review. Die Payload wurde über C#-Erweiterungsmethoden in gängige DB-Operationen (SQL Server, PostgreSQL, SQLite) und in PLC-Kommunikationspfade eingeschleust.
Mechanismus der zeitverzögerten Aktivierung
Triggerfenster und probabilistisches Verhalten
Bei jedem Aufruf prüft der Code das Systemdatum auf den Bereich 08.08.2027–29.11.2028. Fällt die Ausführung in dieses Fenster, generiert die Routine eine Zufallszahl von 1 bis 100; bei Werten über 80 wird der Prozess über Process.GetCurrentProcess().Kill() zwangsbeendet – faktisch eine 20-%-Chance auf einen vermeintlich spontanen Absturz.
ICS/OT im Fokus: Sharp7-Ökosystem und Siemens-PLC
Sharp7Extend als Hebel für industrielle Sabotage
Besondere Sorge bereitet Sharp7Extend, ein angebliches Add-on zur etablierten PLC-Bibliothek Sharp7. Das Paket unterbricht bis zum 06.06.2028 Verbindungen zu PLCs mit einer Wahrscheinlichkeit von 20 %. Zusätzlich versucht es, ein nicht vorhandenes Konfigurationsfeld zu lesen, was die Initialisierung deterministisch scheitern lässt. Eine weitere Komponente verzögert ihre Wirkung 30–90 Minuten und verfälscht anschließend in 80 % der Fälle Schreiboperationen auf die PLC – eine Kombination aus unmittelbarer und später einsetzender Sabotage, die in ICS/OT-Umgebungen Prozesssicherheit und Anlagenverfügbarkeit kompromittieren kann.
Warum diese Lieferkettenattacke schwer zu erkennen ist
Die zeitliche Verzögerung um mehrere Jahre und die probabilistische Ausführung erschweren Detektion wie Forensik erheblich. Verantwortliche Teams können bis zur Aktivierung gewechselt haben; sporadische Ausfälle wirken wie Hardwarefluktuationen oder seltene Softwarefehler. Solche Eigenschaften sind in der Lieferkette erprobt: Historische Fälle wie event-stream (npm) oder UA-parser-js zeigen, wie unauffällige Abhängigkeiten zur Angriffsbasis werden. Rahmenwerke wie NIST SSDF und SLSA sowie Behördenleitfäden von CISA adressieren genau diese Risiken und empfehlen reproduzierbare Builds, Artefakt-Integritätsprüfungen und kontinuierliche Abhängigkeitsüberwachung.
Empfehlungen: Sofortmaßnahmen und langfristige Härtung
Laut Socket sollten betroffene Codebasen und Build-Artefakte umgehend auf die genannten Pakete geprüft und bei Fund als kompromittiert eingestuft werden. Darüber hinaus sind folgende Maßnahmen zielführend:
- Inventarisierung und SBOM: Vollständige Abhängigkeitslisten (z. B. CycloneDX) mit Versionen erstellen und versioniert archivieren.
- Version-Pinning und vertrauenswürdige Feeds: Private NuGet-Feeds/Spiegel nutzen, Hash- und Signaturprüfungen aktivieren, Zulassungslisten führen.
- Code-Review schärfen: Erweiterungsmethoden und Hooks in kritischen Pfaden (DB/PLC) gezielt prüfen; ungewöhnliche Zeit- und Zufallsprüfungen hinterfragen.
- Monitoring & Forensik: Unerwartete Prozessabbrüche, Transaktionsanomalien und PLC-Fehler systematisch korrelieren; Ereignisprotokolle zentral sammeln und aufbewahren.
- CI/CD-Scanning: Kontinuierliche Analysen mit mehreren Scannern, Policies gegen neu/unverifizierte Maintainer, Attestierungen (in-toto/SLSA) für Artefakte.
Organisationen sollten die Gelegenheit nutzen, ihre Supply-Chain-Security zu professionalisieren: Abhängigkeiten konsolidieren, Vertrauensprozesse für Pakete aktualisieren, und „saubere“ Referenzzustände früh festhalten. Wer jetzt SBOMs etabliert, Policies für Third-Party-Code durchsetzt und Telemetrie für Abbrüche wie Process.Kill() überwacht, erhöht die Chance, zeitgesteuerte „Bomben“ rechtzeitig zu entdecken und ihre Auswirkungen in .NET-, Datenbank- und ICS/OT-Landschaften zu minimieren.
