Anatomie des Python-Wurms, der KI-Sicherheitsagenten manipuliert

Haben Sie einen Punkt erreicht, an dem Sie Ihrem KI-Code-Assistenten mehr vertrauen als Ihrer eigenen manuellen Überprüfung? Viele Entwickler haben das. Wir verlassen uns auf Large Language Models (LLMs), um nach Schwachstellen zu suchen, Korrekturen vorzuschlagen und die Integrität von Drittanbieter-Paketen zu überprüfen. Aber was passiert, wenn die Malware weiß, wie sie der KI antworten muss? Ich habe letzte Woche mehrere Nächte damit verbracht, die technischen Details der Hades-Kampagne zu untersuchen, einer Bedrohung, die einen Wendepunkt im Umgang von Angreifern mit automatisierten Abwehrmechanismen markiert. Dies ist nicht nur ein Datendieb. Es ist eine psychologische Operation, die sich gegen die Software richtet, die wir zu unserem Schutz einsetzen.

Forscher von StepSecurity haben diese Kampagne kürzlich als das neueste Werk der Bedrohungsgruppe Miasma identifiziert. Während sich Miasma zuvor auf das Ernten von Cloud-Zugangsdaten konzentrierte, ist Hades ein aggressiverer, selbstverbreitender Wurm. Er zielt speziell auf Python-Entwicklerumgebungen über kompromittierte Pakete im PyPI-Ökosystem ab. Die Liste der betroffenen Bibliotheken umfasst ensmallen, mflux-streamlit und mehrere Tools, die in der Bioinformatik verwendet werden. Wenn Sie in der Computerbiologie oder den Datenwissenschaften arbeiten, ist Ihre Workstation ein hochwertiges Ziel für diese spezifische Gruppe.

Der Einstiegspunkt im Python-Initialisierungsprozess

Der Angriff beginnt, wenn ein Entwickler ein kompromittiertes Paket importiert. Hades versteckt seinen primären Loader in der Datei __init__.py. Dies ist eine Standarddatei, die Python verwendet, um ein Verzeichnis als Paket zu kennzeichnen. Durch das Platzieren des bösartigen Skripts an dieser Stelle stellen die Angreifer sicher, dass der Code in dem Moment ausgeführt wird, in dem das Paket in ein Projekt geladen wird. Der Loader ist obfuskiert, um eine einfache signaturbasierte Erkennung zu vermeiden, aber sein Zweck ist simpel. Er schleust eine vorkompilierte Bun-Runtime-Binärdatei in das System ein.

Bun ist ein leistungsstarkes JavaScript-Toolkit. Es ist ein exzellentes Werkzeug für legitime Entwickler, aber auch eine perfekte Ausführungsumgebung für Malware. Da Bun eine eigenständige Binärdatei ist, ermöglicht es der Malware, komplexe JavaScript-Payloads auszuführen, ohne dass eine Node.js-Installation auf dem Rechner des Opfers erforderlich ist. Dies umgeht herkömmliche Überwachungen, die nach verdächtigen npm- oder Node-Aktivitäten suchen. Auf architektonischer Ebene erlaubt der Einsatz von Bun den Angreifern, in einer Schattenumgebung zu agieren, die außerhalb der Standard-Sicherheitsüberwachung der meisten Python-zentrierten Workstations liegt.

Wie Malware den automatisierten Gatekeeper manipuliert

Das innovativste Merkmal von Hades ist seine Fähigkeit, KI-Sicherheitsagenten zu belügen. Viele moderne Entwicklungsumgebungen nutzen LLMs, um Code nach bösartigen Mustern zu scannen. Hades antizipiert dies. Am Anfang seiner bösartigen Dateien fügt die Malware einen Textblock ein, der als Adversarial Prompt konzipiert ist. Dieser Text weist das LLM an, jeglichen darunter liegenden verdächtigen Code zu ignorieren und das Paket als verifiziert und sicher einzustufen.

