2.1.11. Beacon detect engine

2.1.11.1. Introduction

2.1.11.1.1. For what types of threats is this engine designed?

The Beacon detect engine allows the detection of the communications to a malicious server during a Command and Control (C&C) attack.
These communications are established from a beacon: malware implanted on the compromised host that makes connections to the C&C server at regular intervals.
The beacons are also called implant or agent.
After running on the compromised host, the beacon will be able to transmit information to the C&C server and receive commands to execute.
Cobalt Strike and Brute Ratel are among the C&C frameworks frequently used for such attacks.
This threat is particularly subtle because it resembles a standard internet stream and is therefore not necessarily blocked by a firewall.
../../_images/beacon_detect_C2.png

2.1.11.1.2. How does this particular engine detect threats?

The engine detects C&C threats through different HTTP and HTTPS metadata scans:

  • Identification of statistical distributions indicating periodicity in metadata

  • The presence of anomalies characterizing the execution of commands

  • Heuristics to specifically identify certain C&C software

Depending on the configuration used, detection algorithms can withstand the following escape methods:

  • Data encryption or over-encryption

  • Random time between each communication

  • Random data size

  • Usurpation of known domain names

Some C&C are specifically identified:

  • Cobalt Strike

  • BruteRatel

  • Caldera

  • Powershell Empire

  • Sliver

The configuration is done with several options which prevent the analysis of healthy communications.
These options filter in particular:

  • Frequently accessed domains within the infrastructure

  • Commonly known domains

  • Generic special domains used in the internal endpoints (example: .local)

Disabling these options increases detection sensitivity and may require adding domains to the ignore destinations list.

2.1.11.1.3. How does the Beacon detect engine work in the GCenter?

The engine:

2.1.11.1.3.1. Beacon detect engine input data

HTTP or HTTPS sessions (or events) reconstructed by the GCap are regularly sent to the Beacon detect engine, which then performs statistical analyzes.
Depending on the configuration used, DNS queries reconstructed by the GCap can also be exploited.
For basic engine operation:
  • HTTP logging and TLS logging must be enabled in the `Base variables` section of the `Detection strategy/Sigflow engine/Gcaps profiles` menu
    For further details of these functions and their activations, see `Base variables` Section of the `GCaps profiles` screen.
  • The Metadata rate limiter must be disabled for HTTP and TLS protocols in the `Detection strategy/Sigflow engine/Metadata rate limiter` menu
    For further details of its function and the protocols activations, see `Metadata rate limiter` screen.

Important

Activate the HTTP or TLS protocol disables the detection of the Beacon detect engine for these protocols.

For optimal engine operation:

Note

2.1.11.2. Events generated

Events generated by the Beacon detect engine are alerts only.
These are displayed:
  • In the main interface named WebUI of the GCenter in the `Alerts` screen.
    The main interface named WebUI is described in the Overview of the WEB UI.
  • In the interface named Kibana UI:
    • Click on the `Hunting` icon of the `WebUI`.
      The interface displayed is the interface named Kibana UI (described in Overview of the Kibana GUI).

    • Click on the ☰ icon and then on `Discover`

    • Select the `engines_alerts*` choice in the Data View

    • In the search field, enter `event.module :"beacon_detect"` filter to display only the alerts of the Beacon detect engine

      ../../_images/GCE103_BEACON-ALERTS-1.PNG
    • Click on the toggle icon (1) on the left of the Alert.
      The expanded document (2) is displayed.
      ../../_images/GCE103_BEACON-ALERTS-3.PNG
      The detailed information of this alert can be viewed in table or json format (see the Beacon detect log data structure).
      The displayed counters are given in the Engine log data structure appendix.

2.1.11.2.1. Example of a Beacon detect alert in Kibana

../../_images/GCE103_BEACON-ALERTS-3.PNG
The presentation of the `Alert details` window is given in the `Alert details` window.
The counters are detailed in the Beacon detect log data structure.

