Back to Intelligence

Node.js Runtime Abuse: Detecting and Blocking node.exe Malware Delivery in Targeted Attacks

SA
Security Arsenal Team
September 4, 2026
13 min read

The Symantec Threat Hunter Team published a report this week documenting a technique that should be on every SOC's radar: threat actors are using the legitimate, trusted Node.js JavaScript runtime — node.exe — as a delivery and execution vehicle for malicious code. Campaigns leveraging this method have been observed since February 2026, targeting government departments, technology companies, and hotels.

This is not a vulnerability in Node.js. There is no CVE to patch. That is precisely what makes the technique dangerous. Attackers are abusing a signed, widely deployed, developer-trusted binary — a classic living-off-the-land (LotL) approach — to execute malicious JavaScript under the cover of a process most security tools and allow-lists treat as benign. If your EDR is tuned to trust anything signed by the Node.js Foundation, you have a blind spot the size of a runtime engine.

Defenders need to act now: baseline where Node.js legitimately runs in your environment, detect anomalous invocation patterns, and restrict runtime execution where it has no business existing.

Technical Analysis

What is being abused

Node.js is an open-source JavaScript runtime maintained by the OpenJS Foundation. node.exe (Windows) and the node binary (Linux/macOS) are digitally signed, frequently auto-updated, and commonly installed by developers, build pipelines, and bundled silently inside commercial applications (Electron-based apps, VS Code, Slack, Teams tooling, CI/CD agents). That ubiquity is the attack surface.

Why attackers choose node.exe

From a defender's perspective, the technique's appeal breaks down into four operational advantages for the adversary:

  1. Signed-binary trust. node.exe carries a legitimate signature. Application allow-listing policies, AV exclusions, and EDR heuristics frequently downgrade scrutiny of signed runtime binaries.
  2. Full system capability via JavaScript. Node.js is not a sandboxed browser engine. It exposes the child_process, fs, net, and crypto modules — meaning a single .js file can spawn commands, read/write arbitrary files, and open raw network connections with no additional tooling dropped to disk.
  3. Fileless and inline execution. node.exe -e "<script>" executes JavaScript directly from the command line, and scripts can be piped via stdin or downloaded in-memory. Payloads never need to touch disk as an executable, defeating hash-based and signature-based controls.
  4. Payload staging in plain sight. Malicious .js files blend into legitimate project directories (node_modules, AppData\Roaming\npm, web server roots), and Node's HTTP/HTTPS client capabilities make C2 traffic look like ordinary API calls.

Attack chain (as observed since February 2026)

Based on the Symantec Threat Hunter Team's reporting, the general chain follows this pattern:

  1. Initial access — typically a phishing-delivered loader or a compromised installer/dependency that plants a malicious JavaScript file (or retrieves one at runtime).
  2. Execution via node.exe — the runtime is invoked against a .js payload, an inline -e script, or a script staged in a user-writable directory such as %APPDATA%, %TEMP%, or a public profile path.
  3. In-process malicious activity — the script performs reconnaissance, spawns cmd.exe/powershell.exe children, establishes HTTPS C2, and pulls down follow-on payloads — all parented to or executed within the trusted node.exe process.
  4. Persistence — scheduled tasks, Run keys, or npm lifecycle hooks (e.g., preinstall/postinstall scripts in a planted package.json) re-invoke the runtime at logon.

Affected platforms and targeting

  • Platforms: Any system with Node.js installed — observed targeting Windows endpoints and servers in the reported campaigns; Linux build servers and developer workstations are equally exposed.
  • Sectors targeted: Government departments, technology companies, and hospitality (hotels).
  • Exploitation status: Confirmed active in-the-wild use in targeted attacks since February 2026. This is not a vulnerability and therefore has no CVE, CVSS score, or CISA KEV entry — it is abuse of legitimate functionality (MITRE ATT&CK T1218 – System Binary Proxy Execution in spirit, with T1059.007 – JavaScript as the execution technique).

The core defensive problem

You cannot patch this away. The only durable defenses are visibility (know where Node.js should and should not execute), constrained execution (application control policies that scope who can invoke runtimes and from where), and behavioral detection (alerting on how node.exe is being used, not merely that it ran).

Detection & Response

