[Rule Tuning] Statistical Model Detected C2 Beaconing Activity

Link to rule

https://www.elastic.co/guide/en/security/8.12/statistical-model-detected-c2-beaconing-activity.html

https://elastic.github.io/detection-rules-explorer/rules/5397080f-34e5-449b-8e9c-4c8083d7ccc6

Query


beacon_stats.is_beaconing: true and
not process.name: ("WaAppAgent.exe" or "metricbeat.exe" or "packetbeat.exe" or "WindowsAzureGuestAgent.exe" or "HealthService.exe" or "Widgets.exe" or "lsass.exe" or "msedgewebview2.exe" or "MsMpEng.exe" or "OUTLOOK.EXE" or "msteams.exe" or "FileSyncHelper.exe" or "SearchProtocolHost.exe" or "Creative Cloud.exe" or "ms-teams.exe" or "ms-teamsupdate.exe" or "curl.exe" or "rundll32.exe" or "MsSense.exe" or "wermgr.exe" or "java" or "olk.exe" or "iexplore.exe" or "NetworkManager" or "packetbeat" or "Ssms.exe" or "NisSrv.exe" or "gamingservices.exe" or "appidcertstorecheck.exe" or "POWERPNT.EXE" or "miiserver.exe" or "Grammarly.Desktop.exe" or "SnagitEditor.exe" or "CRWindowsClientService.exe")

Description

This rule may trigger when using package managers, such as dnf. As I was setting up our new logstash servers I needed to install python and searched for a few other packages. This triggered an alert with the two attributes.

process.name: "dnf" and beacon_stats.destination_ips: [209.132.178.16, 23.1.8.251, 34.120.127.130]

Two of these are Red Hat's IPs and one seems to be for elastic artifacts (when I installed logstash).

Adding items such as dnf, yum, apt, winget may reduce false positives from scripts/admins running multiple commands or automatic update checks running on a fixed schedule.

Example Data

The query provided above would add additional processes to and not process.name: (...)

I'm willing to submit a PR for this but before I open a draft I also want to make sure I'm not missing some scenario where package managers are used to mask beaconing.

A more complete list, or if this has been observed at all with them, would also allow for more to be included in one change.
I've only observed this once, but it's also the first time Elastic Agent with Defend has been enrolled as the first step after the initial provision + domain join.

elastic / detection-rules