Bug #3684: Specific rule is not firing against pcap if other rule is enabled - Suricata - Open Information Security Foundation

Actions

Copy link

Bug #3684

closed

Specific rule is not firing against pcap if other rule is enabled

Added by Konstantin Klinger over 4 years ago. Updated about 4 years ago.

Status:

Closed

Priority:

Normal

Assignee:

Target version:

Affected Versions:

4.1.6, 5.0.2, 5.0.3

Effort:

Difficulty:

Label:

Description

Hi all,

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.

Thanks,
Konstantin

Files

Download all files

redmine_share.zip (372 KB) redmine_share.zip		Konstantin Klinger, 04/30/2020 07:25 AM
Screenshot 2020-04-30 at 17.05.56.png (110 KB) Screenshot 2020-04-30 at 17.05.56.png	checksum	Konstantin Klinger, 04/30/2020 03:06 PM

Actions

Copy link

Updated by Konstantin Klinger over 4 years ago

Running Suricata with the following command: suricata -vvv -c suricata.yaml -r miss.pcap -l .

Actions

Copy link

Updated by Victor Julien over 4 years ago

Status changed from New to Assigned
Assignee set to Victor Julien
Target version set to 6.0.0beta1

Actions

Copy link

Updated by Konstantin Klinger over 4 years 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

Actions

Copy link

Updated by Konstantin Klinger over 4 years ago

File Screenshot 2020-04-30 at 17.05.56.png Screenshot 2020-04-30 at 17.05.56.png added

Wireshark tells the checksum for the packet is correct.

Actions

Copy link

Updated by Jason Taylor over 4 years 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:

suricata -V
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.

Actions

Copy link