North Korea's TraderTraitor put macOS backdoors on an Indian IT provider, and the delivery was never proven

A 26 day gap the report does not close

The two backdoors were on the laptop by 18 March 2026. The fake interview repository that everyone assumes delivered them was not cloned until 13 April. That is 26 days the wrong way round, and it is the most honest sentence in an otherwise confident piece of research.

On 18 September 2026 SentinelLABS published an account of a North Korean intrusion into an unnamed IT services provider in India. The interesting part is not the attribution, which the firm largely inherits, but the candour: SentinelLABS found the malware in its own telemetry and worked backwards, and it states plainly that for this victim it cannot prove how the implants were delivered. The friendly story, a developer tricked into running a booby-trapped coding task, is the story of a different victim. Here the evidence runs out before it reaches the door.

What the report establishes, and what it leaves open

Strip the report to load-bearing facts. One endpoint was involved: an Apple Silicon MacBook belonging to a DevOps engineer at an Indian IT services provider with no connection to cryptocurrency. On that machine SentinelLABS observed two Rust backdoors for ARM macOS, FLATROOF (dropped as SystemUpdate) and ROOFDECK (dropped as iSync), the same pair seen in the LayerZero Labs intrusion that led to the KelpDAO theft. Both were on disk from 18 March, sat dormant, and first executed on 29 March when the code editor Cursor opened a workspace and, within seconds, launched them.

The attribution is not SentinelLABS testing North Korea from scratch. The chain of custody runs through the LayerZero Labs incident report of 18 May 2026, where Mandiant and CrowdStrike attribute the crypto heist to the DPRK with high confidence and, more specifically, to UNC4899 with medium confidence. SentinelLABS ties the Indian victim to that campaign by matching the backdoors, then reasons that the same actor is responsible. That is a defensible inference. It is still an inference, and the confidence in the actor sub-cluster was only medium at source.

Read against the SentinelLABS report of 18 September 2026 and the LayerZero Labs report of 18 May 2026

Stated in the sources	Not stated
Two macOS backdoors, FLATROOF and ROOFDECK, on one DevOps engineer's MacBook	The name of the Indian provider, or its size beyond 'much smaller'
Implants on disk from 18 March, first execution 29 March via Cursor	How the implants were delivered to this specific victim
The machine held cloud credentials and source control access	Whether the attacker used them, or reached any client system
Attribution to DPRK, high confidence; to UNC4899, medium confidence (LayerZero report)	Any independent, high confidence attribution of this Indian victim to the group
The intrusion 'yielded insufficient value to sustain', in the vendor's assessment	Whether any data was exfiltrated from this victim at all

The last row matters. SentinelLABS assesses that the actor walked away because the target was not worth the effort, and the timeline supports it: the final beacon in the collected telemetry was on 1 June, and the last backdoor binary was moved to the Trash on 17 June. But 'we saw it stop' is not the same as 'nothing was taken'. A single endpoint's telemetry cannot rule out exfiltration that left no trace on that endpoint.

The lure that is documented, and the one that is not

The documented delivery method across this campaign is elegant, and worth understanding even though it may not be how this victim was hit. The actor poses as a hiring team, shares a GitHub repository framed as an infrastructure engineering take-home task, and waits for the candidate to run it. The weapon is a file most engineers treat as inert: .terraform.lock.hcl, the Terraform dependency lock file.

A lock file exists to pin dependencies so a project is reproducible. HashiCorp's own guidance describes a trust on first use model: Terraform records a provider's checksums the first time it sees them and errors later if they change. The subtle move here is that the malicious lock file names a provider whose registry is not the official registry.terraform.io but a typosquat: SentinelLABS lists registry.hashicorp-aws[.]com, registry.hashicorp-aws[.]io and registry.hashicorp-terraform[.]io. When the candidate runs terraform init, Terraform treats the pinned custom provider as the source of truth and downloads and executes attacker-controlled modules. The lock file, the artefact that is supposed to guarantee integrity, is the thing that carries the payload.

For the Indian victim, none of that chain is proven. The implants predate the clone of terraform-candidate-repo by more than three weeks. SentinelLABS says only that both backdoors were present 'as far back as March 18' and that the delivery mechanism is unknown. The interview repository the engineer did clone, on 13 April, is real, but it lands after the machine was already compromised. Treat the lure as the campaign's signature, not as this incident's confirmed entry point.

What the two backdoors actually do

FLATROOF is the first-stage collector, also documented in June 2026 as macOS.Gaslight. It talks to its operator over the Telegram Bot API, which means its command and control rides ordinary HTTPS to a service most networks allow. Its command set is small: id, shell, kill, upload, stop. Its value is a bundled Python module that copies Chrome, Brave, Firefox and Safari browser data, terminal command histories, an application inventory, a process snapshot, a system_profiler hardware and software profile, and a raw copy of login.keychain-db, the macOS login keychain. On first run it also strips the quarantine attribute from ROOFDECK and sets it executable, so the second implant runs with no Gatekeeper prompt and no signature check.

