Executive Summary

• Following disclosure of the TraderTraitor attack against LayerZero in April 2026, SentinelOne identified an additional victim with the same macOS backdoors.
• Our analysis explores the mechanics of these backdoors and the expanded targeting against a victim in the IT services sector with no relationship to cryptocurrency trading.
• We also identified more weaponized GitHub repositories from the social engineering schemes used to target job seekers in these campaigns.
• This report expands on how Terraform lock files enable the delivery of malware from custom Terraform provider registries controlled by the attackers.

Overview

Throughout 2026, the financially motivated DPRK state-sponsored Lazarus subgroup TraderTraitor (aka UNC4899, PUKCHONG, Jade Sleet) has engaged in campaigns targeting entities involved in cryptocurrency trading, including a high-profile attack disclosed in April where USD 292 million was stolen from KelpDAO through a compromise of LayerZero.

KelpDAO is a decentralized finance (DeFi) protocol that supports restaking Ethereum; LayerZero provides services with the capability to exchange cryptocurrency across different blockchain platforms.

TraderTraitor compromised LayerZero and determined methods to create a fake cryptocurrency minting event, which the attacker combined with a DDoS against validation servers so that compromised servers would approve an illegitimate mint event, leading to the massive theft.

Following the public disclosure of this breach, SentinelOne identified an additional victim infected with the macOS backdoors, FLATROOF (aka macOS.Gaslight) and ROOFDECK, which were first observed in the LayerZero attack.

Unlike the previous high-profile victim, this target was a much smaller organization in the IT services industry. Our investigation revealed insights into what happens when this threat actor compromises a smaller organization that we believe ultimately yielded insufficient value to sustain the intrusion.

Weaponized Terraform Coding Projects

Each campaign related to this wave of activity uses social engineering via fake job interview lures, a traditional Contagious Interview approach common among DPRK actors. The attacker makes contact with job seekers from the company that is ultimately compromised; the GitHub profile of each targeted job seeker we identified falls into DevOps or cryptocurrency/FinTech engineering projects.

The GitHub repository themes for coding project lures are designed as infrastructure engineering projects related to the company that the DPRK actors are posing as. By pivoting from the gtn-candidate-repo repository shared by LayerZero in their incident report, we identified additional lures, which included references to the companies Northwind and Novacart.

It is unclear if these were fabricated companies used by the threat actor, or if they were posing as hiring teams from real companies with these names; one Northwind example describes it as an ecommerce company launching in the near future. Other repository names that we identified include:

• Northwind-IAC
• novacart-interview
• terraform-candidate-repo

The repositories contain a weaponized .terraform.lock.hcl file in the coding project with a custom provider that points to a domain controlled by the attacker. We identified three malicious provider domains across multiple repositories:

registry.hashicorp-aws[.]com
registry.hashicorp-aws[.]io
registry.hashicorp-terraform[.]io

When the victim runs terraform init with the weaponized lockfile in place, Terraform treats the custom provider as the source of truth, resulting in Terraform downloading and executing the malicious provider modules.

Developer awareness can lead to friction against this type of attack: in one repository, the candidate being interviewed added a note saying that they removed a typosquatted provider from the project’s original lock file, which may suggest they thought the interviewer was testing for their security awareness.

According to the LayerZero report, the attackers installed the FLATROOF and ROOFDECK macOS backdoors after an employee installed a weaponized interview coding project on their company workstation. TraderTraitor used the backdoors to collect API keys from the organization and to escalate privileges to expand into the victim’s Amazon Web Services and Google Cloud Platform environments.

While we lack insight into many of the subsequent infections resulting from the GitHub repositories we located, SentinelOne identified an unrelated victim by hunting through our telemetry for the macOS backdoors observed in the LayerZero attack.

Additional Victim

The Victim

The affected organization is an IT services provider based in India and unaffiliated with cryptocurrency. One endpoint was involved: an Apple Silicon MacBook belonging to a DevOps engineer. The engineer ran Terraform and Ansible against AWS, OVH and OpenStack on most working days, and the machine held cloud credentials and source control access: much like LayerZero’s “Developer1”. Individuals whose social media profile advertises infrastructure or DevOps work are candidates for this type of attack, and the value of the target is whatever their laptop can reach.

Infection Timeline

According to our telemetry on this host, both backdoors were on disk as far back as March 18, so we cannot prove how they were delivered. They remained dormant until March 29, when beaconing and host activity began.

