This is a very interesting intrusion using deno.exe in a way I haven’t personally seen before.
What stands out here is not just Deno itself, but the full execution chain and how multiple runtimes are stitched together.
It starts via an MSI that launches a VBS script. VBS acts as the initial orchestrator: it drops and runs PowerShell, installs Deno, writes a JavaScript runner to %LOCALAPPDATA%, and explicitly creates a Startup LNK for persistence. That LNK points to a hidden PowerShell command which executes deno run --allow-all romeo_worker74.cjs(good detection opportunity!!), ensuring execution on every user logon.
From there, Deno takes over as a loader/backdoor. It fingerprints the host, reaches out to sharecodepro\.com, and waits for server-delivered modules.
It then kicks off a scheduled task that runs pythonw.exe from C:\ProgramData\<random_chars>\, executing a Python backdoor. Defender exclusions are added for the Python path to reduce visibility. The Python component connects to 23\.94\.145\.120:9999 as its main C2 and also queries ip-api\.com for basic situational awareness.
PowerShell is additionally used to retrieve more payloads (Petuhon\.zip, Smokest120\.zip), indicating parallel tooling or follow-on stages.
In short, this is a multi-stage, multi-language intrusion:
VBS for orchestration and persistence
PowerShell for payload delivery
Deno as a modular execution framework
Python as a secondary, more traditional C2 channel
Lightweight components, user-level persistence, and flexible server-driven capabilities. The execution pattern is the most interesting part here. I'll update this post if anything else.
Possible interesting "topwebcomicsv1.msi": 5a1c14335d0a8b007ff2813e6ef738e8836be38257cc82fe03c02b71d71e1b01
It is using Deno, "the next-generation JavaScript runtime". Seeing malware using Deno is not a common thing, at least yet...
🤷♂️