The discovery of malicious Terraform providers distributed through the HashiCorp Registry highlights an important expansion in software supply-chain attacks.

Security researchers at Aikido identified malware embedded in two Terraform providers and two Go modules:

  • gocommunity-io/dockerd
  • kreuzwenker/docker
  • gocommunity.io/orderedbtree
  • gogets.dev/btreex

The Terraform providers had already accumulated hundreds and, in one case, more than a thousand downloads before being identified.

The malware shares infrastructure and technical characteristics with the Graphalgo campaign, which has previously been associated by researchers with North Korea-linked threat activity.

The significance is not simply that another malicious dependency has appeared.

This is one of the first publicly documented cases of malware being distributed directly through Terraform providers hosted on HashiCorp's centralized registry.

That introduces a new attack surface into environments where developers and infrastructure teams routinely execute third-party code with access to highly privileged credentials.

Why Terraform providers are particularly attractive targets

Terraform is widely used to create and manage:

  • cloud infrastructure;
  • virtual machines;
  • Kubernetes clusters;
  • networking;
  • storage;
  • IAM policies;
  • databases; and
  • security controls.

Terraform providers are plugins that interact directly with those services.

To perform their legitimate functions, they frequently operate in environments containing credentials for:

  • AWS;
  • Azure;
  • Google Cloud;
  • Kubernetes;
  • GitHub;
  • infrastructure APIs; and
  • internal platforms.

That makes a Terraform execution environment extremely valuable to an attacker.

A malicious npm package running on a developer laptop may steal local credentials.

A malicious Terraform provider may execute in a context that already possesses permission to modify production infrastructure.

That is a significantly more interesting position for an attacker.

The malware is written in Go and is cross-platform by nature

Aikido found that the malicious payload embedded in the Terraform providers is implemented in Go.

The code overlaps strongly with malware previously distributed through npm packages as part of the Graphalgo campaign.

The Terraform variant shares:

  • blockchain-based command infrastructure;
  • Slack-based communication;
  • cryptographic mechanisms; and
  • attacker-controlled public keys

with recent JavaScript samples linked to the same activity.

This suggests the operators are not abandoning earlier techniques.

They are porting the same attack architecture into additional developer ecosystems.

That adaptability is important.

Attackers do not care whether developers prefer JavaScript, Python, Go, or Terraform.

They follow the environments where valuable credentials and trusted execution opportunities exist.

The malware gathers information about the victim first

When executed, the Go malware collects information about the infected environment.

The collected data includes:

  • hardware characteristics;
  • operating system;
  • hostname; and
  • whether Node.js is installed.

This information is sent to an attacker-controlled Slack channel.

The reconnaissance allows the operator to understand the compromised environment before issuing further instructions.

That also suggests the campaign is not simply interested in indiscriminately infecting every system that downloads the package.

The attacker appears interested in identifying useful targets and determining what capabilities are available on each host.

Slack is used as one command-and-control channel

The malware uses a Slack bot token as one of its communication paths.

It periodically queries Slack's:

conversations.history

API endpoint for messages.

The malware then interprets messages using packet types that control file transfer.

Researchers identified packet types representing:

  • the beginning of a transfer;
  • chunks of file content; and
  • the end of a transfer.

This allows the attacker to deliver additional content to an infected machine through legitimate Slack infrastructure.

Abusing legitimate SaaS platforms for command-and-control offers several advantages.

Connections to Slack are common in enterprise environments.

Defenders cannot simply block the service globally without potentially disrupting normal business communication.

This makes C2 detection more dependent on which process is talking to Slack and what that process does next, rather than the reputation of the destination alone.

Blockchain provides a second command channel

The malware also contains a considerably more unusual command-and-control mechanism.

It interacts with an Ethereum smart contract hosted on the Arbitrum Sepolia test network.

The implant polls the smart contract approximately every three seconds for encrypted instructions.

Commands obtained through this mechanism can result in code being executed as:

  • Go; or
  • JavaScript.

This approach effectively uses the blockchain as a dead drop.

Instead of connecting directly to an attacker-controlled command server, the malware retrieves instructions from public blockchain infrastructure.

That makes traditional takedown significantly more difficult.

A conventional domain can be seized.

A hosting provider can remove an attacker server.

