2.1.9. Ransomware detect engine

2.1.9.1. Introduction

2.1.9.1.1. For what types of threats is this engine designed?

The GCenter includes an engine capable of detecting ransomware executions.
Ransomware is malware that blocks access to the computer or files by encrypting them and demands ransom payments from the victim to regain access.
Most ransomware will not only encrypt files locally on an infected computer but will also try to encrypt all files accessible from network shares.
For this, the ransomware uses the SMB protocol (including its most widespread version in business: SMBv2).
In order to be as generic as possible, and to be able to detect new ransomware, the model uses only the commands for reading and writing files.

2.1.9.1.2. How does this particular engine detect threats?

The ransomware detection engine functions as a semi-supervised anomaly detector (novelty detection).
It is therefore necessary to be trained with legitimate data corresponding to the customer’s specific traffic (over a certain period of time which depends on the amount of SMB traffic on its network).
The training uses a neural network algorithm called autoencoder.
Once the model is trained and tested on a number of examples of ransomware whose network traffic could be captured, an optimal anomaly score threshold is determined.
The model is then ready to be used to make predictions: for each sample tested (each sample corresponds to one end (20 seconds) of a SMB session, containing at least one READ or WRITE event), an anomaly score is determined.
If this score is higher than the threshold defined above, then a unit alert for this sample is recorded.

2.1.9.1.3. How does Ransomware detect work in the GCenter?

The engine:

analyzes the events sent by GCap (for further details, see Detections / Predictions)
analyzes these events (for further details, see How does this particular engine detect threats?)
generates alerts (for further details, see Events generated)

2.1.9.1.3.1. Training and re-training

The first training is triggered automatically by the GCenter, as soon as the number of examples (samples) needed (of the order of 200000) is reached.
A periodic process check regularly that if a re-training is necessary because the client traffic can be modified enough (for example via a change in network configuration) so that the learning done previously has become obsolete.
If re-training is required, a notification is issued to the user to inform him.
The effective triggering of the re-drive is then triggered manually.

Note

During re-training, the engine continues to detect with previous learning.

2.1.9.1.3.2. Detections / Predictions

The trained model can then be used by the engine to make predictions of ransomware.

Detection is done in two steps:

The first step uses the machine learning model to make unit predictions on samples
The second step takes into account the contextual information of the SMB session in order to determine if it corresponds to a ransomware

Indeed, legitimate traffic is likely to occasionally (at least for a part of SMB sessions) have abnormal behaviour, and therefore raise unit alerts at the end of the first step. It is therefore necessary to have a second step to determine whether it is a ransomware.

Periodically, the following process is executed:

Step 1:
- The engine tracks each SMB session and cut them in small 20-seconds time windows, that we will call "sample"
- On each sample, features are built on READ and WRITE commands: for instance, READ/WRITE ratio or READ/WRITE sequences : many other features are employed
- Based on these features, a prediction is made on each sample and produce an abnormality score
- When multiple samples of the same SMB session are suspicious, and depending on the sensitivity level, an alert is produced
Step 2: for each SMB session with at least an abnormality score above the defined threshold, the following actions are performed:
- Analysis of ransomware behaviour shows that the number/share of abnormal samples in their SMB session is much larger than in legitimate traffic.
  
  Similarly, the observed anomaly scores are also generally much higher.
- All this information is taken into account to raise or not a global alert on the corresponding SMB session.
- Multiple sensitivity levels (5 levels. 5 corresponding to the highest sensitivity) corresponding to as many severity levels are associated with alerts.
- In practice, the engine will potentially sequentially raise alerts for increasingly low sensitivities (and therefore significant severity) as the SMB session is analyzed.

2.1.9.2. Events generated

Events generated by the Ransomware engine are alerts.

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 Overview of the WEB UI.
- To view the alerts, select the `Ransomware` filter and view the list of alerts
  
  See the presentation of the Web UI `Alerts`.
- Click on the selected alert.
  
  The `Alert details` window is displayed.
  
  The detailed information of this alert is displayed.
