Suspected TraderTraitor Group Uses Trojanized Terraform Provider to Deliver Cross-Platform Malware

Introduction

In July 2026, Zscaler ThreatLabz uncovered a campaign linked to TraderTraitor (also tracked as Jade Sleet, UNC4899, Pressure Chollima, and Slow Pisces), an advanced persistent threat actor backed by the North Korean government that has targeted the cryptocurrency industry for years. This campaign also significantly overlaps with the previously reported KelpDAO incident, the analysis of which discussed both FLATROOF and ROOFDECK, two malware families also observed in this campaign. The attackers utilized a trojanized Terraform provider to deliver a Bash loader that selects and downloads malware tailored to the victim's operating system. The FLATROOF malware deployed Python scripts to steal sensitive data from the victim before ultimately dropping the ROOFDECK backdoor to gain full remote control.

In this blog, ThreatLabz examines the inner workings of these tools and analyzes the multi-stage infection chain. We also explore how this sophisticated malware conceals and retrieves its final command-and-control (C2) address to evade detection.

Key Takeaways

• In July 2026, ThreatLabz discovered a trojanized Terraform provider that executes malicious code as soon as Terraform loads the provider.
• The trojanized Terraform provider downloads a cross-platform Bash loader from a HashiCorp-themed lookalike domain while preserving normal Terraform behavior.
• The loader selects payloads for macOS, Linux, and Windows according to the operating system and CPU architecture.
• Encrypted executables are appended to decoy .woff files and recovered using marker-based extraction and AES-256-CBC decryption.
• The delivered FLATROOF variant is a Rust-based cross-platform backdoor with platform-specific persistence and redundant C2 channels.
• The FLATROOF Python stealers target browser credentials, cookies, terminal history, system information, and cryptocurrency wallet extensions.
• The subsequent backdoor named ROOFDECK uses layered C2 discovery through local configuration, a cryptographically signed Pastebin dead drop, and Nostr profile metadata.

Attack Chain

The figure below illustrates the attack chain, from the execution of the trojanized Terraform provider through FLATROOF deployment, data theft, and installation of the ROOFDECK backdoors. 

Figure 1: Infection chain delivering FLATROOF and ROOFDECK through a trojanized Terraform provider.

Technical Analysis

While this analysis was being prepared for publication, SentinelLabs independently reported related TraderTraitor activity involving weaponized Terraform projects, FLATROOF, and ROOFDECK malware. Their research provides detailed insight into the social engineering and initial intrusion aspects of the campaign. Our analysis focuses on the internal implementation of the malicious Terraform provider and its cross-platform payload delivery mechanism.

Trojanized Terraform provider

The initial payload identified by ThreatLabz is written in Go and named terraform-provider-awsbeta_v1.0.0. It masquerades as an Amazon Web Services (AWS) provider for HashiCorp Terraform. Terraform providers are executable plugins loaded by Terraform to communicate with infrastructure platforms and services. Although it remains unclear how the trojanized Terraform provider was delivered to the victim, Terraform provider binaries execute on developer workstations and CI/CD systems. This suggests that the campaign may target cloud engineers or developers who use Terraform.

The binary’s Go symbols reveal a functional provider scaffold under terraform-provider-awsbeta/internal/provider, including example resource and data source implementations. The threat actor added a malicious sibling package named awsbeta and called its exported routine directly from main. As a result, the malicious code executes when Terraform starts the provider.

The provider uses a file named session.lock in the system temporary directory as a run-once marker. If the marker is absent, the provider:

1. Determines the temporary directory using TMPDIR, falling back to /tmp.
2. Downloads a second-stage payload over HTTPS.
3. Writes a Bash payload to a file named safari_updater in the temporary directory.
4. Adds executable permissions to the file.
5. Launches it through sh -c as a detached child process.
6. Creates the lock file to prevent repeated execution.

The download URL uses the lookalike domain hashicorp-terraform[.]io and a path resembling a legitimate Terraform plugin metrics endpoint. Meanwhile, the provider continues to respond as expected, which may make the compromise less noticeable to the victim.

Cross-platform Bash loader

The downloaded safari_updater file is a Bash script that supports macOS, Linux, and Windows systems running a compatible Unix-like shell environment such as Cygwin, MinGW, or MSYS.

