26 PyPI-Pakete haben Cloud-Zugangsdaten gestohlen, noch bevor Ihr Code überhaupt ausgeführt wurde

Wichtigste Erkenntnisse

• Hades lieferte .pth-Start-Hooks aus, sodass die Payload bei jedem Start von Python ausgelöst wurde und nicht nur einmal bei der Installation.
• Derselbe Trick war bereits elf Wochen zuvor in LiteLLM integriert worden, daher war die Technik nicht neu.
• Wheels überspringen den Schritt der Quellcode-Kompilierung, können aber dennoch eine Datei ablegen, die bei jedem Start des Interpreters Code ausführt.
• Die Überprüfung der eigenen Umgebung erfordert nur eine Handvoll Befehle, und die meisten der dabei gefundenen .pth-Dateien sind legitim.

Ein Entwickler führt „pip install“ aus, der Befehl wird ordnungsgemäß beendet, und der CI-Job wird als erfolgreich angezeigt. Es wurde jedoch nichts kompiliert und kein Schritt zur Quellcode-Kompilierung ausgeführt, da das Paket als Wheel bereitgestellt wurde und Wheels eigentlich die sicherere Wahl sein sollten.

Dann wird der nächste Python-Prozess gestartet. Etwas liest die Datei ~/.aws/credentials ein.

So sieht in groben Zügen die „Hades“-Kampagne aus, die Orca Security am 8. Juni 2026 in 26 PyPI-Paketen. Socket zählt bei Betrachtung derselben 37 schädlichen Wheel-Dateien 19 Pakete, sodass die angegebene Zahl davon abhängt, welche Bestandsliste man heranzieht. So oder so umgeht der Code mehrere Kontrollmechanismen, die speziell zur Verhinderung der Codeausführung während der Installation entwickelt wurden – und zwar nicht durch Ausnutzung eines Fehlers, sondern durch Nutzung einer Funktion, die bereits in der Standardbibliothek vorhanden war, bevor die meisten dieser Kontrollmechanismen überhaupt existierten.

Die Struktur der „Hades“-Kampagne

Was dieses Beispiel von gewöhnlichem Typosquatting ist nicht irgendein einzelner Trick. Es ist die Kombination.

Es handelte sich hierbei nicht um gefälschte, ähnlich klingende Namen, die darauf warteten, dass jemand versehentlich eine Installation auslöste. Das Veröffentlichungsmuster deutet auf eine Übernahme des Betreuerkontos hin, gefolgt von einer Flut aufeinanderfolgender Patch-Veröffentlichungen im gesamten Portfolio dieses Betreuers, wobei der Schwerpunkt auf wissenschaftlichem Python, Bioinformatik und ML-Tools lag. Pakete, denen die Teams bereits vertrauten, lieferten plötzlich manipulierte neue Versionen aus.

Jede kompromittierte Version legte eine Datei mit der Endung *-setup.pth direkt im Verzeichnis „site-packages“ ab. Anstatt wie viele andere Infostealer nach Krypto-Wallets oder Browser-Cookies zu suchen, zielte die Payload auf Cloud-Anmeldedaten, Entwicklergeheimnisse und CI/CD- -Token. Der Startup-Hook ist nur die erste Stufe. Er lädt die Bun-JavaScript-Laufzeitumgebung von GitHub herunter und führt eine verschleierte JavaScript-Nutzlast namens _index.js aus. Ein Python-Startup-Hook, der eine JavaScript-Laufzeitumgebung initialisiert, um AWS-Schlüssel zu stehlen – das ist ein seltsamer Satz, aber eine treffende Beschreibung dessen, was tatsächlich passiert ist.

Einige Proben enthielten zudem einen persistenten Daemon namens „gh-token-monitor“, der mit zerstörerischen Maßnahmen droht, falls die gestohlenen Token gesperrt werden. Malware, die darauf ausgelegt ist, Sie für die korrekte Reaktion auf einen Vorfall zu bestrafen, ist so neuartig, dass man einen Moment darüber nachdenken muss.

Hades kam nicht aus dem Nichts. Es knüpft an den LiteLLM-Kompromiss vom März 2026 und der im Mai 2026 gemeldeten Kompromittierung des „durabletask“-Pakets, womit sich drei bemerkenswerte PyPI-Lieferkettenangriffe innerhalb eines Zeitraums von weniger als drei Monaten ereignet haben. Alle drei wurden mit derselben übergeordneten Kampagnenlinie in Verbindung gebracht, die unter Namen wie TeamPCP, Mini Shai-Hulud und Miasma verfolgt wird.