A blockchain transaction or smart-contract state is not nearly as easy for defenders to eliminate.

Encryption separates commands intended for different victims

After checking in, the malware generates an ephemeral public-private key pair.

It then combines its temporary key material with attacker-controlled public keys to derive shared encryption keys.

This design allows the threat actor to send encrypted commands through shared infrastructure while preventing one infected host from necessarily understanding messages intended for another.

That is a sophisticated design decision.

If every infected client reads the same blockchain data or Slack channel, there is normally a risk that commands and responses could leak between compromised machines.

The cryptographic design reduces that problem.

It also makes passive monitoring of the shared communication channel less useful unless defenders possess the required keys.

The blockchain design may actually limit attacker scalability

Interestingly, the sophistication also introduces a bottleneck.

Aikido notes that all infected clients consume messages from the same blockchain mechanism and simply ignore data they cannot decrypt.

That means the operator must manage communication carefully across victims.

This may indicate that the campaign is intended for relatively targeted compromise rather than massive indiscriminate distribution.

That observation aligns with other aspects of Graphalgo activity.

The Graphalgo campaign appears highly selective

Recent Graphalgo-related packages have used unusual execution gates.

In some npm samples, malware activates only when a specific cryptographic computation occurs.

Researchers found cases where a payload decrypts only after the victim solves a particular linear algebra problem using a specific matrix.

That is an extremely unusual anti-analysis mechanism.

A generic sandbox executing the package may never trigger the malicious behavior.

The intended victim, however, may encounter the exact condition while completing a developer challenge provided by the attacker.

This strongly fits the pattern of targeted developer recruitment attacks.

Fake job interviews remain an important initial-access vector

Researchers assessing Graphalgo activity believe fake job interviews are likely a major delivery mechanism.

The broader campaign has involved attackers posing as representatives of nonexistent Web3 companies and contacting developers through:

  • LinkedIn;
  • Facebook;
  • job forums; and
  • direct recruitment outreach.

Victims are given what appears to be a legitimate coding exercise.

The supplied project may look benign.

However, one of its dependencies points to a malicious package on npm, PyPI, Go, or now potentially Terraform.

The developer does the rest.

They clone the repository.

They install the dependencies.

They run the code.

And the attacker's malware executes inside a machine likely containing exactly the credentials the attacker wants.

This attack model bypasses several traditional security instincts

Fake-job attacks are effective because the victim believes they are performing professional work rather than opening a suspicious attachment.

There may be:

  • no executable attachment;
  • no obvious phishing document;
  • no malicious macro;
  • no suspicious login page.

Instead, the victim receives source code.

Developers are naturally accustomed to running source code from GitHub.

That trust is the attack surface.

Terraform makes the fake-job model potentially more dangerous

If a malicious coding challenge includes Terraform infrastructure, the developer may reasonably expect to run:

terraform init

and:

terraform plan

or related commands.

During initialization, Terraform downloads the required provider plugins.

If one of those providers is malicious, execution enters the attacker-controlled component through what appears to be a legitimate infrastructure-development workflow.

This is particularly dangerous if the developer is already authenticated to cloud platforms.

Terraform providers often inherit credentials from:

  • environment variables;
  • CLI configuration;
  • shared credentials files;
  • cloud identity systems; and
  • CI/CD secret stores.

The malicious provider may therefore find itself sitting beside extremely valuable access tokens.

Infrastructure-as-code dependencies deserve the same scrutiny as application dependencies

Many organizations have mature software-composition analysis for:

  • npm;
  • PyPI;
  • Maven;
  • NuGet; and
  • container images.

Terraform providers may receive significantly less scrutiny.

That gap is becoming difficult to justify.

A provider is executable code.

It should therefore be assessed based on:

  • publisher reputation;
  • provenance;
  • signing;
  • source repository;
  • release history;
  • download anomalies;
  • unexpected native behavior; and
  • changes between versions.

Infrastructure teams should not assume that code is safe simply because Terraform obtained it from a recognized registry.

The registry distributes packages.

It does not guarantee that every package is trustworthy.

HashiCorp Registry becomes part of the supply-chain threat model

The novelty here is particularly important.

Aikido describes this as the first time it has observed malware distributed directly through Terraform providers in HashiCorp's centralized registry.