The script maps each operating system to a font family and each architecture to a font style to construct the filename for the next-stage payload. Linux uses NotoSansCJK, macOS uses HiraginoSans, and Windows uses the MalgunGothic font name for the next-stage payload. Architectures are represented by style names such as Bold (x86_64, amd64), Regular (aarch64, arm64), ExtraBold (ARMv7, ARMv6), or Italic (32-bit x86). The resulting filename resembles a normal web font file, such as HiraginoSans-Regular.woff on a macOS system with an ARM64 processor. 

The encrypted payloads are disguised as font files and are downloaded from a public source. For example, a GitHub repository hosting the next-stage payloads is shown in the figure below.

Figure 2: Attacker-controlled GitHub repository hosting encrypted payloads disguised as font files.

Payloads are written to paths that resemble those of legitimate application components, as listed in the table below. Note that the directories are created if they do not already exist.

Table 1: Operating system-specific payload storage locations for FLATROOF.

The loader attempts to download the payload from three sources in sequence: a dynamic DNS host, a GitHub repository, and a Vercel-hosted site. The use of public hosting and URL paths that resemble font caches may help malicious traffic blend with ordinary developer and web activity.

Each downloaded .woff file contains decoy font data followed by the marker @@ENDFONT@@ and an encrypted executable. The loader extracts the data after the marker, Base64 decodes it, and decrypts it with AES-256-CBC using the key PTa3WZPQZAjj55t@. To maximize compatibility, the loader can decrypt the payload via Python, Node.js, Perl, or OpenSSL depending on the software that is installed on the infected system. On macOS, the script removes the quarantine attribute using the xattr -d com.apple.quarantine command and applies an ad hoc code signature before execution.

FLATROOF cross-platform backdoor

The decrypted payloads for macOS, Linux, and Windows share the same Rust source module layout and core functionality. ThreatLabz assesses that the malware is consistent with the FLATROOF family described in the KelpDAO incident.

FLATROOF decrypts its embedded configuration using the key u73adF39ZT with PBKDF2-HMAC-SHA256, followed by AES-256-GCM decryption. The JSON configuration defines platform-specific installation paths, persistence mechanisms, polling intervals, and C2 communication channels, as shown in the example below.

{
 "aes_key": "a9d932dcfa3289a6",
 "github_polling_interval": 60,
 "github_repo": "xxx",
 "github_token": "ghp_xxx",
 "init_python_enable": false,
 "main_base_url": "hxxps://arusupport-region1-webhook[.]online/statics/cache/v11/abicfjej",
 "main_upload_url": "https://www.example.com",
 "payload_path_linux": ".config/snap/imagent",
 "payload_path_macos": "Library/Services/imagent",
 "payload_path_win": "AppData/Local/Microsoft/Windows/PowerShell/config.exe",
 "persist_enable": true,
 "persist_name_linux": "snap-imagent",
 "persist_name_macos": "imagent",
 "persist_name_win": "powershell-config-service",
 "persist_type_linux": "service",
 "persist_type_macos": "zlogout",
 "persist_type_win": "reg",
 "tg_room_id": -1003[redacted]807,
 "tg_token": "8757853278:[redacted]dKI91AvprMdUkqOLAq37AOKg"
}

The analyzed variants support three C2 mechanisms:

• Telegram Bot API for command retrieval and exfiltration of command results or files.
• GitHub API polling using a configured repository and token (not configured in the variant shown above).
• An attacker-controlled HTTP webhook for registration and tasking.

Not every channel was configured in every sample, but the shared code supports multiple communication channels, providing redundancy and potentially allowing malicious traffic to blend in with traffic to widely used services.

FLATROOF also implements platform-specific persistence mechanisms. The configuration references a service on Linux, a shell logout mechanism on macOS, and a registry Run value on Windows. Its command set supports system discovery, process and file management, command execution, payload download, data upload, persistence management, configuration changes, and self-removal.

Embedded Python information stealers

FLATROOF uses operating system-specific Python scripts to collect and package host and browser artifacts into a compressed archive for exfiltration. The Linux and macOS scripts stage data in temp/collected_data before creating temp/collected_data.zip, while the Windows script archives files from a directory named data into collected_data.zip and removes local staging files afterward.

All three scripts target browser profile artifacts that can contain saved credentials, cookies, browsing history, and autofill data:

