Wenn KI Malware empfiehlt: Die neue Dimension der Supply-Chain-Angriffe

Wenn KI Malware empfiehlt: Die neue Dimension der Supply-Chain-Angriffe

Die Software-Supply-Chain ist unter Beschuss – und die Angreifer werden kreativer. Zwei aktuelle Vorfälle zeigen, wie Cyberkriminelle das Vertrauen von Entwicklern missbrauchen: Ein getarntes NuGet-Paket stiehlt brasilianische Bankdaten, während eine Welle von npm-Paketen Cloud-Geheimnisse absaugt. Was diese Angriffe besonders gefährlich macht? Sie nutzen die Mechanismen aus, die eigentlich das Entwickler-Alltagserlebnis verbessern sollen – bis hin zur KI-gestützten Suche.

Sicoob.Sdk: Ein trojanisches Pferd für Bankdaten

Sicherheitsforscher von Socket haben ein bösartiges NuGet-Paket entdeckt, das sich als legitimes C# SDK für Sicoob ausgibt – einem der größten genossenschaftlichen Finanzverbünde Brasiliens. Die Versionen 2.0.0 bis 2.0.4 von „Sicoob.Sdk" enthielten Funktionen, die sensible Informationen wie Client-IDs und PFX-Zertifikate exfiltrierten. Diese Zertifikate werden zur Authentifizierung von Unternehmen im Sicoob-Bankennetzwerk verwendet, um Banking-Operationen wie Instant Payments (Pix) und dynamische QR-Codes zu automatisieren.

Das Paket wurde fast 500-mal heruntergeladen. Laut Sicherheitsforscher Kirill Boychenko liest das Paket bei der Instanziierung von SicoobClient die PFX-Datei, kodiert sie Base64 und sendet sie zusammen mit Client-ID und Passwort an einen hartcodierten Sentry-Endpunkt. Zusätzlich werden rohe Boleto-API-Antworten abgefangen – ein beliebtes brasilianisches Zahlungsmittel –, was Transaktionsdetails, Zahlungstatus, Beträge und Zahlerdaten preisgeben kann.

KI als Verstärker: Besonders alarmierend ist, dass Google Search AI Mode das Paket als legitime C#-Bibliothek für Sicoob-Banking-APIs anzeigte. Das amplifiziert die Reichweite der Malware erheblich, da Entwickler zunehmend auf KI-Empfehlungen vertrauen, um Bibliotheken zu finden. Wenn KI-Systeme Malware als legitim einstufen, wird die etablierte Verteidigungslinie – die kritische Prüfung durch den Entwickler – ausgehebelt.

Quellcode-Mismatch als Täuschungsmanöver: Das verlinkte GitHub-Repository war sauber, während die Malware nur im NuGet-Paket existierte. Diese Diskrepanz – ein „Source-to-Package-Mismatch" – täuscht Entwickler, die den Code überprüfen wollen, in falscher Sicherheit. Wer auf GitHub nachschaut, findet nichts Verdächtiges. Die Schadcode landet erst im Artefakt, das über den Registry verbreitet wird.

Nach verantwortungsvoller Offenlegung hat NuGet das Paket blockiert. Der Profil „sicoob" bot weitere 11 Pakete an, die zusammen etwa 6.000 Downloads erreichten. Organisationen, die das Paket installiert haben, sollten es sofort entfernen, Zertifikate austauschen und API-Logs auf ungewöhnliche Aktivitäten prüfen.

npm-Pakete im Typosquatting- und Credential-Harvesting-Fokus

Parallel entdeckte das Microsoft Defender Security Research Team 14 bösartige npm-Pakete, die bekannte OpenSearch-, ElasticSearch-, DevOps- und Environment-Konfigurationsbibliotheken typosquatting-ten. Veröffentlicht am 28. Mai 2026 vom Akteur „vpmdhaj", nutzten sie einen preinstall-Hook, um AWS-Anmeldeinformationen, HashiCorp-Vault-Token, npm-Token und CI/CD-Pipeline-Secrets zu stehlen.

Die Pakate:

• @vpmdhaj/devops-tools
• @vpmdhaj/elastic-helper
• @vpmdhaj/opensearch-setup
• @vpmdhaj/search-setup
• app-config-utility
• elastic-opensearch-helper
• env-config-manager
• opensearch-config-utility
• opensearch-security-scanner
• opensearch-setup
• opensearch-setup-tool
• search-cluster-setup
• search-engine-setup
• vpmdhaj-opensearch-setup

