Unleashing Elite Wolf: A Practical Guide to NSA’s ICS Signatures

Last week, the cybersecurity community got a valuable new resource when the NSA and CISA jointly released Elite Wolf, a set of threat detection signatures aimed at protecting Industrial Control Systems (ICS). These rules provide a much-needed starting point for asset owners in critical infrastructure, the defense industrial base, and national security systems.

But here’s the catch: these aren’t “set it and forget it” solutions. Dropping them into your environment without tuning will likely lead to a tidal wave of alerts.

This guide will break down what’s inside the Elite Wolf ruleset, explore their strengths and weaknesses, and show you practical ways to transform them from noisy baselines into high-fidelity detection tools for your security program.

What is Elite Wolf? A Quick Primer

Elite Wolf is a collection of Snort rules published on GitHub, designed to help defenders spot potentially malicious activity on Operational Technology (OT) networks. The release is a follow-up to an NSA publication from July 2020 and specifically targets equipment from three major ICS vendors:

• Rockwell Automation (Allen-Bradley)

• Schweitzer Engineering Labs (SEL)

• Siemens

The core idea is to provide defenders with ready-made signatures that can identify suspicious interactions with these devices. However, the NSA and CISA are clear that these rules require a human in the loop. You will need to analyze the alerts they generate to distinguish between routine operations and genuine threats.

A Look Inside the Rulebook: Strengths and Weaknesses

The effectiveness of the Elite Wolf rules varies significantly by vendor. The authors clearly had hands-on access to the devices, but their approaches differ in complexity and utility.

Schweitzer Engineering Labs (SEL): The Gold Standard 

The SEL rule set is by far the most impressive and detailed. Instead of just looking at generic web traffic, it dives deep into the specifics of SEL devices.

• Certificate-Based Identification: Many rules cleverly use unique strings found in the X.509 (SSL) certificates of specific SEL device models (like the 3530, 3620, and 2488) to identify them on the network.

• Proprietary Protocol Analysis: The standout feature is the 21 rules dedicated to “SEL Telnet,” a proprietary management protocol. The NSA team reverse-engineered this protocol to detect critical functions, access level changes, and even the use of default usernames and passwords (like the password tail). This is a huge win for defenders.

The primary weakness here is the potential for alert fatigue. During a plant turnaround or maintenance window, legitimate use of these interfaces could flood your SOC with alerts. You need to understand when and how SEL Telnet is used in your environment to properly baseline activity.

Siemens & Allen-Bradley: A Web-Centric Approach 

The rules for Siemens and Allen-Bradley are much simpler and, unfortunately, much noisier. They primarily focus on detecting access to specific files and pages on the devices’ built-in web servers.

• Siemens: The rules target the S7-1200 PLC, looking for HTTP traffic containing strings like S7web.css or specific fields in the default SSL certificate.

• Allen-Bradley: Similarly, these rules alert when specific web pages on a Rockwell PLC are accessed, giving you granularity on what a user was looking at.

The glaring weakness for both is that they will generate an alert every single time a technician, operator, or automated tool accesses the web interface. In many environments, this is constant. Without significant tuning, these rules will lead to massive analyst fatigue and are likely to be ignored.

From Noisy to Precise: Simple Tweaks to Sharpen Your Rules

The out-of-the-box rules are a foundation, not a finished product. With a few simple modifications, you can drastically reduce false positives and increase the value of the alerts.

1. Filter by IP Address

The most powerful initial tweak is to add context about your network topology. You can modify the rules to only trigger on traffic from unexpected sources.

For example, the default Siemens rule alerts on any access to the S7web.css file.

Default Rule: alert tcp any 80 -> any any (msg:"ELITEWOLF SIEMENS S7-1200 Web CSS"; flow:to_client,established; content:"S7Web.css"; classtype:web-application-activity; sid:20230002; rev:1;)

Let’s say you only want to be alerted if a device from the public internet (a non-private IP) accesses this file. You can change the destination from any to !$HOME_NET or specifically exclude private IP ranges (RFC 1918).

