da667
commented
10 months ago Hi there,
My name is Tony, I work on the ProofPoint Emerging Threats team, and I wanted take a stab at answering this question for you.
First and foremost my understanding of the ELITEWOLF ruleset is that it does not exist to detect particularly malicious activity against the ICS controllers covered by the rules, but exists as a sort of 'auditing' ruleset.
What that means is that these rules are meant to detect mostly routine activity or fingerprints that can identify connection attempts to specific controllers -- Telnet Banners, Specific Webpages, SSH versions, Default SSL Certificates, etc. The ruleset also includes a few rules that detects suspicious activity as well -- retrieving or uploading specific files via FTP, using default credentials, or viewing certain webpages that contain specific system data about the controller in question.
Again, by default, these are actions that are not overtly malicious, but depending on the context, could be an indicator of anomalous activity. In my mind, there are two specific use cases for these rules:
-
Using them to establish an audit trail of activity relating to ICS controllers
- Who is accessing these controllers?
- What actions are they taking?
- When did these actions occur?
-
Using the rules to detect said "normal" activity from unusual sources, or to unusual destinations.
- Let's say you have a lot of these rules triggering. And that its all for seemingly normal traffic. But when you sort the alerts by the IP addresses accessing the controllers, you start seeing IP addresses you don't recognize. Of course you'd want to know about those events, in order to know if anything was tampered with.
Unfortunately, the ET team has to account for wide variations in how IDS rules are deployed. So by default, the rule headers for most of these rules in which the client is attempting to access a controller is usually going to be:
alert [tcp/http/ssh/etc.] any any -> $HOME_NET any
Whereas for rules in which the controller is responding to an access request, the rule header is going to look like:
alert [tcp/tls/etc.] $HOME_NET any -> any any
This is because we have to account for cases of unauthorized access in which controllers are being access both from within an internal network, as well as from the network perimeter. Now, if the rules in their current state do not serve your purpose, then there are a number of methods available in both Snort and Suricata that can be use to reduce the volume of alerts in order to reduce alert fatigue:
- Disabling the rules altogether
- Disabling the rules, and creating a local rule that excludes a subnet from which the traffic is expected (e.g. creating 'pass' rules)
- Creating a local rule and modifying it with the
thresholdkeyword to limit the number of alerts over a given time period - Setting global threshold config files in either Snort or Suricata and defining either thresholds or supressions in that file. Users can create a suppression to prevent rules from alerting based on source or destination IP address criteria. Its a little bit easier than disabling the current rule and increating a new local rule or pass rule.
- Utilizing BPF, or other low-level capture card logic to prevent Snort or Suricata from seeing the traffic in the first place.
I detailed these options for alert fatigue management on our community website here. I hope this helps to explain the purpose of these rules as well as addressing options to combat alert fatigue. Happy Hunting, and good luck.
OGSteve
Might I suggest a url reference that shows how these might be found in a malicious context? These were pushed from Proofpoint this week and are extremely noisy with no clear indication of how this activity might be malicious. Anytime you write open source signatures it is a good idea to reference your source for writing said signatures.
For reference, these are the culprits: