Graphalgo: Malicious RAT Hides in Terraform Providers and Go Modules

Aikido Security researchers have discovered a new supply chain attack called Graphalgo, in which a malicious Go-based RAT is distributed through Terraform providers and Go modules. This marks the first documented delivery of malware through the HashiCorp Registry: attackers published the malicious providers gocommunity-io/dockerd and kreuzwenker/docker (a typosquat of the popular kreuzwerker/docker with 56 million downloads), as well as the Go modules gocommunity.io/orderedbtree and gogets.dev/btreex. The campaign uses targeted triggers, blockchain and Slack for command and control, making detection extremely difficult.

Key IOCs: Terraform providers gocommunity-io/dockerd and kreuzwenker/docker; Go modules gocommunity.io/orderedbtree and gogets.dev/btreex; domains gocommunity[.]io and gogets[.]dev; Ethereum contract 0xAD02b5cDE693529d3bdA0266299501ad0193036C on Arbitrum Sepolia; Slack workspaces portfolio-devs.slack[.]com and portfolio-testers.slack[.]com.

🎯 Attack Mechanics: Targeted Activation and Hidden Execution

The malicious Terraform providers contain hidden entry points in the file /internal/provider/resource_docker_container_funcs.go that activate only when specific conditions are met. The malware remains dormant unless the SHA256 hash of the concatenated Terraform variables containerName and networkID matches the target value b9966e3762e9a0d5d263b8cb3cca07294f81af9714d40ddf4628cb85d74e8ad5. This mechanism means the malicious provider is harmless in most cases and activates only during a targeted attack against specific infrastructure.

⚙️ Activation Process and Second-Stage Execution

  • Trigger check: Calculate the SHA256 hash of containerName + networkID
  • Key decryption: Use the hash as an AES key to decrypt the file path
  • Archive extraction: Extract import-resource.sqlite3 (SHA256: 5f892a5424e88a21a3eb3d7f82ebf04d8ac31cdb19ada25153be4165df977d0f)
  • Content decryption: AES-decrypt each file in the archive
  • Second-stage execution: Execute through a detached go run . process in the background

The use of a specific trigger undermines sandbox testing: a scanner installing the Graphalgo provider with ordinary inputs sees a normal Docker provider. The attacker apparently knew or expected to learn the exact container and network names used by the target, suggesting reconnaissance or social engineering before the package was downloaded. This is a classic sign of a targeted operation rather than a mass campaign.

The Go module gogets.dev/btreex first appeared on September 8, but the attacker forged commits to make them appear to date back to November 2025. Because Go Modules treats commit dates as authoritative, the Go module proxy and pkg.go.dev displayed the falsified date. The attacker also created two fake Go package websites — gogets.dev and gocommunity.io — to make the packages appear to be established projects.

🔗 Dual C2 Infrastructure: Slack and Blockchain Dead Drop

The second stage of the Graphalgo RAT is a Go agent with two command-and-control channels, making it particularly resilient to detection and blocking. The malware initially collects system information, including hardware attributes, OS details, hostname and the availability of Node on the infected system, and then transmits this data through both channels.

💬 Slack as a C2 Channel

The malware sends the collected information to the frontend-devs Slack channel in the portfolio-devs.slack[.]com workspace (Portfolio Devs). Notably, the malware communicates with api.slack.com, and the workspace subdomain is not contacted directly. For Slack C2 communications, the malware uses the hardcoded public key 302a300506032b656e032100bad013df6eec5d686f4cc8551e0a5c87a0135164bdd1dafb1c75141d1b526702.

  • Initial contact: Writes the client's public key to the frontend-devs channel
  • Encryption: All subsequent communications are encrypted using a shared key
  • Operational channel: Subsequent messages are sent to the qa-announcements channel in the portfolio-testers.slack[.]com workspace
  • Polling: The malware checks Slack every 10 seconds

Slack API traffic is common in most corporate networks, so egress filtering is unlikely to flag Graphalgo check-ins. This makes Slack an ideal channel for covert communication in environments where developers actively use the platform.

⛓️ Blockchain Dead Drop on Arbitrum Sepolia

For blockchain-based C2, the malware retrieves data from an Ethereum smart contract on the Arbitrum Sepolia testnet using the hardcoded contract address 0xAD02b5cDE693529d3bdA0266299501ad0193036C. The process works as follows:

  1. Retrieve the private key for a shared Ethereum wallet
  2. Decrypt the private key using a key derived from the same material used to decrypt the second stage
  3. Retrieve the threat actor's public key from the contract
  4. Create a shared key using the public key and an ephemeral private key
  5. Write the ephemeral private key to the contract through the setCPubKey method
  6. Read encrypted commands from serviceData1 and serviceData2

The C2 mechanism provides further evidence that this malware is part of a targeted operation. The threat actor's ability to issue commands is constrained because all clients consume all messages and perform a no-op when they cannot decrypt messages intended for other clients. This is a particularly sophisticated implementation of a blockchain dead drop that integrates bidirectional communication with minimal risk of information leakage or disruption. The malware polls the blockchain every 3 seconds.

