2.1.10. Beacon detect engine

2.1.10.1. Introduction

2.1.10.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.

2.1.10.1.2. How does this particular engine detect threats?

The Beacon Detect 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.10.1.3. How does the Beacon Detect engine work in the GCenter?

The engine:

Analyses the events sent by GCap (for further details see Beacon Detect engine input data)
Analyses these events (for further details see How does this particular engine detect threats?)
Generates alerts (for further details see Events generated by the engine)

2.1.10.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:

DNS 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 the `Base variables` Section of the `GCaps profiles` screen.

2.1.10.1.4. Management of the Beacon Detect engine

To view the status of the Beacon Detect engine, see the Viewing the engine status paragraph.
To update the Beacon engine, see the Engine update paragraph.
To configure the Beacon engine, see the Beacon Detect configuration engine and management of the ignored destination list paragraph.

2.1.10.1.5. Events generated by the engine

Events generated by the Beacon Detect engine are alerts only.

These are displayed:

In the main interface named WEB UI of the GCenter in the `Alerts` screen.

The main interface named WEB UI is described in the Overview of the WEB UI.
- To display the beacon alerts, select the `Beacon` engine filter.
  
  See the presentation of the Web UI `Alerts`.
- Click on the selected alert.
  
  The `Alert details` window is displayed.
In the interface named Kibana UI:
- Click on the `Hunting` icon of the `WEB UI`.
  
  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
- Click on the toggle icon on the left of the Alert
  
  The expanded document is displayed.
  
  The detailed information of this alert can be viewed in table or json format.

2.1.10.1.6. Essential information to understand the context of the alert

2.1.10.1.6.1. What are the key fields of an alert and their meaning in the webui?

Before undertaking any investigation or qualification of the alert, it is essential to start by observing several elements that will provide essential information to understand the context of the alert.

Here are the main fields displayed in the `Alerts` screen of the WEB UI of the GCenter:

`Risk`

This is the risk score of the alert.

It depends on the identification of detection evasion techniques used by C&C and features specific to some known C&C frameworks.
`Name`

This is the threat description based on the analysis. It consists of:
- The alert severity:
  
  - `Beacon behavior detected to` is displayed if a specific C&C server has been identified
  
  - `Highly suspicious beacon behavior detected to` is displayed if a generic C&C behavior has been identified
  
  - `Suspicious beacon behavior detected to ` is displayed when a periodic communication pattern has been identified
- the Server Name Indication (tls.sni )

Note

To modify the options of the engine: see the Setting up the beacon detect engine

2.1.10.2. Events generated

Events generated by the Beacon Detect engine are alerts only.

These are displayed:

In the main interface named WEB UI of the GCenter in the `Alerts` screen.

The main interface named WEB UI is described in the Overview of the WEB UI.
- To display the beacon alerts, select the `Beacon` engine filter.
  
  See the presentation of the Web UI `Alerts`.
- Click on the selected alert.
  
  The `Alert details` window is displayed.
In the interface named Kibana UI:
- Click on the `Hunting` icon of the `WEB UI`.
  
  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
- Click on the toggle icon on the left of the Alert
  
  The expanded document is displayed.
  
  The detailed information of this alert can be viewed in table or json format.

2.1.10.2.1. Example of a Beacon detect alert in kibana

../../_images/GCE103_BEACON-ALERTS-3.PNG

The presentation of the Alert details is given in the Alert details window.

The counters are detailed in Beacon detect log data structure.

2.1.10.2.2. Beacon detect log data structure

The logs are composed of different parts:

The leading part
The source part defined by "_source"
The field portion defined by "_fields"

This information is displayed in the Expanded document of Kibana.

2.1.10.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.10.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 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 tables ( Data related to detection results).

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.10.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 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.10.3. Management of the engine

2.1.10.3.1. Viewing the engine status

The engine status is displayed in `Health checks` screen if the engine has been activated: to check see `Beacon detect` screen.

The engine can be activated if the installed Licence allows it ; see the `License` screen.

2.1.10.3.2. Engine update

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

2.1.10.3.3. Beacon Detect configuration engine and management of the ignored destination list

The management interface is used:

To filter the events (engine inputs) either to activate protocols or to filter events:
- see the screen description, see `Metadata rate limiter` screen
- see the procedure, see Configuring Metadata Rate Limiters
To activate the engine or modify its parameters (sensitivity or Alerts rate limiter):
- see the screen description, see `Beacon detect` screen
- see the procedure, see Setting up the beacon detect engine
To manage the `Ignore list` used to explicitly filter healthy destinations (defined by domain name or IP):
- see the screen description, see `Beacon detect` screen
- see the procedure, see Setting up the beacon detect engine

2.1.10.4. Alert Analysis

The alerts are displayed on a specific screen: this screen is described in Web UI `Alerts`.
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 Analysing the Beacon Detect alerts.