Hackers Abuse Trusted Terraform Workflows to Infect Developer Systems With Cross-Platform Malware

A newly identified supply-chain campaign is abusing Terraform provider workflows to infect developer systems with malware built for macOS, Linux, and Windows.

The activity uses a trojanized Terraform provider that appears to be a legitimate AWS-related plugin, allowing it to run malicious code while still behaving like a normal provider.

The campaign is a major concern for cloud engineers, DevOps teams, and cryptocurrency or Web3 developers because Terraform providers run on workstations and CI/CD systems that may hold source-code access, cloud credentials, API keys, deployment permissions, and browser-stored login data.

The case closely follows earlier reports on fake Terraform job tests used to compromise developers through trusted-looking infrastructure projects.

Researchers from Zscaler ThreatLabz identified the malware campaign in July 2026 and linked its tools and targeting patterns to suspected TraderTraitor activity. TraderTraitor is also tracked as Jade Sleet, UNC4899, Pressure Chollima, and Slow Pisces.

However, Zscaler said it did not have enough unique code, infrastructure, or cryptographic evidence to attribute this campaign to the group with high confidence.

The initial file, named terraform-provider-awsbeta_v1.0.0, is written in Go and poses as an Amazon Web Services provider for HashiCorp Terraform.

It contains a working provider structure, helping it appear normal to a victim. At the same time, an added malicious package runs as soon as Terraform loads the provider.

Hackers Abuse Trusted Terraform Workflows

The provider checks for a session.lock file in the temporary directory, downloads a Bash loader if that file is absent, runs it in the background, and then creates the lock file to avoid running twice.

The Bash loader, called safari_updater, checks the operating system and CPU architecture before selecting a tailored payload. It supports macOS, Linux, and Windows systems that use a compatible Unix-like shell, including Cygwin, MinGW, or MSYS.

The loader downloads files disguised as normal .woff web-font files, a method that can make the payload look less suspicious during a quick file review.

The malicious files contain decoy font content followed by an @@ENDFONT@@ marker and an encrypted executable. The loader extracts the hidden data, Base64-decodes it, and decrypts it with AES-256-CBC.

It can use Python, Node.js, Perl, or OpenSSL, depending on which tool is installed on the victim device. On macOS, it also removes the quarantine attribute and applies an ad hoc code signature before execution, helping the malware run without normal Gatekeeper warnings.

The delivered malware is assessed to be FLATROOF, a Rust-based backdoor that supports all three major desktop operating systems. It can establish persistence through a Linux service, macOS logout configuration, or a Windows Registry Run value.

FLATROOF & ROOFDECK

FLATROOF can collect system information, list processes, manage files, execute commands, download follow-on payloads, upload stolen data, and remove itself when needed.

Its Python-based data stealers search for Chromium and Firefox browser data, including saved credentials, cookies, browsing history, autofill data, shell history, installed applications, running processes, and the current username.

On macOS, the malware can collect Safari data and the login.keychain-db file. On Windows, it targets Chrome, Edge, Brave, Windows Credential Manager entries, command history, and wallet-extension data from MetaMask, Phantom, Trust Wallet, and Rabby.

This browser and wallet focus resembles developer package supply-chain threats that have increasingly targeted Web3 environments. The campaign also deploys ROOFDECK, a Windows and macOS backdoor with stronger remote-control functions.

ROOFDECK can discover files and disks, run shell commands, transfer files, read and write clipboard data, manage background tasks, update itself, and erase traces.

Its command-and-control discovery process is especially notable: it can use a local configuration file, a cryptographically signed Pastebin record, or Nostr profile metadata to locate its active server.

This use of public platforms as flexible delivery or control layers is similar to other malware server hiding methods seen in developer-focused campaigns.

For defenders, the incident shows why provider verification must be part of Terraform security. Teams should restrict unapproved providers, validate checksums in Terraform lock files, review provider source addresses, and block lookalike domains.

Security teams should also watch for Terraform-related processes launching shells, unexpected files in temporary directories, suspicious .woff downloads, and executables running from user profile folders.

Applying secure CI/CD pipeline practices can further reduce the risk by adding code review, dependency controls, secret management, and automated scanning before infrastructure changes are deployed.

Indicators of compromise (IoCs):-

Note: IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.

Stops threats before impact with 21 min faster MTTR. Integrate ANYRUN’s Sandbox in your SOC

The post Hackers Abuse Trusted Terraform Workflows to Infect Developer Systems With Cross-Platform Malware appeared first on Cyber Security News.