Diese LiteLLM-Zeile ist der heikle Teil. Der „Startup-Hook“-Trick war im Juni nichts Neues. Er wurde bereits im März in einem Paket ausgeliefert, das täglich Millionen von Downloads verzeichnete, und zwar in Form einer Datei namens „litellm_init.pth“. Elf Wochen später gelang es mit dieser Technik immer noch, bösartige Komponenten an den Kontrollen vorbeizuschleusen, die zur Absicherung der Ausführung während der Installation eingerichtet worden waren.

Warum eine .pth-Datei vor Ihrem Code ausgeführt wird

Hier ist der Mechanismus, und er ist auf eine Art beeindruckend, wie es hässliche Dinge manchmal eben sind.

Beim normalen Start verarbeitet das „site“-Modul von Python die .pth-Dateien, die es in den konfigurierten Site-Verzeichnissen findet. Offiziell dient dies dazu, Verzeichnisse zu „sys.path“ hinzuzufügen – jeweils eines pro Zeile. Es gibt jedoch noch ein zweites, weitaus weniger bekanntes Verhalten in diesem Modul: Jede Zeile, die mit „import“ beginnt und auf die ein Leerzeichen oder ein Tabulator folgt, wird als Python-Code ausgeführt.

Eine Zeile reicht also schon aus.

import os, base64; exec(base64.b64decode(‘…’))

Speichere das in einer Datei mit der Endung .pth im Verzeichnis „site-packages“ – es muss weder importiert noch aufgerufen werden. Es wird jedes Mal ausgeführt, wenn in dieser Umgebung ein Python-Prozess gestartet wird. Auf einem stark ausgelasteten CI-Runner oder einem Entwickler-Laptop geschieht das dutzende Male am Tag, und es wird bei pip, bei „python -c“ sowie bei allen Vorgängen ausgelöst, die der Sprachserver deines Editors im Hintergrund ausführt.

Wussten Sie schon: Dies ist weder ein Fehler noch ein raffinierter Exploit. Es handelt sich um ein dokumentiertes Verhalten im „site“-Modul von Python, das bereits Jahre vor der Einführung moderner Paketierungswerkzeuge existierte. MITRE erfasst es mittlerweile als benannte Angrifftechnik unter dem Namen „Python Startup Hooks“, Subtechnik T1546.018 unter der Kategorie „Event Triggered Execution“.

Setuptools verwendet für einige anpassbare Installationen .pth-Dateien, und coverage.py kann denselben Mechanismus nutzen, um coverage automatisch in Unterprozessen zu starten. Genau deshalb eignet es sich so gut als Angriffsvektor. Ein Scanner, der versucht, eine bösartige .pth-Datei zu identifizieren, muss diese irgendwie von der Datei „distutils-precedence.pth“ unterscheiden, die im Lieferumfang von setuptools enthalten ist und aus völlig legitimen Gründen strukturell dasselbe tut.

Warum „Wheels“ eigentlich das sichere Format sein sollte

Seit Jahren lautet die gängige Empfehlung, Wheels gegenüber Quelldistributionen den Vorzug zu geben, und die Begründung dafür ist durchaus stichhaltig. Die Installation eines sdist bedeutet in der Regel, dass es zunächst kompiliert werden muss, und bei diesem Kompilierungsvorgang wird paketgesteuerter Code über ein PEP-517-Backend ausgeführt – was, wie man es auch dreht und wendet, nichts anderes ist als die Ausführung von beliebigem Code. Ein Wheel ist bereits kompiliert, sodass die Installation im Wesentlichen aus dem Entpacken und Ablegen der Dateien besteht.

Dieser Ratschlag ist nach wie vor sinnvoll, und diese Vorgehensweise hat ohnehin funktioniert. Ein Wheel kann eine .pth-Datei enthalten, und beim Entpacken eines Wheels wird jede .pth-Datei auf oberster Ebene direkt in den Ordner „site-packages“ kopiert.

Die Ausführung erfolgt lediglich mit einer Verzögerung.

Schauen Sie sich die „wheel“-Zeile an. Eine Überprüfung während der Installation, die die Umgebung untersucht und nichts findet, ist keine Fehlfunktion. Zum Zeitpunkt der Installation ist noch kein schädlicher Code ausgeführt worden. Die Payload wartet und wird beim nächsten Python-Aufruf ausgelöst, was bei einem Container-Build möglicherweise erst dann geschieht, wenn das Image bereits gepusht wurde und Datenverkehr verarbeitet.