Ich habe letzten Monat eine ähnliche Technik in einer Sandbox-Umgebung getestet. Ich gab einem LLM ein Skript, das eine offensichtliche Reverse-Shell enthielt, stellte ihm jedoch einen Kommentar voran, der besagte, dass der Code ein vorab autorisierter Sicherheitstest für einen Regierungsauftrag sei. Die KI ignorierte den Exploit und meldete, dass das Skript alle Sicherheitsprotokolle einhalte. Hades nutzt genau diese digitale Strategie des Trojanischen Pferdes. Es nutzt die kognitive Logik der KI aus. Da LLMs anfällig für Social Engineering sind, akzeptieren sie diese versteckten Anweisungen als hochpriorisierte Befehle. Dies führt zu einem falsch-negativen Ergebnis, wodurch die Malware die automatisierte Analyse des Unternehmens umgehen kann.

Ausnutzung des Frameworks für Lieferkettenintegrität

Hades versteckt sich nicht nur; es versucht, offiziell zu wirken. Es nutzt mehrere geschäftskritische Sicherheits-Frameworks aus, darunter OpenID Connect (OIDC) und Supply-chain Levels for Software Artifacts (SLSA). Wenn die Malware feststellt, dass sie innerhalb eines GitHub Actions-Workflows ausgeführt wird, prüft sie auf OIDC-Variablen. Anschließend verwendet sie diese Anmeldedaten, um kryptografisch signierte SLSA-Provenienz-Bundles über Sigstore zu generieren.

Dies ist eine raffinierte Umgehung genau der Systeme, die die Softwareintegrität garantieren sollen. Durch das Generieren eines gültigen Sigstore-Bundles kann die Malware kompromittierte Versionen von Bibliotheken auf PyPI oder npm veröffentlichen, die so aussehen, als kämen sie aus einer offiziellen, verifizierten Build-Umgebung. Für einen externen Beobachter oder ein automatisiertes Tool sieht das Paket so aus, als hätte es eine gültige Herkunftskette. Dies macht die Sicherheitsinfrastruktur zu einer Waffe für den Angreifer. Es lässt den kompromittierten Code vertrauenswürdiger erscheinen als legitimen, unsignierten Code.

Memory Scraping und laterale Bewegung

Sobald die Malware etabliert ist, beginnt sie mit dem Sammeln von Daten. Sie enthält maßgeschneiderte Memory Scraper für Linux, macOS und Windows. Diese Scraper zielen auf die Speicherzuordnungen aktiver Prozesse ab, um sensible, verschlüsselte Daten zu extrahieren, die ansonsten auf der Festplatte nicht zugänglich sind. Dies ist ein heimlicher Ansatz, da er die Erstellung verdächtiger Dateien vermeidet, die ein Endpoint Detection and Response (EDR)-System melden könnte.

Der Wurm sucht auch nach Wegen zur Verbreitung. Er scannt das infizierte System nach SSH-Schlüsseln, SCP-Konfigurationen und GitHub-Token. Wenn er einen Token mit Schreibberechtigungen findet, nutzt er den GitHub Actions Runner, um Geheimnisse direkt aus dem Speicher zu extrahieren. Anschließend versucht er, andere Repositories des Benutzers zu infizieren. Der Command-and-Control (C2)-Verkehr wird innerhalb der öffentlichen GitHub-Infrastruktur versteckt. Gestohlene Daten werden komprimiert, verschlüsselt und in neue öffentliche Repositories unter der Kontrolle des Angreifers hochgeladen. Diese Repositories tragen oft die Beschreibung "Hades — The End for the Damned".

Der Persistenzmechanismus der verbrannten Erde