The detections below are tuned for precision. The highest-fidelity signals in most enterprise environments are: node.exe spawning command interpreters, node.exe executing inline scripts with -e/-p flags, node.exe running from user-writable or temp paths, and node.exe making outbound network connections on servers/endpoints where Node is not an expected workload. Baseline first — developer workstations and build servers will legitimately generate some of this telemetry.

Sigma Rules

YAML
---
title: Node.js Runtime Spawning Command Shell or Scripting Engine
id: 3f9c2a71-8b4d-4e1a-b6c2-7d5e9f0a1234
status: experimental
description: Detects node.exe spawning cmd.exe, powershell.exe, wscript, or other script interpreters, consistent with malicious JavaScript invoking child_process to run system commands, as reported in targeted Node.js runtime abuse campaigns.
references:
  - https://thehackernews.com/2026/09/attackers-turn-trusted-nodejs-runtime.html
  - https://attack.mitre.org/techniques/T1059/007/
author: Security Arsenal
date: 2026/09/24
tags:
  - attack.execution
  - attack.t1059.007
logsource:
  category: process_creation
  product: windows
detection:
  selection_parent:
    ParentImage|endswith:
      - '\node.exe'
  selection_child:
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\powershell_ise.exe'
      - '\pwsh.exe'
      - '\wscript.exe'
      - '\cscript.exe'
      - '\mshta.exe'
      - '\rundll32.exe'
      - '\regsvr32.exe'
      - '\certutil.exe'
      - '\bitsadmin.exe'
  condition: selection_parent and selection_child
falsepositives:
  - Legitimate build tooling, npm scripts, and installer frameworks that shell out during installs
  - Electron-based development workflows
level: high
---
title: Node.js Inline Script Execution via Command Line
id: 8a1e4b62-2c7f-4d9a-91e3-5b6c0d8f2345
status: experimental
description: Detects node.exe invoked with -e, --eval, or -p flags to execute JavaScript inline, a technique used to run malicious code without dropping a script file to disk.
references:
  - https://thehackernews.com/2026/09/attackers-turn-trusted-nodejs-runtime.html
  - https://attack.mitre.org/techniques/T1059/007/
author: Security Arsenal
date: 2026/09/24
tags:
  - attack.execution
  - attack.t1059.007
  - attack.defense_evasion
logsource:
  category: process_creation
  product: windows
detection:
  selection_image:
    Image|endswith: '\node.exe'
  selection_cli:
    CommandLine|contains:
      - ' -e '
      - ' --eval '
      - ' -p '
      - '--print '
  condition: selection_image and selection_cli
falsepositives:
  - Developers testing one-liner scripts interactively
  - Rare build pipeline usage of inline evaluation
level: medium
---
title: Node.js Execution from User-Writable or Temporary Path
id: c5d7f1a3-4e8b-4a6c-b2d9-1e3f5a7b3456
status: experimental
description: Detects node.exe executing a script from or running itself within user-writable directories such as AppData, Temp, or Public, consistent with staged malicious JavaScript payloads.
references:
  - https://thehackernews.com/2026/09/attackers-turn-trusted-nodejs-runtime.html
  - https://attack.mitre.org/techniques/T1059/007/
author: Security Arsenal
date: 2026/09/24
tags:
  - attack.execution
  - attack.t1059.007
logsource:
  category: process_creation
  product: windows
detection:
  selection_image:
    Image|endswith: '\node.exe'
  selection_path:
    CommandLine|contains:
      - '\AppData\Local\Temp\'
      - '\AppData\Roaming\'
      - '\Users\Public\'
      - '\ProgramData\'
      - '\Downloads\'
      - 'C:\Temp\'
      - 'C:\Windows\Temp\'
  filter_known:
    CommandLine|contains:
      - '\AppData\Roaming\npm\'
      - '\AppData\Roaming\npm-cache\'
  condition: selection_image and selection_path and not filter_known
falsepositives:
  - npm global package execution (largely filtered), portable Node.js installs, some Electron updaters
level: medium

KQL (Microsoft Sentinel / Defender)

KQL — Microsoft Sentinel / Defender
// Hunt: Node.js runtime abuse — anomalous node.exe execution patterns
// Covers: shell spawns, inline eval, user-writable path execution, and network activity
// Tables: DeviceProcessEvents / DeviceNetworkEvents (MDE), SecurityEvent (4688 via AMA)