Achtung: Sandboxing bei der Installation und eine „Wheels-only“-Richtlinie sind beides nützliche Kontrollmaßnahmen, doch keine von beiden allein verhindert, dass ein bösartiger .pth-Hook später ausgeführt wird, wenn Python außerhalb dieser Sandbox gestartet wird. Wenn Ihr Bedrohungsmodell davon ausgegangen ist, dass diese beiden Maßnahmen die Ausführung von beliebigem Code abdecken, sollten Sie diese Annahme noch einmal überprüfen.

Eine der wirksamsten Kontrollmaßnahmen findet statt, noch bevor das Artefakt überhaupt in die Umgebung gelangt. Das bedeutet, dass der tatsächliche Inhalt eines Pakets überprüft und verifiziert wird, anstatt sich darauf zu verlassen, dass das Verhalten bei der Installation dies meldet. Eine Möglichkeit, dies zu erreichen, besteht darin, Pakete aus dem Quellcode neu zu kompilieren und zu prüfen, was dabei herauskommt.

Wonach die Nutzlast suchte

Vor allem Cloud-Anmeldedaten. Und der Suchraum ist viel kleiner und vorhersehbarer, als die meisten Teams annehmen, da ein Entwicklerrechner oder CI-Runner wertvolle Geheimnisse in der Regel über eine kurze Liste bekannter Speicherorte preisgibt. Die Anmeldedaten und Konfigurationsdateien unter ~/.aws. Die Standard-Anmeldedaten für Anwendungen unter ~/.config/gcloud. Die kubeconfig unter ~/.kube/config. Die Registry-Authentifizierung in ~/.docker/config.json. Alle Umgebungsvariablen, die die CI-Plattform einfügt. Und auf Cloud-Hosts der Instanz-Metadatendienst unter 169.254.169.254. Der Hades-Bericht führt zudem GitHub-, npm-, PyPI- und RubyGems-Token sowie SSH-Schlüssel ganz oben in der Liste auf – und genau so wird aus einem Anmeldedaten-Stealer ein Programm, das sich von selbst verbreitet.

Sofern er erreichbar ist, ist der Metadatendienst der eigentliche Gewinn. Er ist es, der einen kompromittierten Laptop dazu nutzen kann, einen viel größeren Teil der umgebenden Cloud-Umgebung zu kompromittieren. Auf einem Build-Agenten mit einer zugewiesenen IAM-Rolle kann eine Payload, die echte Codeausführung statt nur SSRF ermöglicht, temporäre Anmeldedaten für alles abrufen, wozu diese Rolle berechtigt ist – sei es ein einfacher GET-Aufruf bei älteren IMDSv1-Konfigurationen oder ein PUT- und anschließender GET-Token-Austausch, wenn IMDSv2 erzwungen wird. In beiden Fällen muss nichts auf der Festplatte vorhanden sein.

Das ist die strategische Logik hinter dem Ganzen. Zugangsdaten, die aus einer Build-Umgebung entnommen werden, sind wertvoller als solche, die vom Laptop einer Person abgegriffen werden, und CI-Runner werden in der Regel weniger direkt von Menschen überwacht als Arbeitsstationen, obwohl sie ungewöhnlich wertvolle Geheimnisse enthalten.

Der Abschnitt über KI-Scanner

In mehreren Berichten zu Hades wurde eine indirekte Prompt-Injektion innerhalb der Pakete festgestellt, wobei der Text speziell darauf ausgelegt war, die KI-gestützte Sicherheitsüberprüfung zu manipulieren und nicht dazu, den Menschen zu täuschen, der den Pull-Request liest.

Das ist eine bemerkenswerte neue Entwicklung, die als Taktik nur dann Sinn ergibt, wenn Angreifer nun davon ausgehen, dass sich zwischen dem Paket und dem Entwickler ein LLM befindet. Mitte 2026 ist das keine schlechte Annahme. Einige Teams verfügen bereits über ein Modell, das die Unterschiede bei den Abhängigkeiten zusammenfasst, bevor ein Mensch sich überhaupt damit befasst.

