{"id":33349,"date":"2026-04-08T11:51:16","date_gmt":"2026-04-08T09:51:16","guid":{"rendered":"https:\/\/www.kaspersky.de\/blog\/?p=33349"},"modified":"2026-04-08T12:22:43","modified_gmt":"2026-04-08T10:22:43","slug":"supply-chain-attacks-in-2025","status":"publish","type":"post","link":"https:\/\/www.kaspersky.de\/blog\/supply-chain-attacks-in-2025\/33349\/","title":{"rendered":"Die spektakul\u00e4rsten Lieferkettenangriffe von 2025"},"content":{"rendered":"<p>Lieferkettenangriffe sind <a href=\"https:\/\/www.kaspersky.com\/blog\/supply-chain-attacks-in-2024\/52965\/\" target=\"_blank\" rel=\"noopener nofollow\">seit Jahren<\/a> eine der gef\u00e4hrlichsten Kategorien von Cybersicherheitsvorf\u00e4llen. Das Jahr\u00a02025 hat ganz deutlich gezeigt, dass Cyberkriminelle in diesem Bereich noch einen Zahn zugelegt haben. In diesem ausf\u00fchrlichen Bericht betrachten wir Lieferkettenangriffe aus dem Jahr 2025\u00a0\u2013 nicht unbedingt die kostspieligsten Angriffe, aber sicherlich die ungew\u00f6hnlichsten und spektakul\u00e4rsten.<\/p>\n<h2>Januar\u00a02025: RAT im GitHub-Repository von DogWifTools<\/h2>\n<p>Gleich nach den Feiertagen versahen Cyberkriminelle zum Warmwerden mehrere Versionen von DogWifTools systematisch mit <a href=\"https:\/\/www.bleepingcomputer.com\/news\/security\/solana-pumpfun-tool-dogwiftool-compromised-to-drain-wallets\/\" target=\"_blank\" rel=\"noopener nofollow\">Hintert\u00fcren<\/a>. Dieses Dienstprogramm wurde entwickelt, um Solana-basierte <a href=\"https:\/\/de.wikipedia.org\/wiki\/Meme-Coin\" target=\"_blank\" rel=\"noopener nofollow\">Meme-Coins<\/a> auf Pump.fun zu starten und energisch zu bewerben. Nach der Kompromittierung des privaten GitHub-Repositorys f\u00fcr DogWifTools warteten die Angreifer, bis die Entwickler ein neues Build hochluden, injizierten einen RAT und tauschten wenige Stunden sp\u00e4ter das legitime Programm durch eine b\u00f6sartige Version aus. Nach Angaben der Entwickler infizierten die Angreifer die Versionen\u00a01.6.3 bis\u00a01.6.6 von DogWifTools f\u00fcr Windows erfolgreich mit Trojanern.<\/p>\n<p>Der Endspurt erfolgte Ende Januar. Nachdem die Angreifer mithilfe des RAT riesige Datenmengen von infizierten Ger\u00e4ten gesammelt hatten, leerten sie die Krypto-Wallets ihrer Opfer. Die Opfer sch\u00e4tzen den Gesamtbetrag des gestohlenen Kryptoguthabens auf \u00fcber 10\u00a0Millionen US-Dollar. Die Angreifer <a href=\"https:\/\/x.com\/JizzyGroup\/status\/1884395542072959208\" target=\"_blank\" rel=\"noopener nofollow\">bestritten<\/a> diese Zahl, verrieten aber nicht, wie viel sie tats\u00e4chlich verdient hatten.<\/p>\n<h2>Februar\u00a02025: 1,5-Milliarden-Dollar-\u00dcberfall auf Bybit<\/h2>\n<p>Wenn der Januar zum Aufw\u00e4rmen diente, war der Februar eine totale Kernschmelze. Der <a href=\"https:\/\/www.kaspersky.de\/blog\/bybit-hack-lessons-how-to-do-self-custody-properly\/32010\/\" target=\"_blank\" rel=\"noopener\">Hack der Krypto-B\u00f6rse Bybit<\/a> stellte fr\u00fchere Vorf\u00e4lle vollst\u00e4ndig in den Schatten und wurde zum gr\u00f6\u00dften Krypto-Raub aller Zeiten. Den Angreifern gelang es, die Software Safe{Wallet} zu kompromittieren. Sie diente der Multi-Signatur-Offline-Speicherung, auf die sich die B\u00f6rse zur Verwaltung ihrer Assets st\u00fctzte.<\/p>\n<p>Die Bybit-Mitarbeiter dachten, sie w\u00fcrden eine Routinetransaktion signieren. In Wirklichkeit autorisierten sie einen b\u00f6sartigen Smart Contract. Nach der Ausf\u00fchrung wurde eine prim\u00e4re Cold Wallet geleert und das Guthaben wurde auf mehrere Hundert von Angreifern kontrollierte Wallets verteilt. Die endg\u00fcltige Beute \u00fcberstieg 400.000 ETH\/stETH mit einem sagenhaften Gesamtwert von ungef\u00e4hr 1,5\u00a0Milliarden US-Dollar!<\/p>\n<h2>M\u00e4rz\u00a02025: Angriff auf Coinbase durch kaskadierende Kompromittierung in GitHub Actions<\/h2>\n<p>Das Fr\u00fchjahr\u00a02025 begann mit einem raffinierten Angriff, bei dem eine <a href=\"https:\/\/www.kaspersky.com\/blog\/malicious-github-action-changed-files\/53179\/\" target=\"_blank\" rel=\"noopener nofollow\">Kompromittierung mehrerer GitHub Actions<\/a> als prim\u00e4rer Bereitstellungsmechanismus diente. GitHub Actions bietet Workflow-Muster zur Automatisierung von DevOps-Standardaufgaben. Alles begann mit dem Diebstahl eines privaten Zugriffstokens, das einem Administrator des Analysetools SpotBugs geh\u00f6rte. Die Angreifer ver\u00f6ffentlichten einen b\u00f6sartigen Prozess und entf\u00fchrten das Token eines Mitarbeiters des Workflows reviewdog\/action-setup, der ebenfalls an dem Projekt beteiligt war.<\/p>\n<p>Dann kompromittierten sie eine Abh\u00e4ngigkeit des Workflows tj-actions\/changed-files und ver\u00e4nderten diesen, um ein b\u00f6sartiges Python-Skript auszuf\u00fchren. Dieses Skript suchte nach hochwertigen Geheimnissen, z.\u00a0B. nach AWS-, Azure- und Google Cloud-Schl\u00fcsseln, GitHub- und NPM-Token, Anmeldeinformationen f\u00fcr Datenbanken und privaten RSA-Schl\u00fcsseln. Seltsamerweise schrieb das Skript alles, was es fand, direkt in \u00f6ffentlich zug\u00e4ngliche Build-Protokolle. Damit waren die durchgesickerten Daten nicht nur f\u00fcr die Angreifer verf\u00fcgbar, sondern f\u00fcr alle, die sich einigerma\u00dfen in diesem Bereich auskannten.<\/p>\n<p>Das urspr\u00fcngliche Ziel dieser Operation war ein Repository, das zu der Krypto-B\u00f6rse Coinbase geh\u00f6rt. Gl\u00fccklicherweise erkannten die Entwickler die Bedrohung rechtzeitig und verhinderten die Kompromittierung. Als den Angreifern offenbar klar wurde, dass sie die Kontrolle \u00fcber die Pipeline tj-actions\/changed-files verloren, weiteten sie die Attacke aus. Dadurch drohte 23.000 Repositorys eine Offenlegung ihrer Geheimnisse. Schlie\u00dflich mussten <a href=\"https:\/\/thehackernews.com\/2025\/03\/github-supply-chain-breach-coinbase.html\" target=\"_blank\" rel=\"noopener nofollow\">mehrere Hundert<\/a> dieser Repositorys tats\u00e4chlich zusehen, wie ihre vertraulichen Anmeldedaten an die \u00d6ffentlichkeit gerieten.<\/p>\n<h2>April\u00a02025: Backdoor in 21\u00a0Magento-Erweiterungen<\/h2>\n<p>Im April wurde eine Infektion in einer ganzen Reihe von Erweiterungen f\u00fcr Magento <a href=\"https:\/\/www.bleepingcomputer.com\/news\/security\/magento-supply-chain-attack-compromises-hundreds-of-e-stores\/\" target=\"_blank\" rel=\"noopener nofollow\">entdeckt<\/a>, eine der beliebtesten Plattformen zum Erstellen von Online-Shops. Die Hintert\u00fcr war in 21\u00a0Module eingebettet, die von drei Herstellern stammten: Tigren, Meetanshi und MGS. Diese Erweiterungen geh\u00f6rten zur Infrastruktur von mehreren hundert E-Commerce-Unternehmen, darunter mindestens ein internationaler Konzern.<\/p>\n<p>Nach Angaben der Forscher wurde die Backdoor schon 2019 installiert. Im April\u00a02025 aktivierten die Angreifer sie schlie\u00dflich, um Websites zu kompromittieren und Web-Shells hochzuladen. Daf\u00fcr hatten die Erweiterungen eine eingebettete Funktion, die beliebigen Code aus einer Lizenzdatei ausf\u00fchrte.<\/p>\n<p>Ironischerweise geh\u00f6rten zu den infizierten Modulen auch MGS DSGVO und Meetanshi CookieNotice. Wie die Namen vermuten lassen, wurden diese Erweiterungen entwickelt, um Websites bei der Einhaltung von Datenschutz- und Datenverarbeitungsbestimmungen zu unterst\u00fctzen. Aber anstatt sich um die Privatsph\u00e4re zu k\u00fcmmern, wurde <a href=\"https:\/\/www.kaspersky.de\/blog\/illicit-code-on-legitimate-sites\/30305\/\" target=\"_blank\" rel=\"noopener\">Web-Skimming<\/a> betrieben und h\u00f6chstwahrscheinlich wurden Benutzerdaten und Guthaben gestohlen.<\/p>\n<h2>Mai\u00a02025: Verbreitung von Ransomware \u00fcber einen kompromittierten MSP<\/h2>\n<p>Im Mai <a href=\"https:\/\/www.theregister.com\/2025\/05\/28\/dragonforce_ransomware_gang_sets_fire\/\" target=\"_blank\" rel=\"noopener nofollow\">erlangten Hacker aus der DragonForce-Bande Zugriff<\/a> auf die Infrastruktur eines nicht genannten Managed Service Providers (MSP) und verwendeten diese, um ihre Ransomware zu verteilen und Daten von den Kunden des Providers zu stehlen.<\/p>\n<p>Offenbar nutzten die Angreifer mehrere Schwachstellen (einschlie\u00dflich einer kritischen Schwachstelle) in SimpleHelp aus, dem vom MSP verwendeten Tool zur Remote-\u00dcberwachung und -Verwaltung. Diese Schwachstellen wurden bereits\u00a02024 entdeckt und <a href=\"https:\/\/thehackernews.com\/2025\/01\/critical-simplehelp-flaws-allow-file.html\" target=\"_blank\" rel=\"noopener nofollow\">im Januar\u00a02025<\/a> \u00f6ffentlich bekannt gegeben und gepatcht. Leider hatte es der MSP offenbar nicht eilig mit dem Update\u00a0\u2013 eine Nachl\u00e4ssigkeit, die der Erpresserbande gerade recht kam.<\/p>\n<h2>Juni\u00a02025: Backdoor in einem Dutzend beliebter npm-Pakete<\/h2>\n<p>Zu Beginn des Sommers hackten Angreifer das Konto eines Gluestack-Bibliotheksadministrators und nutzten ein gestohlenes Zugriffstoken, um <a href=\"https:\/\/www.bleepingcomputer.com\/news\/security\/supply-chain-attack-hits-gluestack-npm-packages-with-960k-weekly-downloads\/\" target=\"_blank\" rel=\"noopener nofollow\">Hintert\u00fcren in 17\u00a0npm-Pakete einzuschleusen<\/a>. Das beliebteste dieser Pakete, @react-native-aria\/interactions, verzeichnete 125.000 Downloads pro Woche, w\u00e4hrend die Gesamtzahl der kompromittierten Pakete \u00fcber eine Million betrug.<\/p>\n<p>Besonders interessant sind dabei die Schritte, die die Gluestack-Entwickler <a href=\"https:\/\/github.com\/gluestack\/gluestack-ui\/issues\/2894#issuecomment-2955003750\" target=\"_blank\" rel=\"noopener nofollow\">nach dem Vorfall unternahmen<\/a>: Erstens schr\u00e4nkten sie den Zugriff auf das GitHub-Repository f\u00fcr sekund\u00e4re Teilnehmer ein, zweitens aktivierten sie die Zwei-Faktor-Authentifizierung (2FA) f\u00fcr die Ver\u00f6ffentlichung neuer Versionen, und drittens versprachen sie, sichere Entwicklungspraktiken zu implementieren (beispielsweise einen auf Pull-Anfragen basierenden Workflow, systematische Code-Reviews und Audit-Logging). Mit anderen Worten: Vor dem Vorfall gab es in einem Projekt mit Hunderttausenden von Downloads pro Woche keine derartigen Ma\u00dfnahmen.<\/p>\n<h2>Juli\u00a02025: Infektion beliebter npm-Pakete durch einen Phishing-Angriff<\/h2>\n<p><a href=\"https:\/\/www.theregister.com\/2025\/07\/24\/not_pretty_not_windowsonly_npm\/\" target=\"_blank\" rel=\"noopener nofollow\">Auch im Juli waren npm-Pakete<\/a> die Superstars\u00a0\u2013 darunter auch das weit verbreitete Paket mit dem kurzen Namen \u201eis\u201c und 2,7\u00a0Millionen Downloads pro Woche. Diese Bibliothek f\u00fcr JavaScript-Dienstprogramme bietet eine breite Palette von Funktionen zur Typenpr\u00fcfung und Validierung von Werten. Den Hackern gelang ein Phishing-Angriff auf einen der Projektinhaber, und zwar mit dem \u00e4ltesten Trick der Welt: Sie nutzten einen banalen <a href=\"https:\/\/encyclopedia.kaspersky.com\/glossary\/typosquatting\/\" target=\"_blank\" rel=\"noopener\">Tippfehler<\/a> (die Dom\u00e4ne hie\u00df npnjs.com statt npmjs.com) und einen Klon der offiziellen npm-Website.<\/p>\n<p>\u00dcber das kompromittierte Konto ver\u00f6ffentlichten sie mehrere eigene Versionen des Pakets inklusive Hintert\u00fcr. Es dauerte sechs Stunden, bis die Infektion entdeckt wurde. In dieser Zeit luden viele Entwickler die sch\u00e4dlichen npm-Pakete herunter.<\/p>\n<p>Die gleiche Phishing-Taktik wurde auch gegen andere Entwickler angewendet. Die Angreifer nutzten mehrere kompromittierte Entwicklerkonten, um <a href=\"https:\/\/www.bleepingcomputer.com\/news\/security\/popular-npm-linter-packages-hijacked-via-phishing-to-drop-malware\/\" target=\"_blank\" rel=\"noopener nofollow\">verschiedene Varianten eines b\u00f6sartigen Codes<\/a> zu verteilen. Zudem besteht der Verdacht, dass die Hacker einen Teil ihrer \u201eBeute\u201c f\u00fcr sp\u00e4tere Angriffe aufbewahrt haben.<\/p>\n<h2>August\u00a02025: Angriff auf s1ngularity und abgeflossene Entwicklergeheimnisse<\/h2>\n<p><a href=\"https:\/\/www.kaspersky.com\/blog\/nx-build-s1ngularity-supply-chain-attack\/54223\/\" target=\"_blank\" rel=\"noopener nofollow\">Ein Vorfall namens \u201es1ngularity\u201c<\/a> setzte Ende August den Trend f\u00fcr Angriffe auf JavaScript-Entwickler fort. Angreifer kompromittierten Nx, ein beliebtes Build-System und Tool zur CI\/CD-Pipeline-Optimierung. B\u00f6sartiger Code, der in die Pakete eingeschleust wurde, durchsuchte die infizierten Entwicklersysteme nach einer Vielzahl sensibler Daten, darunter Krypto-Wallet-Schl\u00fcssel, npm- und GitHub-Token, SSH-Schl\u00fcssel und API-Schl\u00fcssel.<\/p>\n<p>Interessanterweise nutzten die Angreifer lokal installierte KI-Tools (z.\u00a0B. Claude Code, Gemini CLI und Amazon Q), um Geheimnisse auf den Computern der Opfer auszuspionieren. Alles, was sie fanden, wurde in \u00f6ffentlichen GitHub-Repositorys ver\u00f6ffentlicht, die unter den Namen der Opfer erstellt wurden und die Titel \u201es1ngularity-repository\u201c, \u201es1ngularity-repository-0\u201c und \u201es1ngularity-repository-1\u201c trugen. Eben daher kommt der Name des Angriffs.<\/p>\n<p>Dadurch wurden die vertraulichen Daten Hunderter von Entwicklern sichtbar, und nicht nur Angreifer konnten darauf zugreifen, sondern eigentlich das ganze Internet.<\/p>\n<h2>September\u00a02025: Krypto-Stealer in npm-Paketen mit 2,6\u00a0Milliarden Downloads\/Woche<\/h2>\n<p>Der Trend zur Kompromittierung von npm-Paketen blieb bis in den September hinein stabil. Durch eine neue Phishing-Kampagne, die sich gegen JavaScript-Entwickler richtete, gelang es Angreifern, Schadcode in einige Dutzend hochkar\u00e4tige Projekte einzuschleusen. Einige davon, insbesondere \u201echalk\u201c und \u201edebug\u201c, verbuchen pro Woche <em>Hunderte Millionen<\/em> Downloads. Insgesamt wurden f\u00fcr die infizierten Pakete zum Zeitpunkt der Kompromittierung <a href=\"https:\/\/www.kaspersky.com\/blog\/npm-packages-trojanized\/54280\/\" target=\"_blank\" rel=\"noopener nofollow\">\u00fcber 2,6\u00a0Milliarden Downloads pro Woche<\/a> verzeichnet\u00a0\u2013 und seitdem sind sie noch beliebter geworden.<\/p>\n<p>Die Nutzlast war ein Krypto-Stealer: Malware, die dazu dient, Transaktionen mit Kryptow\u00e4hrungen abzufangen und in die Wallets von Angreifern umzuleiten. Gl\u00fccklicherweise gelang es den Angreifern, trotz erfolgreicher Infektion einiger der weltweit beliebtesten Projekte, die letzte Phase ihrer Operation irgendwie zu vermasseln. Am Ende kassierten sie nur <a href=\"https:\/\/www.theregister.com\/2025\/09\/09\/npm_supply_chain_attack\/\" target=\"_blank\" rel=\"noopener nofollow\">mickrige 925\u00a0US-Dollar<\/a>.<\/p>\n<p>Nur eine Woche sp\u00e4ter ereignete sich ein weiterer wichtiger Vorfall: <a href=\"https:\/\/www.kaspersky.com\/blog\/tinycolor-shai-hulud-supply-chain-attack\/54315\/\" target=\"_blank\" rel=\"noopener nofollow\">Bei der ersten Welle der sich selbst verbreitenden Malware Shai-Hulud<\/a> wurden rund 150\u00a0npm-Pakete infiziert, darunter auch Projekte von CrowdStrike. Die zweite Welle, die einige Monate sp\u00e4ter folgte, erwies sich jedoch als viel destruktiver. Den Riesenwurm sehen wir uns weiter unten genauer an.<\/p>\n<h2>Oktober\u00a02025: GlassWorm infiziert das \u00d6kosystem von Visual Studio Code<\/h2>\n<p>Etwa einen Monat nach dem Shai-Hulud-Angriff betrat eine \u00e4hnliche, sich selbst verbreitende Malware die B\u00fchne: <a href=\"https:\/\/thehackernews.com\/2025\/10\/self-spreading-glassworm-infects-vs.html\" target=\"_blank\" rel=\"noopener nofollow\">GlassWorm<\/a>. Sie infizierte die Erweiterungen von Visual Studio Code sowohl in der Open VSX Registry als auch im Microsoft Extension Marketplace. Die Angreifer suchten nach Konten f\u00fcr GitHub, Git, npm und Open VSX sowie nach Krypto-Wallet-Schl\u00fcsseln.<\/p>\n<p>Die GlassWorm-Entwickler erfanden eine \u00e4u\u00dferst kreative Command-and-Control-Infrastruktur: Sie verwendeten ein Krypto-Wallet der Solana-Blockchain als prim\u00e4ren Kommandoserver, w\u00e4hrend Google Kalender als Backup-Kommunikationskanal diente.<\/p>\n<p>Um den Wurm weiterzuverbreiten, stahlen die Angreifer nicht nur Krypto-Wallets, sondern installierten auf den infizierten Ger\u00e4ten auch den RAT \u201eZombi\u201c und erhielten damit die vollst\u00e4ndige Kontrolle \u00fcber die kompromittierten Systeme.<\/p>\n<h2>November\u00a02025: IndonesianFoods-Kampagne und 150.000\u00a0Spam-Pakete bei npm<\/h2>\n<p>Im November gab es erneut <a href=\"https:\/\/www.kaspersky.com\/blog\/indonesianfoods-npm-spam-campaign\/55453\/\" target=\"_blank\" rel=\"noopener nofollow\">\u00c4rger<\/a> in der npm-Registry. Im Rahmen der koordinierten b\u00f6sartigen IndonesianFoods-Kampagne \u00fcberfluteten Angreifer die Registry mit Zehntausenden nutzloser Pakete.<\/p>\n<p>Hier war das Hauptziel, die Metriken des Systems aufzumischen, um Token auf tea.xyz zu erhalten. Diese Blockchain-Plattform dient dazu, Open-Source-Entwickler zu belohnen. Dazu bauten die Angreifer ein riesiges Netz voneinander abh\u00e4ngiger Projekte, deren Namen sich auf indonesische Gerichte beziehen. Zum Beispiel zul-<a href=\"https:\/\/en.wikipedia.org\/wiki\/Tapai\" target=\"_blank\" rel=\"noopener nofollow\">tapai<\/a>9-kyuki oder andi-<a href=\"https:\/\/de.wikipedia.org\/wiki\/Rendang\" target=\"_blank\" rel=\"noopener nofollow\">rendang<\/a>23-breki.<\/p>\n<p>Die Autoren dieser Kampagne k\u00fcmmerten sich nicht darum, Benutzerkonten zu kapern. Genau genommen enthielten die Spam-Container nicht einmal sch\u00e4dliche Nutzdaten. Es sei denn, man bezeichnet ein Skript als b\u00f6sartig, das alle sieben Sekunden automatisch neue Pakete generiert. Trotzdem diente der Vorfall als eindringliche Erinnerung daran, wie anf\u00e4llig die npm-Infrastruktur f\u00fcr massive Spam-Kampagnen ist.<\/p>\n<h2>Dezember\u00a02025: Shai-Hulud\u00a02.0 und Preisgabe von 400.000 Entwickler-Geheimnissen<\/h2>\n<p>Der absolute Superhit des Jahres\u00a0\u2013 nicht nur unter den Lieferkettenangriffen, sondern wahrscheinlich im gesamten Cybersicherheitsbereich\u00a0\u2013 war die sich selbst verbreitende Malware <a href=\"https:\/\/securelist.com\/shai-hulud-worm-infects-500-npm-packages-in-a-supply-chain-attack\/117547\/\" target=\"_blank\" rel=\"noopener\">Shai-Hulud<\/a> (alias Sha1-Hulud), die es auf Entwickler abgesehen hatte.<\/p>\n<p>Diese Malware war eine logische Weiterentwicklung des bereits erw\u00e4hnten s1ngularity-Angriffs: Auch sie durchsucht Systeme nach allen m\u00f6glichen Geheimnissen und ver\u00f6ffentlicht diese in offenen GitHub-Repositorys. Shai-Hulud f\u00fcgte dieser Basisfunktion jedoch einen Mechanismus zur Selbstvermehrung hinzu: Der Wurm infiziert Projekte, die von bereits kompromittierten Entwicklern verwaltet werden, und nutzt daf\u00fcr gestohlene Anmeldedaten.<\/p>\n<p>Die erste Welle von Shai-Hulud ereignete sich im September und infizierte mehrere hundert npm-Pakete. Gegen Ende des Jahres gab es eine zweite Welle namens <a href=\"https:\/\/securelist.com\/shai-hulud-2-0\/118214\/\" target=\"_blank\" rel=\"noopener\">Shai-Hulud\u00a02.0<\/a>.<\/p>\n<p>Dabei verf\u00fcgte der Wurm auch \u00fcber eine L\u00f6sch-Funktionalit\u00e4t. Wenn die Malware auf einem infizierten System keine g\u00fcltigen npm- oder GitHub-Token finden konnte, l\u00f6ste sie einen destruktiven Code aus, der die Benutzerdateien l\u00f6schte.<\/p>\n<p>Infolge des Angriffs flossen insgesamt <a href=\"https:\/\/www.bleepingcomputer.com\/news\/security\/shai-hulud-20-npm-malware-attack-exposed-up-to-400-000-dev-secrets\/\" target=\"_blank\" rel=\"noopener nofollow\">etwa 400.000 Geheimnisse<\/a> ab. Erw\u00e4hnenswert: Genau wie bei s1ngularity landeten all diese sensiblen Daten in \u00f6ffentlichen Repositorys, wo sie nicht nur von den Angreifern, sondern von beliebigen Personen heruntergeladen werden konnten. Und die Folgen dieses Angriffs werden sehr wahrscheinlich noch lange zu sp\u00fcren sein.<\/p>\n<p>Einer der ersten best\u00e4tigten Exploits, bei dem von Shai-Hulud preisgegebene Geheimnisse ausgenutzt wurden, war ein Krypto-Diebstahl, der mehrere Tausend Nutzer von Trust Wallet betraf. Die Angreifer nutzten diese Geheimnisse an Heiligabend, um eine b\u00f6sartige Version der Trust Wallet-Erweiterung mit integriertem <a href=\"https:\/\/www.kaspersky.de\/blog\/what-is-a-crypto-wallet-drainer\/30894\/\" target=\"_blank\" rel=\"noopener\">Crypto-Drainer<\/a> in den Chrome Web Store hochzuladen. Dabei erbeuteten sie Krypto im Wert von 8,5\u00a0Millionen US-Dollar.<\/p>\n<h2>Schutz vor Lieferkettenangriffen<\/h2>\n<p>Als wir <a href=\"https:\/\/www.kaspersky.com\/blog\/supply-chain-attacks-in-2024\/52965\/\" target=\"_blank\" rel=\"noopener nofollow\">eine \u00e4hnliche Retrospektive f\u00fcr\u00a02024<\/a> zusammenstellen, war es recht einfach, an der Struktur \u201eeine Bedrohung pro Monat\u201c festzuhalten. F\u00fcr\u00a02025 war dies wesentlich schwieriger. Im vergangenen Jahr gab es derart viele massive Lieferkettenangriffe, dass sie nicht alle in diese \u00dcbersicht passten.<\/p>\n<p>Und das Jahr\u00a02026 scheint \u00e4hnlich intensiv zu werden. Darum empfehlen wir dir unseren speziellen Artikel zum Thema <a href=\"https:\/\/www.kaspersky.com\/blog\/supply-chain-attacks-what-are-they-and-how-to-manage-the-risk\/52852\/\" target=\"_blank\" rel=\"noopener nofollow\">Verhinderung von Lieferkettenangriffen<\/a>. Hier schon einmal die wichtigsten Erkenntnisse:<\/p>\n<ul>\n<li>Bewerte deine Anbieter gr\u00fcndlich und pr\u00fcfe sorgf\u00e4ltig den Code, den du in deine Projekte integrierst.<\/li>\n<li>Implementiere strenge Sicherheitsanforderungen direkt in deine Vertr\u00e4ge.<\/li>\n<li>Erstelle einen umfassenden Reaktionsplan f\u00fcr Vorf\u00e4lle.<\/li>\n<li>\u00dcberwache deine Unternehmensinfrastruktur mithilfe einer <a href=\"https:\/\/www.kaspersky.de\/next?icid=de_kdailyplacehold_acq_ona_smm__onl_b2b_kdaily_prodmen_sm-team___knext___\" target=\"_blank\" rel=\"noopener\">XDR-L\u00f6sung<\/a>.<\/li>\n<li>Wenn dein internes Sicherheitsteam \u00fcberfordert ist, nutze einen <a href=\"https:\/\/www.kaspersky.de\/enterprise-security\/managed-detection-and-response?icid=de_kdailyplacehold_acq_ona_smm__onl_b2b_kasperskydaily_wpplaceholder_______\" target=\"_blank\" rel=\"noopener\">externen Service f\u00fcr proaktives Threat Hunting und rechtzeitige Reaktion<\/a>.<\/li>\n<\/ul>\n<p>Mehr Informationen \u00fcber Kettenreaktionen bei Lieferkettenangriffen findest du in unserer Analyse <a href=\"https:\/\/kas.pr\/k8rs\" target=\"_blank\" rel=\"noopener\">Supply chain reaction: securing the global digital ecosystem in an age of interdependence<\/a>. Sie basiert auf den Erkenntnissen von technischen Experten und zeigt auf, wie h\u00e4ufig Unternehmen mit Risiken in der Lieferkette und bei vertrauensw\u00fcrdigen Beziehungen konfrontiert sind, wo Sicherheitsl\u00fccken bestehen und welche Strategien zur Verbesserung der Widerstandsf\u00e4higkeit gegen diese Bedrohungsarten ratsam sind.<\/p>\n<input type=\"hidden\" class=\"category_for_banner\" value=\"kaspersky-next\">\n","protected":false},"excerpt":{"rendered":"<p>Lieferkettenangriffe geh\u00f6rten auch im Jahr 2025 zu den gravierendsten Bedrohungen f\u00fcr Unternehmen. Unser \u00dcberblick \u00fcber die bemerkenswertesten Vorf\u00e4lle des letzten Jahres.<\/p>\n","protected":false},"author":2726,"featured_media":33350,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1848,3107,3108],"tags":[31,1895,274,844,4270,963,3900,4269,3161,2183,1498,3353],"class_list":{"0":"post-33349","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-business","8":"category-enterprise","9":"category-smb","10":"tag-angriffe","11":"tag-backdoors","12":"tag-bedrohungen","13":"tag-business","14":"tag-devops","15":"tag-entwicklung","16":"tag-lieferkette","17":"tag-lieferkettenangriff","18":"tag-open-source","19":"tag-risiken","20":"tag-schwachstellen","21":"tag-stealer"},"hreflang":[{"hreflang":"de","url":"https:\/\/www.kaspersky.de\/blog\/supply-chain-attacks-in-2025\/33349\/"},{"hreflang":"es","url":"https:\/\/www.kaspersky.es\/blog\/supply-chain-attacks-in-2025\/31975\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/supply-chain-attacks-in-2025\/41594\/"},{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/supply-chain-attacks-in-2025\/55522\/"},{"hreflang":"ru-kz","url":"https:\/\/blog.kaspersky.kz\/supply-chain-attacks-in-2025\/30458\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/www.kaspersky.de\/blog\/tag\/lieferkettenangriff\/","name":"Lieferkettenangriff"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/posts\/33349","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/users\/2726"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/comments?post=33349"}],"version-history":[{"count":3,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/posts\/33349\/revisions"}],"predecessor-version":[{"id":33353,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/posts\/33349\/revisions\/33353"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/media\/33350"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/media?parent=33349"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/categories?post=33349"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/tags?post=33349"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}