Jade Sleet uses FLATROOF and ROOFDECK to attack macOS developers via Terraform

An intrusion campaign attributed to the North Korean group known as Jade Sleet again exposed how state actors prioritize developers and development environments to gain access to high-value networks. SentinelOne researchers have published that the opponent used back doors for macOS - identified as FLATROOF and ROOFECK- in an intrusion against an Indian IT service organisation and in previous incidents linked to the Web3 ecosystem, including the attack on the LayerZero bridge infrastructure that affected KelpDAO between March and April 2026.

Confirmed facts: SentinelOne determined that the operations included GitHub repositories created as lures of work interviews, Terraform block files (".terraform.lock.hcl") manipulated to target domains controlled by the attackers, and the implementation of two backdoors written in Rust for ARM macos. FLATROOF uses Telegram as a command and control channel (C2) and is able to run remote commands, transmit and receive files and extract sensitive data from the system and browsers. ROOFECK, for its part, uses the decentralized Nostr protocol for C2, performs system recognition, file handling, remote shell, lateral movement and persists through Launch Agents; in addition, its commands are signed and verified by cryptographic embedded keys, according to SentinelOne.

The security company also documented that the malicious artifacts were present in at least one MacBook with Apple Silicon owned by an Indian firm's DevOps engineer from March 18, 2026, although they remained inactive until March 29, when the beacon communications and other host activity began. The researchers noted that the initial execution occurred "seconds after" a work folder related to a project called cloud field was opened. An updated variant of ROOFDECK was deployed on that team on 20 April 2026; that binary removed symbols and debugging data to make detection difficult.

Context and verifiable background: Jade Sleet (also referred to in reports such as PUKCHONG, Slow Pisces, TraderTraitor or UNC4899) has a documented history of targeting projects and companies linked to cryptomonedas and Web3. In 2025 it was linked to a major theft - approximately $1.5 billion - against Bybit after a supply chain committed in the Safe {Wallet} developer environment. GitHub and security analysts have pointed out since at least 2023 that these types of actors tend to supplant job offers or technical projects to attract developers.

Where the attack fits technically: the initial vector confirmed in this campaign is social and repository-oriented. The attackers create repositories with technical issues related to the target and place a malicious .terraform.lock.hcl file that refers to a false supplier or module (e.g. domain names that mimic HashiCorp's official record). When the developer runs "terraform init" in a compromised working environment, Terraform download and install modules from those locations controlled by the attacker, allowing the execution of remote code and the subsequent deployment of backdoors. This pattern converts the developer's machine into pivot to access code, cloud credentials and pipelines.

Actual consequences and immediate risks: a compromised development workstation can expose secrets (APIs, cloud keys, CI / CD tokens), modify infrastructure as code, inject back doors into pipelines and facilitate side movements to repositories and productive environments. In the documented case, in addition to the risk of browser and key exfiltration (login.keychain-db), the presence of tools with persistence and remote execution capabilities increases the attacker's access window.

Differentiating the confirmed from the uncertain: it is demonstrated that FLATROOF and ROOFDECK were used and that the lures included .terraform.lock.hcl malicious. It is credible - but not fully publicly confirmed in all details - that the initial delivery was exclusively via Terraform in each victim; SentinelOne indicates that the exact delivery mechanism in the case of the committed Mac is not yet fully determined. There is also no complete public evidence of the final scope of any exfiltration in the above-mentioned Indian organization.

What companies and developers should do today: measures must be practical and prioritized by risk, because the protection of development endpoints is now critical.

- Avoid running initialization commands in unverified repositories: before "terraform init," inspect .terraform.lock.hcl and source code. It confirms that suppliers and modules come from official records. The official documentation of Terraform explains how "terraform init" works and the origins of modules: https: / / developer.hashicorp.com / terraform / cli / commands / init.

- Restrict the use of accounts with privileges in development stations: use accounts with less privilege for daily work and reserve high-impact credentials to controlled environments. Implement role-based access and environment separation policies.

- Strengthen the safety of macOS endpoints with behavior detection and EDR that understand Rust binaries and common techniques of persistence in macOS (Launch Agents, symbol removal, etc.). Maintain network telemetry to detect unusual beacons towards Telegram, Nostr or other decentralized channels.

- Protect secrets and rotate them after any suspicion of engagement: revoke and regenerate cloud keys, CI / CD tokens and credentials linked to the affected station. Aize and foresee the machine engaged before reusing it.

- Control of repositories and workflows: enable signature of commit and artifacts, verification of integrity in pipelines, and limitation of automatic execution of scripts from PRs or third-party forks. Code hosting platforms offer configurations to review contributions from external sources.

- Monitor observed indicators: check logs for connections to infrastructure associated with Telegram and Nostr nodes, terraform init activity in development environments, changes in Launch Agents and system key reading. In addition, the outgoing traffic to limit C2's ability to communicate without authorization.

For additional reading and context about this attack pattern and the growing priority of protecting endpoints from developers, you can consult the resources and analysis of security providers and technical platforms, including incident response blogs and official documentation of infrastructure tools: https: / / www.sentinelone.com / blog / and the home page of GitHub's blog where warnings about threats to developers are published: https: / / github.blog /.

In short, this incident is another clear example that compromising the supply chain or the environment of a single developer can be an entry door to much greater damage. The already known defenses - less privileges, verification of origins, rotation of secrets and detection focused on developers - remain the most effective countermeasures if applied with discipline and speed.