VigilantGrid Helped Detect Vendor Communicating with Unauthorized OT Devices

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.

Context

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.

Initial Detection

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.

Why this matters

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.

Evidence Collection

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.

Technical note

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?”

Threat Assessment

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.

Finding 01 — Unrecognized user account: 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.
Finding 02 — Repeated failed login attempts: The user account generated multiple failed password attempts against the RTU — consistent with credential-guessing behavior or a misconfigured external system.
Finding 03 — Unexpected curl activity: 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.

In OT environments, the bar for “suspicious” is deliberately low. A single unrecognized username or an unexpected tool like curl can represent a more meaningful signal than thousands of malformed packets would in a traditional IT context.

Investigation Timeline

From Alert to Resolution

Step 1 — Detection: VigilantGrid surfaces an alert flagging suspected NMAP activity directed at an RTU on the utility’s OT network. The SOC team is immediately notified and triage begins.
Step 2 — Validation: Packet capture for the relevant time window is pulled and analyzed. The niceports/Trinity.txt NMAP signature is identified in the traffic, confirming the scan was real.
Step 3 — Correlation: Investigators correlate traffic from the source IP and identify three compounding indicators: an unrecognized user, repeated authentication failures, and anomalous curl activity.
Step 4 — Escalation: With the evidence assembled, the SOC team reaches out directly to the Utility to report findings and request context on the IP address and associated activity.
Step 5 — Attribution & Resolution: Utility confirms the IP belongs to an authorized third-party vendor troubleshooting a device communication issue — without having coordinated with the utility’s security team first.
Step 6 — Remediation: Utility’s implements access restrictions on the Modbus port for the affected RTU, reducing the attack surface and formalizing access control for third-party activity on that device going forward.

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.

Outcome

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.

Lessons Learned

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.

Visibility is everything: 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.
Correlate before concluding: 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.
Third parties are a vector: 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.
Triage speed matters: 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.

The larger point

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.

This incident was detected and investigated using VigilantGrid, GridIntel’s OT network monitoring and security platform built specifically for electric utilities and critical infrastructure operators. VigilantGrid provides passive, protocol-aware monitoring across Modbus, DNP3, IEC 61850, and other OT communication protocols — surfacing the anomalies that matter without disrupting live operations.