The implants were first launched by Cursor on March 29, seconds after the cloudshield workspace was opened.

macOS Malware

We observed two malware families being deployed in the compromise, identical to the ones described in the LayerZero attack, named FLATROOF and ROOFDECK (by LayerZero and Mandiant). Both are ARM64 backdoors for macOS written in Rust.

FLATROOF

We observed the FLATROOF backdoor deployed under the name SystemUpdate to ~/Library/com.apple.iTunesCloud/SystemUpdate. It is likely intended for initial data collection from the victim machine and to deploy secondary payloads.

Immediately after starting, FLATROOF suppresses Gatekeeper by removing the com.apple.quarantine attribute from ROOFDECK and sets the executable bit on it; the second implant runs with no signature check and no user prompt.

xattr -rd com.apple.quarantine .../com.apple.internal.ck/iSync
chmod +x .../com.apple.internal.ck/iSync

A detailed analysis of FLATROOF (aka macOS.Gaslight) was published by SentinelLABS in June 2026. Here, we present a short summary of the backdoor’s capabilities as denoted by its supported C2 commands:

The backdoor also carries a data-harvesting Python module, used to gather the following data and exfiltrate them over Telegram using a built-in Telegram bot token:

• Chrome, Brave, Firefox, and Safari browser data
• Terminal command histories
• Installed application listings
• A running-process snapshot via ps aux
• System hardware and software profile via system_profiler
• A raw copy of login.keychain-db

ROOFDECK

ROOFDECK acts as a more sophisticated backdoor with broader reconnaissance and lateral movement capabilities. We observed it dropped under the name iSync to ~/Library/com.apple.internal.ck/iSync.

It is clear from the design of the implant that it is intended to be used as an additional deployment after initial foothold and control are established, since it needs a pre-existing configuration file containing at minimum a Nostr public key of an attacker-controlled profile to allow it to connect to its C2 server for the first time.

ROOFDECK uses a local configuration file ~/.config/.repl_history to store C2 URLs and keys and to set beaconing behavior.

Upon first execution, it pulls live Nostr relays from api.nostr[.]watch/v1/online and combines them with a hardcoded relay list belonging to legitimate Nostr services, then searches the relays for an operator’s profile on the Nostr network based on a public profile key given in the configuration file nostr_public_keys. When found, it reads the website field of the profile and uses that as its C2 URL. TraderTraitor has previously used Nostr.

The following is a list of Nostr relays used for operator profile discovery:

wss://relay.damus[.]io
wss://nos[.]lol
wss://nostr[.]mom
wss://relay.snort[.]social
wss://offchain[.]pub
wss://relay.nostr[.]band
wss://nostr.oxtr[.]dev
wss://nostr[.]wine

Persistence was achieved via a plist entry ~/Library/LaunchAgents/loginwindow.plist, with a dynamically specified application identifier string. It uses a hardcoded --type=renderer parameter to make the implant process appear legitimate.

ROOFDECK supports a wide variety of C2 commands for managing the implant, performing reconnaissance, exfiltrating data and executing attacker code. The C2 endpoint is hardcoded as /app_version. Polling for commands is done via HTTPS with a custom pinned TLS certificate embedded in the implant, shown below.

Interestingly, the malware author used default metadata settings with mkcert, which exposed that they are running on a Linux QEMU-based VM using the username ub. We identified multiple domains using a certificate containing this certificate CN (listed in the Indicators of Compromise section).

Subject = Issuer (self-signed):
    O  = mkcert development CA
    OU = ub@ub-Standard-PC-Q35-ICH9-2009
    CN = mkcert ub@ub-Standard-PC-Q35-ICH9-2009
Serial:    1CD6D13FF15ADBF7A42025D10EC99B4A
Key:       RSA 3072-bit
Validity:  2025-06-20 11:06:53 UTC -> 2035-06-20 11:06:53 UTC  (10-year mkcert default)

ROOFDECK commands are signed with the operator’s private key and their integrity is verified using an embedded public key before execution. The command functionalities are separated into distinct handlers in the source code. The implant re-implements many common shell commands related to directory and file operations, another tactic often used in more sophisticated North Korea-aligned toolsets, including Lazarus’ LightlessCan.

Session & Control

Execution

File system / data

Transfer

Reconnaissance / surveillance

All C2 commands are signed on the server side by an attacker-controlled private key. The public key is embedded in the ROOFDECK payload and is used to verify the origin and integrity of the issued commands before executing them.