Die breitere Kampagne: npm als Schlachtfeld

Diese Vorfälle sind Teil einer beunruhigenden Serie:

1. 164 Pakete in fünf Scoped Namespaces mit einem postinstall-Payload, der Umgebungsvariablen an oob.moika[.]tech/report sendet.
2. 141 Pakete (7.–27. Mai 2026), die npm als kostenloses Hosting für einen ad-monetarisierten Web-Proxy für Studenten missbrauchten.
3. „forge-jsxy", ein Keylogger mit Clipboard-Monitoring, .env-Scanning, Shell-History-Exfiltration und Krypto-Wallet-Scanning – eine Fortsetzung der „forge-jsx"-Kampagne.
4. 176 Pakete, die Dependency Confusion mit Versionsnummer „99.99.99" ausnutzten, um plattformspezifische Payloads zu laden.

Die Evolution des Typosquatting: Von Tippfehlern zu „Manufactured Legitimacy"

Laut Sonatype haben Angreifer das klassische Typosquatting überwachsen. Es geht nicht mehr nur um Tippfehler – es geht um „Manufactured Legitimacy": Paketnamen, die plausibel, nützlich und routinehaft aussehen. Techniken umfassen Prefix/Suffix-Addition, Dependency Confusion, Version Mimicry, Embedded Target Terms und funktionale Namensähnlichkeiten.

„Typosquatting ist jetzt ein zu enges Label", so Sonatype. „Das breitere Muster ist hergestellte Legitimität: Angreifer entwerfen Paketnamen, um plausibel, nützlich und operationell routinemäßig auszusehen."

Diese Entwicklung ist besonders tückisch. Wo früher „nodjeon" oder „reqeust" als verdächtig auffielen, wirken Namen wie „opensearch-config-utility" oder „env-config-manager" wie natürliche Ergänzungen moderner Tech-Stacks. Die psychologische Hürde, die Entwickler überwinden müssen, um diese Pakete zu hinterfragen, ist massiv gesenkt.

TeamPCP: Wenn ein vergifteter Dependency zum Wurm wird

Diese Vorfälle spielen vor dem Hintergrund von TeamPCP (aka Replicating Marauder, UNC6780), der Package-Manager über Grenzen hinweg (npm, PyPI, Docker Hub, Packagist) in Wurm-ähnlicher Weise vergiftet. Laut BlueVoyant-Forscher Michael Warren ging es nicht nur um bösartigen Code, sondern um die Ausnutzung von Automatisierung, geerbtem Vertrauen und CI/CD-Workflows, um Kompromittierung weiter downstream zu pushen.

„Ein vergifteter Dependency oder Container-Image konnte eine Kompromittierung in der Release-Pipeline einer unverbundenen Organisation auslösen", so Warren. „Die taktische Verschiebung machte isolierte Software-Vergiftung zu einer reproduzierbaren Methode für Victim-to-Victim-Expansion."

Fazit: Das Vertrauensparadigma ist gebrochen

Die Kombination aus KI-Empfehlungen, die Malware als legitim bewerten, sauberen GitHub-Repos als Tarnung und Paketnamen, die wie natürliche Entwickler-Tools klingen, untergräbt die Grundannahme: dass das Ökosystem sich selbst reguliert. Entwickler können nicht mehr davon ausgehen, dass ein Paket sicher ist, nur weil es auf einem offiziellen Registry existiert oder von einer KI vorgeschlagen wird.

Was zu tun ist:

• Verify, don't trust: Quellcode auf GitHub mit dem veröffentlichten Paket abgleichen (Source-to-Package-Mismatch prüfen).
• Dependency-Scanning: Automatisierte Tools wie Socket oder Snyk einsetzen.
• Least Privilege: Keine Secrets in Umgebungsvariablen ohne Zugriffskontrolle.
• KI-Empfehlungen kritisch prüfen: Nicht blind Links folgen, sondern Herkunft und Reputation verifizieren.
• Incident Response: Bei Verdacht sofort Pakete entfernen, Credentials rotieren, Logs auditen.

Die Supply-Chain-Sicherheit ist kein Randthema mehr – sie ist das zentrale Schlachtfeld moderner Cyberangriffe. Und die Angreifer sind nicht mehr nur Tippfehler-Jäger, sondern Architekten von Legitimität.

---

Quelle: The Hacker News