You learned web shell detection on Microsoft Internet Information Services (IIS), and have relied on those skills for years. But as web frontends moved from static files to server-run JavaScript, Node became the runtime.
Maybe, for a while, you got by with traditional IIS rules. But then along came React2Shell, with attacker code running under the Node.js runtime on Windows and Linux alike. Your IIS rules still work on IIS, but ask yourself, which of them would have spotted React2Shell on Linux?
This blog covers four signals worth watching on Node servers, where the IIS playbook falls short, and how to check which ones your telemetry still captures.
Would your web shell rules even see a Node server?
Probably not. IIS rules key on w3wp.exe, .aspx files, and Sysmon events, and a Node server has none of these. Next.js and React Server Components sit behind an increasingly large share of modern frontends, and React2Shell turned them into web shell targets across cloud workloads and Kubernetes.
Up until relatively recently, web shell detection was a solved Windows problem. But then the stack changed, and the signals didn’t change with it.
Does process lineage still work?
Partly. Exploitation tends to call child_process.execSync to launch shells, curl, or ping, which means node spawning sh is the new w3wp.exe spawning cmd.exe. That makes node spawning a shell your first signal. And it’s a reliable one, because legitimate Node apps rarely launch shells.
Unfortunately, some payloads run entirely inside the Node process and never fork a child. In that case the process tree is empty, and an empty tree proves nothing, so you can’t treat it as a clean result.
What replaces the file write?
In IIS, a new .aspx in a served path runs on the next request, so alerting on that write made sense. But a production Next.js app works differently, with next build discovering routes from app/ and pages/ at build time, so the route is fixed until the next deploy. That means a dropped source file doesn’t become a new route.
A node shell doesn’t need a new route, because it can open its own HTTP listener on a new port and run commands through child_process. When the server runs Node, two signals take over from the file write:
- A new listening port: A node process starts listening somewhere it didn’t before.
- Writes to the app directory outside a deploy window: Changes that don’t line up with a release.
Who alerts on secrets access?
On IIS, secrets sat in web.config, including the MachineKey. On Node, they usually sit in environment variables. Attackers exploiting React2Shell went after cloud credentials, including instance metadata endpoints on Azure, AWS, GCP, and Tencent Cloud.
So, the Node equivalent of a MachineKey read is an environment variable dump or a metadata call. Alerting on either is your fourth signal. Finally, you need to figure out whether your SOC or cloud team alerts on that signal.
How do you tell a deploy from an attacker?
Node hosts add a new source of noise. Build pipelines and dependency installs at startup open ports and write to the app directory, and they look a lot like the signals above.
Provenance separates a deploy from an intruder. You need to ask where processes came from, whether a pipeline started it, and whether a release explains the write. An alert without that context forces analysts to hunt for it manually.
Teams that treat provenance as a core part of web shell detection can investigate every alert, including the false positives. They don’t need to turn them away and risk missing something important. This is how Prophet Security, among the leading AI SOC platforms for mid-market and enterprise SOCs and recognized in Rising in Cyber 2026, approaches web shell detection. Its AI Threat Hunter runs the retrospective sweep when no alert fired.
Which of the four signals does your telemetry capture?
List your Node-facing apps. For each one, ask whether your telemetry captures node spawning a shell, a new listening port, writes to the app directory outside a deploy window, and environment or metadata reads.
____________
Josh is a Content writer at Bora. He graduated with a degree in Journalism in 2021 and has a background in cybersecurity PR. He’s written on a wide range of topics, from AI to Zero Trust, and is particularly interested in the impacts of cybersecurity on the wider economy.