Tuned Rule (Alerting on Public IPs): alert tcp any 80 -> !$RFC1918_RANGES any (msg:"ELITEWOLF SIEMENS S7-1200 Web CSS - Public Access"; flow:to_client,established; content:"S7Web.css"; classtype:web-application-activity; sid:20230002; rev:1;)

This simple change filters out all internal traffic, making each alert far more significant.

2. Use Detection Filters

Automated tools and normal network behavior can cause a flurry of alerts in a short period. A detection filter tells Snort to only generate an alert after an event occurs a certain number of times in a given window.

This is useful for noisy rules, like those that trigger on SSL certificate details.

Tuned Rule (With Detection Filter): alert tls $EXTERNAL_NET any -> $HOME_NET 443 (msg:"ELITEWOLF SIEMENS S7-1200 Default Cert"; flow:to_server,established; tls.cert_subject; content:"O=Siemens, OU=Industry, CN=SIMATIC S7-1200"; **detection_filter: track by_dst, count 5, seconds 60;** classtype:trojan-activity; sid:20230004; rev:1;)

This modified rule will only fire after it sees 5 attempts to connect to the same destination device within 60 seconds, effectively suppressing low-level scanning noise.

Getting Fancy: Moving Beyond HTTP to the Protocol Layer

The biggest limitation of the web-based rules is that a savvy attacker will likely avoid the web interface entirely. They know it’s often monitored and will instead use the native industrial protocols to interact with the PLC.

To truly catch advanced threats, you need to write rules that understand the industrial protocols themselves. Let’s use a common attack vector mentioned by the NSA: connecting to an internet-accessible PLC.

The “Good” (but Flawed) Approach

A simple approach is to alert on any traffic from the internet to the Siemens S7comm port (TCP/102).

alert tcp !$RFC1918_RANGES any -> $HOME_NET 102 (msg:"Possible S7comm from Internet"; classtype:bad-unknown; sid:1000001; rev:1;)

The problem? Port 102 is notoriously crowded. It’s used by S7comm, IEC 60870-5-104, COTP, and other protocols. This rule will still be incredibly noisy and lack specificity.

The “Better” (Protocol-Aware) Approach 

A much better rule inspects the packet’s payload to confirm it’s actually S7comm traffic. The S7comm protocol has a predictable structure, typically encapsulated within TPKT and COTP headers. We can look for specific, static byte values in these headers.

1. TPKT Header: Always starts with version 0x03.

2. COTP Header: Data packets are identified by a PDU Type of 0xf0.

3. S7 Header: The protocol ID for S7comm is always 0x32.

By chaining these content matches together, we can build a highly accurate rule.

High-Fidelity S7comm Rule: alert tcp !$RFC1918_RANGES any -> $HOME_NET 102 (msg:"S7comm Confirmed from Internet"; flow:to_server,established; content:"|03 00|"; depth:2; content:"|f0|"; distance:5; within:1; content:"|32|"; distance:3; within:1; classtype:bad-unknown; sid:1000002; rev:1;)

This rule is exponentially better. It has a very low chance of producing a false positive because it’s looking for three distinct fingerprints of the S7comm protocol in the correct order. An alert from this rule means you have almost certainly identified an external entity communicating directly with your Siemens PLCs—a high-priority incident worth investigating immediately.

Key Takeaways

The NSA and CISA’s Elite Wolf release is a fantastic contribution to the OT security community. However, it should be treated as a starting point.

• Customization is Mandatory: To avoid drowning in alerts, you must tune these rules for your specific environment by filtering IPs and setting detection thresholds.

• Go Beyond the Web: Relying solely on HTTP-based detection leaves you blind to attackers who operate at the protocol layer.

• Embrace Protocol-Aware Rules: The most robust and reliable detections come from writing rules that understand the structure of the industrial protocols themselves.

Take these rules, put them in your lab, and start tweaking. By refining them, you can build a powerful, customized defense for your most critical systems.