let Lookback = 14d;
// --- Part 1: node.exe spawning command shells or LOLBins ---
DeviceProcessEvents
| where TimeGenerated > ago(Lookback)
| where InitiatingProcessFileName =~ "node.exe"
| where FileName in~ ("cmd.exe","powershell.exe","pwsh.exe","wscript.exe","cscript.exe",
                     "mshta.exe","rundll32.exe","regsvr32.exe","certutil.exe","bitsadmin.exe")
| project TimeGenerated, DeviceName, AccountName,
          ParentCmd = InitiatingProcessCommandLine,
          ChildProcess = FileName, ChildCmd = ProcessCommandLine,
          ReportId, DeviceId
| extend Detection = "node.exe spawned shell/LOLBin"
;
// --- Part 2: node.exe inline eval or script execution from user-writable paths ---
DeviceProcessEvents
| where TimeGenerated > ago(Lookback)
| where FileName =~ "node.exe"
| where ProcessCommandLine has_any (" -e ", "--eval", " -p ", "--print",
        "\\AppData\\Local\\Temp\\", "\\Users\\Public\\", "\\Downloads\\",
        "C:\\Temp\\", "C:\\Windows\\Temp\\")
| where ProcessCommandLine !has "\\AppData\\Roaming\\npm\\"  // suppress standard npm global bin
| project TimeGenerated, DeviceName, AccountName,
          NodeCmd = ProcessCommandLine,
          Parent = InitiatingProcessFileName, ParentCmd = InitiatingProcessCommandLine,
          ReportId, DeviceId
| extend Detection = "node.exe inline eval / user-writable path"
;
// --- Part 3: node.exe outbound network connections on non-developer assets ---
DeviceNetworkEvents
| where TimeGenerated > ago(Lookback)
| where InitiatingProcessFileName =~ "node.exe"
| where RemoteIPType == "Public"
| summarize Connections = count(),
            RemoteHosts = make_set(RemoteUrl, 25),
            RemoteIPs = make_set(RemoteIP, 25),
            Ports = make_set(RemotePort, 10)
        by DeviceName, InitiatingProcessAccountName, bin(TimeGenerated, 1h)
| where Connections > 50 or array_length(RemoteIPs) > 10   // beaconing / fan-out heuristic
| project TimeGenerated, DeviceName, InitiatingProcessAccountName,
          Connections, Ports, RemoteIPs, RemoteHosts
| extend Detection = "node.exe high-volume or fan-out outbound traffic"

Tuning guidance: Build an allow-list table (_GetWatchlist('NodeJsLegitHosts') or a custom NodeJsBaseline table) of developer workstations and CI/CD build agents, and append | where DeviceName !in (NodeJsBaseline) to each section. The network heuristic (Part 3) is your best catch-all for servers that should never run Node at all — invert it on those assets with no thresholding.

Velociraptor VQL

VQL — Velociraptor
-- Artifact: Node.js Runtime Abuse Hunt
-- Purpose: Identify suspicious node.exe execution — inline eval, scripts in
--          user-writable paths, shell children, and unexpected network sockets.

-- Part 1: Live processes matching suspicious node.exe patterns
SELECT Pid, Ppid, Name, Exe, CommandLine, Username, CreateTime
FROM pslist()
WHERE Name =~ '(?i)node\.exe$'
  AND (
       CommandLine =~ '(?i)( -e |--eval| -p |--print)'
    OR CommandLine =~ '(?i)(AppData\\Local\\Temp|Users\\Public|Downloads|Windows\\Temp)'
  )
  AND NOT CommandLine =~ '(?i)AppData\\Roaming\\npm\\'

-- Part 2: Network connections held by node.exe processes
SELECT Pid, Name, Status,
       Laddr.IP AS LocalIP, Laddr.Port AS LocalPort,
       Raddr.IP AS RemoteIP, Raddr.Port AS RemotePort
FROM netstat()
WHERE Name =~ '(?i)node'
  AND Status =~ 'ESTABLISHED'
  AND NOT Raddr.IP =~ '^(10\.|172\.(1[6-9]|2[0-9]|3[01])\.|192\.168\.|127\.)'

-- Part 3: Recently created .js files in high-risk staging directories (7 days)
SELECT FullPath, Size, Mtime, Btime
FROM glob(globs=[
  'C:/Users/*/AppData/Local/Temp/**/*.js',
  'C:/Users/*/Downloads/**/*.js',
  'C:/Users/Public/**/*.js',
  'C:/Windows/Temp/**/*.js'
])
WHERE Mtime > (now() - 604800)
ORDER BY Mtime DESC

