Bösartige Veröffentlichung des elementary-data-PyPI-Pakets stiehlt Cloud-Zugangsdaten von Data Engineers

Ein Python-Paket namens elementary-data auf PyPI, das über eine Million Downloads pro Monat verzeichnet, war Ziel eines Supply-Chain-Angriffs über einen Angriffsvektor in GitHub Actions.

Kurzfassung

Was ist elementary-data?

elementary-data ist ein dbt-natives CLI-Tool zur Datenbeobachtung, das Data- und Analytics-Engineers verwenden, um den Zustand von Pipelines zu überwachen, Anomalien zu erkennen und fehlgeschlagene Tests in Data Warehouses wie Snowflake, BigQuery, Redshift und Databricks nachzuverfolgen. Das Paket verzeichnet rund 280.000 Downloads pro Woche und über 1,1 Millionen pro Monat und gehört damit zu den weit verbreiteten Data-Tools.

Das Paket lässt sich in die meisten großen Cloud-Datenplattformen integrieren. Genau das machte es zu einem attraktiven Ziel. Ein Tool, das zur Laufzeit von CI/CD regelmäßig Verbindungen zu Snowflake, BigQuery und AWS herstellt, kommt mit vielen wertvollen Zugangsdaten in Berührung.

Der Ablauf des Angriffs

Die Kompromittierung erfolgte in zwei Phasen: Zunächst wurde die Veröffentlichungspipeline kompromittiert, anschließend wurden bösartige Inhalte veröffentlicht, die weitere Zugangsdaten stehlen. Bei diesem Sicherheitsvorfall, der die Kompromittierung des Pakets elementary-data betraf, handelt es sich um einen der prominentesten Angriffsvektoren, die TeamPCP und andere Bedrohungsakteure in jüngster Zeit ausgenutzt haben.

Phase 1: Skriptinjektion in GitHub Actions

Am 24. April 2026 um 22:10 UTC veröffentlichte ein Angreifer mit einem zwei Tage alten GitHub-Konto (realtungtungtungsahur) einen präparierten Kommentar zu PR #2147 im elementary-data-Repository. Der Kommentar nutzte eine Sicherheitslücke durch Skriptinjektion in .github/workflows/update_pylon_issue.yml aus, einem Workflow zur Verarbeitung von Issue- und PR-Kommentaren.

Der anfällige run:-Block setzte ${{ github.event.comment.body }} direkt in ein Shell-Skript ein, bevor die Bash-Analyse erfolgte. Da dieser Ausdruck zum Zeitpunkt der Workflow-Vorlagenverarbeitung erweitert und nicht als Zeichenfolgenargument bereinigt wird, können über den Kommentartext Shell-Metazeichen oder Unterbefehle eingeschleust werden, die eine beliebige Codeausführung im Runner ermöglichen. Als der Workflow ausgelöst wurde, lief die Nutzlast des Angreifers mit dem GITHUB_TOKEN des Repositorys im Gültigkeitsbereich.

Entscheidend ist, dass der Angreifer keinen direkten Schreibzugriff auf das Repository benötigte. Der im Runner verfügbare GITHUB_TOKEN hatte ausreichende Berechtigungen, um Commits zu erstellen, Tags zu pushen und andere Workflows auszulösen. Der injizierte handle_comment-Job blieb zwei Stunden und sechsundvierzig Minuten aktiv. So hatte der Angreifer ausreichend Zeit, die einzelnen nachfolgenden Phasen vorzubereiten.