In the interface named Kibana UI

For further details, refer to the Overview of the Kibana GUI.

To display Ransomware alerts in this interface:
- In the main interface WEB UI, to view the alerts, select the `Ransomware` engine filter.
  
  See the presentation of the Web UI `Alerts`.
- After selected the alert, click on the `Open host SMB activity` command of the `Actions` menu.
  
  Kibana is opened on the `Ransomware` category of the `Alerts ` section.
  
  The interface displayed is the interface named Kibana UI (described in the Overview of the Kibana GUI).
  
  In the `Overview` tab, the database is filtered on the `source.ip:` parameter.
  
  The detailed information of this alert can be viewed in table or json format.

Note

The Kibana user interface is also accessible without a filter via the `Hunting` icon in the left menu bar.

2.1.9.2.1. Example of Ransomware detect alert in the WebUI

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

The counters are given in the Example of an alert exported.

2.1.9.2.2. Ransomware 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.9.2.2.1. The header part of the Ransomware logs

The header section contains:

"_index": "engines_alerts-2024.12.17-000002",
"_id": "maMz2pMBPJntoSnXt_aZ",
"_version": 1,
"_score": 0,

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

2.1.9.2.2.2. The source part of the logs

The source part defined by "_source" contains:

"source": {
     "ip": "x.x.x.x",
     "port": 50066
   },
   "network": {
     "protocol": "smb",
     "transport": "tcp",
     "timestamp": "2024-12-18T14:34:54.069000+00:00",
     "community_id": "UNDEFINED",
     "flow_id": 2133648979435527
   },
   "@version": "1",
   "observer": {
     "log_format_version": "1.0.0",
     "hostname": "gcenter.gatewatcher.fr",
     "product": "gcenter",
     "uuid": "34b30bd0-ff0f-5fb2-a746-6500d47b45dd",
     "gcap": {
       "hostname": "gcap.gatewatcher.fr",
       "ingress": {
         "interface": {
           "name": "monvirt"
         }
       },
       "version": "2.5.4.0-rc9"
     },
     "version": "2.5.3.103",
     "vendor": "gatewatcher"
   },
   "event": {
     "kind": "alert",
     "created": "2024-12-18T14:37:08.775755+00:00",
     "end": "2024-12-18T14:35:20.642000",
     "dataset": "alert",
     "module": "ransomware_detect",
     "start": "2024-12-18T14:35:00.642000",
     "category": [
       "network",
       "intrusion_detection"
     ],
     "severity": 1,
     "id": "ce827e02-7eb6-4842-8863-b787f52d1104"
   },
   "destination": {
     "ip": "y.y.y.y",
     "port": 445
   },
   "ecs": {
     "version": "8.6.0"
   },
   "@timestamp": "2024-12-18T14:37:08.775Z",
   "smb": {
     "session_id": 593737889611873
   },
   "ransomware": {
     "alert_threshold": 930,
     "session_score": 35,
     "malicious_behavior_confidence": 80

2.1.9.3. Management of the engine

2.1.9.3.1. Viewing the engine status

The engine status is displayed in `Health checks` screen.

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

2.1.9.3.2. Engine update

The engine is updated with each new version of the GCenter.

2.1.9.3.3. Ransomware detect configuration and management of the ignored files list

The management interface is used:

To activate the engine or modify its parameters:
- See the screen description, see `Ransomware detect` screen.
- See the procedure, see Setting up the Ransomware detect engine
To manage the `Ignore list`, list to explicitly filter healthy destinations (defined by IP):
- See the screen description, see `Ransomware detect` screen.
- See the procedure, see Managing the `Ignore list` of the Beacon detect.

Note

Even with metadata limiter enabled, ransomware detect will perform normally.

2.1.9.4. Alert Analysis

The alerts are displayed on a specific screen: this screen is described in Web UI `Alerts`.
The general procedure for analyzing alerts is described in Using of NDR dashboards.
The specific procedure for analyzing Ransomware detect alerts is described in the Analysing the Ransomware detect alerts.