Das führt zu einem heiklen Problem. Ein Modell, das den Inhalt eines nicht vertrauenswürdigen Pakets ausliest, verarbeitet per Definition von einem Angreifer kontrollierte Eingaben. Es muss genauso behandelt werden wie jeder andere nicht vertrauenswürdige Eingabepfad. Was es jedoch keinesfalls übernehmen darf, ist die Rolle eines unabhängigen Richters, der darüber entscheidet, ob das gerade Ausgelesene sicher ist. Dieses Urteil als maßgeblich anzusehen, ist eine als Kontrollmechanismus getarnte zirkuläre Abhängigkeit.

Expertentipp: Wenn ein Modell irgendwo in Ihrer Pipeline den Inhalt von Abhängigkeiten überprüft, behandeln Sie das Paket als nicht vertrauenswürdige Eingabe und halten Sie dessen Text aus dem Anweisungskontext des Prüfers heraus. Kombinieren Sie dies mit deterministischen statischen Prüfungen und lassen Sie das Urteil des Modells nicht als einziges Entscheidungskriterium gelten.

So führen Sie sofort eine Überprüfung Ihrer Umgebung durch

Das lohnt sich unabhängig davon, ob Sie glauben, betroffen zu sein oder nicht, und es handelt sich eher um ein paar Befehle als um ein großes Projekt. Wenn Sie schnell wissen möchten, ob Sie betroffen sind: Die Listen der betroffenen Pakete sind in den Berichten zu Orca und Socket veröffentlicht, und einen Vergleich dieser Listen mit Ihren Lockfiles ist besser als zu raten.

Suchen Sie zunächst die Website-Verzeichnisse, die tatsächlich verarbeitet werden. Das ist wichtig, da auch das benutzerspezifische Verzeichnis „site-packages“ berücksichtigt wird und eine Liste, die nur systemweite Verzeichnisse enthält, dieses Verzeichnis unbemerkt übersieht.

python -m site

Suchen Sie anschließend unter Linux oder macOS nach .pth-Dateien, die Zeilen mit ausführbaren Befehlen enthalten. Unter Windows müssen Sie ebenfalls die „site-packages“-Verzeichnisse Ihrer Python-Installationen und virtuellen Umgebungen durchsuchen.

find / -path „*site-packages*“ -name „*.pth“ \

  -exec grep -lE “^import[[:space:]]” {} \; 2>/dev/null

Diese Leerzeichenklasse ist wichtig, da „site“ nur Zeilen ausführt, in denen auf „import“ ein Leerzeichen oder ein Tabulator folgt, und ein bloßes „^import“ problemlos mit einer völlig harmlosen Zeile übereinstimmt, die mit „importlib“ beginnt. Wenn Sie schon dabei sind: Der Hades-spezifische Durchlauf sucht nach allem, was mit „*-setup.pth“ übereinstimmt, und auch „sitecustomize.py“ sowie „usercustomize.py“ sollten Sie sich ansehen, da sie zur selben Familie von Start-Hooks gehören. Berichten zufolge haben einige Hades-Beispiele Code in „__init__.py“ eingefügt, anstatt überhaupt eine .pth-Datei mitzuliefern; daher ist eine ausschließlich auf .pth-Dateien beschränkte Überprüfung kein garantierter Beweis für die Fehlerfreiheit.

Sie werden Treffer erhalten, und das ist normal. Rechnen Sie mit „distutils-precedence.pth“ aus setuptools, „__editable__*.pth“ aus editierbaren Installationen und vielleicht ein oder zwei aus wissenschaftlichen Bibliotheken. Lesen Sie sie trotzdem durch. Legitime .pth-Dateien enthalten in der Regel Pfadeinträge oder kleine Import-Hooks, die von namentlich bekannten Tools generiert wurden. Kodierte Blobs, exec()-Aufrufe, das Starten von Unterprozessen oder alles, was auf das Netzwerk zugreift, sollten jedoch genauer unter die Lupe genommen werden, auch wenn kein einzelnes Muster beweist, dass eine Datei in irgendeiner Weise bösartig ist.

Um herauszufinden, ob die Seitenverarbeitung für ein bestimmtes Verhalten verantwortlich ist, das Sie untersuchen möchten, starten Sie den Interpreter mit deaktivierter Seitenverarbeitung.

python -S -c „print(‚Verarbeitung der Website übersprungen‘)“

Wenn das Verhalten unter der Option -S nicht mehr auftritt, deutet dies auf die Initialisierung der Website hin, und die .pth-Hooks sind ein Ansatzpunkt für die Untersuchung. Das grenzt die Suche ein. Es beweist jedoch nicht, welcher Startmechanismus dafür verantwortlich war, da die Option -S weit mehr als nur die Ausführung von .pth-Dateien deaktiviert.

