That is the latest finding from SentinelOne, which has uncovered another victim of the TraderTraitor campaign, a DPRK-linked threat cluster also tracked as UNC4899, PUKCHONG and Jade Sleet. The discovery is significant for one reason in particular: the victim had no connection to cryptocurrency. The campaign shows how TraderTraitor is broadening the value it sees in developer machines. The target does not have to operate a crypto exchange, manage digital assets or hold cryptocurrency. If one developer’s laptop can reach cloud infrastructure, source code, credentials or production systems, it can be valuable enough to attack.
SentinelOne’s investigation, published on September 18, 2026, found the same two macOS backdoors previously associated with the LayerZero incident: FLATROOF and ROOFDECK. Researchers also identified additional weaponized GitHub repositories apparently used as coding challenges in fake recruitment approaches.
The case adds another warning to a growing body of evidence that developer environments have become a frontline security boundary.
From Crypto Theft to Developer Access
TraderTraitor has previously been associated with attacks against cryptocurrency-related organizations.
In April 2026, SentinelOne reported that the group had compromised LayerZero in an operation connected to the theft of approximately $292 million from KelpDAO, according to the company’s investigation. The attackers reportedly used access to create a fraudulent cryptocurrency minting event while disrupting validation infrastructure with a DDoS attack.
The newly investigated victim was very different.
SentinelOne identified an IT services provider in India with no cryptocurrency business. Only one endpoint was involved: an Apple Silicon MacBook used by a DevOps engineer.
That engineer routinely worked with AWS, OVH and OpenStack using Terraform and Ansible. The machine also had access to cloud credentials and source-control systems.
In other words, the attacker did not necessarily need to compromise the company’s central infrastructure first.
The developer’s workstation already provided a potential bridge.
The Fake Job Interview Became the Attack Vector
The campaign follows a tactic increasingly associated with DPRK-linked operations: fake job interviews and coding assignments.
The attacker approaches a developer or job seeker, posing as a potential employer or recruiter. The candidate is then given what appears to be a legitimate infrastructure or software engineering task.
The projects identified by SentinelOne were designed around infrastructure engineering and included repositories such as:
Northwind-IACnovacart-interviewterraform-candidate-repogtn-candidate-repo
The names alone are not evidence that the organizations referenced in them were involved. SentinelOne said it remains unclear whether some of the names represented fabricated companies or whether the attackers were impersonating real businesses.
The dangerous element was hidden deeper inside the project.
The Terraform Lock File Trap
Terraform is widely used to automate cloud infrastructure. Its dependency lock file, .terraform.lock.hcl, records provider selections and checksums so teams can reproduce consistent environments.
HashiCorp’s documentation explains that Terraform uses the lock file when installing providers and that teams commonly commit it to version control. The file is therefore an important part of the infrastructure-as-code workflow.
That normal behavior is exactly what the attackers attempted to abuse.
SentinelOne found weaponized lock files containing references to custom provider domains controlled by the attackers, including:
registry.hashicorp-aws[.]comregistry.hashicorp-aws[.]ioregistry.hashicorp-terraform[.]io
These domains were designed to resemble legitimate infrastructure associated with HashiCorp and Terraform.
Once a victim ran terraform init with the malicious configuration in place, Terraform could be directed toward the attacker’s provider infrastructure, allowing malicious provider code to be downloaded and executed.
HashiCorp itself notes that Terraform can use providers from alternative origin registries and that organizations can operate private provider registries. It also warns that lock-file information alone does not automatically establish that a provider is trustworthy.
That distinction matters.
A lock file can help ensure that the expected provider package is used. It does not mean the dependency was trustworthy when it was first introduced.
One Developer Actually Spotted the Trick
There was also an encouraging detail in SentinelOne’s investigation.
In one repository, the candidate removed a typosquatted provider from the original lock file and left a note indicating that the suspicious provider had been identified.
That suggests the candidate may have recognized the domain as suspicious or interpreted the unusual provider as a security test.
It is a useful reminder that developer awareness can interrupt an attack before technical controls ever need to respond.
For organizations looking to strengthen this human layer, cybersecurity awareness and professional training should specifically address developer-targeted social engineering, malicious dependencies and infrastructure-as-code risks rather than relying only on conventional phishing examples.
FLATROOF and ROOFDECK: What Happened on the Mac?
SentinelOne found two ARM64 macOS backdoors on the compromised system: FLATROOF and ROOFDECK.
FLATROOF was found under a filename designed to look legitimate:
~/Library/com.apple.iTunesCloud/SystemUpdate
It can execute shell commands, terminate processes and upload files. SentinelOne also found functionality capable of harvesting browser information, terminal histories, installed applications, running processes, system information and a copy of the macOS login.keychain-db.
ROOFDECK was found as:
~/Library/com.apple.internal.ck/iSync
It provides substantially broader capabilities, including command execution, file discovery, file transfer, reverse shells, process enumeration and persistence.
It can also access the macOS clipboard – potentially exposing information copied by the user, including credentials, sensitive data or cryptocurrency-related strings.
The malware used Nostr infrastructure to help discover command-and-control information and employed signed commands to control what the implant executed.
The Attack Stayed Quiet
The timeline is particularly revealing.
SentinelOne’s telemetry showed that the malware was already present on the Mac by March 18, 2026, although researchers could not establish exactly how it arrived.
The implants remained largely dormant until March 29.
At approximately 05:00 UTC, the developer opened a workspace in the Cursor development environment. Seconds later, Cursor spawned shell processes and launched both malicious implants.
The malware then established outbound command-and-control communications.
The backdoors continued beaconing while Cursor sessions were active, according to SentinelOne’s telemetry.
On April 13, the developer cloned another Terraform-related GitHub repository – adding another data point linking the developer workflow to the campaign.
On April 20, one day after LayerZero publicly discussed its incident, the attackers deployed a newer ROOFDECK variant.
That version subsequently removed the original malware from the machine and continued communicating with a new command-and-control server until June 1.
The timing does not prove that the malware update was a direct reaction to the LayerZero disclosure. SentinelOne explicitly treats that relationship as speculation. But the sequence illustrates how quickly operators can modify malware after their infrastructure or techniques become public.
Why Developer Laptops Are Becoming High-Value Targets
This incident reinforces a shift already visible across software supply-chain attacks.
Developer machines frequently have access to:
- Cloud credentials
- Git repositories
- SSH keys
- API tokens
- CI/CD systems
- Infrastructure-as-code
- Production configuration
- Internal documentation
- Corporate VPNs
- Package registries
That makes a developer endpoint fundamentally different from an ordinary employee workstation.
A compromised laptop can become an access broker into much larger environments.
Cybercory recently reported on the SleeperGem supply-chain campaign, which similarly focused on developer machines rather than relying exclusively on traditional production-server compromise.
The broader trend is clear: attackers increasingly understand how software is built and are targeting the people, tools and dependencies involved in that process.
Our recent coverage of DPRK-linked software supply-chain activity also highlighted how threat actors are experimenting with unconventional techniques to establish and maintain command-and-control channels.
Why This Matters for the Middle East and Africa
The campaign has no reported geographic limitation to the Middle East or Africa, and SentinelOne’s newly identified victim is in India.
Nevertheless, the attack model is highly relevant to organizations across MEA.
Cloud engineers, DevOps teams and software developers in banks, fintech companies, telecom operators, government agencies, technology companies and digital-service providers often have exactly the combination of access that makes these systems attractive.
As organizations across the Gulf and Africa accelerate cloud migration and digital transformation, developer workstations increasingly sit close to critical infrastructure.
That makes cloud security, endpoint security, identity protection and software supply-chain security interconnected problems rather than separate security projects.
Organizations can review their exposure through dedicated cybersecurity assessment, cloud security and vulnerability management services.
10 Actions Security Teams Should Take
1. Treat developer endpoints as high-value assets
Identify developers, DevOps engineers and cloud engineers who have privileged access to source code, cloud environments and CI/CD platforms. Apply enhanced endpoint monitoring to these systems.
2. Inspect .terraform.lock.hcl files
Do not automatically trust a lock file simply because it exists in a Git repository.
Review provider source addresses, versions and hashes before executing unfamiliar Terraform projects.
3. Verify the provider registry
For unfamiliar projects, confirm that provider addresses point to expected and trusted registries. Terraform’s official documentation explains how provider sources and origin registries work.
4. Investigate typosquatted domains
A provider address that resembles a legitimate domain by only a few characters should trigger investigation.
Typosquatting remains effective because developers are accustomed to copying commands and configuration from external projects.
5. Restrict external coding projects on corporate devices
Organizations should consider policies governing job interviews, freelance projects and other external coding assignments on company-managed machines.
Where appropriate, provide an isolated environment for employees who need to inspect untrusted code.
6. Monitor IDE child processes
Security teams should investigate unusual processes spawned by development environments such as Cursor, VS Code and other IDEs.
An IDE launching an unexpected unsigned executable from a user’s home directory deserves investigation.
7. Hunt for suspicious macOS persistence
Look for unusual files under ~/Library/LaunchAgents/, particularly plist files configured to launch unfamiliar executables automatically.
Also investigate suspicious binaries masquerading as Apple components.
8. Protect and rotate cloud credentials
Developer endpoints should not provide unrestricted, long-lived access to production environments.
Use short-lived credentials, strong identity controls, MFA and least privilege wherever practical.
9. Monitor outbound connections from development tools
Unexpected outbound TLS connections from an IDE, shell or development process should be investigated, especially when the destination is not associated with an approved development service.
10. Train developers against targeted social engineering
Security awareness programs should include realistic examples of fake recruiters, coding challenges, GitHub repositories, malicious dependencies and Terraform provider attacks.
The objective is not simply to tell developers “don’t click suspicious links.” They need to understand how a legitimate-looking engineering task can become the initial access mechanism.
Organizations can strengthen this capability through cybersecurity training and awareness programs tailored to developers, DevOps teams and privileged technical users.
What Developers Should Check Before Running a Coding Assignment
For individual developers, the safest assumption is simple: code received from an unknown recruiter is untrusted code until proven otherwise.
Before running a project:
- Read the
READMEinstead of immediately executing commands. - Inspect
terraform.tfand provider declarations. - Open
.terraform.lock.hclmanually. - Verify every provider source address.
- Check whether the provider actually exists in the expected registry.
- Investigate unfamiliar domains.
- Avoid using production credentials during interviews.
- Use a disposable virtual machine or isolated environment when possible.
- Do not connect an interview project to corporate cloud accounts.
- Report suspicious repositories to your security team.
HashiCorp recommends reviewing provider signing information and notes that its tooling cannot automatically determine whether a provider is trustworthy or complies with an organization’s own security policies.
That is an important distinction for DevOps teams: cryptographic integrity and organizational trust are not the same thing.
The Bigger Lesson
TraderTraitor’s latest activity is less about cryptocurrency than it initially appears.
The cryptocurrency sector may have been an important target, but the underlying technique is much broader: identify people with valuable technical access, approach them through a trusted professional context, give them something that looks like legitimate work, and let their own development tools execute the attack.
That model can work against a bank, cloud provider, technology company, government contractor or software startup just as effectively as it can against a crypto business.
The SentinelOne investigation also demonstrates why developer security cannot stop at endpoint antivirus or dependency scanning. The attack crosses several layers at once: social engineering, GitHub repositories, Terraform, provider registries, macOS, cloud credentials and command-and-control infrastructure.
For security leaders, the practical takeaway is straightforward: the developer workstation is now part of the software supply chain — and therefore part of the organization’s critical attack surface.
Protecting it requires more than securing the laptop. It requires controlling what code developers execute, where dependencies come from, which credentials they can access, and how quickly suspicious activity can be detected.
Source: SentinelOne, “Don’t Call Us, We’ll Call Your APIs: TraderTraitor Backdoors Resurface on Victim With No Crypto Ties,” September 18, 2026.
Related Cybercory coverage: SleeperGem: Developer Machines Become the New Supply-Chain Battlefield (cybercory.com); DPRK Cyber Operators Pivot to NullReceiver (cybercory.com)
