In April 2026, the DPRK-aligned group TraderTraitor (also tracked as Jade Sleet, UNC4899, and PUKCHONG) stole USD 292 million from the DeFi protocol KelpDAO by compromising LayerZero Labs, forging a fraudulent minting event and pairing it with a DDoS against validation servers so the fake mint would be approved. It's the kind of attack that gets a name and a headline.
The victim SentinelOne wrote up in September doesn't fit that mould at all. No cryptocurrency, no DeFi exposure, no minting event. Just an Indian IT services company, unrelated to crypto, and one Apple Silicon MacBook belonging to a DevOps engineer who ran Terraform and Ansible against AWS, OVH, and OpenStack most working days. SentinelOne's own framing is the line worth sitting with: “the value of the target is whatever their laptop can reach.”
That's the actual thesis of this piece. Not the ransom, not the wallet: the reach.
SentinelOne's telemetry shows both backdoors, FLATROOF and ROOFDECK, present on the machine as early as 18 March. They couldn't establish how the implants arrived; the company is candid about that gap. What they could reconstruct, to the second, is what happened next.
Nothing, for eleven days. Cursor was in daily use on the machine across 25 to 28 March. No malicious activity.
Then, on 29 March at 05:00:41 UTC, the developer opens a workspace: ~/DevOps-Automation/cloudshield. Five seconds later, at 05:00:46, Cursor's integrated terminal spawns a bash init-file process; a second after that, at 05:00:47, it gives way to a zsh -l login shell, which sources ~/.zshrc and ~/.zprofile as any login shell does. Six seconds after that login shell appears, at 05:00:53, twelve seconds after the workspace was first opened, Cursor's own parent process launches both implants via nohup, named SystemUpdate and iSync, each carrying a --type=renderer flag so they blend in with the ordinary Electron/Chromium helper processes an IDE like Cursor spawns constantly. Two seconds later, both are phoning home: FLATROOF to Telegram, ROOFDECK to a C2 host it resolves through a Nostr dead-drop, reading a public relay network for an operator profile and taking its C2 URL from that profile's “website” field. By 05:00:58, FLATROOF has stripped ROOFDECK's quarantine attribute and set its executable bit, so the second implant runs with no Gatekeeper prompt at all.
Fourteen seconds, start to C2, from opening a folder.
Three weeks later, on 20 April, one day after LayerZero Labs went public with the KelpDAO disclosure, the operators pushed a third implant to the same host, a stripped-down loginwindow binary that deleted both original implants outright. That timing suggests the operators were tracking coverage of their own campaign and moved to destroy evidence accordingly.
It would be tempting to read this as “AI coding assistant runs malware from a repo.” That framing is wrong, or at least unproven, and worth heading off before it hardens into folklore.
Nothing in SentinelOne's reporting shows Cursor's AI, its agent mode, or any LLM component interpreting content and deciding to execute anything. The process tree tells a much older story: a login shell spawned, and login shells source dotfiles on start. Whatever fired those nohup commands most plausibly lived in ~/.zshrc or ~/.zprofile already, planted whenever the backdoors were first delivered, and simply waited for the next login shell to come along and read it. Cursor's integrated terminal happened to be what spawned that shell. It could as easily have been Terminal.app, iTerm, or a VS Code integrated terminal; nothing about the mechanism described here is specific to an AI-assisted IDE. SentinelOne never published the dotfile contents, so this is the most consistent reading of their own timeline, not their stated conclusion, and should be treated as such.
SentinelOne's own recommendations back this reading. They don't tell defenders to sandbox their AI agents. They tell defenders to watch for “unsigned binaries executing from the home directory” and “integrated development environment (IDE) child processes that are not signed IDE components.” That's a process-monitoring gap, the kind CI runners get and developer laptops generally don't, not a vendor-hype-versus-reality story about agentic coding tools.
One detail resists a tidy explanation. Beaconing was “gated on Cursor sessions,” quiet whenever Cursor wasn't running. nohup'd processes are meant to survive independent of their parent terminal, so why execution tracked the IDE's own uptime isn't something SentinelOne explains, and isn't something this piece will guess at.
FLATROOF carries an alias worth knowing. SentinelOne's own September report calls it “FLATROOF (aka macOS.Gaslight),” pointing back to a separate SentinelLabs writeup from June. That report, by Phil Stokes, documents something genuinely novel: a 3.5 KB payload embedded in the binary, 38 fabricated “system” messages, Markdown-fenced and delimited with {{DATA}} tokens to mimic an LLM triage harness's own prompt scaffold. The aim, in SentinelOne's words, is to push “an LLM agent into aborting, truncating, or refusing analysis.” It attacks, as the title has it, the analyst, not the sandbox.
It's the mirror image of the prompt injection readers will recognise from compromised webpages and poisoned tool output. That familiar pattern targets an AI acting on a user's behalf, tricking it into an unauthorised action the user never asked for. Gaslight targets an AI acting on a defender's behalf, and the goal is inaction: get the LLM-assisted analyst to give up, not act out. Same underlying failure, an LLM that can't reliably separate adversarial data from a legitimate instruction, aimed in the opposite direction for the opposite outcome.
Whether the India host's own FLATROOF sample carries that specific payload is where the trail runs out, and it's worth being precise about why rather than papering over it. The two samples are not the same file. SentinelOne's June report gives the Gaslight sample's SHA-256 as 6328567511d88fdc2ae0939c5ef17b7a63d2a833881900de018a4f12f4982525 (SHA-1 1948f50831621e1a016a3bf3…), a real VirusTotal record, first submitted 22 May 2026, now flagged by 32 of 63 vendors, up from zero at the time SentinelOne wrote it up. The September report gives only a SHA-1 for the India host's SystemUpdate binary, 02df07a173ab03b82a4fb6a08973fff8b1467f28, and it has no VirusTotal record at all; querying it directly returns nothing, no file page, no fuzzy match. That's consistent with how each sample surfaced: Gaslight came from a public VT upload, the India sample came from SentinelOne's own endpoint telemetry on a private victim machine that was never submitted anywhere public.
So: confirmed, same malware family, on SentinelOne's own naming. Confirmed, different specific binary. Unconfirmed, and on current public evidence unconfirmable, whether the build that rode a login shell onto this DevOps engineer's Mac also carries the payload built to gaslight the analyst who eventually found it.
Strip away the AI framing and what's left is a supply-chain problem that predates any of this tooling: developer endpoints carry cloud credentials, source control access, and pipeline reach that most organisations still monitor like ordinary workstations. SentinelOne's own advice reads like a shorter version of an argument this publication has made before. Flag engineers with cloud and source-control access as a sensitive monitoring group, not because they're more careless, but because their laptops reach further. Watch IDE child processes the way you'd watch a CI runner's, not the way you'd watch a browser. Treat an unsolicited take-home coding assignment as a security event worth reporting, not just an HR curiosity, because telemetry alone won't show that a recruiter sent it.
None of that requires trusting an AI to make the call. It requires the same discipline this publication keeps returning to: explicit constraints, written down, before the automation goes anywhere near production. A login shell sourcing a dotfile is a decades-old attack surface. Wrapping it in a modern IDE didn't make it novel; it just made the blast radius bigger, because what's on the other end of that terminal now is a cloud engineer's full reach, not a text editor.
Editor's note: this piece sits alongside “If You Can't Trust the People Who Built It” and “The Sign-Out That Doesn't Sign You Out” as part of an ongoing thread on AI-adjacent tooling and the governance gaps that open around it.
The Sovereign Auditor covers digital sovereignty, cybersecurity governance, and data protection policy, with particular focus on Isle of Man jurisdiction and Crown Dependency issues.
Payments via PayPal. Credentials delivered by email. No Substack. No Stripe. No middlemen.