Mit dem gestohlenen Token fälschte der Angreifer einen Release-Commit mit dem Hash b1e4b1f3aad0d489ab0e9208031c67402bbb8480. Der Commit war so gestaltet, dass er automatisiert und offiziell wirkte: Er war ein verwaister Commit (von keinem Branch aus erreichbar), wurde als github-actions[bot] verfasst, trug eine gefälschte PGP-Signatur mit dem Status „Verified“ und verwendete die Commit-Nachricht release/v0.23.2 (#2188) – wortgetreu kopiert aus einem legitimen PR, der neun Tage zuvor zusammengeführt worden war. Der Angreifer versah diesen verwaisten Commit mit dem Tag v0.23.3 und löste anschließend den eigenen Release package-Workflow des Repositorys mit tag=v0.23.3 als Eingabe aus. Der Checkout-Schritt dieses Workflows verwendete ref: ${{ inputs.tag || github.ref }}, sodass direkt aus dem bösartigen verwaisten Commit erstellt wurde, ohne master anzutasten. Die legitime CI/CD-Pipeline paketierte und veröffentlichte den bösartigen Code. Um 22:20 UTC war elementary-data==0.23.3 auf PyPI verfügbar. Vier Minuten später folgte ein kompromittiertes Docker-Image (ghcr.io/elementary-data/elementary:0.23.3 und :latest, Digest sha256:31ecc5939de6d24cf60c50d4ca26cf7a8c322db82a8ce4bd122ebd89cf634255).

Dieser Angriffsvektor ist im PyPI-Ökosystem wiederholt aufgetreten. Beim Supply-Chain-Angriff auf Ultralytics im Dezember 2024 wurde dasselbe Injektionsmuster mit pull_request_target verwendet, um Zugangsdaten zu stehlen und vier bösartige Versionen zu veröffentlichen. Die Kompromittierung von LiteLLM Anfang 2026 nahm einen etwas anderen Weg (eine manipulierte GitHub-Action eines Drittanbieters), führte aber zum selben Ergebnis: Gestohlene PyPI-Tokens wurden zur Veröffentlichung eines Pakets verwendet, das Zugangsdaten stiehlt.

Phase 2: Das bösartige Paket

Der Angreifer bettete die bösartige Nutzlast in eine Datei namens elementary.pth ein, die sich im site-packages-Verzeichnis des Pakets befand.

.pth-Dateien sind Python-Pfadkonfigurationsdateien, die site.py, das Startmodul von Python, beim Start des Interpreters automatisch verarbeitet. Jede Zeile in einer .pth-Datei, die mit import beginnt, wird beim Start des Interpreters als Python-Code ausgeführt, bevor Ihr eigener Code läuft. Das bedeutet, dass die Malware bei jedem Start von Python auf dem betroffenen System aktiviert wird, auch bei Vorgängen wie pip install – nicht nur, wenn ein Nutzer ausdrücklich elementary importiert.

Diese Technik kam auch bei der Kompromittierung von LiteLLM v1.82.8 zum Einsatz. Sie ist dauerhafter und schwieriger zu erkennen als das Einbetten von bösartigem Code in __init__.py, da das manipulierte Paket nicht importiert werden muss. Die Installation allein reicht aus.

Ein Blick in die Nutzlast: Was die Malware tat

Der eingebettete Code in elementary.pth war ein Zugangsdaten-Stealer mit dreistufiger Verschlüsselung: einem äußeren Base64-Wrapper, einer anschließenden XOR-Verschlüsselung mit einem MD5-Keystream als Schlüssel (Seed: swabag) und einer zweiten XOR-Entschlüsselung. Gemessen an heutigen Malware-Standards ist die Verschleierung nicht besonders ausgefeilt, aber gezielt eingesetzt: Sie erschwert die einfache Erkennung anhand von Zeichenfolgen und erhöht den Zeitaufwand, um zu analysieren, was das Paket tatsächlich tut.

Sobald Python auf einem betroffenen Rechner gestartet wurde, führte die dekodierte Nutzlast Folgendes aus:

1. Zugangsdaten und Geheimnisse gesammelt und dabei das Dateisystem nach einer breiten Palette von Informationen durchsucht:

• dbt-Profile (~/.dbt/profiles.yml) und Zugangsdaten für Data Warehouses (Snowflake, BigQuery, Redshift, Databricks).

• Cloud-Anbieter-Zugangsdaten: AWS-~/.aws/credentials sowie aktive Rollen-Zugangsdaten, die über den IMDSv2-Metadatenendpunkt abgerufen wurden, mit direkt signierten SigV4-Aufrufen an AWS Secrets Manager und SSM Parameter Store; GCP-application_default_credentials.json; Azure-~/.azure/-Verzeichnisse.

• Private SSH-Schlüssel (id_rsa, id_ed25519, ~/.git-credentials).

• Container- und Orchestrierungsgeheimnisse: ~/.docker/config.json, ~/.kube/config, alle /etc/kubernetes/*.conf -Dateien sowie Kubernetes-ServiceAccount-Tokens.

• Zugangsdaten von Paketmanagern: ~/.npmrc, ~/.pypirc, ~/.cargo/credentials.toml.

• Weitere gespeicherte Geheimnisse: .env*-Dateien (Suche bis zu sechs Verzeichnisebenen tief), ~/.vault-token, ~/.netrc, ~/.pgpass, ~/.my.cnf, API-Tokens in Umgebungsvariablen.

• Kryptowährungs-Wallet-Dateien (Bitcoin, Litecoin, Dogecoin, Zcash, Dash, Monero, Ripple, Ethereum, Cardano, Solana-Validator-Schlüsselpaare).

• Systemdateien: /etc/passwd, /etc/shadow, Shell-Verlaufsdateien, /var/log/auth.log.

2. Alle gesammelten Informationen gebündelt und in einem Archiv namens trin.tar.gz abgelegt. Anschließend wurde es über curl --data-binary an den C2-Server igotnofriendsonlineorirl-imgonnakmslmao.skyhanni.cloud exfiltriert. Dazu wurde der HTTP-Header X-Rise-To-The-Trinny: agree verwendet.

3. Eine Markierungsdatei hinterlassen: $TMPDIR/.trinny-security-update (Linux/macOS) oder %TEMP%\.trinny-security-update (Windows). Sie zeigt an, dass die Malware mindestens einmal ausgeführt wurde.

Der Umfang der betroffenen Zugangsdaten geht weit über dbt und Data Warehouses hinaus. Die Nutzlast ist darauf ausgelegt, alle auf dem Rechner erreichbaren Geheimnisse zu erfassen – darunter Kubernetes-Cluster, Geheimnisverwaltungen für Infrastruktur und Kryptowährungsschlüssel. Die gezielte Suche nach dbt- und Data-Warehouse-Daten macht den Vorfall für die Nutzer des Tools besonders relevant. Doch jeder, der das Tool auf einem Entwicklerrechner oder CI-Runner ausführt, riskiert deutlich mehr.

Das Profil der gestohlenen Zugangsdaten passt genau zu den typischen Nutzern des Tools. Data Engineers, die die elementary-data-CLI ausführen, verwenden sie mit hoher Wahrscheinlichkeit für ein verbundenes Data Warehouse und verfügen über Cloud-Anbieter-Zugangsdaten – häufig in einer CI/CD-Umgebung, in der diese als Secrets oder Umgebungsvariablen gespeichert sind. Dies ist ein gezielter Angriff, kein wahlloser Massenangriff.

Auswirkungen und Umfang

Der Angriffszeitraum begann am 24. April um 22:20 UTC, als das Paket auf PyPI erschien, und endete mit seiner Entfernung am 25. April zwischen 8:51 und 11:51 UTC. Community-Mitglieder hatten das Problem um 6:18 UTC gemeldet. Die Exposition dauerte somit etwa acht bis zehn Stunden.

Alle, auf die eine der folgenden Aussagen zutrifft, sollten davon ausgehen, dass die Malware ausgeführt und ihre Zugangsdaten exfiltriert wurden:

• Sie haben in diesem Zeitraum pip install elementary-data ausgeführt oder ein Upgrade vorgenommen,

• Sie haben zwischen dem 24. April, 22:24 UTC, und der Entfernung ein Docker-Image aus der elementary-data-Registry abgerufen,

• oder Ihre CI/CD-Pipeline hat automatisch die neueste Version abgerufen.

Elementary Cloud und das Elementary-dbt-Paket waren nicht betroffen. Auch keine anderen CLI-Versionen enthielten den bösartigen Code.

Erkennung: Sind Sie betroffen?

Schritt 1: Installierte Version prüfen

pip show elementary-data

Wenn die Ausgabe Version: 0.23.3 anzeigt, war Ihre Umgebung gefährdet.

Schritt 2: Nach der Ausführungsmarkierung suchen

Bei der Ausführung schreibt die Malware eine Markierungsdatei:

# Linux / macOS (checks $TMPDIR, which defaults to /tmp if unset)
ls -la "${TMPDIR:-/tmp}/.trinny-security-update"

# Windows (PowerShell)
Test-Path "$env:TEMP\.trinny-security-update"

Wenn diese Datei vorhanden ist, wurde der Code zum Diebstahl von Zugangsdaten in dieser Umgebung ausgeführt. Fehlt die Datei, bedeutet das nicht unbedingt, dass Ihre Umgebung sicher ist: Die Malware hat die Markierung möglicherweise nicht bei jedem Ausführungspfad geschrieben, oder das temporäre Verzeichnis wurde geleert.

Schritt 3: Mit Snyk überprüfen

So überprüfen Sie Ihre Python-Abhängigkeiten auf dieses und andere bekannte bösartige oder verwundbare Pakete:

# Scan your project dependencies
snyk test --file=requirements.txt

# Or for pip-based environments
pip freeze > requirements_check.txt && snyk test --file=requirements_check.txt

Die Schwachstellendatenbank von Snyk enthält SNYK-PYTHON-ELEMENTARYDATA-16316110 und meldet alle Umgebungen, die noch auf 0.23.3 festgelegt sind.

Hinweis: Wir empfehlen Ihnen, unser Spickzettel zu bewährten Sicherheitspraktiken für Python und unseren Beitrag zu bewährten Methoden für die Containerisierung von Python-Anwendungen mit Docker zu lesen, um sichere Entwicklungspraktiken umzusetzen.

Abhilfe

1. Sofort aktualisieren

pip install --upgrade elementary-data

Version 0.23.4 wurde am 25. April 2026 veröffentlicht und enthält keinen bösartigen Code.

Wenn Sie eine requirements.txt- oder pyproject.toml-Datei verwenden, aktualisieren Sie die festgelegte Version:

elementary-data>=0.23.4

2. Alle möglicherweise offengelegten Zugangsdaten erneuern

Betrachten Sie alle Zugangsdaten, auf die Python-Prozesse auf betroffenen Rechnern zugreifen konnten, als kompromittiert. Insbesondere:

• dbt-Profile: Erneuern Sie Warehouse-Passwörter und OAuth-Tokens in ~/.dbt/profiles.yml.

• Cloud-Anbieterschlüssel: Erneuern oder widerrufen Sie AWS-IAM-Schlüssel (und prüfen Sie Secrets Manager und SSM Parameter Store auf abgerufene Werte), GCP-Service-Account-Schlüssel und Azure-Service-Principals.

• Kubernetes: Erneuern Sie ServiceAccount-Tokens und überprüfen Sie alle zugänglichen Dateien unter /etc/kubernetes/*.conf.

• Container-Registries: Erneuern Sie die in ~/.docker/config.json gespeicherten Zugangsdaten.

• Paketmanager-Tokens: Rotieren Sie die Tokens in ~/.npmrc, ~/.pypirc und ~/.cargo/credentials.toml.

• Secrets-Manager: Rotieren Sie HashiCorp-Vault-Tokens (~/.vault-token) sowie alle Zugangsdaten in .netrc, .pgpass oder .my.cnf.

• SSH-Schlüssel: Falls private Schlüssel auf dem Computer vorhanden waren, sollten Sie davon ausgehen, dass sie offengelegt wurden, und sie rotieren.

• CI/CD-Secrets: War der betroffene Computer ein CI-Runner, rotieren Sie alle in dieser Umgebung gespeicherten Secrets.

Allein das Rotieren reicht nicht aus. Prüfen Sie die Zugriffsprotokolle auf die Exfiltrationsdomain igotnofriendsonlineorirl-imgonnakmslmao.skyhanni.cloud sowie auf die Protokolle Ihrer Dienste, um bereits erfolgte unbefugte Zugriffe zu erkennen.

3. Python-Caches leeren

# Remove any cached .pth files or bytecode
pip cache purge

# Find and remove any elementary.pth artifacts
find / -name "elementary.pth" 2>/dev/null

4. Saubere Docker-Images herunterladen

Das kompromittierte Image (ghcr.io/elementary-data/elementary:0.23.3 und :latest) hatte den Digest sha256:31ecc5939de6d24cf60c50d4ca26cf7a8c322db82a8ce4bd122ebd89cf634255. Das letzte bekanntermaßen saubere Image ist 0.23.2 mit dem Digest sha256:b3bbfafde1a0db3a4d47e70eb0eb2ca19daef4a19410154a71abee567b35d3d9. Laden Sie ein sauberes Image herunter, das nach dem 25. April 2026 erstellt wurde:

docker pull ghcr.io/elementary-data/elementary:latest

Vergewissern Sie sich, dass Sie keine zwischengespeicherte Kopie des kompromittierten Images ausführen:

docker images ghcr.io/elementary-data/elementary --digests

5. GitHub-Actions-Workflows prüfen

Wenn Sie Python-Pakete betreuen, sollten Sie diesen Vorfall zum Anlass nehmen, alle Workflows zu überprüfen, die Issue- oder PR-Kommentarereignisse verarbeiten. Suchen Sie gezielt nach nicht in Anführungszeichen gesetzten Kontextausdrücken, die direkt in run:-Blöcke interpoliert werden:

# Vulnerable: ${{ github.event.comment.body }} expands before bash parses the command
- run: echo "Comment: ${{ github.event.comment.body }}"

# Safe: pass untrusted input through an environment variable
- run: echo "Comment: $COMMENT_BODY"
  env:
    COMMENT_BODY: ${{ github.event.comment.body }}

Snyks Beitrag zu Schwachstellen in GitHub Actions und die Analyse des TJ-Actions-Kompromittierungsfalls behandeln die allgemeinen Muster, auf die Sie achten sollten.

Neben der Bereinigung von Eingaben ist es nachhaltiger, langlebige PyPI-API-Tokens vollständig aus den Workflow-Secrets zu entfernen. PyPI unterstützt Trusted Publishers, die kurzlebige OIDC-Tokens verwenden, die auf einen bestimmten Workflow in einem bestimmten Repository beschränkt sind – diese Tokens lassen sich nicht exfiltrieren und wiederverwenden. Die Angreifer hinter elementary-data benötigten ein langlebiges Secret zum Veröffentlichen; Trusted Publishers beseitigen diese Angriffsfläche. Sichern Sie privilegierte Release-Workflows außerdem durch manuelle Freigaben ab, bei denen ein Mensch bestätigen muss, bevor der Veröffentlichungsschritt ausgeführt wird.

Ein wiederkehrendes Muster

Dieser Angriff folgt einem inzwischen vertrauten Muster: Eine Schwachstelle in der GitHub-Actions-Konfiguration eines Projekts finden, Code einschleusen, der das PyPI-Veröffentlichungs-Token stiehlt, mit diesem Token eine schädliche Version veröffentlichen und eine .pth-Datei oder einen ähnlichen Startmechanismus einbetten, um möglichst viele Systeme zu erreichen.

Dasselbe Muster zeigte sich beim Ultralytics-Angriff (Dezember 2024, Einschleusung über den pull_request_target-Branch, Kryptowährungs-Miner), beim LiteLLM-Angriff (Anfang 2026, manipulierte Trivy-Action, Zugangsdaten-Diebstahl mit dauerhaftem Backdoor) und beim Cline/Clinejection-Vorfall (KI-gestützte Prompt-Injection in Actions, gestohlene Tokens).

Dieses Muster ist nicht neu. Die Methoden zu seiner Ausnutzung sind gut bekannt und werden offenbar aktiv und wiederholt eingesetzt. Für Paketbetreuer hat die Absicherung von Workflows Priorität: Beschränken Sie den Einsatz von the use of pull_request_target, verlangen Sie manuelle Freigaben für Release-Workflows, verwenden Sie kurzlebige OIDC-Tokens für PyPI-Veröffentlichungen anstelle langlebiger API-Tokens und implementieren Sie Branch-Protection-Regeln, um unbefugte Release-Auslöser zu verhindern.

Für Nutzer von elementary-data reagierte das Elementary-Team schnell: Von der Meldung aus der Community bis zu den ersten Gegenmaßnahmen vergingen weniger als vier Stunden, und das Team veröffentlichte einen vollständigen Vorfallsbericht. Dieses schnelle Reaktionstempo ist neben dem Vorfall selbst bemerkenswert.