ELITEWOLF: How the NSA Detects Attacks on Power Grids and Water Systems

Hook

While most security teams worry about stolen credentials and ransomware, adversaries are already probing the industrial control systems that run power plants, water treatment facilities, and manufacturing lines—and most traditional security tools can't even see them.

Context

Operational Technology (OT) networks present a fundamentally different security challenge than traditional IT infrastructure. These are the networks controlling physical processes: PLCs managing factory assembly lines, SCADA systems operating electrical substations, DCS controllers in chemical plants. For decades, these systems operated in isolation, relying on air gaps for security. But modern industrial facilities increasingly connect OT to corporate IT networks for remote monitoring, predictive maintenance, and business intelligence.

This convergence creates exposure. In 2015, attackers used BlackEnergy malware to disable circuit breakers at Ukrainian power companies, causing blackouts for 230,000 people. In 2017, Triton malware targeted safety instrumented systems at a Saudi petrochemical plant, attempting to trigger an explosion. Traditional network security tools struggle in these environments because they don't understand industrial protocols like Modbus, DNP3, or IEC 104, and because OT systems can't tolerate the network overhead or instability that active scanning introduces. ELITEWOLF emerged from NSA's Cybersecurity Directorate as a solution: pre-built Snort signatures specifically designed to detect reconnaissance, exploitation, and manipulation of industrial control systems without disrupting operations.

Technical Insight

ELITEWOLF's architecture is deliberately minimalist: it's a collection of Snort rules that passive network monitors can deploy at strategic points in OT networks. The genius lies not in complexity but in specificity—these signatures understand the semantics of industrial protocols in ways generic IDS rules never could.

Consider a typical rule targeting Modbus, the de facto protocol for communicating with PLCs. A generic approach might simply alert on any Modbus traffic to unfamiliar hosts. ELITEWOLF goes deeper, examining function codes and data patterns. Here's a simplified example of what an ELITEWOLF-style rule structure looks like:

alert tcp any any -> $SCADA_NET 502 (msg:"ELITEWOLF Modbus Force Listen Only Mode";
  flow:to_server,established;
  content:"|00 00 00 00 00 06|"; offset:0; depth:6;
  content:"|08 04|"; offset:7; depth:2;
  threshold:type limit, track by_src, count 1, seconds 3600;
  classtype:attempted-admin;
  sid:3000001; rev:1;)

This rule detects Modbus function code 0x08 subfunction 0x04, which forces a slave device into "Listen Only Mode"—a tactic attackers use to silence monitoring devices before launching attacks. The rule examines the Modbus Application Protocol header (the first 6 bytes) and then checks for the specific function code combination. The threshold prevents alert fatigue by limiting notifications to one per source per hour.

The real sophistication emerges when you examine rules targeting protocol anomalies rather than just suspicious commands. Industrial protocols have strict state machines—certain sequences of operations are mechanically impossible or operationally nonsensical. ELITEWOLF includes rules that fire when devices receive commands outside valid operational sequences:

alert tcp $SCADA_NET any -> any any (msg:"ELITEWOLF DNP3 Cold Restart During Active Session";
  flow:to_client,established;
  content:"|05 64|"; offset:11; depth:2;
  flowbits:isset,dnp3.session.active;
  flowbits:isnotset,dnp3.expected.restart;
  classtype:suspicious-command;
  sid:3000042; rev:1;)

This DNP3 rule (used in electric utilities and water systems) triggers when an outstation receives a cold restart command while maintaining an active session—a pattern consistent with attackers attempting to reset devices to clear forensic evidence or disrupt operations. The flowbits track session state across packets, maintaining context that simpler pattern-matching can't achieve.

Deployment architecture matters enormously. ELITEWOLF rules should run on sensors positioned at choke points: the boundary between IT and OT networks, connections between OT zones of different security levels, and links to Internet-accessible HMIs or historians. The rules assume passive monitoring via switch SPAN ports or network TAPs—they're designed to observe, not intercept. This is critical in OT environments where even milliseconds of inline inspection latency could disrupt time-sensitive control loops.