2.1.11.2.2. Beacon detect log data structure

The logs are composed of different parts:

  • The header part

  • The source part defined by "_source"

  • The field part defined by "_fields"

This information is displayed in the `Expanded document` screen of Kibana.

2.1.11.2.2.1. The header part of the Beacon detect logs

The header section contains:

"_index": "engines_alerts-,
"_id": "-a9H1JMBe7Sz",
"_version": 1,
"_score": 0,

The detailed information is given in the table (Counters of the header part of logs).

2.1.11.2.2.2. The source part of the Beacon detect logs

The source part is defined by "_source" in the logs.

Note

The data displayed on the WebUI (alerts details window) is a part of the data displayed on the `Extended document` screen on the Kibana interface.
All data can be exported to a SIEM via syslog (an example of an exported alert is shown).
The detailed information is given in the table (Counters of the header part of logs).

The example given here is a Kibana example.

"tls": {
  "client": {
    "server_name": "cisco-update.com"
  }
},
"@version": "1",
"event": {
  "created": "2024-09-09T13:02:34.254441+00:00",
  "end": "2024-09-09T11:52:25.666000+00:00",
  "severity": 3,
  "module": "beacon_detect",
  "start": "2024-09-09T11:47:44.012000+00:00",
  "category": [
    "network",
    "intrusion_detection"
  ],
  "kind": "alert",
  "id": "5e7bb104-6493-43b2-be4d-f7c28ce79e85",
  "dataset": "alert"
},
"source": {
  "ip": "10.0.0.60",
  "mac": "60:57:18:e9:4f:5d"
},
"beacon": {
  "mean_time_interval": 1,
  "active": true,
  "possible_cnc": "not_recognized",
  "session_count": 260,
  "type": "constant",
  "id": "c4c886b4ad",
  "hostname_resolution": "not_analyzed"
},
"destination": {
  "ip": "157.230.93.100",
  "port": 443
},
"observer": {
  "product": "gcenter",
  "uuid": "78f4fed1-c9ad-52b9-b509-6b87767f501f",
  "log_format_version": "1.0.0",
  "hostname": "gcenter-clelyo-01.gatewatcher.com",
  "gcap": {
    "hostname": "gcap-clement-l.gatewatcher.fr",
    "version": "2.5.4.0-rc1"
  },
  "version": "2.5.3.103",
  "vendor": "gatewatcher"
},
"ecs": {
  "version": "8.6.0"
},
"@timestamp": "2024-09-09T13:02:59.354490664Z",
"url": {
  "domain": "cisco-update.com"
},
"network": {
  "protocol": "tls",
  "timestamp": "2024-09-09T11:47:44.012000+00:00",
  "transport": "tcp"
}

2.1.11.2.2.3. List of counters of the Malcore alert

Note

The alert counters are visible:

  • In the `Alert details` screen of the WebUI

  • In the `Expanded document` screen of Kibana

  • In the export to the SIEM

The detailed information is given in the table (Counters of the source part of logs).

2.1.11.3. Management of the engine

2.1.11.3.1. Viewing the engine status

The engine status is displayed in the `Health checks` screen if the engine has been activated: to check see `Beacon detect` screen (Beacon command).
The engine can be activated if the installed license allows it; see the `License` screen.

2.1.11.3.2. Engine update

There are updates for the engine.
These updates can be done manually or scheduled via the Threat DB update command.
See Dedicated modules for managing updates: Threat DB update and Software update and in particular the part Update presentation.

2.1.11.3.3. Beacon detect configuration engine and management of the ignored destination list

The management interface is used:

2.1.11.4. Alert Analysis

The alerts are displayed on a specific screen described in the WebUI `Alerts` screen.
The general procedure for analysing alerts is described in Using of NDR dashboards.
The specific procedure for analysing Beacon detect alerts is described in the Analyzing the Beacon detect alerts.