Remediation & Hardening Script

This PowerShell script inventories Node.js installations and execution exposure, then applies AppLocker executable/script rules to restrict node.exe to approved paths. Test in audit mode first — broad blocking will break developer workflows and Electron apps.

PowerShell
#Requires -RunAsAdministrator
# Node.js Runtime Abuse — Inventory & Hardening Script
# Security Arsenal | September 2026
# Run Phase 1 everywhere. Run Phase 2 (enforcement) only after audit review.

$ReportPath = "C:\ProgramData\NodeJsHardening"
New-Item -Path $ReportPath -ItemType Directory -Force | Out-Null

# ---- Phase 1: Inventory — find every node.exe and unsigned/unexpected install ----
Write-Host "[*] Phase 1: Inventorying Node.js runtimes..." -ForegroundColor Cyan

$nodeBinaries = Get-CimInstance Win32_Process -Filter "Name='node.exe'" |
    Select-Object ProcessId, ExecutablePath, CommandLine,
                  @{N='User';E={$_.GetOwner() | ForEach-Object {"$($_.Domain)\$($_.User)"}}}

$nodeBinaries | Export-Csv "$ReportPath\RunningNodeProcesses_$(Get-Date -Format 'yyyyMMdd_HHmm').csv" -NoTypeInformation
$nodeBinaries | Format-Table -AutoSize