The signature set also includes rules targeting reconnaissance patterns. Attackers rarely jump straight to manipulating industrial processes; they first enumerate the environment. ELITEWOLF detects scanning behaviors specific to OT:

alert tcp any any -> $SCADA_NET any (msg:"ELITEWOLF ICS Protocol Scan Detected";
  flags:S;
  detection_filter:track by_src, count 15, seconds 60;
  threshold:type threshold, track by_src, count 15, seconds 60;
  classtype:network-scan;
  sid:3000103; rev:1;)

This rule identifies sources opening TCP connections to 15+ hosts in the SCADA network within 60 seconds—benign in IT networks but highly suspicious in OT environments where communication patterns are typically static and deterministic. A legitimate HMI connects to the same dozen PLCs day after day; scanning behavior indicates reconnaissance.

What makes ELITEWOLF particularly valuable is its integration with the SCADA/ICS threat intelligence ecosystem. Many rules reference specific CVEs in industrial equipment or match attack patterns from disclosed incidents. When Ukrainian power companies were compromised, analysts reverse-engineered the attack chain. ELITEWOLF rules encode those lessons, detecting similar techniques: suspicious firmware uploads, unexpected configuration changes, or coil/register manipulations consistent with circuit breaker attacks.

Gotcha

ELITEWOLF's signature-based approach inherits all the limitations of that paradigm, amplified by OT's unique constraints. First, false positives are operationally catastrophic in ways they aren't in IT. If an IT security tool incorrectly blocks a web request, someone can't access a dashboard. If an OT alert triggers unnecessary emergency procedures, you might shut down a production line costing tens of thousands per hour, or worse, create an unsafe condition by disrupting safety systems.

This means every ruleset requires extensive tuning. The repository provides generic rules, but your Modbus traffic patterns differ from everyone else's based on your specific PLCs, your process logic, your vendor equipment mix. What's anomalous in a water treatment plant is normal in a steel mill. You'll spend weeks establishing baselines, adjusting thresholds, and whitelisting legitimate operations. Organizations without deep expertise in both their industrial processes AND network security will struggle.

Second, signatures only catch known patterns. Nation-state attackers developing custom OT malware won't trigger these rules if they've designed novel techniques. ELITEWOLF would have missed Stuxnet's PLC rootkit functionality because it operated at a layer these signatures don't reach—it wasn't network behavior but PLC code manipulation. You need complementary detection strategies: behavioral analytics, integrity monitoring, and physical process anomaly detection. ELITEWOLF is one layer, not a complete solution. The rules also age poorly; as protocols evolve and new ICS equipment deploys, signatures need updating, but the repository's maintenance cadence is unpredictable for a government project.

Verdict

Use ELITEWOLF if you're protecting critical infrastructure with SCADA/ICS/OT environments, have security analysts who understand both industrial protocols and your specific operational processes, and already run Snort or compatible IDS infrastructure with visibility into OT network segments. It's particularly valuable for utilities, manufacturing facilities, and industrial operators facing compliance requirements (TSA pipelines, NERC CIP for power) or nation-state threat models where government-vetted signatures provide defensive advantage. The rules offer a significant head start over building OT detection capabilities from scratch.

Skip ELITEWOLF if you lack dedicated security analysts to tune rules and investigate alerts—the false positive rate in untuned deployments will overwhelm generic SOC teams unfamiliar with industrial operations. Also skip if you don't have passive network monitoring infrastructure positioned to observe OT traffic (many older facilities lack this visibility entirely), or if you need automated response capabilities—these are alerting-only signatures because blocking in OT requires human judgment to avoid disrupting critical processes. For fully managed solutions with less operational overhead, commercial platforms like Nozomi or Claroty provide more hand-holding, though at enterprise price points.