Microsofts Open-Source-Tools wurden gehackt und zum Diebstahl von Passwörtern von KI-Entwicklern missbraucht
(techcrunch.com)- Dutzende Open-Source-Projekte, die auf GitHub gehostet wurden, wurden von Hackern kompromittiert. Dabei wurde Passwort-stehlende Malware in den Code eingeschleust, woraufhin Microsoft den Zugriff auf die betroffenen Projekte blockierte und eine Untersuchung einleitete
- Viele der betroffenen Projekte stehen mit Tools in Verbindung, die beim Programmieren mit dem Cloud-Dienst Azure sowie KI-Entwickler-Apps wie Claude Code, Gemini CLI und VS Code verwendet werden
- Wenn Nutzer ein infiziertes Tool in einer KI-Coding-App öffnen, werden Passwörter und sensible Zugangsdaten entwendet
- Laut GitHub wurden mindestens 70 Projekte deaktiviert; Microsoft entfernte einige Repositories vorübergehend und stellte sie nach Prüfung wieder her
- Der Vorfall ist ein aktuelles Beispiel für einen Supply-Chain-Angriff auf populären Open-Source-Code. Berichten zufolge ist es bereits das zweite Mal innerhalb weniger Wochen, dass ein Open-Source-Projekt von Microsoft kompromittiert wurde
Überblick über den Vorfall und Microsofts Reaktion
- Microsoft untersucht derzeit, wie die Projekte kompromittiert wurden, nachdem Hinweise bestätigt wurden, dass Hacker Passwort-stehlende Malware in den Code eingeschleust haben. Deshalb wurde der Zugriff auf Dutzende Open-Source-Projekte auf GitHub blockiert
- Viele der betroffenen Projekte stehen im Zusammenhang mit Tools, die für die Entwicklung mit dem Cloud-Dienst Azure sowie mit KI-Entwickler-Apps wie Claude Code, Geminis Kommandozeilenoberfläche und VS Code genutzt werden
- Wie viele Personen die betroffenen Tools tatsächlich heruntergeladen haben, ließ sich zunächst nicht feststellen
- Microsoft bestätigte die Abschaltung der Repositories; zuerst berichtet hatte 404 Media
- Microsoft-Sprecher Ben Hope: „Einige Repositories wurden vorübergehend entfernt, während potenziell schädliche Inhalte untersucht werden.“
- Einige Repositories wurden nach Prüfung wiederhergestellt, andere könnten während laufender Arbeiten offline bleiben
- Eine kleine Zahl von Kunden, die Inhalte aus den betroffenen Repositories heruntergeladen haben könnten, wurde benachrichtigt. Falls zusätzlicher Handlungsbedarf festgestellt wird, will Microsoft sie über die bestehenden Support-Kanäle direkt kontaktieren
- Auf Nachfrage von TechCrunch nannte Microsoft zunächst keine konkrete Zahl betroffener Kunden
Funktionsweise der Malware
- Das Sicherheitsunternehmen Cloudsmith und die Community-basierte Malware-Analyse-Website OpenSourceMalware gehörten zu den ersten, die auf den Hack hinwiesen
- Die Malware ist darauf ausgelegt, Passwörter und andere sensible Zugangsdaten zu stehlen, wenn Nutzer die infizierten Tools in KI-Coding-Apps öffnen
- Beim Aufruf der Projektseiten auf GitHub, der Microsoft-eigenen Code-Hosting-Plattform, wurden mindestens 70 Projekte als „deaktiviert“ angezeigt
- Angezeigte Meldung: „Der Zugriff auf dieses Repository wurde von GitHub-Mitarbeitern aufgrund eines Verstoßes gegen die GitHub-Nutzungsbedingungen deaktiviert.“
Einordnung als Supply-Chain-Angriff
- Der Vorfall ist der jüngste in einer Reihe von Fällen der vergangenen Monate, bei denen weit verbreitete Open-Source-Projekte kompromittiert wurden, um Malware bei vielen Nutzern zu platzieren, die den betreffenden Code installieren
- Solche Angriffe werden als „Supply-Chain“-Angriffe bezeichnet und zielen auf Code, der in vielen Softwareprodukten verwendet wird oder von bestimmten Nutzergruppen eingesetzt wird
- Solche Ziele können für Hacker attraktiv sein, weil sie Zugriff auf Cloud-Systeme und große Mengen an Kundendaten haben können
- Dass einzelne Entwickler von Open-Source-Projekten ins Visier geraten, ist nicht ungewöhnlich; teils ist dies Teil langfristiger Versuche, das Vertrauen der Entwickler zu gewinnen
- Ungewöhnlich ist jedoch, dass ein großer Technologiekonzern wie Microsoft kompromittiert wird, obwohl er über Ressourcen zur Abwehr solcher Angriffe verfügt
Hinweise auf wiederholte Kompromittierung
- Laut Ars Technica ist dies der zweite bekannte Fall innerhalb der vergangenen Wochen, in dem ein Microsoft-Open-Source-Projekt kompromittiert wurde
- Mitte Mai erklärten Sicherheitsforscher, dass das Microsoft-Open-Source-Projekt Durable Task, das Entwicklern beim Erstellen von Apps hilft, gehackt worden zu sein scheint
- OpenSourceMalware bezeichnete den jüngsten Vorfall als „erneute Kompromittierung (re-compromise)“ des Durable-Task-Projekts
- Das deutet darauf hin, dass Microsoft die Hacker beim ersten Vorfall möglicherweise nicht vollständig entfernt hat oder dass es sich um einen völlig neuen, unabhängigen Einbruch handeln könnte
2 Kommentare
Könnte das vielleicht der Grund sein, warum ich weiterhin Anmeldeversuche für mein MS-Konto bekomme, selbst wenn ich das Passwort ändere?
Hacker-News-Kommentare
Das ist reine Spekulation und eine persönliche Beobachtung, aber das frühere RBAC-Modell war praktisch schon kaputt und wirkt jetzt völlig zerbrochen.
Coding-Assistenten und Engineers fassen gleichzeitig viele voneinander unabhängige Projekte an, und besonders dadurch, dass sie nun sogar Experimente machen, für die früher keine Zeit da war, ist das Supply-Chain-Risiko in Unternehmen meiner Meinung nach stark gestiegen.
Ich sage nicht, dass das direkt damit zusammenhängt, aber ich glaube, es hat Einfluss, und dass Entwickler und Manager vielerorts inzwischen dazu drängen, mit privaten Geräten irgendwie schnell AI-Coding zu betreiben, dürfte bald ebenfalls zum Problem werden.
Es fällt schwer zu glauben, dass es unter den jüngsten Supply-Chain-Vorfällen kein gemeinsames Muster gibt, und dass es Hackergruppen gibt, die sich auf solche Angriffe spezialisieren, liegt meiner Meinung nach daran, dass die Belohnung groß ist.
Das ist eine Fortsetzung der schon lange bestehenden fehlenden Sicherheit bei der Installation von Entwickler-Abhängigkeiten und des Shai-Halud-Wurms.
Hacker haben herausgefunden, dass es leicht ist, Entwickler dazu zu bringen, irgendetwas zu installieren, und dass Entwicklergeräte ideale Ziele sind, weil dort viele sensible Daten wie Zugangsdaten, Cloud-CLIs und MCP liegen.
Sicherheit wird ignoriert, Hauptsache man rennt als Erster aus der Gruppe los — es fühlt sich wie eine exakte Wiederholung des früheren IoT-Hypes an.
Am Ende kommt dann genau so etwas heraus.
Persönlich glaube ich, dass das Capability-basierte Sicherheitsmodell die Zukunft ist, auch wenn der Name etwas verwirrend ist.
Schon die Überschrift ist tendenziös formuliert, und der Text ist so geschrieben, als sei es die Schuld von Open Source.
Noch absurder wird es dadurch, dass die Verantwortung für den versuchten Supply-Chain-Angriff Microsoft zugeschoben wird.
Da steht:
Microsoft did not immediately provide the specific number of customers affected, when asked by TechCrunch.— aber TechCrunch erklärt nicht, dass Open Source nun einmal so funktioniert.Ich kritisiere Microsoft gern, wenn es Anlass gibt, aber in diesem Fall finde ich, dass Microsoft sichere und richtige Maßnahmen ergriffen hat.
Der Artikel stellt es so dar, als sei alles Microsofts Fehler und als sei es etwas Peinliches, den Umfang der Kompromittierung begrenzt zu haben.
Auch die Formulierung
steal passwords of AI developerslässt eine merkwürdige Doppeldeutigkeit offen: Sind damit „AI-Entwickler“ gemeint oder „Entwickler, die AI verwenden“?Auch die Erklärung des Supply-Chain-Angriffs beschreibt nicht dessen eigentliche Bedeutung, sondern nur das Ergebnis und warum die Angriffsfläche existiert, daher halte ich diese Berichterstattung für sehr schlecht.
Ich habe schon erlebt, dass über Dinge berichtet wurde, an denen ich direkt gearbeitet hatte, wobei für Suchmaschinenoptimierung Fakten frei erfunden wurden, und es gab keinen Weg, eine Korrektur durchzusetzen.
Microsoft hat strukturelle Sicherheitsprobleme, und dass GitHub Actions nicht ausreichend abgesichert waren und Merge Requests die CI/CD umgehen konnten, hat das begünstigt oder sichtbar gemacht.
Das ist ein Microsoft-Problem, das schon vor AI existierte, und darüber gibt es auch keine Debatte: https://www.cisa.gov/sites/default/files/2025-03/CSRBReviewO...
Im AI-Zeitalter hat sich dieses Problem endemisch verbreitet und wird nun als Waffe eingesetzt.
Was genau ist tatsächlich passiert, und wie sollte man das lesen?
Das scheinen relevante Beiträge zu sein
https://news.ycombinator.com/item?id=48418318 (The Blight Reaches Microsoft: 73 Repos Disabled in 105 Seconds)
https://news.ycombinator.com/item?id=48450543 (Miasma Worm Hits Microsoft Again: Azure Functions Action and 72 Other Repositories Disabled After Supply Chain Attack Targeting AI Coding Agents)
https://news.ycombinator.com/item?id=48416155
https://news.ycombinator.com/item?id=48416269 (Miasma Worm Targets AI Coding Agents via GitHub Repos)
Am Montag hat die Hades-Kampagne Unterstützung für Composer, Go und Pip hinzugefügt. Davor wurden nur NPM und AI-Assistant-Editoren unterstützt; Ruby war zwar auch dabei, aber es scheint heute kaum noch jemand Rubygems zu verwenden
Was selbst Microsoft übersieht, ist, dass dies der erste Wurm ist, der auf allen Plattformen des Code-Ökosystems läuft. Er läuft auf Entwickler-Hosts, Servern und CI/CD-Runnern und verbreitet sich in alle Repositories, auf die diese Systeme zugreifen können
Um diesen Wurm zu besiegen, müsste man alle Computer sowie AWS EC2, Google Cloud Platform, Azure und Kubernetes-Cluster gleichzeitig zu 100 % abschalten. Er verbreitet sich buchstäblich über die gesamte Infrastruktur hinweg
Wie bei APT28-Malware üblich, besteht der Kill Switch darin, die Host-Sprache auf
ru_RU.KOI8-Rzu setzen, also die UmgebungsvariableLANG. Dann wird der Verbreitungsmechanismus deaktiviertMitigation-Tool: https://github.com/cookiengineer/antimiasma
Blogbeitrag: https://cookie.engineer/weblog/articles/malware-insights-mia...
Ich vermute stark, dass es sich um einen Fall schlampiger Nutzung traditioneller Personal Access Tokens handelt
Wenn man Tokens an AI-Agenten auf irgendeinem seltsamen openclaw-Gerät weitergibt, sollte man fein granulare Tokens verwenden
Mein GitHub-Konto erstreckt sich über drei Organisationen mit völlig unterschiedlichen Richtlinien, und ich finde es immer noch etwas erstaunlich, dass klassische Tokens weiterhin erlaubt sind
Zumindest sollte man sie für jede Organisation manuell freigeben müssen
Ein für menschliche Konten „geprägtes“ Access Token an AI-Agenten weiterzugeben, fühlt sich an wie das neue „Passwort auf einen Post-it schreiben“
Es ist nicht leicht zu beurteilen, was für welche Aufgabe genau nötig und korrekt ist
Außerdem denken viele Softwareentwickler, dass es wichtiger ist, sich auf den Code statt auf Berechtigungen zu konzentrieren, und sehen Rechte oft als Verantwortung anderer
Berechtigungen auf Organisationsebene würden für meinen Zweck vermutlich völlig ausreichen
Gestern musste ich das Passwort meines persönlichen Microsoft-Kontos zurücksetzen, weil ich eine Zwei-Faktor-Authentifizierungs-Benachrichtigung wegen eines Anmeldeversuchs aus Rumänien bekommen habe
Ich habe keine Ahnung, wie man an das Passwort gekommen ist. Das einzige Microsoft-Produkt, das ich besitze, ist eine Xbox
Schon vor AI wirkte Microsoft auf mich undicht wie ein Sieb, und ich wünschte, mein Unternehmen könnte sich von Microsoft lösen, aber wir hängen bereits fest
Daher ist das Konto in der Praxis wahrscheinlich genau so eingerichtet, und die MFA-Anfrage, die du erhalten hast, war womöglich gar keine Zwei-Faktor-Authentifizierung, sondern einfach ein Versuch, auf das Konto zuzugreifen
Ich habe solche Anfragen auch mehrmals täglich bekommen und festgestellt, dass die Einrichtung der Microsoft-Authenticator-App auf dem Telefon bei aktivierter Sperre wie Gesicht, Fingerabdruck oder PIN zwangsweise auf passwortlos umstellt
Um das zu umgehen, muss man beim Einrichten des Kontos in der Authenticator-App all diese Sperren deaktivieren
Da ich mein Microsoft-Konto kaum nutze, authentifiziere ich mich inzwischen per separater E-Mail statt über den Authenticator
Dass das überhaupt so funktioniert, ist wahnsinnig, aber vermutlich erfüllt irgendjemand intern bei Microsoft damit KPIs für passwortlose Anmeldungen
Ich weiß allerdings nicht sicher, ob Microsoft das auch so macht
Ich wünschte, jemand würde erklären, wie man in so viele Repositories obfuskierte Dateien einschleusen kann. Gibt es überhaupt keine Code-Reviews?
Auch die Überschrift ist irreführend.
setupfügt Konfigurationen hinzu, die von den Leuten, die im Repository arbeiten, automatisch ausgeführt werden, und diese Leute müssen VSCode, Cursor, Claude oder Gemini verwenden.Wer Codex, opencode oder andere Execution-Harnesses nutzt, dürfte sicher sein.
Details: https://www.stepsecurity.io/blog/miasma-worm-hits-microsoft-...
Er arbeitet dort schon ziemlich lange, hat aber noch nie gesehen, wie das Projekt, für das er zuständig ist, tatsächlich aussieht; er hat das Repository geklont und kennt die verwendete Sprache, aber mehr auch nicht.
Alles wird gerade grob mit AI zusammengeklebt. Das Projekt ist das Authentifizierungs- und Autorisierungssystem für das gesamte Produkt des Unternehmens.
Laut ihm: „Ich drücke den ganzen Tag nur Tab und schreibe in Reviews ‚beabsichtigtes Verhalten‘. Die Reviews macht komplett AI, Menschen greifen nicht ein. CEO und CTO meinen das todernst und wollen, dass wir so arbeiten. Wenn etwas kaputtgeht, hat niemand je den eigentlichen Code gesehen, also weiß auch niemand, wie es funktioniert. Die Leistungsbewertung richtet sich nicht danach, was wir geschafft haben, sondern nach der Zahl der verwendeten Tokens.“
Es ist gut möglich, dass es derzeit in vielen Unternehmen so läuft, und es wäre nicht abwegig anzunehmen, dass es keine echten Code-Reviews gibt.
github-actionsgekennzeichnet.Das heißt, es wurde in die interne GitHub-CI/CD-Schiene authentifiziert, und solche Commits gibt es so viele, dass es für jedes Automatisierungstool schwer wäre, in einem Heuhaufen aus Spreu das Gift zu finden.
Deshalb hängt das mit der GitHub-Sicherheitsverletzung vom September 2025 zusammen.
„Die GitHub-Stars der fünf Repositories summieren sich auf 1.459, wovon allein mantine-datatable 1.225 ausmacht. Stars sind ein grober Proxy dafür, wie viele Entwickler den Quellcode lokal ausgecheckt haben, und genau diese Gruppe ist das Ziel des Angriffs.“
„Alle Commits waren unsigniert, hatten die Identität github-actions und hinterließen dieselbe Sechs-Dateien-Signatur mit Nachrichten wie
chore: update dependencies [skip ci]. Dass fünf Repositories in 49 Sekunden abgearbeitet wurden, war kein Mensch, sondern Automatisierung. Das passt zur Selbstverbreitung von Shai-Hulud, bei der nach dem Einsammeln von GitHub-Tokens mit Schreibrechten aus einer früheren Infektion ein Persistence-Payload in jedes Repository gepusht wird, das diese Tokens erreichen.“https://safedep.io/miasma-worm-ai-coding-agent-config-inject...
So funktioniert es tatsächlich: https://safedep.io/config-files-that-run-code/
Ich habe mit diesen Leuten nichts zu tun, aber das ist die einfachste und zugleich detaillierteste Erklärung, die ich bisher dazu gefunden habe, was hier gerade passiert.
Es ist eine kleine Firma, aber bei manchen Leuten wirkt der Drang, AI wie einem Orakel zu vertrauen, fast religiös.
Ich lese mehr als 90 % des von mir generierten Codes so, als würde ich den Code eines Junior-Entwicklers reviewen.
Ich betreibe gerade ziemlich intensiv Vibe Coding an einem neuen Feature, aber sobald GitHub-PRs wieder funktionieren, werde ich alles gründlich lesen.
Und solchen Leuten vertrauen wir die Root-CA-Zertifikate für Secure Boot an?
„Jeder der oben beschriebenen Mängel mag für sich genommen noch nachvollziehbar sein. In ihrer Gesamtheit weisen sie jedoch auf ein Versagen von Microsofts organisatorischen Kontrollen, Governance und Unternehmenskultur im Umgang mit Sicherheit hin.“
Microsofts Produkte und Services sind überall. Das Unternehmen ist eines der wichtigsten Technologieunternehmen der Welt, vielleicht sogar das wichtigste. Mit dieser Stellung geht Verantwortung auf höchstem globalem Niveau einher. Es braucht eine verantwortungsvolle, sicherheitsorientierte Unternehmenskultur, die beim CEO beginnt, damit Finanz- oder Go-to-Market-Faktoren die Cybersicherheit und den Schutz von Microsoft-Kunden nicht untergraben.
„Leider hat der Ausschuss im Verlauf dieser Prüfung eine Reihe operativer und strategischer Entscheidungen festgestellt, die auf eine Unternehmenskultur bei Microsoft hindeuten, in der sowohl Investitionen in die Unternehmenssicherheit als auch rigoroses Risikomanagement niedrige Priorität hatten. Diese Entscheidungen haben weltweit erhebliche Kosten und Schäden für Microsoft-Kunden verursacht.“
„Der Ausschuss ist überzeugt, dass Microsoft seine Sicherheitskultur in Ordnung bringen muss.“
[0] https://www.cisa.gov/resources-tools/resources/CSRB-Review-S...
Wie auch immer, es steht dir frei, das Microsoft-Zertifikat zu entfernen und dein eigenes zu registrieren.
Auch dieser Vorfall setzt nur die Vorgeschichte fort, in der Microsoft weniger ein Unternehmen war, das sich um Sicherheit kümmert, sondern eher selbst ein Sicherheitsproblem.
Sie haben in den letzten 40 Jahren immer wieder gezeigt, dass es ihnen egal ist.
Vielleicht habe ich es erst spät erkannt, aber ich sage schon seit Längerem: Auch wenn man KI aus Gründen wie „der Code ist schlecht“ nicht einsetzen will, sollte man zumindest für Sicherheitsaudits den Einsatz von KI in Betracht ziehen.
Zumindest sollte man Tools verwenden, die Code auf Schwachstellen scannen.
Der Angriffsvektor umfasst nicht nur Plugins, die Daten stehlen, sondern auch 0-Day-Schwachstellen in fast jeder eingesetzten Software sowie Script-Kiddies mit LLMs, die eure Webdienste angreifen.
Hacking wird zunehmen und schlimmer werden, daher sollte man jede Organisation überdenken, die nicht in Cybersicherheitsaudits und Audit-Tools investiert.
Niemand sollte auf dem eigenen Rechner einfach
npm installoderpip installausführen.Wenn man konsequent geeignetes Sandboxing (https://github.com/ashishb/amazing-sandbox) nutzt, kann man den Schadensumfang solcher Angriffe stark begrenzen.
Ich habe den Code überflogen, konnte aber nichts finden, das das bestätigen würde.
npm installoderpip installnicht auf dem eigenen Rechner ausführen soll: Welche Alternative wird dann vorgeschlagen?Bedeutet das, dass man sie nicht außerhalb einer Sandbox installieren sollte?
Entwicklung in einer Sandbox ist gut, aber der nächste Schritt ist das Deployment in Produktion.
Wie erkennt man, ob innerhalb der Sandbox bösartiges Verhalten stattgefunden hat, damit man diese Malware nicht weiter ausrollt?
Es ist viel zu komisch, dass Microsofts Github den Zugriff von Microsoft Azure und allen anderen Nutzern auf Microsofts Codebasis wegen eines Verstoßes gegen die Nutzungsbedingungen ausgesetzt hat.
Das vermittelt die Organisationsstruktur auf sehr anschauliche Weise: https://www.businessinsider.com/big-tech-org-charts-2011-6