• Chromium-based browser databases: History, Cookies, Login Data, and Web Data
• Firefox browser databases: places.sqlite, cookies.sqlite, logins.json, key4.db, formhistory.sqlite, and addons.json
• Command and shell history
• List of installed applications and running processes, system information, and the current username

The scripts also include platform-specific capabilities for stealing sensitive data from each targeted operating system, as shown in the table below.

Table 2: Operating system-specific capabilities across Python scripts.

Additionally, the Windows script contains two embedded native payloads. The first is a 64-bit Windows executable that is decoded using the XOR key 0x37 and injected into a suspended Chromium process to recover master encryption keys. The recovered keys are saved to [browser name]_aes.txt for staging. The second component, dropped as cookie_copy_tool.exe, copies cookie data when standard database copy operations fail.

The Python script’s verbose comments, use of emojis, repetitive exception handling, and inconsistent naming conventions suggest that portions of the code may have been generated or modified with the assistance of a large language model (LLM), as shown in the figure below.

Figure 3: Python script showing indications of code generated using AI.

ROOFDECK backdoor

ThreatLabz also identified Windows and macOS variants of ROOFDECK that are likely related to this campaign. ROOFDECK's most distinctive feature is its resilient C2 discovery process. The malware first reads a local configuration file disguised as a legitimate application file. It can then retrieve a Pastebin file containing an encrypted server address and an RSA signature separated by ||.

ROOFDECK verifies the signature before decrypting and accepting the server address. This prevents a third party from modifying the Pastebin file to redirect infected systems without the operator’s signing key. 

If the Pastebin lookup fails, ROOFDECK can query Nostr profile metadata. The malware contains a set of attacker-controlled public identities and relay servers, expands the relay list through a public directory, and reads the website field from profile events. At the time of analysis, an active profile named tulip pointed to the same Pastebin URL embedded in the Windows variant, as shown in the figure below.

Figure 4: Attacker-controlled Nostr profile and metadata used to locate the current Pastebin URL for C2 discovery.

This layered design provides several ways to obtain the C2 server address:

1. Use the locally stored address.
2. Retrieve a signed and encrypted address from Pastebin.
3. Use Nostr metadata to locate the current dead-drop Pastebin URL.

Once the server address is resolved, ROOFDECK communicates with the server over HTTP and WebSocket endpoints.

The Windows and macOS variants implement nearly identical functionality, including:

• Host, process, disk, and filesystem discovery
• Execution of individual shell commands and access to an interactive reverse shell
• File creation, deletion, movement, compression, download, and upload
• Clipboard read and write operations
• Background task management
• Persistence installation, removal, and status checks
• Changes to C2 and polling settings
• Agent updates, version checks, and destruction

Threat Attribution

Public reporting indicates that this campaign targets cryptocurrency and Web3 developers through trojanized developer tools that deliver cross-platform malware—tactics consistent with activity previously attributed to TraderTraitor.

Similar campaigns have leveraged trojanized applications, Python packages, and social engineering via fraudulent job offers. The use of FLATROOF and ROOFDECK malware also overlaps with findings reported in the KelpDAO incident.

ThreatLabz identified substantial overlap in tactics and targeting with TraderTraitor. However, ThreatLabz has not identified unique code similarities, shared infrastructure, or cryptographic links sufficient to independently attribute this campaign to TraderTraitor with high confidence.

Conclusion

This campaign highlights how threat actors abuse trusted developer workflows through trojanized Terraform providers to deliver cross-platform malware across macOS, Linux, and Windows systems. FLATROOF and ROOFDECK provide extensive capabilities for credential theft and persistent access. ROOFDECK also supports resilient C2 discovery through signed Pastebin files and Nostr metadata. Organizations should restrict the use of untrusted Terraform providers, verify provider checksums, and monitor for unexpected process activity to reduce the risk of developer workstation compromise.

Zscaler Coverage

The Zscaler Cloud Sandbox has been successful in detecting this campaign and its many variants. The figure below depicts the Zscaler Cloud Sandbox, showing detection details for the malware used in this campaign.

Figure 5: Zscaler Cloud Sandbox report for the malware used in this campaign.

In addition to sandbox detections, Zscaler’s multilayered cloud security platform detects indicators related to this campaign at various levels with the following threat names:

• OSX.Backdoor.FLATROOF
• OSX.Backdoor.ROOFDECK

Indicators Of Compromise (IOCs)

Host indicators

Network indicators

MITRE ATT&CK Framework