Secure Bulletin Navigating the cyber sea with knowledge
Home > Articolo > Trojanized Terraform Provider Delivers Cross-Platform Backdoors to Developers
Trojanized Terraform Provider Delivers Cross-Platform Backdoors to Developers
Read Time:3 Minute, 42 Second

A supply-chain campaign is abusing the trust placed in Terraform providers to compromise developer computers and CI/CD systems across macOS, Linux and Windows. The attackers distribute a trojanized plugin that resembles an AWS provider and retains working provider functionality, while executing a hidden infection chain as soon as Terraform loads it.

Zscaler ThreatLabz identified the activity in July 2026. Its targeting and methods overlap with operations associated with TraderTraitor, also known as Jade Sleet and by several other industry names, but researchers said the available code and infrastructure evidence was insufficient for a high-confidence attribution.

A functional provider conceals the loader

The initial Go binary is named terraform-provider-awsbeta_v1.0.0. A plausible structure helps it survive a quick inspection and behave as a victim expects. A malicious package runs alongside that functionality, checks the temporary directory for a session.lock file and downloads a Bash loader when the marker is absent. It then creates the lock to avoid executing the same stage twice.

The loader, called safari_updater, identifies the host operating system and processor architecture before choosing a compatible payload. Besides native macOS and Linux targets, it supports Windows machines with Unix-like environments such as Cygwin, MinGW or MSYS.

Payloads are disguised as WOFF web fonts. The files contain decoy font data followed by a marker and an encrypted executable. The script separates the hidden section, decodes it from Base64 and decrypts it with AES-256-CBC, using whichever supported utility—such as Python, Node.js, Perl or OpenSSL—is available. On macOS, it removes the quarantine attribute and applies an ad hoc signature to reduce normal execution friction.

FLATROOF steals data and opens remote access

The delivered FLATROOF backdoor is written in Rust and supports all three major desktop operating systems. It gathers system information, lists processes, manages files, runs commands, transfers additional payloads and can remove itself. Persistence differs by platform, using mechanisms such as a Linux service, a macOS logout configuration or a Windows Registry Run entry.

Companion Python stealers search Chromium and Firefox profiles for passwords, cookies, browsing history and autofill content. They also gather shell history, usernames, installed applications and process details. Platform-specific collection extends to Safari and the macOS login keychain, as well as Windows Credential Manager, command history and browser wallet extensions including MetaMask, Phantom, Trust Wallet and Rabby.

The operation can also install ROOFDECK on Windows and macOS. This backdoor provides broader remote-control functions, including command execution, clipboard access, file and disk discovery, transfers, background-job management and self-update. It can discover its command server from a local configuration, a cryptographically signed Pastebin entry or Nostr profile metadata, giving the operator alternative control channels.

Why infrastructure tooling is an attractive lure

Terraform providers are executable components, not passive configuration. Developers and build systems run them in environments that often have cloud credentials, repository access, deployment permissions and access to production infrastructure. A provider that appears relevant to a job test or new project can therefore bypass a victim’s suspicion while landing near high-value secrets.

The cross-platform design also matches modern engineering teams, where a single project may involve Mac laptops, Linux runners and Windows workstations. Supporting multiple decryption tools increases the odds that the loader succeeds without shipping obvious additional dependencies.

Defenders should verify providers and watch execution

Teams should allow only approved provider sources, review names for lookalikes and validate checksums recorded in Terraform lock files. Provider additions and lock-file changes should require peer review, particularly when they arrive through a recruitment exercise, unfamiliar repository or unsolicited collaboration request.

  • Alert when Terraform processes launch shells or scripting engines unexpectedly.
  • Investigate WOFF downloads followed by decoding, decryption or execution.
  • Monitor temporary directories for unfamiliar lock files and loaders.
  • Block known malicious infrastructure using safely defanged indicators.
  • Rotate cloud, source-control and wallet credentials after suspected execution.

CI/CD runners should be isolated, ephemeral and granted only the permissions required for each job. Secrets should come from managed stores and expire quickly rather than remaining in environment files or developer browsers. Egress controls can also stop an unapproved provider from reaching arbitrary download and command servers.

This campaign turns a familiar infrastructure workflow into an initial-access mechanism. Treating providers like signed software dependencies—and monitoring what they launch—can prevent the convenience of infrastructure as code from becoming a direct path to developer identities and production cloud environments.

Share: Twitter  |  Facebook  |  LinkedIn
Join the discussion

This is a blog in the Fediverse: you can find this article everywhere with @blog@securebulletin.com and every comment/answer will appear here.

If you want to comment on Trojanized Terraform Provider Delivers Cross-Platform Backdoors to Developers, use the discussion on Forum.

>> forum community

Comments

Leave a Reply