The Jade Sleet India IT provider disclosure broadens the defensive relevance of a campaign previously associated heavily with cryptocurrency targets. SentinelOne says it found the FLATROOF and ROOFDECK backdoors on an Apple Silicon Mac used by a DevOps engineer at an India-based IT-services company with no cryptocurrency ties. The same workstation was used for cloud and infrastructure work involving AWS, OVH and OpenStack and contained cloud and source-control credentials.
The most important evidence boundary is equally clear: SentinelOne did not establish how the two backdoors were originally delivered to this victim. The researchers separately documented weaponized Terraform-themed interview repositories used in the broader TraderTraitor campaign, but that campaign-level tradecraft should not be presented as the proven initial infection route for this Indian endpoint.
What SentinelOne actually confirmed
SentinelOne’s telemetry placed both FLATROOF and ROOFDECK on disk by March 18, 2026. The researchers later observed active execution on March 29, when a development workspace named cloudshield was opened in Cursor and the two implants launched seconds later.
The compromised system belonged to a DevOps engineer whose work included Terraform and Ansible and administration of AWS, OVH and OpenStack environments. SentinelOne says the endpoint also held source-control and cloud credentials. That makes the machine strategically important even without evidence that the attackers successfully used those credentials against downstream infrastructure.
Why the non-crypto India victim matters
TraderTraitor activity has frequently been discussed through cryptocurrency and Web3 intrusions. SentinelOne’s new victim is different: a smaller India-based IT-services provider with no cryptocurrency relationship. That does not prove a wholesale shift away from crypto targeting, but it shows that a privileged developer endpoint can be valuable because of the access it holds rather than the employer’s industry alone.
For IT-services companies, managed service providers and software teams, the key exposure is the trust placed in developer workstations. A DevOps engineer may hold source-control credentials, cloud sessions, deployment tools, infrastructure-as-code projects and access to multiple customer or production environments. Compromise of that endpoint can therefore create a route toward broader enterprise infrastructure even when the organization itself is not the attacker’s obvious end target.
SentinelOne’s Jade Sleet attribution is an assessment
SentinelOne associates the activity with TraderTraitor, which it also maps to Jade Sleet, UNC4899 and PUKCHONG. TPS treats that attribution as SentinelOne’s threat-intelligence assessment rather than an independently proven identity. The observed malware, endpoint timeline and victim characteristics are direct findings from SentinelOne telemetry; the actor linkage should remain explicitly attributed.
The initial infection route is still unknown
The chronology matters. Both backdoors were already present on disk by March 18. SentinelOne observed their first execution on March 29. A repository named terraform-candidate-repo was cloned later, on April 13. Because the implants pre-dated that repository activity, the available evidence does not support saying that the Terraform interview repository caused the original infection on this machine.
SentinelOne explicitly states that it could not prove how FLATROOF and ROOFDECK were initially delivered to this victim. TPS therefore does not treat a fake interview, malicious Terraform project or Cursor workspace as the confirmed initial-access vector for this incident.
How the weaponized Terraform repositories work
Separately from the unresolved initial-access question, SentinelOne documented weaponized infrastructure-engineering repositories used in the wider campaign. Examples included repositories such as Northwind-IAC, novacart-interview and terraform-candidate-repo.
The researchers found malicious .terraform.lock.hcl files that referenced attacker-controlled provider infrastructure designed to resemble legitimate registries. When a developer runs terraform init, Terraform can retrieve the provider specified by the project configuration and lock file. In a weaponized project, that trust path can be abused to deliver attacker-controlled code.
This is an abuse of project and repository trust rather than evidence that Terraform itself contains the vulnerability described in this campaign. Likewise, the fact that the malicious activity occurred around development work does not establish a vulnerability in Cursor.
What FLATROOF and ROOFDECK can expose
SentinelOne describes FLATROOF as an ARM64 macOS backdoor capable of executing shell commands and collecting information from the compromised system. Its collection capabilities include browser data, terminal history, installed applications, running processes, system information and a copy of the user’s login.keychain-db.
ROOFDECK provides broader reconnaissance and remote-operation capabilities, including file operations and shell functionality. In the context of a DevOps workstation, these capabilities matter because the endpoint may bridge local developer activity with source repositories, cloud infrastructure and production administration.
What DevOps and security teams should check now
- Treat privileged developer endpoints as sensitive infrastructure. Systems used for cloud administration, CI/CD, source control or infrastructure-as-code deserve monitoring comparable to other high-value administrative endpoints.
- Review SentinelOne’s published FLATROOF and ROOFDECK indicators. Hunt for matching malware artifacts, suspicious binaries and related infrastructure in endpoint and network telemetry.
- Investigate unexpected executables under user home directories. SentinelOne specifically highlights unsigned binaries and unusual execution paths as useful hunting signals.
- Review unusual IDE child processes and outbound connections. Unexpected processes launched around development workspaces or unexplained outbound TLS activity deserve investigation.
- Inspect unsolicited coding and interview repositories before execution. Review project files, dependency sources and Terraform provider references before running initialization or build steps on a privileged corporate endpoint.
- Check Terraform provider sources. Unknown or look-alike provider domains in project or lock files should be treated as suspicious until independently verified.
- Scope credentials based on actual compromise evidence. If a matching endpoint compromise is found, review and rotate affected cloud, source-control and infrastructure credentials according to incident-response findings rather than assuming every exposed service was successfully breached.
What the disclosure does not prove
The research does not establish that AWS, OVH or OpenStack environments belonging to this victim were successfully compromised. It does not establish that corporate source code was stolen, that customer systems were breached or that a software supply-chain compromise occurred. The endpoint’s access makes those consequences plausible areas for incident investigation, but they should not be converted into confirmed outcomes without evidence.
The report also does not identify the Indian IT-services company. TPS will not speculate about the victim’s identity from partial technical or organizational clues.
What could change next
This assessment should be updated if SentinelOne or another primary threat-intelligence source establishes the original infection route, identifies additional Indian victims, confirms downstream cloud or source-control access, publishes materially new FLATROOF or ROOFDECK variants, or changes the TraderTraitor/Jade Sleet attribution. Dedicated guidance from CERT-In would also materially change the India-specific reader state.
Verification note
TPS reviewed SentinelOne’s original September 18 threat research and reconciled the victim timeline, malware findings, campaign attribution, Terraform-repository evidence and defensive recommendations. The chronology was used to keep the broader Terraform lure tradecraft separate from the still-unproven initial infection method on this specific Indian DevOps endpoint.