Bring Your Own Runtime: Sophos MDR maps a repeatable Deno-based intrusion chain

Sophos MDR says it investigated multiple intrusion cases in early 2026 involving one threat activity cluster that consistently installed Deno, a legitimate JavaScript and TypeScript runtime, in order to execute malicious JavaScript directly in memory ^[1]. Initial access vectors differed between victims, but the malware, infrastructure and execution chains shared enough post-compromise behaviour that MDR describes a repeatable attack framework it continues to track ^[2][3].

The mechanic worth internalising is what Sophos calls Bring Your Own Runtime: rather than depend on whatever interpreters happen to exist on the host, the attackers downloaded and installed Deno themselves before running obfuscated JavaScript, mostly command-and-control payloads ^[4][5]. That converts execution from an environmental question into a delivery problem the attacker controls.

The staging around it is conventional. Social engineering, web-based delivery and malware masquerading as legitimate software provided the foothold; malicious MSI packages then dropped VBS and PowerShell loaders that retrieved, installed and executed the runtime ^[6][7]. Sophos reports heavy use of living-off-the-land binaries across both stages, naming msiexec, wscript, PowerShell, curl and tar ^[8]. The documented progression runs from PowerShell or command-based staging, to MSI execution, to VBS and PowerShell loaders, to Deno runtime deployment, to in-memory payload execution ^[9]. Of those five stages, the three in the middle held steady while variation clustered at the front, in initial access, and at the back, in secondary payload deployment ^[10][11]. Sophos states that staging mechanisms, runtime deployment techniques and C2 design remained highly consistent ^[12]. In one figure the firm compares process trees across four victims and reports that similarities outweigh differences ^[13].

The JavaScript run through Deno performed host fingerprinting, execution control checks and persistent C2 communication, and in some cases pulled and ran further payloads ^[14]. Those are ordinary capabilities. The point is the pathway they arrived on.

Sophos's own framing of the defensive problem is the part to argue with or act on: security tooling and behavioural detections are often optimised around established attack pathways and commonly abused scripting engines, and it reads the adoption of Deno as a move toward less commonly monitored runtimes for reliable execution ^[15][16]. That is a single vendor characterising its own telemetry, but it is testable in-house this week. If a detection stack alerts on PowerShell and wscript behaviour but treats an unfamiliar signed runtime binary spawning network-connected child processes as noise, the gap is specific and closable: inventory which interpreters your detections actually name, and check whether runtime installation by an MSI custom action or a loader script produces any alert at all.

Corroboration is thin but not absent. Sophos's Counter Threat Unit has been tracking ClickFix-involved Deno abuse in a later evaluation window and has published its own account ^[17], and Sophos points to ThreatDown documentation of a similar intrusion chain using Deno-based JavaScript execution to deliver Castle RAT ^[18].

What to watch: whether the uniform middle segment stays uniform, because that is where durable detection value sits, and whether the same BYOR pattern shows up with other runtimes now that the technique has been written up. Sophos also says its report includes analysis of a recovered malicious MSI covering staging, persistence, custom actions and payload delivery ^[19]; that artefact detail is where hunt queries will come from.