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

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 KalpDAO 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