-----BEGIN RSA PUBLIC KEY-----
MIIBCgKCAQEAzan/EObUVxXNfPHdkDyCVR0AC9apleciK9ZQw+neWo6q+wvAhnLp
Pe7FZLomuwntUgI3afLDblgw9t19Kh7w/8CVwFncxh4PdqtdYno4teQ6fDLKXSWa
ZBG7zZ9R22jxPpiY70XKilXJuds34q7pfzVfbLvLTmTWyTtcyrOnRSCOwEHP/gHX
0gX+8sdX7go6O37WwzB4zNvThS+E7hG+fVfrgEaH7IUi3RY9esuBS50UomfYefO3
dK1aDMDWIwVj1skacPR9LazEc6PSGjSXxzI/N2xcpP9QKXn/Pk6r9fBzudhBL3Mw
vWyNi03JbZGtGFiy6Wai6heJqgY7pF1PAQIDAQAB
-----END RSA PUBLIC KEY-----

Another version of ROOFDECK

On April 20, one day after LayerZero’s first public announcement of the KelpDAO incident, the attackers deployed a new version of ROOFDECK to the compromised machine (SHA-1: 5728b11d30586bbfc1d8bd12df1c722a06e767a2, path ~/Library/com.apple.appleaccountd/loginwindow) as an executable named loginwindow. 

After the new version initialized and started beaconing, the attackers used it to remove the old ROOFDECK and FLATROOF binaries. This new ROOFDECK was functionally identical to the previous one, but with stripped symbols and debug information, likely intended to more effectively evade detection. We can only speculate whether this was a reaction to LayerZero’s publication, but the timing is nevertheless interesting.

After the update, we observed intermittent beaconing activity to a new C2 server, grenight[.]com, until June 1. On June 17, the loginwindow binary was moved to Trash.

Conclusion

DPRK-aligned actors like TraderTraitor are leaning heavily into targeting developers to establish a foothold in a network, increasingly through fake job interviews. The incident we investigated shows that not every organization they infiltrate will become a viable target for a massive cryptocurrency theft.

These groups’ initial access efforts include targeting third parties and their software supply chain, which is where much of the industry’s exposure has moved, putting the developer endpoint at the center of the defense. Endpoints used for development carry access to cloud, pipelines and source code, which makes monitoring and protection a high priority for organizations. These campaigns use purpose-built development environments aimed at one engineer at a time, paired with backdoored Terraform builds that differ for each victim.

Recommendations

For organizations:

• We recommend flagging engineers with cloud engineering permissions and source control access as a sensitive group for endpoint security monitoring.
• Look for unsigned binaries executing from the home directory, integrated development environment (IDE) child processes that are not signed IDE components, and outbound TLS from either.
• Reports of interview take-home assignments and unsolicited repositories from these users are worth following up as well, since telemetry alone will not show that a recruiter sent one.
• Consider company policy that prevents using corporate workstations for external job interviews and consider how to enforce this type of policy.
• Educating developers with sensitive access is crucial: the weaponized Terraform provider domain was removed by one job seeker who flagged the typosquatted domain as suspicious. Organizations should add content to their security awareness training programs to highlight the risks of using projects with unknown origins as well as the nature of employees being targeted by threat actors to compromise the organization.

For developers:

• Before running a coding project containing a .terraform.lock.hcl file, ensure that the provider registry belongs to known good domains: anything that is not a known namespace following registry.terraform.io, the official provider domain, should be treated as suspect.
• Malicious packages can also be hosted on the official provider registry domain, so it is important to investigate the source of all packages when using an included lockfile. Terraform’s official registry supports browsing modules and providers, and modules contain a link to its source code.

This report is being published alongside a presentation at LABScon 2026, Don’t Call Us, We’ll Call Your APIs: Anatomy of an Expanding DPRK Multi-Cloud Intrusion. SentinelOne thanks Google and Mandiant for their partnership in providing technical details on this threat actor’s tools and techniques, and Nick Simonian for collaborating on this research.

Indicators of Compromise

IoCs (additional victim)

Custom certificate used for TLS communication

Host IoCs – ROOFDECK

Network IoCs – ROOFDECK

Certificate Domains related to “ub” user

Coding Challenge Repositories

hashicorp-aws[.]com Provider:

hashicorp-aws[.]io Provider:

hashicorp-terraform[.]io Provider: