Skip to content

[Rule Tuning] Cobalt Strike Command and Control Beacon  #3187

Closed
@ChestoOfGlen

Description

@ChestoOfGlen

Link to rule

https://github.com/elastic/detection-rules/blob/f584fb6e31fa6a052a316fa108adf83e9a0d5e82/rules/network/command_and_control_cobalt_strike_beacon.toml

Description

This rule has a lack of capitalisation in the query with respect to the AND/OR operators in the most recent update. This is causing this rule to match on the word "and" in Elasticsearch instead of properly applying the logic and searching for the C2 destination traffic events.
The specific issue is with the last "AND", however I think that all AND/OR operators should be capitalised as that appears to be the standard defined in the Elastic documentation for query string/Lucene syntax (https://www.elastic.co/guide/en/elasticsearch/reference/8.10/query-dsl-query-string-query.html#query-string-syntax).
image

This has caused a huge amount of false positives in our environment since the rule package was updated around October 14.
z-browser-32438219137-6035031742390-39b55aa9de690dc68abf0f1a1bde316e879171dbd7ec1b5adb4d0cefe36f1482

Confirming that running this same Lucene query in Discover returns only false positive results as it matches on the word "and".
image

And running it with properly capitalised AND/OR operators returns the expected zero results.
image

Finally, just to note, the previous commit for this rule had the "AND" properly capitalised.

event.dataset: (network_traffic.tls or network_traffic.http) AND destination.domain:/[a-z]{3}.stage.[0-9]{8}\..*/

image

Solution is to, naturally, update the query to use correct capitalisation for the AND/OR operators, in line with what appears in the query string/Lucene Elastic docs as linked above.

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions