Schadcode in Terraform-Providern: erstmals über die HashiCorp-Registry verteilt
Sicherheitsforscher haben Go-basierte Malware in zwei Terraform-Providern und zwei Go-Modulen gefunden. Laut Bericht nutzen Angreifer damit erstmals die zentrale HashiCorp-Registry als Verteilweg. Betroffen sind nur wenige hundert Downloads, doch Terraform-Provider laufen mit den Rechten der CI-Pipeline und damit nah an Cloud-Zugangsdaten.
Wer Terraform im Unternehmen einsetzt, sollte heute einmal in die eigenen Lockfiles schauen. Sicherheitsforscher haben Go-basierte Schadsoftware entdeckt, die über zwei Terraform-Provider und zwei Go-Module verteilt wurde. Laut dem Bericht ist es das erste Mal, dass Angreifer die zentrale, von HashiCorp betriebene Registry als Verteilweg für Schadcode nutzen. Betroffen sind konkret die Provider gocommunity-io/dockerd und kreuzwenker/docker sowie die Module gocommunity.io/orderedbtree und gogets.dev/btreex.
Wahrscheinlich nicht betroffen ist, wer Terraform gar nicht einsetzt oder ausschließlich offizielle und verifizierte Provider aus bekannten Namespaces wie hashicorp/ bezieht. Die Downloadzahlen sind klein: 222 beziehungsweise 1.449 Abrufe. Das ist kein Massenvorfall, sondern ein Präzedenzfall. Ein sofortiger Notfall-Einsatz ist damit für die meisten Umgebungen nicht nötig, eine einmalige Bestandsprüfung der Lockfiles aber schon, und zwar bevor dieser Verteilweg größer wird.
Was ist passiert?
Das Sicherheitsunternehmen Aikido hat Go-basierte Malware beschrieben, die über zwei Go-Module und zwei Terraform-Provider ausgeliefert wurde. Neu daran ist nicht die Schadsoftware selbst, sondern der Kanal: Die zentrale HashiCorp-Registry, aus der Terraform bei terraform init seine Provider bezieht, diente hier erstmals als Vertriebsweg.
Die verteilte Malware zeigt Überschneidungen mit der Kampagne Graphalgo. Diese hatte ReversingLabs erstmals im Februar 2026 dokumentiert und nordkoreanischen Akteuren (DPRK) zugeordnet. Das Vorgehen der Kampagne folgt einem bekannten Muster: Entwickler werden über soziale Plattformen wie LinkedIn und Facebook oder über Jobangebote in Foren angesprochen, wobei sich die Angreifer als nicht existierende Web3-Unternehmen ausgeben. Die Opfer sollen anschließend eine Programmieraufgabe erledigen und bekommen dazu ein harmlos wirkendes GitHub-Repository, das die Schadfunktion über eine auf npm oder PyPI veröffentlichte Abhängigkeit einschleust.
Zeitgleich wurde eine neue Gruppe bösartiger npm-Pakete identifiziert, die dieselbe Malware ausliefert. Als betroffen markiert wurden unter anderem indexed-btree, mathsbase, mathmain, math-universe, modern-events, quick-events und crypto-hasher. Diese Liste stammt von Checkmarx, JFrog und SafeDep. Der Vorfall ist also kein isolierter Terraform-Fall, sondern die Ausweitung einer laufenden Kampagne auf ein weiteres Ökosystem.
Wer ist betroffen?
Relevant ist der Vorfall für alle Teams, die Infrastruktur als Code mit Terraform oder OpenTofu verwalten und dabei Provider aus der öffentlichen Registry ziehen, sowie für Go-Entwicklerteams, die Module aus fremden Namespaces einbinden. Besonders genau hinsehen sollten Organisationen, in denen Terraform in einer CI-Pipeline oder auf einem Admin-Arbeitsplatz mit hinterlegten Cloud-Zugangsdaten läuft.
- Umgebungen mit den Providern
gocommunity-io/dockerdoderkreuzwenker/dockerin einer.terraform.lock.hcl - Go-Projekte mit
gocommunity.io/orderedbtreeodergogets.dev/btreexingo.mododergo.sum - Entwicklerrechner, auf denen im Rahmen eines angeblichen Bewerbungsverfahrens fremder Code aus einem GitHub-Repository ausgeführt wurde
- Build-Runner, die Terraform ohne Netzwerk- oder Registry-Einschränkung ausführen
Wahrscheinlich nicht betroffen sind reine Windows- oder Microsoft-365-Umgebungen ohne Terraform, Teams die ausschließlich verifizierte Provider aus dem Namespace hashicorp/ nutzen, sowie Projekte mit einer gepflegten Allowlist erlaubter Quellen. Wer eine private Registry oder einen Provider-Mirror betreibt und daraus nur freigegebene Versionen spiegelt, ist über diesen Weg ebenfalls nicht erreichbar.
Wie kritisch ist das?
Die Breitenwirkung ist gering, die potenzielle Tiefe pro Treffer aber hoch. Das ergibt eine ungewöhnliche Risikolage: wenig Fälle, aber im Einzelfall direkt an sensiblen Zugangsdaten.
Der Grund liegt in der Funktionsweise von Terraform. Ein Provider ist keine passive Bibliothek, sondern eine ausführbare Datei, die bei terraform init heruntergeladen und bei terraform plan oder terraform apply mit den Rechten des ausführenden Kontos startet. Das ist typischerweise eine CI-Pipeline oder ein Admin-Arbeitsplatz, und dort liegen in aller Regel Cloud-Zugangsdaten in Reichweite: Umgebungsvariablen, Token-Dateien, Profile in der Konfiguration des jeweiligen Cloud-Anbieters. Das ist eine andere Qualität als ein bösartiges npm-Paket in einer Web-Anwendung.
Zur technischen Seite berichtet Aikido, die über Terraform-Provider und Go-Module verteilte Variante sei eine Go-Portierung, die sich Blockchain- und Slack-Infrastruktur mit der npm-Version teilt. Sie nutze zwei Befehlskanäle: einen Slack-Bot-Token und einen sogenannten Blockchain Dead Drop, also verschlüsselte Kommandos, die aus einem Smart Contract auf einem Testnetz abgerufen werden. Zunächst sammle die Malware Systeminformationen wie Hardwaremerkmale, Betriebssystem und Hostname und sende diese an einen vom Angreifer kontrollierten Slack-Kanal. Diese Angaben stammen aus dem Bericht der Forscher und sind nicht unabhängig bestätigt. Ebenfalls nicht abschließend geklärt ist, welche Befehle tatsächlich auf Opfersystemen ausgeführt wurden: SafeDep hält fest, dass zwar der Implantat-Code vorliegt, nicht aber der später nachgeladene Code.
Einordnend wichtig: Laut dem Bericht ist es nicht der erste Fall, in dem nordkoreanische Akteure Terraform für Schadcode nutzen. SentinelOne beschrieb bereits zuvor eine Aktivität mit der Bezeichnung TraderTraitor, die präparierte Terraform-Lockfiles und eigene, von den Angreifern kontrollierte Provider-Registries verwendete. Neu ist hier die Nutzung der zentralen öffentlichen Registry.
Was sollten Admins jetzt tun?
- Bestandsprüfung zuerst: Alle Repositories nach
.terraform.lock.hclundgo.sumdurchsuchen und diese Dateien gegen die vier Paketnamen prüfen:gocommunity-io/dockerd,kreuzwenker/docker,gocommunity.io/orderedbtree,gogets.dev/btreex. Ein einfacher rekursiver Suchlauf über alle Projektverzeichnisse reicht als Erstprüfung. - Bei einem Treffer die betroffene Pipeline anhalten, den Provider entfernen und das Ergebnis nicht einfach neu bauen, sondern den Runner als kompromittiert behandeln.
- Alle Zugangsdaten rotieren, die auf einem Treffer-System erreichbar waren: Cloud-Schlüssel, Terraform-Backend-Token, Registry-Token, Deploy-Keys. Ein reines Entfernen des Pakets reicht nicht.
- Die gemeldeten npm-Pakete in den eigenen JavaScript-Projekten gegenprüfen, insbesondere
indexed-btree,mathsbase,mathmain,math-universe,modern-events,quick-eventsundcrypto-hasher. - Provider-Quellen einschränken: nur verifizierte Namespaces zulassen, idealerweise über einen Provider-Mirror oder eine private Registry mit Freigabeprozess.
- Lockfiles verbindlich machen.
terraform initin der Pipeline mit gesperrtem Upgrade fahren, damit Versionen nicht unbemerkt wechseln, und Änderungen an Lockfiles im Code-Review sichtbar behandeln. - Ausgehenden Netzwerkverkehr der Build-Runner prüfen. Verbindungen zu Slack-APIs oder zu Blockchain-Endpunkten aus einem Terraform-Lauf heraus sind ein deutliches Warnsignal.
- Build-Runner mit minimalen Rechten betreiben: kurzlebige Anmeldeinformationen statt statischer Schlüssel, getrennte Rollen für Plan und Apply.
- Entwicklerteams kurz informieren, dass angebliche Bewerbungsaufgaben mit fremden Repositories der aktuelle Einstiegsweg dieser Kampagne sind. Fremden Code nur in einer Wegwerf-Umgebung ausführen, nie auf dem Arbeitsgerät mit Produktivzugängen.
- Terraform- und Go-Abhängigkeiten in die regelmäßige Abhängigkeitsprüfung aufnehmen, falls dort bisher nur Container-Images und npm abgedeckt waren.
Einordnung für Unternehmen
Für kleine und mittlere Unternehmen ist die praktische Botschaft nicht Panik, sondern Prozess. Viele Betriebe prüfen inzwischen Container-Images und npm-Abhängigkeiten, behandeln Terraform-Provider aber weiter als Infrastruktur-Werkzeug, dem man selbstverständlich vertraut. Genau diese Lücke nutzt der beschriebene Fall.
Der Aufwand für die Gegenmaßnahme ist überschaubar. Eine Liste der erlaubten Provider-Namespaces, ein fester Lockfile-Umgang und ein Runner ohne dauerhafte Cloud-Schlüssel kosten wenig und wirken unabhängig davon, welches Paket als nächstes auffällt. Wer heute nur die vier genannten Namen sucht, hat den Vorfall abgehakt, aber nichts geändert.
Ebenso wichtig ist die Personalseite. Der Einstiegsweg dieser Kampagne ist kein technischer Exploit, sondern ein Jobangebot. Eine kurze interne Regel, dass Bewerbungs- oder Testaufgaben mit fremdem Code nicht auf dem produktiven Arbeitsgerät laufen, ist billiger als jede Nachbereinigung eines kompromittierten Entwicklerrechners.
Passende Anleitungen auf S-EDV
- Gitleaks als Docker-Secret-Scanner einrichten hilft dabei, Zugangsdaten in Repositories und Pipelines aufzuspüren, bevor ein kompromittierter Build-Lauf sie abgreift.
- Docker-Images mit Trivy scannen und eine SBOM erzeugen zeigt, wie eine verbindliche Abhängigkeitsprüfung im Build aussieht.
- Supply-Chain-Angriff auf ein weit verbreitetes Rust-Paket ordnet ein, wie dieselbe Angriffsklasse in einem anderen Ökosystem aussieht.
