Hello All. As a follow-up to my recent Mythos post, I have been thinking about cyber-hygiene improvements organizations can make in their OT environments. In environments where patching may no longer be an option, tools like Sysmon shift the strategy from prevention to visibility and early detection. You’re essentially compensating for unpatchable risk by increasing your ability to observe attacker behavior in real time. In many cases, these Windows machines cannot run modern EDR tools due to their vintage and/or cannot support them in their current OT environment. On legacy Windows systems (including XP/7-era HMIs), Sysmon can be one of the few viable ways to regain some defensive ground.

Monitoring process creation is one of the highest-value use cases. Most successful attacks on legacy systems still require some form of execution—whether that’s cmd.exe, PowerShell (where present), dropped binaries, or living-off-the-land techniques. By baselining what “normal” looks like on an HMI and alerting on deviations (new parent-child relationships, unusual command-line arguments, unsigned binaries), you can catch activity that would otherwise go completely unnoticed.

DNS and outbound connectivity is even more critical in OT. Many of these systems are not supposed to communicate externally at all. So when you see DNS queries to Internet domains, failed or successful connections to external IPs, or even unusual internal name resolution patterns, that’s often a high-fidelity signal. In a world where AI-driven attacks may rapidly establish command-and-control, those early outbound indicators can be the only warning you get.

Feeding this telemetry into a SIEM is where the real value compounds. SIEMs will allow you to correlate across layers—endpoint behavior, network activity, and even OT protocol anomalies if you’re integrating tools like Nozomi or Claroty. This is where you move beyond simple alerting into detection engineering, building use cases such as:

• Process execution + outbound connection within a short window
• New binary execution on a system with no change tickets
• DNS queries to rare or previously unseen domains
• Lateral movement patterns combined with OT protocol access

That said, there are a few realities to be aware of.

First, Sysmon on legacy systems requires careful tuning. These environments are typically very static, which is actually an advantage—you can get to a high-confidence baseline quickly—but noisy configs will overwhelm both the system and your analysts. Minimal, targeted logging (process create, network connections, DNS if available, and maybe file creation in sensitive directories) tends to work best.

Second, performance and stability matter more than anything in OT. Even tools that access Windows natively such as Sysmon need to be validated in a lab or staging environment before deployment. The last thing you want is a monitoring control impacting an HMI tied to production or safety systems.

Third, this approach doesn’t reduce vulnerability exposure—it simply makes exploitation more visible. So it needs to sit alongside:

• Strong network segmentation
• Strict allow-listing where possible
• Passive OT monitoring for protocol-level anomalies

The bigger picture is that this aligns perfectly with the shift we’re seeing in the wake of AI-driven vulnerability discovery. If we assume that new flaws will continue to be found in unpatchable systems, then behavioral monitoring becomes the control of last resort.

In that sense, deploying Sysmon isn’t just a technical improvement—it’s a strategic acknowledgment that: You may not be able to stop the exploit, but you can still catch the attacker.