Hospitality Under Fire: Photo ZIPs Dropping Node.js on Front-Desk Machines

Solid query. The biggest issue we face with hospitality clients is that front-desk staff are trained to open attachments from strangers. It's part of their workflow for visa verification and bookings.

We've started deploying ThunderMap rules specifically looking for javascript or js extensions inside ZIPs, even if they claim to be images.

Also, check your proxy logs. If the implant is beaconing out, it's likely hitting domains that haven't been seen before in your environment. Correlating the Node.js spawn with an outbound connection to a non-whitelisted CDN or IP is usually the smoking gun.

I manage an MSP for several smaller hotel chains. We don't typically see node.exe installed on front-desk terminals unless the PMS vendor uses a web-based local client (Oracle Opera or similar).

If you suspect compromise, check for unsigned PowerShell scripts executing in user context. Often these Node.js implants are wrapped in a PS1 launcher for persistence. You can hunt for that with:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4688} | Where-Object {$_.Message -match 'node.exe' -and $_.Message -match '-NoProfile'}

This specific campaign seems to rely heavily on the 'urgency' of a guest arrival, so user awareness training is going to be 90% of the fix here.

The use of Node.js is interesting because it allows the payload to be easily obfuscated. The 'Photo ZIP' lure is classic social engineering, but the tech stack suggests the actors are comfortable with web tech stacks.

From a pentester perspective, if you can't block ZIPs entirely, force enable Mark of the Web (MotW) on downloads coming from the internet. Then, ensure your Attack Surface Reduction (ASR) rules are set to block Office apps from creating child processes and Win32 API calls from executable content. It won't stop the initial zip extract, but it stops the follow-through.

Good point, Dylan. From an email security perspective, the challenge is flagging these archives before they hit the endpoint. Since the payload is script-based, standard static analysis might miss it if it's obfuscated. I recommend configuring transport rules to quarantine ZIPs containing .js or .cjs files. Additionally, check for archives that use password protection, as this is a common tactic to bypass scanning.

On the detection side, since the payload might bypass static analysis, we should focus on runtime behavior. It's rare for node.exe to spawn child processes like cmd or powershell on a POS terminal. You might look for suspicious parent-child process chains:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4688} | Where-Object { $_.Message -match 'node.exe' -and $_.Message -match 'powershell.exe' }

Has anyone seen this specific implant establishing persistence via scheduled tasks?

Building on Alex's point, hunting for parent-child anomalies is critical. If you're using Sentinel, this KQL query helps catch the execution chain early:

DeviceProcessEvents
| where FileName =~ "node.exe" and InitiatingProcessFileName in ("cmd.exe", "powershell.exe")

Since node.exe shouldn't be running there, AppLocker policies explicitly denying it in user directories would be a more proactive preventative measure than just relying on runtime detection.