SIEM detections false positive

We've upgraded our stack to 7.6.0 yesterday, and we love the new Detections mechanism!

I'm aware these are in beta, but some of the definitions have a boolean 'or' where there should be an 'and'.

This is particularly where the rule is ' from/to the Internet'.

eg. SMB Activity to the Internet definition is 'network.transport: tcp and destination.port: (139 or 445) and ( network.direction: outbound or ( source.ip: (10.0.0.0/8 or 172.16.0.0/12 or 192.168.0.0/16) and not destination.ip: (10.0.0.0/8 or 172.16.0.0/12 or 192.168.0.0/16) ) )'

This will result in detections for '10.0.0.1 to 10.0.0.2:445' when it shouldn't.
I've highlighted the 'or' that should be changed to 'and'

@ danielsnelling I am changing the category from Kibana to SIEM so the SIEM team can pick up your question.

Glad to hear you are liking the detection engine. This is a known issue with use of the network.direction field that is fixed in 7.61. The workaround is to duplicate the rule and remove the network.direction test. This issue is also discussed here:

I've read through that bug, and the proposed fix.
The fix seems to be wanting to completely ignore signals from sysmon (usually stored in winlogbeat-*), and take the view that the signal only comes from a firewall log and not an endpoint.

The rule will work (from a monitored endpoint point of view) if the logic changes the 'or' to an 'and'.
ie SMB Activity to the Internet:
If the traffic is tcp and the destination port is 139/445, and the traffic is outbound and the destination ip isn't RFC1918, then Alert!

Hi, yes, you can remove the network.direction test when using these on endpoint data. This field is more useful when it has been populated by a Suricata, Snort or Zeek network list. It is not a super reliable layer three context in endpoint pipelines because these typically have no network lists or maps. The rule needs more branching logic to confine evaluation of the network.direction field to appropriate event types.

Such a modified version of the search for endpoint events would look like this;

network.transport: tcp and destination.port: (139 or 445) and source.ip: (10.0.0.0/8 or 172.16.0.0/12 or 192.168.0.0/16) and not destination.ip: (10.0.0.0/8 or 172.16.0.0/12 or 192.168.0.0/16)

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.