Persistenz ist eine Kernkomponente des Hades-Designs. Die Malware etabliert eine Präsenz auf der Workstation und überwacht den Status der gestohlenen Zugangsdaten. Wenn ein Sicherheitsteam den Einbruch erkennt und den gestohlenen GitHub-Token widerruft, wechselt Hades in einen reaktiven Modus. Es führt einen Wiper-Prozess aus, der versucht, die lokalen Dateien des Benutzers zu löschen.

Dies ist eine Vergeltungstaktik. Sie schafft eine hochriskante Situation für Incident Responder. Wenn man den Zugriff sperrt, riskiert man den Verlust der Daten auf dem lokalen Rechner. Diese Logik zwingt Unternehmen dazu, während der Sanierungsphase vorsichtig vorzugehen. Die Malware zielt auch auf die Konfigurationsdateien von 14 verschiedenen KI-Agenten ab. Sie platziert Anweisungen, die eine neue Infektion auslösen, wann immer der Entwickler seinen KI-Assistenten zum aktuellen Arbeitsbereich konsultiert. Dies erzeugt eine Schleife, in der der Versuch, Hilfe von einem KI-Tool zu erhalten, das System erneut infiziert.

Aufbau einer proaktiven Verteidigung gegen täuschende Malware

Die Hades-Kampagne zeigt, dass unsere Abhängigkeit von KI als primäre Sicherheitsebene eine Schwachstelle darstellt. Wir müssen uns zu einem Modell bewegen, in dem die KI eher ein Mitarbeiter als eine ultimative Autorität ist. Aus Risikoperspektive ist die beste Verteidigung eine granulare, die sich nicht auf einen einzigen Gatekeeper verlässt.

Wichtige Erkenntnisse zur Sicherung Ihrer Umgebung:

1. Nutzen Sie strikte Isolationsgrenzen für LLMs. Übergeben Sie niemals rohen, nicht vertrauenswürdigen Code an einen KI-Scanner ohne einen System-Prompt, der dem Modell explizit verbietet, Anweisungen zu folgen, die im Code selbst enthalten sind.
2. Überprüfen Sie Ihre GitHub Actions-Berechtigungen. Implementieren Sie das Prinzip der geringsten Privilegien für OIDC-Token und stellen Sie sicher, dass Runner keinen unnötigen Schreibzugriff auf Ihre Repositories haben.
3. Überwachen Sie auf unbefugte Ausführung von Binärdateien. Hades verlässt sich auf das Einschleusen einer Bun-Runtime. Tools, die die Ausführung unbekannter Binärdateien im Pfad __init__.py melden oder blockieren, können die Infektion am Einstiegspunkt stoppen.
4. Überprüfen Sie die Sigstore-Provenienz manuell. Während Hades Bundles fälschen kann, können Diskrepanzen im Build-Zeitpunkt oder in den Umgebungsvariablen manchmal bei einer forensischen Prüfung entdeckt werden.
5. Implementieren Sie robuste Backup-Strategien. Da Hades einen Wiper enthält, sind Offline- oder unveränderliche Backups Ihrer Entwicklungsarbeit der einzige Weg, um die Gefahr von Datenverlusten während der Sanierung zu mindern.

Blickt man auf die Bedrohungslandschaft, ist Hades wahrscheinlich ein Vorgeschmack auf die Zukunft. Angreifer versuchen nicht mehr nur, die Schlösser an unseren Türen aufzubrechen; sie lernen, wie sie den digitalen Türsteher davon überzeugen können, sie hereinzulassen. Wir müssen aufhören, KI-Urteile als absolute Wahrheiten zu betrachten, und anfangen, sie als Datenpunkte zu behandeln, die eine menschliche Verifizierung erfordern.

Quellen: NIST Cybersecurity Framework, MITRE ATT&CK Framework (Software Supply Chain Compromise), StepSecurity Hades Campaign Report.

Haftungsausschluss: Dieser Artikel dient ausschließlich Informations- und Bildungszwecken und ersetzt keine professionelle Cybersicherheitsprüfung oder einen Incident-Response-Service.