This matters because Terraform users may implicitly treat the registry as trusted infrastructure.

Attackers understand that reputation.

The same pattern has appeared repeatedly across other ecosystems:

npm became trusted → attackers published malware there

PyPI became trusted → attackers published malware there

container registries became trusted → attackers uploaded poisoned images

Now infrastructure-as-code registries are becoming attractive for the same reason.

The more developers trust a distribution system, the more valuable it becomes to an attacker.

This is not the only recent Terraform-related attack

The timing is notable because another recent campaign also involved malicious Terraform delivery.

Earlier in September, attackers compromised infrastructure behind Coder's registry.coder.com, inserting unauthorized servers into the registry pool and serving modified Terraform modules designed to steal credentials.

That incident was technically different.

The Coder attack involved compromise of registry infrastructure.

The Graphalgo activity involves malicious Terraform providers being intentionally published through a package ecosystem.

But the appearance of both attacks within weeks illustrates the same broader trend:

Terraform and infrastructure-as-code workflows are becoming attractive supply-chain targets.

Another DPRK-linked campaign has also used Terraform mechanisms

The Hacker News notes that SentinelOne recently documented another North Korea-linked cluster, TraderTraitor, using weaponized Terraform lock files and attacker-controlled Terraform provider registries to deliver Rust backdoors.

That does not prove all these campaigns are operated by the same actor.

Researchers appropriately caution that attribution remains uncertain.

However, the repeated appearance of Terraform-based delivery in campaigns associated with DPRK-linked activity makes coincidence increasingly interesting.

North Korea-linked threat actors have a long history of targeting developers, cryptocurrency companies, and Web3 organizations through fake recruitment and coding exercises.

Terraform naturally fits that model because Web3 and cloud-development teams routinely work with infrastructure-as-code.

Attribution should still be treated carefully

The Graphalgo campaign has technical overlaps with activity previously attributed by researchers to North Korea-linked actors.

That includes:

  • infrastructure overlap;
  • developer targeting;
  • fake recruitment;
  • package ecosystem abuse; and
  • similar malware architecture.

However, the current Terraform activity should be described as linked or overlapping with DPRK-associated campaigns, rather than independently declaring that the North Korean government definitively operated every identified package.

Cyber attribution is rarely improved by enthusiasm.

The malware also uses fake ecosystem development to build credibility

Aikido found evidence that the attacker created what appear to be fake Go ecosystems around the malicious modules.

That means the operators did not simply publish one suspicious dependency and hope someone downloaded it.

They attempted to create surrounding packages and development activity that made the ecosystem appear more legitimate.

This is an important evolution in package-reputation attacks.

Developers frequently evaluate dependencies using signals such as:

  • repository structure;
  • related packages;
  • download counts;
  • activity history; and
  • ecosystem references.

Attackers can manufacture those signals.

Download counts can also be manipulated

Related Graphalgo research found that attackers used GitHub Actions infrastructure to artificially increase download counts for malicious packages.

This creates another useful lesson.

Popularity is not proof of legitimacy.

A package with thousands of downloads may look safer than one with twelve downloads.

But if those downloads were generated automatically by attacker-controlled workflows, the metric becomes meaningless.

Software supply-chain controls therefore need stronger provenance signals than popularity.

What should organizations do if these packages were installed?

Any system that executed the identified Terraform providers or Go modules should be treated as potentially compromised.

Organizations should search for:

gocommunity-io/dockerd

kreuzwenker/docker

gocommunity.io/orderedbtree

gogets.dev/btreex

across:

  • Terraform configuration;
  • .terraform.lock.hcl;
  • Go module files;
  • dependency inventories;
  • SBOMs;
  • developer systems;
  • CI/CD environments; and
  • cached provider directories.

The exact package version and execution timeline should be established.

Credential rotation may be necessary

Because Terraform environments often contain privileged credentials, removing the malicious provider is not necessarily sufficient.

If the provider executed, defenders should identify every secret available within that process context.

Potentially exposed credentials may include:

  • cloud API keys;
  • Terraform Cloud tokens;
  • Kubernetes credentials;
  • GitHub or GitLab tokens;
  • SSH keys;
  • CI/CD secrets;
  • Vault credentials; and
  • service-account tokens.

Credentials that could have been accessed should be rotated according to risk.