C2 Channel Polling Interval Platform Purpose
Slack 10 seconds api.slack.com Initial contact, key exchange
Blockchain 3 seconds Arbitrum Sepolia Dead-drop commands, persistent communication

Blockchain traffic is less common in corporate networks. Aikido recommends that organizations without a business need to interact with blockchains configure alerts for network connections to HTTP-based blockchain services. On command, the malware can execute additional Go or JavaScript code or delete itself.

🛡️ Response Playbook: Isolation, Rotation and Reimaging

If any of the Graphalgo packages or providers were installed on a developer machine or CI/CD runner, the entire environment should be considered compromised. Simply removing the package is not sufficient to clean the machine because the malware launches its second stage as a detached background process.

🚨 Immediate Actions Upon Detection

  • Isolate the machine: Disconnect it from the network immediately. Given the malware's C2 channels (Slack API calls and an Ethereum smart contract), the infected host may remain accessible to the threat actor even after the package is removed
  • Rotate all credentials: Do not limit rotation to Go module tokens. Rotate GitHub/GitLab tokens, npm/PyPI/Go publishing tokens, cloud credentials and SSH keys. If the affected package was executed through a Terraform provider, prioritize cloud and infrastructure credentials because this attack vector targets DevOps workstations with direct access to production
  • Check for unauthorized activity: Review recent commits, package publications, Terraform applies and GitHub Actions runs originating from this machine or using its credentials. Assume that the attacker may have acted using valid, working credentials
  • Reimage the device: Remove the package and reimage the machine. Because the malware executes the decrypted second stage through a detached go run . process, removing the package alone does not guarantee that everything it launched is gone. Reimaging is the only way to be certain the host is clean

🔍 Searching for Indicators of Compromise

This week, confirm that none of the four Graphalgo packages exist anywhere in your environment, identify everyone inside or outside the company who runs Terraform with production credentials, and shorten the lifetime of those credentials. These three actions address the Graphalgo campaign specifically as well as the broader class of attacks targeting infrastructure tools.

For teams running Terraform in-house, it is necessary to:

  • Search repositories and lock files for gocommunity-io/dockerd, kreuzwenker/docker, gocommunity.io/orderedbtree and gogets.dev/btreex, and block the domains gocommunity.io and gogets.dev at the DNS level
  • Require code review for any changes to the required_providers block, with the reviewer verifying the provider namespace against the official Terraform Registry page
  • Consider a private registry or provider network mirror so engineers can install only Terraform providers approved by your team
  • Replace long-lived cloud access keys on engineering laptops with short-lived credentials issued through single sign-on, and move production applies into CI pipelines that authenticate through OpenID Connect (OIDC) federation instead of stored secrets
  • Configure alerts for connections to public blockchain services from engineering endpoints and build runners if there is no business reason to allow them
  • Reclassify DevOps and platform engineering laptops as tier 0 assets in your inventory and endpoint detection and response (EDR) policy

Critical note: Reimaging is the only reliable way to clean the system. The malware launches its second stage as a detached process, so removing the provider does not stop code that is already running. Any machine that installed these packages should be considered fully compromised, and all cloud credentials it had access to should be rotated.

📊 Context: The Growing Threat of Supply Chain Attacks on IaC

The Graphalgo campaign represents the first documented delivery of malware through Terraform providers, but it fits into a growing trend of supply chain attacks targeting infrastructure tools. Terraform is used by more than 75% of companies to manage cloud infrastructure, making it an attractive target for attackers seeking access to production environments through DevOps workstations.

🎯 Why Terraform Providers Are Vulnerable

  • Trust in the Registry: Engineers typically trust packages from the official HashiCorp Registry without extensive verification
  • Typosquatting: kreuzwenker/docker looks like the legitimate kreuzwerker/docker, especially at a quick glance
  • Automatic installation: Terraform automatically downloads providers during terraform init without additional confirmation
  • Privileged access: DevOps workstations often have access to production credentials for infrastructure management
  • Weak verification: Most teams do not have processes for verifying provider authenticity before use

The use of blockchain and Slack for C2 reflects the evolution of malware techniques, with attackers using legitimate services for covert communication. This makes detection more difficult because the traffic resembles ordinary business activity. Blockchain dead drops are becoming increasingly popular among advanced threat actors because they provide infrastructure that is resilient to takedowns.

🔐 Long-Term Protective Measures

To prevent similar attacks, organizations should implement a multi-layered supply chain security strategy. This includes using private registries for all infrastructure packages, mandatory verification of checksums and signatures before installation, segmentation of access to production credentials and continuous monitoring of network activity for anomalous connections to blockchain services.

The Graphalgo campaign demonstrates that even well-known and widely used Infrastructure as Code tools can become vectors for sophisticated targeted attacks. The combination of specific triggers, dual C2 infrastructure and a falsified release history demonstrates the high level of sophistication of the threat actors behind this operation. Organizations should reassess their approaches to supply chain security and treat infrastructure tools with the same rigor as critical production systems.

“Supply chain security is not about trusting every link, but verifying every link. In the world of Infrastructure as Code, a single unverified provider can become a doorway into your entire cloud infrastructure.”

— Bruce Schneier, cryptographer and security expert

24.09.2026, 02:26