Specific rule is not firing against pcap if other rule is enabled
I've observed a pretty weird behaviour while investigating a rule miss against a pcap where this rule should normally hit.
If you run etpro-all.rules against the pcap you will have several alerts, but not on the rule with the sid 2841978 (ETPRO MALWARE Lemon_Duck Powershell Requesting Payload M2).
If you run a rule file that contains only this one rule with sid 2841978 it will fire as expected.
So I divided the problem down to rule 2009247 that is interfering with sid 2841978. If you run a rule file with both rules against the pcap 2841978 will not fire. If you run a rule file with only 2841978 in it, 2841978 will fire.
I've tested this behavior with Suricata 4.1.6, 5.0.2 and the newest 5.0.3.
In the attached zip archive you will find the yaml configurations and the logs for both runs. I couldn't compress the pcap to be smaller than 20MB. Please ping me when you're starting looking into this. I will share it with you via a file share system then.
Updated by Konstantin Klinger over 1 year ago
I've tried a few other options and found out this:
1) suricata -vvv -c suricata.yaml -r miss.pcap -l . -k none
1a) both_rules.rules -> hits on 2841978
1b) one_rule.rules -> hits on 2841978
2) suricata -vvv -c suricata.yaml -r miss.pcap -l .
2a) both_rules.rules -> NO hits on 2841978
2b) one_rule.rules -> hits on 2841978
Updated by Jason Taylor over 1 year ago
- File zebrocy.pcap added
A scenario we ran into the other day seems to be related to this issue. Specifically we are seeing what appear to be FNs on a given pcap for rules when being replayed with -k none. Scenario:
This is Suricata version 6.0.0-dev (e5fd47dcf 2020-05-01)
rm *.json *.log; suricata -vv -c ~/suri/suricata.yaml -k none -S test.rules -r ~/research/mytest.pcap
Suricata runs and results in no alerts,
rw-rw-r-. 1 jt jt 0 May 7 12:08 alert.json
If I run the following:
rm *.json *.log; suricata -vv -c ~/suri/suricata.yaml -S test.rules -r ~/research/mytest.pcap
Suricata runs and results in the alerts as expected,
rw-rw-r-. 1 jt jt 8.0K May 7 12:09 alert.json
In this case wireshark is also indicating that the checksum is correct on the traffic. The rule tested against is 2842156, pcap is attached.