When the Network Talks Back: Detecting and Investigating Suspect Activity in an OT Environment
A real-world walkthrough of how a single anomalous alert in an operational technology environment triggered a full SOC investigation — and what the evidence ultimately revealed.
Why OT Environments Demand a Different Kind of Vigilance
Operational Technology (OT) environments — the networks that underpin power grids, water treatment facilities, pipelines, and other critical infrastructure — operate under a fundamentally different threat model than traditional IT systems. Where an IT breach might mean stolen data, an OT breach can mean physical consequences: outages, equipment damage, or worse. The devices running these networks, such as Remote Terminal Units (RTUs) and Programmable Logic Controllers (PLCs), were often designed decades ago with availability as the primary concern, and security as an afterthought.
Because these systems are sensitive and their protocols were never intended for adversarial environments, even routine-seeming network activity — a scan, a connection attempt, an unexpected username — can be a meaningful signal. That's precisely what makes continuous OT-aware monitoring so critical.
The following is a detailed account of one such signal: an alert surfaced by VigilantGrid, GridIntel's OT monitoring platform, that initiated a full investigation into potential unauthorized activity on a utility's operational network.
The Alert That Started It All
Monitoring a utility client's network, our security operations team identified an unusual message flagged by VigilantGrid. The alert indicated what appeared to be a suspected NMAP scan targeting one of the utility's RTUs — a type of activity that, in normal operations, simply does not occur on this network.
NMAP (Network Mapper) is a powerful open-source tool widely used by network administrators to inventory devices, audit open ports, and understand network topology. It is equally well-known as a staple in an attacker's reconnaissance toolkit. A port scan against an RTU is not normal operational behavior, and in the context of an OT network, it is inherently suspicious.
Upon identifying this alert, the security operations team immediately triaged the event and notified the SOC team. The first order of business: determine whether this was a genuine NMAP scan or a false positive.
Confirming the Scan: Pulling the Packet Capture
To validate the alert, investigators pulled the packet capture (PCAP) corresponding to the time window of the suspected activity. What they found was unambiguous.
Buried within the captured traffic was a tell-tale string in one of the HTTP request packets: a request URI containing ://niceports,/Trinity.txt. This is a well-documented NMAP signature. NMAP uses this particular request to elicit a 404 Not Found response from a web server — not because it expects to find the file, but because the shape and headers of the 404 response reveal information about the host's operating system and web server software. It is, in essence, a fingerprinting technique.
The niceports/Trinity.txt probe is part of NMAP's service and version detection engine. By analyzing how the target responds to unexpected or malformed requests, NMAP can infer details about the underlying software stack without completing a full connection. This behavior has been a known NMAP artifact for years and is a reliable indicator in network forensics.
With this evidence in hand, the team had high confidence that NMAP had indeed been run against the RTU. The focus of the investigation shifted from "did this happen?" to "should we be alarmed?"
Three Indicators That Elevated Concern
While NMAP activity alone warranted attention, the broader picture of traffic originating from the same source IP raised the severity considerably. Investigators identified three additional indicators that together painted a troubling picture.
A user was observed authenticating against the RTU. This username was not recognized by the RTU, the utility's asset owners, or the SOC team.
The user account generated multiple failed password attempts against the RTU — consistent with credential-guessing behavior or a misconfigured external system.
Traffic analysis revealed the use of curl to probe endpoints on the network. This type of traffic had never previously appeared in the utility's OT baseline.
Critically, all of this activity — the NMAP scan, the unrecognized login attempts, and the curl probing — originated from the same IP address. This correlation strongly suggested coordinated activity from a single external actor rather than coincidental noise.
From Alert to Resolution
Malicious Actor or Authorized Vendor?
After completing their initial investigation, the SOC team reached out directly to the utility — referred to here as utility/asset owner — with a structured report of their findings. Utility's response provided the missing context: the activity was traced to a third-party company managing one of the devices associated with that IP address. The vendor had been attempting to diagnose a communication issue and had done so without notifying the utility's security team in advance.
In other words, this was not a malicious intrusion — but it was a serious operational security gap. A vendor working on OT-adjacent equipment had inadvertently triggered behaviors indistinguishable from early-stage reconnaissance: network scanning, credential testing, and endpoint probing. Without continuous monitoring and a mature SOC process, this activity could have gone entirely unnoticed — or worse, been dismissed without investigation.
As a direct result of the investigation, Utility implemented port-level access restrictions on the Modbus port for the affected RTU, reducing its exposure to unauthorized access. The incident also highlighted the importance of coordinating third-party maintenance activities with the utility's security operations team before work begins.
What This Incident Reveals About OT Security
This investigation, while resolving benignly, serves as a textbook example of why continuous OT monitoring is not optional — it is essential. The activity observed would have been completely invisible without a purpose-built OT monitoring platform, a trained SOC team, and the willingness to investigate anomalies that might otherwise seem low-priority.
OT environments are often described as "dark" — operators know what equipment they have, but not necessarily what is happening on the wire. Passive monitoring platforms change that equation entirely.
A single anomalous packet rarely tells the full story. Correlating the NMAP alert with the failed logins and curl traffic built a much stronger — and ultimately accurate — picture.
Authorized vendors with legitimate access can introduce risk through uncoordinated maintenance activity. Third-party access should be logged, scheduled, and communicated to security teams in advance.
Immediate triage and SOC notification meant the investigation moved quickly. In a genuine intrusion scenario, that speed could be the difference between containment and a serious incident.
In this case, the source turned out to be a well-meaning vendor rather than an attacker. But the investigation process was identical to what it would have been for a genuine threat. OT security programs should be built to detect, investigate, and respond to anomalies — and let the evidence determine whether the intent was malicious. Assuming benign intent without investigation is not a security posture; it is a liability.