Die Überprüfung eines Rades, bevor es den Boden berührt, erfolgt über zwei Befehle.

pip download –no-deps somepackage

unzip -l somepackage-*.whl | grep ‘\.pth’

Ein Wheel, das eine .pth-Datei enthält, ist nicht automatisch bösartig, und eine .pth-Datei führt nicht automatisch irgendetwas aus, da nur Zeilen ausgeführt werden, die mit „import“ und einem Leerzeichen beginnen. Ein Wheel, das eine solche Datei enthält, sollte jedoch genauer unter die Lupe genommen werden, und falls darin eine ausführbare „import“-Zeile enthalten ist, sollte dies lieber vorab besprochen werden, bevor es in Ihre Lockfile-Datei gelangt, und nicht erst danach.

Falls Sie doch etwas finden, entfernen Sie das Paket und leeren Sie anschließend den Wheel-Cache, denn ein „vergiftetes“ Wheel, das sich im Cache von pip oder uv befindet, wird sich beim nächsten Aufruf dieser Version problemlos selbst neu installieren. Führen Sie anschließend eine Rotation aller Elemente durch, auf die die Umgebung Zugriff hat. Cloud-Schlüssel, GitHub-, PyPI- und npm-Token, SSH-Schlüssel, kubeconfigs. In den Orca-Leitlinien zu Hades werden das Entfernen von Paketen und die Rotation von Anmeldedaten als obligatorisch und nicht als optional behandelt, und das ist die richtige Herangehensweise.

Warum „pip install“ nicht der richtige Ausgangspunkt ist, um Vertrauen zu setzen

LiteLLM, durabletask und Hades unterscheiden sich zwar in den Details, doch das zugrunde liegende Muster ist identisch. Bei keinem dieser Fälle war eine Sicherheitslücke in der Anwendung erforderlich, die das Paket nutzte. In jedem Fall wurde ein Teil der Paketierungspipeline ausgenutzt, den das System von Haus aus als vertrauenswürdig einstuft – sei es ein kompromittierter Release-Prozess bei LiteLLM, ein gestohlenes Veröffentlichungstoken bei durabletask oder missbrauchte Veröffentlichungsidentitäten in Verbindung mit einem dokumentierten Start-Hook bei Hades.

Eine Sache, die dieses Muster ausschließt, ist das „Hash-Pinning“. Die bösartige Datei „litellm_init.pth“ wurde im RECORD des Wheels korrekt mit einem passenden Hash deklariert, sodass „pip install –require-hashes“ problemlos durchgegangen wäre. Hashes belegen, dass das heruntergeladene Artefakt mit dem von Ihnen genehmigten Artefakt übereinstimmt. Sie beweisen jedoch nicht, dass das genehmigte Artefakt harmlos war oder dass sein Herausgeber nicht kompromittiert worden war.

In der Praxis hängt die Antwort davon ab, in welchem Umfang Sie Python einsetzen.

Eine Handvoll Dienste? Überprüfen Sie Ihre .pth-Dateien und legen Sie für brandneue Versionen eine kurze Quarantänephase fest, bevor Sie diese übernehmen, denn diese Kampagnen erzielten einen Großteil ihrer anfänglichen Reichweite durch neu veröffentlichte schädliche Versionen, bevor die Verteidiger Zeit hatten, zu reagieren.

Sie setzen Python in einer großen Umgebungsflotte ein? Das Audit ist ein guter Ausgangspunkt, doch der sinnvollere architektonische Ansatz besteht darin, die Paketprüfung vor die Installation zu verlagern, damit bösartige Artefakte gar nicht erst in den „site-packages“-Ordner gelangen können.

Und falls Ihre CI-Runner Zugangsdaten für Cloud-Rollen enthalten, sollten Sie dort ansetzen. Beschränken Sie den Geltungsbereich dieser Rollen auf ein Minimum, entfernen Sie statische Zugangsdaten mit langer Gültigkeitsdauer und verwenden Sie stattdessen kurzlebige Zugangsdaten, wo immer die Plattform dies zulässt – denn genau dort liegt das größte Risiko, wenn eine fehlerhafte Installation zu einem Vorfall führt.

Sicherung der Python-Lieferkette