ROOFDECK is the heavier tool, and its tradecraft is the tell. For command and control it does not hard-code a server. It reads a public key from its config, looks that operator up on the Nostr network, a decentralised social protocol, and takes the operator's C2 URL from the website field of their profile. Commands are signed with the operator's private key and verified against an embedded public key before they run. It carries handlers that re-implement common shell commands for file operations, a trait SentinelLABS notes in more sophisticated North Korea-aligned toolsets. It persists as a LaunchAgent disguised with a --type=renderer argument to look like a browser helper process. Its screenshot command, tellingly, returns 'not implemented yet': this is tooling still under construction.

The reassuring labels are not controls

Three comforting phrases are doing quiet work in coverage of this story, and each is a label rather than a defence.

'A lock file.' The word implies safety: pinned, verified, reproducible. Trust on first use means the lock file guarantees only that you keep getting the same provider you were first pointed at. If that provider was an attacker's from the start, the lock file faithfully preserves the compromise.

'We have EDR.' At LayerZero Labs, the report states, endpoint detection and response was running on the developer's device and did not detect the malware, and identity access management with SSO and mandatory MFA was enforced and did not stop the session-key theft that followed. The same two backdoors then appeared on the Indian provider. A control that a well-resourced crypto firm had switched on, and that still missed these tools, is not a box you can tick and stop thinking.

'An IT services provider' and 'much smaller organisation.' The size is offered almost as reassurance, a lesser victim. Invert it. A provider whose whole business is running other people's IT is, by definition, a machine with credentials into many other estates. SentinelLABS is explicit that the value of such a target 'is whatever their laptop can reach'. Smaller does not mean lower blast radius.

Separating method from accusation

It is worth being precise about who did what, because the two halves of this report carry different weight. The method is strong and checkable: SentinelLABS hunted its own product telemetry for the file hashes and behaviours seen at LayerZero Labs, found a second host carrying them, and reconstructed a minute-by-minute timeline from process and network events. That is forensics on data the firm holds, and the indicators are published for anyone to verify.

The accusation, that this is North Korea's TraderTraitor, is an overlay. It rests on shared malware with an intrusion that Mandiant and CrowdStrike attributed, and on the campaign's known interview-lure pattern. Shared tooling is good evidence but not proof of the same operator, and the source attribution to the specific sub-group was medium confidence. None of this is a reason to doubt the finding. It is a reason to write 'linked to' rather than 'carried out by', which is what the careful sources do.

Were the provider's clients affected? The report does not say

This is the question a UK reader most wants answered, and it is the one the sources most clearly leave open. For the Indian provider, SentinelLABS describes access on the laptop, cloud credentials and source control, but states no use of them and names no client. It even assesses that the intrusion yielded too little to sustain. If that holds, the one-to-many disaster did not happen here.

The comparison case is why nobody should relax. At LayerZero Labs the same backdoors gave the attacker a developer's session keys, which opened the cloud environment, which let them poison two RPC nodes and forge a cross-chain message that unlocked 116,500 rsETH, about 292 million dollars. That was possible because the affected application ran a single-verifier configuration, so one compromised path was enough. The lesson is not about crypto. It is that this actor's first move is a developer's endpoint, and its second is to inherit whatever that endpoint can reach. A managed service provider's engineer can often reach a great deal more than one company.

The UK angle: you may not be the target, but you may be downstream

No UK entity is named, and the direct lure targets individual developers, not their employers' procurement. The UK exposure is structural: a large share of British IT support, application maintenance and DevOps work is delivered by managed service providers with delivery centres in India. Those providers hold standing, privileged access into UK client estates. An engineer compromised at the provider is a foothold inside its clients' supply chain, whether or not this particular intrusion went that far.

UK policy is moving to meet exactly this. The Cyber Security and Resilience Bill, introduced to Parliament on 12 November 2025 and at report stage in the Lords by autumn 2026, will bring medium and large managed service providers into the scope of the NIS Regulations, with the Information Commission as regulator and a duty to report significant incidents. The government's own factsheet says MSPs' 'widespread and trusted access to their clients' networks' creates a 'one to many' impact, and the definition reaches providers based overseas that serve UK customers. The direction is set. It is not yet in force, and the technical detail comes later in secondary legislation, so the contractual questions below are the lever you have this week.

What to do, in the order worth doing it

The question that exposes the gap

The reassuring reading of this report is that a state actor broke into an outsourcer, found little of value, and left. Maybe. But the report cannot tell you how the backdoors arrived, cannot rule out what left the machine, and cannot see past the one endpoint it had telemetry for. So the question to carry into your next supplier review is not 'were they breached'. It is: if one engineer at our IT provider were quietly compromised for 75 days, which of our systems would show us nothing, and who in our contract is supposed to be looking?