Network Beaconingedit
This feature provides an early warning system for command and control beaconing activity. It monitors network traffic for indicators of compromise and provides analytics to add context to alerts and aid your threat hunting.
Deploy the packageedit
To deploy the network beaconing framework in your environment using the release package, follow these steps.
The release package includes dashboards for monitoring beaconing activity in your environment. You can review signals via a Lens dashboard called Network beaconing.
Feature detailsedit
This feature uses a transform to categorize network data by host and process name, then runs scripted metric aggregations on the host-process name pairs. For a given time window, the scripted metric aggregation checks each pair for the following:
- Signals repeating at regular intervals, accounting for minor variations in those intervals.
- Low variation of bytes sent from source to destination.
- Low variation of bytes sent from destination to source.
The transform, which runs every hour, also filters out common, known applications and IPs to reduce false positives. The transform outputs information about the detection, process, and host indicators, for example:
The values highlighted above are typical of beaconing behavior and can help with your investigation.
Further customizationsedit
Advanced users can also tune the scripted metric aggregation’s parameters, such as jitter percentage or time window. To overwrite the default parameters: delete the transform, change the parameters, and restart the transform. The configurable parameters are:
-
number_buckets_in_range: The number of time buckets into which the time window is split. Using more buckets improves estimates for various statistics, but also increases resource usage. -
time_bucket_length: The length of each time bucket. A higher value indicates a longer time window. Set this to a higher value to check for very low-frequency beacons. -
number_destination_ips: The number of destination IPs to collect in results. Setting this to a higher value increases resource usage. -
max_beaconing_bytes_cov: The maximum coefficient of variation in the payload bytes for the low source and destination bytes variance test. Higher values increase the chance of flagging traffic as beaconing, increasing recall while reducing precision. -
max_beaconing_count_rv: The maximum relative variance in the bucket counts for the high-frequency beacon test. As withmax_beaconing_bytes_cov, tuning this parameter involves a tradeoff between recall and precision. -
truncate_at: The lower and upper fraction of bucket values discarded when computingmax_beaconing_bytes_covandmax_beaconing_count_rv. This allows you to ignore occasional changes in traffic patterns. However, if you retain too small a fraction of the data, these tests will be unreliable. -
min_beaconing_count_autocovariance: The minimum autocorrelation of the signal for the low-frequency beacon test. Lowering this value generally increases recall for malicious command and control beacons, while reducing precision. -
max_jitter: The maximum amount of jitter assumed to be possible for a periodic beacon, as a fraction of its period.
You can also make changes to the transform query. The default query looks for beaconing activity over a 6-hour time range, but you can change it.
Beaconing is not used exclusively by malware. Many legitimate, benign processes also exhibit beacon-like activity. To reduce false positives, default filters in the transform query exclude known beaconing processes and IPs that fall into two groups:
- The source IP is local and the destination is remote.
- The destination IP is in a block of known Microsoft IP addresses.
You can create additional filters to meet the needs of your environment.