North Korea-linked hackers hide backdoors in fake Terraform AWS provider
Zscaler ThreatLabz says a trojanized Terraform provider posing as an AWS plugin delivered FLATROOF and ROOFDECK backdoors to crypto and cloud developers.
At a glance
- A Go binary named terraform-provider-awsbeta_v1.0.0 posed as an AWS provider while silently fetching malware.
- The chain delivers the Rust-based FLATROOF backdoor, Python stealers and the ROOFDECK backdoor on Windows, macOS and Linux.
- Zscaler links the activity to TraderTraitor with limited confidence and notes overlap with the KelpDAO incident.
- Defenders are urged to restrict untrusted Terraform providers, verify checksums and monitor CI/CD systems.
Hackers suspected of working for North Korea's TraderTraitor group have used a trojanized HashiCorp Terraform provider disguised as an Amazon Web Services plugin to plant backdoors on developer machines, Zscaler ThreatLabz said in research published on October 8. The campaign targets cryptocurrency, Web3 and cloud engineers, and because Terraform providers run on developer workstations and CI/CD systems, it puts build infrastructure and the cloud credentials stored there at risk.
What happened
According to Zscaler, its researchers uncovered the campaign in July 2026. The malicious component is a Go binary named terraform-provider-awsbeta_v1.0.0 that masquerades as an AWS provider. The company said the provider continues to work normally, while malicious code executes when Terraform loads it.
Zscaler attributes the activity to TraderTraitor, also tracked as Jade Sleet, UNC4899, Pressure Chollima and Slow Pisces, but only with limited confidence. The researchers said they found substantial overlap in tactics and targeting, yet no unique code similarities, shared infrastructure or cryptographic links strong enough for a high-confidence attribution. The company added that the campaign significantly overlaps with the KelpDAO incident, and that SentinelLabs independently reported related activity involving weaponized Terraform projects.
Technical details
Per Zscaler, the provider uses a run-once lock file and downloads a Bash loader called safari_updater from the lookalike domain hashicorp-terraform[.]io. The loader selects a payload based on the operating system and CPU architecture. The payloads are encrypted executables appended to decoy .woff font files and are decrypted with AES-256-CBC.
The first stage is FLATROOF, a Rust-based cross-platform backdoor that can communicate over the Telegram Bot API, GitHub API polling or an attacker-controlled webhook. FLATROOF deploys Python stealers that collect browser credentials, cookies and history, shell history, keychain and keyring secrets, Windows Credential Manager entries and data from crypto wallet extensions such as MetaMask, Phantom, Trust Wallet and Rabby. Zscaler said parts of the scripts may have been written with the help of a large language model. The second backdoor, ROOFDECK, locates its command server through a local address, a signed and encrypted Pastebin entry or Nostr profile metadata, and offers remote shell, file and clipboard access.
Who is affected
Zscaler said it remains unclear how the fake provider reached victims. Organizations most exposed are those whose engineers install Terraform providers from outside trusted sources, particularly in crypto and Web3 companies, which TraderTraitor has targeted for years.
What to do
Zscaler recommends restricting the use of untrusted Terraform providers, verifying provider checksums and monitoring developer workstations and CI/CD systems for unexpected process activity. Security teams can also hunt for the published indicators, including the loader file name safari_updater, the FLATROOF command server arusupport-region1-webhook[.]online and the ROOFDECK server delay.servehttp[.]com, and should rotate cloud and wallet credentials on any system where the provider was run.
Sources
- Suspected TraderTraitor Group Uses Trojanized Terraform Provider to Deliver Malware — Zscaler ThreatLabz
This story is based on the sources listed above. Always check the vendor’s official advisory before acting on critical systems.