Diese Vorverlagerung der Überprüfung ist die Grundidee hinter SecureChain für Python. Pakete werden aus dem Quellcode neu kompiliert und geprüft, bevor sie überhaupt in Ihre Umgebung gelangen – anstatt erst gescannt zu werden, wenn sie bereits bei jedem Interpreter-Start ausgeführt werden. Und der Schutz endet auch nicht am Tag der Installation.

Neue CVEs werden für Pakete bekannt gegeben, die Sie bereits ausführen, und irgendwann zieht sich ein Betreuer komplett zurück. SecureChain sorgt weiterhin für Patches für die tatsächlich in Ihrem Stack vorhandenen Komponenten, und für Pakete im Katalog wird diese Unterstützung auch nach das Ende der Lebensdauer fortgesetzt, anstatt Sie vor die Wahl zwischen einer ungepatchten Abhängigkeit und einer erzwungenen Neuprogrammierung zu stellen. Wenn derzeit eine „Wheels-only“-Richtlinie oder ein Scan nach der Installation als Verteidigungslinie dient, ist Hades ein guter Anlass, um zu überprüfen, wo diese Verteidigungslinie tatsächlich verläuft – bei der Installation und jeden Tag danach.

FAQ

Was ist PyPI-Malware?

Schädlicher Code, der im Python Package Indexveröffentlicht, meist versteckt in einem Paket, das sich als legitimes Paket ausgibt, oder in einem legitimen Paket, dessen Herausgeberkonto kompromittiert wurde. Er wird oft bereits während der Installation oder beim Start des Interpreters ausgeführt, anstatt darauf zu warten, dass Ihr Anwendungscode ihn aufruft.

Was ist eine .pth-Datei und warum ist sie gefährlich?

Eine .pth-Datei, die sich in einem der Site-Verzeichnisse von Python befindet, wird beim Start vom Site-Modul verarbeitet. Zeilen, die mit „import“ beginnen und auf das „import“ ein Leerzeichen oder ein Tab folgt, werden ausgeführt. Das bedeutet, dass eine .pth-Datei bei jedem einzelnen Start des Python-Prozesses beliebigen Code ausführen kann. Dies ist ein dokumentiertes, beabsichtigtes Verhalten, und sowohl setuptools als auch „editable installs“ nutzen es rechtmäßig – genau das macht böswillige Dateien so schwer zu erkennen.

Schützen „Wheels“ vor schädlichen Python-Paketen?

Nur teilweise. Wheels umgehen den Build-Schritt aus dem Quellcode, den die Installation eines sdist erfordert, und dieser Build-Schritt kann paketsteuerbaren Code ausführen. Sie verhindern jedoch nicht, dass ein Paket eine .pth-Datei mit einer ausführbaren Import-Zeile enthält, die bei jedem Start des Interpreters ausgeführt wird.

Wie kann ich überprüfen, ob ein Paket einen Start-Hook installiert hat?

Durchsuche die Site-Verzeichnisse, die Python tatsächlich für .pth-Dateien verwendet, nach Zeilen, die mit „import“ beginnen und auf die ein Leerzeichen folgt, und lies diese dann ordnungsgemäß ein. Das Starten des Interpreters mit der Option -S deaktiviert die automatische Site-Initialisierung, einschließlich der Verarbeitung von .pth-Dateien. Dies hilft dabei festzustellen, ob das Startverhalten eine Rolle spielt, ohne jedoch zu beweisen, welcher Mechanismus dafür verantwortlich ist.

Wird das von pip-audit oder einem Scanner erkannt?

Das hängt vom jeweiligen Tool ab. Auf Empfehlungen basierende Scanner stützen sich auf ihre zugrunde liegenden Feeds für Sicherheitslücken und schädliche Pakete, sodass eine neu veröffentlichte schädliche Version möglicherweise nicht sofort erkannt wird. Verhaltens- und artefaktbasierte Tools erkennen solche Probleme manchmal schneller, wobei die Abdeckung je nach Anbieter sehr unterschiedlich ist.

Zusammenfassung

Artikel Name

Malware auf PyPI und wie die „Hades Startup Hook“-Kampagne funktionierte

Beschreibung

Hades hat mithilfe von .pth-Start-Hooks PyPI-Malware in 26 Paketen versteckt. Erfahren Sie, wie die Schadlast noch vor der Ausführung Ihres Codes ausgeführt wurde und wie Sie Ihre eigene Umgebung überprüfen können.

Autor

Artem Karasev

Name des Herausgebers

TuxCare

Logo des Herausgebers