The unpleasant principle remains the same across supply-chain incidents:

uninstalling malware does not un-steal a credential.

Review cloud and infrastructure audit logs

Because Terraform operates against infrastructure APIs, security teams should also review:

  • AWS CloudTrail;
  • Azure Activity Logs;
  • Google Cloud audit logs;
  • Kubernetes audit logs;
  • Terraform Cloud activity;
  • GitHub audit events; and
  • identity-provider logs

for unexpected activity associated with developer or automation credentials.

An attacker who steals cloud credentials may use them from another system entirely.

The absence of further malware on the original workstation therefore does not establish that the incident is contained.

Restrict outbound communication from build environments

This campaign also demonstrates why unrestricted outbound Internet access from CI/CD and infrastructure automation environments creates risk.

Most Terraform providers need to communicate with specific APIs.

They do not necessarily require unrestricted access to:

  • Slack;
  • public blockchain RPC endpoints;
  • arbitrary domains; and
  • unrelated SaaS platforms.

Egress policies can therefore provide a valuable defensive layer.

A Terraform provider unexpectedly communicating with a Slack bot API or an Ethereum testnet should be unusual enough to investigate.

Pin providers and verify checksums

Terraform lock files allow organizations to pin provider versions and verify package hashes.

Teams should use them consistently.

Version pinning will not protect against a malicious version that was already selected intentionally, but it can prevent unexpected provider changes.

Organizations should also verify:

  • expected provider namespace;
  • source location;
  • cryptographic checksum;
  • release provenance; and
  • publisher identity.

Typosquatting is particularly dangerous in Terraform because provider names can resemble popular legitimate alternatives.

Private mirrors can reduce exposure

Larger organizations may benefit from maintaining approved internal mirrors or registries for Terraform providers.

Instead of allowing every developer and CI runner to download arbitrary providers directly from the public registry, security teams can:

  • approve known providers;
  • mirror vetted versions;
  • scan artifacts;
  • enforce provenance;
  • monitor updates; and
  • block unknown namespaces.

This changes the trust model from:

anything in the public registry can execute

to:

only explicitly reviewed providers can execute internally.

That is considerably more defensible.

Developers need security awareness specifically for coding tests

Organizations should also educate developers about recruitment-based attacks.

Warning signs include recruiters who:

  • insist on running unfamiliar repositories;
  • provide unusual dependency installation instructions;
  • request disabling security software;
  • ask candidates to install custom development tools;
  • send projects from newly created organizations; or
  • require execution of code before a meaningful interview has occurred.

Developers should inspect dependency files before running untrusted code.

For sensitive corporate machines, recruitment coding exercises should ideally be executed inside isolated disposable environments rather than directly on the developer workstation.

The broader cybersecurity lesson

The malicious Terraform providers illustrate how software supply-chain attacks continue to move closer to infrastructure itself.

The progression is logical:

application dependency → developer compromise → credential theft → infrastructure dependency → direct access to cloud control planes

Terraform is a particularly attractive step in that evolution because it frequently sits at the point where code meets production infrastructure.

The attackers do not necessarily need to exploit AWS, Azure, Kubernetes, or Terraform itself.

They simply need a developer to trust the wrong provider.

The attack chain can then become:

fake recruiter → coding exercise → Terraform initialization → malicious provider execution → host reconnaissance → Slack/blockchain C2 → additional code execution → potential credential theft and infrastructure compromise

The crucial lesson is therefore that Infrastructure-as-Code is still code.

Its plugins, providers, modules, registries, and lock files should receive the same scrutiny organizations already apply to application dependencies.

Possibly more scrutiny.

Because when a malicious JavaScript library runs, it may compromise an application.

When a malicious Terraform provider runs with production cloud credentials, it may be standing next to the keys to the entire infrastructure.

Cybersecurity researchers have disclosed Go-based malware distributed via two Go Modules and two Terraform providers, marking the first time threat actors are using the centralized repository hosted by HashiCorp as a distribution vector for malicious payloads. According to Aikido, the list of Terraform providers and Go modules is below - gocommunity-io/dockerd (222 downloads) kreuzwenker/

Source: Attackers Use Malicious Terraform Providers to Deliver Go Malware via HashiCorp Registry via The Hacker News — published 23 Sep 2026.