2.1.2. Shellcode detect engine

2.1.2.1. Introduction

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

The Shellcode Detect engine allows the detection and analysis of shellcodes.
A shellcode is a binary code designed to be injected and executed into a program by exploiting a vulnerability.
Similar to a miniature malware, its goal is usually to take control of the infected system, but any type of action can be performed.
Shellcodes often have many constraints related to the exploited vulnerability (limited size, forbidden bytes, ...).
Thus, an attacker will generally use it to "put a foot in the door", before moving on to more advanced techniques.
A shellcode can be used to open a backdoor on the machine, to let the attacker act live, or download directly in memory a malware and run it.
A shellcode can also be obfuscated, "encoded", to avoid being detected by patterns, but while remaining executable as is.
It must be able to self-decode, we then speak of polymorphism.
There are many encoding algorithms for shellcodes on the internet, more or less complex.
Due to its nature, shellcode is difficult to detect:
  • Not a file

  • It is directly executed in memory in a healthy program

  • Its small size reduces pattern possibilities for detection

  • May be obfuscated to avoid pattern detection

A shellcode can also be used in a malware in order to blur the tracks during an antivirus scan.

2.1.2.1.2. How does this particular engine detect threats?

Shellcode detection is done in several steps:

  • The first step is to analyze the samples for shellcode encodings.
    Indeed, these algorithms are specific to shellcodes, they cannot be found in another context.
    This process allows accurate and indisputable identification of shellcodes.
  • If one or more encodings are identified, the shellcode is extracted and sent to the analysis step.

  • If no encoding has been identified, the sample goes through a thorough indicator search.
    This process will perform an intelligent, emulation-based search to try to identify a typical shellcode behaviour.
  • The last step is to analyze the identified shellcode in order to validate the detection, and extract as much information as possible.
    This process will perform full shellcode emulation and record all system functions called.

2.1.2.1.3. How does Shellcode Detect engine work in the GCenter?

The engine:


2.1.2.1.3.1. Shellcode Detect engine input data

Any packet passing through the network will undergo a search for smart patterns to identify those that may contain a shellcode.
These packages are then extracted and sent to the GCenter for further analysis by the Shellcode Detect engine.
Once the analysis is completed, if a shellcode has been identified, an alert is raised with all the information collected.

Currently, only shellcodes for Linux and Windows machines, under Intel x86 and x64 architecture, are detected.
Encoding identification will only be possible for a defined set of algorithms, but this will not prevent the detection of shellcodes whose encoding could not be identified.
Detection of shellcodes embedded in malware is possible and will follow the same scanning path, but will not work if they are "hidden" (encryption, compression, ...) since it would require a dynamic analysis of the malware itself.

In order for the engine to be operational, a first update of the "Threat-DB" will have to take place.

2.1.2.2. Events generated

Events generated by the Shellcode Detect engine are alerts only.
These are displayed:
  • In the main interface named WEB UI on the GCenter in the `Alerts` screen
    The main interface named WEB UI is described in the Overview of the WEB UI.
    • To display only these alerts, select the `Shellcode` engine filter.
      See the presentation of the Web UI `Alerts`.
      ../../_images/GCE103_SHELLCODE-01.png
    • Click on the selected alert.
      The `Alert details` window is displayed.
      The detailed information of this alert is displayed in Example of a Shellcode alert in the Webui
      ../../_images/GCE103_SHELLCODE-02.PNG
  • 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 `Shellcode` tab (2) of the `Alerts` category (1).

    • Select the `Overview` tab (3).

    • Select the time range (4) to display data.
      ../../_images/GCE103_SHELLCODE-08.PNG
    It is then possible to filter on certain values for, for example:
    • Do not display healthy machines (filter false positives)

    • Show only alerts from a particular IP

    • Do not display alerts from a specific GCap

  • To consult information about a specific alert:

    • Click on the toggle icon on the left of the Alert (1).
      The expanded document (2) is displayed.
      ../../_images/GCE103_SHELLCODE-09.PNG
      The detailed information of this alert can be viewed in table or json format.

2.1.2.2.1. Example of a Shellcode alert in the Webui

../../_images/GCE103_SHELLCODE-02.PNG
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.2.2.2. Shellcode 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.2.2.2.1. The header part of the Shellcode logs

The header section contains:

"_index": "engines_alerts-2024.12.04-000030",
"_id": "BqIIkpMBe7GX5B2fdvZJ",
"_version": 1,
"_score": 0,

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


2.1.2.2.2.2. The source part of the Shellcode logs

The source part defined by "_source" contains:

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.

"event": {
  "created": "2024-12-04T14:17:28.138941+0000",
  "dataset": "alert",
  "severity": 1,
  "module": "shellcode_detect",
  "kind": "alert",
  "category": [
    "network",
    "intrusion_detection"
  ],
  "id": "f22d2438-d436-4391-9e7d-3fe1321ebed0"
},
"@version": "1",
"destination": {
  "port": 9999,
  "ip": "X.Y.Z.A"
},
"source": {
  "port": 33390,
  "ip": "W.S.Q.E"
},
"observer": {
  "log_format_version": "1.0.0",
  "hostname": "gcenter.domain.local",
  "vendor": "gatewatcher",
  "gcap": {
    "ingress": {
      "interface": {
        "name": "monvirt"
      }
    },
    "hostname": "gcap.gatewatcher.com",
    "version": "2.5.4.0"
  },
  "product": "gcenter",
  "uuid": "fc1e66e3-a397-5eb4-9277-754be778f317",
  "version": "2.5.3.103"
},
"ecs": {
  "version": "8.6.0"
},
"shellcode": {
  "sample_id": "12-04-2024T14:17:25_92517a8550cf4130b23466244880c1c7_gcap-int-129-dag.gatewatcher.com",
  "analysis": [
    {
      "args": "{'pathname': '//etc/passwd', 'flags': 'O_WRONLY|O_APPEND', 'mode': 'None'}",
      "_id": 0,
      "call": "sys_open",
      "ret": "4"
    },
    {
      "args": "{'fd': '//etc/passwd (4)', 'buf': 'bob::0:0::/://bin/sh', 'count': 20}",
      "_id": 1,
      "call": "sys_write",
      "ret": "20"
    },
    {
      "args": "{'fd': '//etc/passwd (4)'}",
      "_id": 2,
      "call": "sys_close",
      "ret": "0"
    },
    {
      "args": "{'status': 4}",
      "_id": 3,
      "call": "sys_exit",
      "ret": "0"
    },
    {
      "info": "Stop : End of shellcode (Exit)",
      "_id": -1
    }
  ],
  "sub_type": "Linux_x86_32",
  "encodings": [
    {
      "name": "Shikata_ga_nai",
      "count": 1
    }
  ],
  "id": "8ae5f9d35f3878cac3064fe93e4c311d"
},
"@timestamp": "2024-12-04T14:17:28.138Z",
"network": {
  "protocol": "unknown",
  "transport": "tcp",
  "timestamp": "2024-12-04T14:16:12.828909+0000",
  "flow_id": 1134126449059384

2.1.2.2.2.3. List of counters of the 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.2.3. Management of the engine

2.1.2.3.1. Viewing the engine status

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


2.1.2.3.2. Engine update

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


2.1.2.3.3. Engine configuration

The configuration interface enables to activate the engine:

2.1.2.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 Shellcode detect alerts is described in the Analysing the Shellcode detect alerts.