# Locate node.exe on disk outside sanctioned install paths
$sanctionedPaths = @(
    'C:\Program Files\nodejs',
    'C:\Program Files (x86)\nodejs'
)
Write-Host "[*] Scanning for node.exe in non-standard locations (this may take several minutes)..." -ForegroundColor Cyan
$rogueNodes = Get-ChildItem -Path 'C:\Users','C:\ProgramData','C:\Temp' -Recurse -Filter 'node.exe' `
    -ErrorAction SilentlyContinue | Where-Object {
        $p = $_.FullName; -not ($sanctionedPaths | Where-Object { $p -like "$_*" })
    }
$rogueNodes | ForEach-Object {
    $sig = Get-AuthenticodeSignature $_.FullName
    [PSCustomObject]@{
        Path      = $_.FullName
        SizeKB    = [math]::Round($_.Length/1KB,1)
        Modified  = $_.LastWriteTime
        SigStatus = $sig.Status
        Signer    = $sig.SignerCertificate.Subject
    }
} | Export-Csv "$ReportPath\NonStandardNodeBinaries_$(Get-Date -Format 'yyyyMMdd_HHmm').csv" -NoTypeInformation

if ($rogueNodes) {
    Write-Host "[!] WARNING: node.exe found outside sanctioned paths — review CSV and investigate." -ForegroundColor Red
} else {
    Write-Host "[+] No rogue node.exe binaries found in user-writable locations." -ForegroundColor Green
}

# ---- Phase 2: AppLocker restriction (AUDIT FIRST, then enforce) ----
# Allows node.exe only from Program Files; denies execution from user paths.
Write-Host "[*] Phase 2: Staging AppLocker rules for node.exe..." -ForegroundColor Cyan

$policyXml = @"
<AppLockerPolicy Version="1">
  <RuleCollection Type="Exe" EnforcementMode="AuditOnly">
    <FilePathRule Id="a1b2c3d4-0001-4000-8000-000000000001" Name="ALLOW: Node.js from Program Files"
                  Description="Permit sanctioned Node.js installs" UserOrGroupSid="S-1-1-0" Action="Allow">
      <Conditions><FilePathCondition Path="%PROGRAMFILES%\nodejs\*" /></Conditions>
    </FilePathRule>
    <FilePathRule Id="a1b2c3d4-0002-4000-8000-000000000002" Name="DENY: node.exe from user-writable paths"
                  Description="Block runtime execution from staging directories" UserOrGroupSid="S-1-1-0" Action="Deny">
      <Conditions>
        <FilePathCondition Path="%OSDRIVE%\Users\*\node.exe" />
        <FilePathCondition Path="%OSDRIVE%\ProgramData\*\node.exe" />
        <FilePathCondition Path="%WINDIR%\Temp\node.exe" />
      </Conditions>
    </FilePathRule>
  </RuleCollection>
  <RuleCollection Type="Script" EnforcementMode="AuditOnly">
    <FilePathRule Id="a1b2c3d4-0003-4000-8000-000000000003" Name="DENY: .js from Temp/Public/Downloads"
                  Description="Block JS payload staging locations" UserOrGroupSid="S-1-1-0" Action="Deny">
      <Conditions>
        <FilePathCondition Path="%OSDRIVE%\Users\Public\*.js" />
        <FilePathCondition Path="%WINDIR%\Temp\*.js" />
      </Conditions>
    </FilePathRule>
  </RuleCollection>
</AppLockerPolicy>
"@

$policyFile = "$ReportPath\NodeJsAppLockerPolicy.xml"
$policyXml | Out-File $policyFile -Encoding UTF8
Write-Host "[+] AppLocker policy staged at $policyFile (AuditOnly mode)." -ForegroundColor Green
Write-Host "    Review with: Set-AppLockerPolicy -XmlPolicy '$policyFile' -Merge" -ForegroundColor Yellow
Write-Host "    After 2+ weeks of clean auditing, change EnforcementMode to 'Enabled' and re-import." -ForegroundColor Yellow

# ---- Phase 3: Verify AppLocker service and logging are active ----
$ids = Get-Service -Name AppIDSvc -ErrorAction SilentlyContinue
if ($ids.Status -ne 'Running') {
    Set-Service AppIDSvc -StartupType Automatic
    Start-Service AppIDSvc
    Write-Host "[+] Application Identity service started (required for AppLocker)." -ForegroundColor Green
}
Write-Host "[*] Done. Review reports in $ReportPath before enforcing." -ForegroundColor Cyan

Remediation

Because this is abuse of legitimate functionality rather than a patchable flaw, remediation centers on control and visibility:

  1. Inventory Node.js across the estate. Enumerate every node.exe/node binary via EDR, SCCM/Intune, or the script above. Any runtime outside C:\Program Files\nodejs, sanctioned developer toolchains, or known application bundles is an investigation candidate.
  2. Constrain execution with application control. Use AppLocker, Windows Defender Application Control (WDAC), or Intune App Control policies to allow node.exe only from approved paths and deny it from user-writable directories. On servers with no Node workload, block the binary outright. Audit first; enforce after baselining.
  3. Enable script and command-line logging. Ensure process creation events with full command lines (Sysmon Event ID 1 or 4688 with command-line auditing) flow to your SIEM. Without command-line telemetry, the -e inline-execution technique is invisible.
  4. Hunt on behavior, not hashes. Deploy the Sigma/KQL logic above. Prioritize: node.exe spawning shells, inline eval flags, execution from Temp/AppData/Public, and unexpected egress from node.exe on production servers.
  5. Network-level containment. Egress-filter servers so that runtimes like node.exe cannot reach arbitrary internet destinations. Alert on node.exe establishing connections to newly registered or low-reputation domains — its HTTPS traffic otherwise blends into normal API chatter.
  6. Watch the supply chain angle. Audit package.json lifecycle hooks (preinstall, postinstall) in internally consumed packages and lock npm installs to vetted registries. A planted dependency is a natural delivery mechanism for this technique.
  7. EDR tuning. Confirm your EDR does not blanket-exclude signed runtime binaries from behavioral analytics. If it does, carve node.exe (and peers like python.exe, wscript.exe, mshta.exe) out of blanket trust.
  8. Targeted sectors take priority. Government, technology, and hospitality organizations are the confirmed targets. If you operate in those verticals, treat this as an active-threat hunt this week, not a backlog item.

Monitor the Symantec Threat Hunter Team's advisories and The Hacker News coverage for published IOCs as the campaign attribution matures, and feed any released hashes/domains into your blocklists.

The Bottom Line

Node.js joins a long line of trusted tooling — PowerShell, certutil, mshta, rundll32 — that attackers bend to their purposes because defenders trust the binary instead of scrutinizing the behavior. The organizations that catch this campaign will be the ones that stopped asking "is this file malicious?" and started asking "should this process be doing this, here, right now?" Baseline your runtimes, constrain where they can run, and alert on what they do.

Related Resources

Security Arsenal Incident Response Services AlertMonitor Platform Book a SOC Assessment incident-response Intel Hub

incident-responseransomwarebreach-responseforensicsdfirnodejs-abuseliving-off-the-landmalware-deliverysymantec-threat-hunterprocess-hollowing-lolbin

Is your security operations ready?

Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.

Book a SOC AssessmentSee AlertMonitor in Action