Stopping ICS Threats Before They Reach the Network
Detection engineering for OT is one of the most effective ways to stop cyber threats before they reach your operational environment. When it comes to protecting critical infrastructure, early detection is everything. Many organizations lack direct visibility into their Operational Technology (OT) networks, making it harder to spot cyber threats before they cause real-world damage.
In this post, we’ll walk through a detection engineering strategy focused on Stage 1 of the ICS Cyber Kill Chain—before the attacker reaches OT systems. We’ll show how you can spot malicious activity in the IT network using common tools and techniques, even without specialized OT monitoring.
Why Detection Engineering for OT Starts with Stage 1
Before attackers reach the OT layer to launch ICS-specific attacks (Stage 2), they often move through the IT network, gaining credentials, persistence, and control. Early detection during this initial phase is the most cost-effective and scalable way to reduce OT risk—especially in environments without native OT sensors or logs.
ICS Cyber Kill Chain (Stage 1 and Stage 2)
Detection Engineering for OT Using the Four Detection Types
To improve detection coverage—especially in environments with limited OT visibility—we use the trusted Four Types of Threat Detection framework from Dragos. This model categorizes detection logic into four complementary types: two environmental and two threat-based.
The Four Types of Threat Detection
This layered approach allows defenders to combine static IOCs with real-world behaviors, baseline deviations, and misconfigurations—all using logs they likely already have.
We’ll apply these types to a real-world malware case—FrostyGoop—highlighting detection opportunities in Stage 1 of the attack lifecycle.
Real-World Malware Case: FrostyGoop
Even without OT-specific indicators, the following activity in IT networks can reveal a threat actor’s early movements. The FrostyGoop malware is a useful case study. Before executing its ICS payload, it performed several detectable actions inside the IT environment:
– Targeted municipal and energy networks
– Exploited MicroTik router vulnerabilities
– Used ReGeorg webshell for persistence
– Communicated via TOR
– Dumped SAM registry hives
FrostyGoop Stage 1 Intrusion Flow
Detection Rules Your Team Can Implement
Below are detection rules aligned to each detection type. These can be implemented using standard log sources, threat intel, and network models.
| Rule Name | Description | Detection Type | Detection Focus |
|---|---|---|---|
| ReGeorg Webshell IOCs | Detects known ReGeorg webshell hashes (VirusTotal) | Indicators | Match static file hashes from known C2 shells |
| Dump SAM Registry Hive | Alerts on attempts to extract the SAM hive using reg.exe, PowerShell, etc. | Threat Behavior | Detect log-based password hash dumping |
| Outbound TOR Traffic | Flags connections to TOR exit nodes, often used for covert exfiltration | Configuration Analysis | IP match against dynamic TOR feeds |
| MicroTik Router Anomalies | Detects abnormal login activity using statistical baselining | Modeling | Highlights sudden login spikes from new or misused IPs |
Detection Query Examples
Here are simplified query patterns based on each rule:
ReGeorg Webshell IOCs
Collection of publicly available hash values for the ReGeorg webshell. Full list is available at https://www.virustotal.com/gui/search/regeorg
| Detection Type | Indicators |
| Query | 9542c35939eb0509031e69255555aa8d74f861838c481bb7cd52576e6005e165 e2fba584f752624e77e08cb8ec810bc620bf220c0504abbb852ddf99762549a6 e90454f84a0124a5c74d88c24544488ec7d1abd350415679be9675ed01f0ec82 a7ee04ce481016fc27f731b012fb4df57a42ae49adae77fb1392e347fd24d96b 3400574b584a608f1566ec4d63e73d1204fdd9a7d26ab229942d728f316de221 |
Dump SAM Registry Hive Access
The SAM registry hive contains password hashes that attackers will often try to collect for offline cracking. This detection searches Windows Event Logs for any possible collection attempts using native windows tools such as reg.exe vssadmin.exe or PowerShell.
| Detection Type | Threat Behavior |
| Query | index=wineventlog (EventCode=4688 OR EventCode=1) ( (CommandLine=”reg save” AND CommandLine=”HKLM\SAM“) OR (CommandLine=”reg.exe” AND CommandLine=”HKLM\SAM“) OR (CommandLine=”copy” AND CommandLine=”\Windows\System32\config\SAM“) OR (CommandLine=”vssadmin” AND CommandLine=”shadow” AND CommandLine=”copy“) OR (CommandLine=”powershell” AND CommandLine=”Copy-Item” AND CommandLine=”\Windows\System32\config\SAM“) ) | table _time, host, user, parent_process_name, process_name, CommandLine |
Outbound TOR Traffic
Most organizations do not allow the TOR browser or protocol within their environment, so the presence of any traffic to a known TOR node can be a useful detection mechanism. The challenge is that TOR nodes are being added and removed on a constant basis, so this requires a good source of intel that is routinely updated. This detection uses the Network Traffic data model to alert on any outbound traffic to a known TOR IP address.
| Detection Type | Configuration Analysis |
| Query | | tstats summariesonly values(All_Traffic.dest_ip) as dest_ip, values(All_Traffic.src_ip) as src_ip, count from datamodel=Network_Traffic.All_Traffic where All_Traffic.dest_ip!=null AND All_Traffic.direction=”outbound” by _time, All_Traffic.dest_ip, All_Traffic.src_ip | lookup tor_ips ip as dest_ip OUTPUT ip as matched_ip | where isnotnull(matched_ip) | table _time, src_ip, dest_ip, count |
Microtik Router Anomalies
The detection below looks for anomalies based on the number of logins from a specific source IP. It uses the standard logs from the Microtik routers themselves, but this query could easily work on a variety of network traffic log sources.
| Detection Type | Modeling |
| Query | index=mikrotik_logs sourcetype=syslog (“login” OR “authentication”) | rex “user=(?[^\s]+)” | rex “src-address=(?\d+.\d+.\d+.\d+)” | rex “via=(?\w+)” | eval hour=strftime(_time, “%H”) | stats count by username, src_ip, method, hour | eventstats avg(count) as avg_count, stdev(count) as stddev_count by src_ip | eval is_anomaly=if(count > avg_count + (2 * stddev_count), “yes”, “no”) | where is_anomaly=”yes” |
Final Takeaway
At Edgewater, we believe that strong cybersecurity is proactive, pragmatic, and tailored to each mission. Whether you’re defending energy grids, municipalities, or federal systems, our approach focuses on visibility, early intervention, and resilient architectures.
We help agencies and critical infrastructure teams:
– Detect OT threats earlier in the cyber kill chain
– Integrate threat intelligence into operational workflows
– Build layered defenses with limited resources
We don’t just deliver services—we strengthen security where it matters most.
Continue Learning in Our OT Blog Series
OT Cybersecurity on a Budget: A Practical Guide to Doing More with Less
Cyber Threat Intelligence for OT: Prioritizing Threats with Limited Resources
OT Security in Government: Strategies to Reduce Your Cyber Attack Surface
Need Help Improving Detection Coverage?
Our team helps federal and critical infrastructure clients operationalize their OT detection strategies. Explore Edgewater’s cybersecurity services to learn how we can help secure your OT environment.