Improving Threat Detection Capabilities with the MITRE ATT&CK Security Knowledge Framework

To Be Continued

The analysis content of Wazuh is credited to Zhang Hao and Xie Tao, I am just living in vain, they understand technology. Looked at the content, still divided into three parts, this time let's talk about the functions and rules of Wazuh.

Function Analysis

Log Collection

The Wazuh agent's log collection monitors the changes in the file content to be collected according to the settings in the agent configuration, and sends the changed log information to the server when a change occurs. The server decodes the log content through the decoder and matches the rules for alert processing. Its main processing flow is as shown in the following figure:

The agent's configuration file /var/ossec/etc/ossec.conf specifies the log files to be collected:

The log information collected from the specified files by the agent is sent to the server, where the log content is parsed. As shown in the following figure, the server can output the original log file information after parsing:

The original log information records the time of the event, the user performing the operation, the result of the event, and the original log file. The server parses the results and matches the rules to form alert information, displaying the matched rule set, security warning levels, and other content.

The code implementation is performed by the logcollector module, which will process the log files based on their types separately, as shown in the following figure:

After determining the type of the log file, proceed with the reading and sending of the log. The log content is finally sent to the ossec-remoted process of the manager by ossec-agentd and then sent to the ossec-analysisd process for analysis.

Log file collection supports configuration methods such as specifying files, regular expression matching, log monitoring, and collection from Windows event log files, environment variables, etc.

File Integrity Monitoring

The Wazuh file integrity monitoring mainly monitors Linux configuration files and Windows registry content. During the installation of the agent, it will collect file information on the endpoint and form encrypted verification storage. By setting the configuration items, the syscheck component in the server scans the files regularly, compares the scanned file data with the stored data, and determines whether they have been modified. The file integrity verification is not performed in real time, but is scanned and executed periodically. Its main workflow is as shown in the following figure:

In the configuration items, you can set the scan interval, the directories and files to be monitored, and other settings such as directories not to be monitored, as shown in the following figure:

Malware Detection

The Wazuh agent implements malware detection mainly by detecting actions that do not match the expected behavior patterns of command execution in the operating system. Malware modifies or mimics the original system commands to execute specific actions, achieving the effect of hiding malicious behaviors on the endpoint for information collection. This is performed by the rootcheck module, as system files are changed, and can also be checked by the syscheck module for file integrity monitoring. The main workflow is as shown in the following figure:

Through the monitoring of file integrity, when it is determined that the integrity of the files of specific commands in the system has changed, an alert is issued for the change of the command, and the administrator determines whether the program has malicious behavior.

Some malicious programs may hide their own process ID, making it impossible to see the process in the system list. Wazuh can view hidden processes in the system by replacing the system ps command (trojan version).

Malware may hide the port information used, and it is not possible to query the port usage information when checking with common commands such as netstat, the proxy will try to connect to the udp and tcp ports on the system using socket(), thereby determining whether there are hidden ports (this is also the practice of some manufacturers).

Wazuh will check the files on the endpoint system, looking for abnormal file permissions, hidden files or directories, etc., to determine whether they are malicious programs.

Wazuh will also check for malicious programs by checking programs such as dev, sys, etc., from multiple aspects, and the main checking methods are as follows:

Security policy standard detection

System security policy detection is the process of verifying whether the system meets the security configuration and a set of predefined rules for the specified applications, by scoring the configuration of security policies in the system using the security policies published by the Internet Security Center (CIS). Modules that perform functions include rootcheck, openscap, and CIS-CAT.

The detection of rootcheck mainly checks for the existence of configuration files, whether files or special strings are contained in the Windows registry, etc. Some strategies are as follows in the table:

The policy and compliance database is managed by the server, and they are下发 to the agent by the server.

OpenScap provides the function of executing configurations, mainly used for verifying security compliance, assessing vulnerabilities, and expressing and manipulating security data in a standardized way, the main process of assessment includes:

Scap scan:Read the scap policy and check if the system meets its application.

Security policy:How the system is set up and what content is checked.

Configuration file:Provide guidelines and value sets that meet specific security benchmarks.

Evaluation:The process in which the scanning program executes on the agent based on specific policies and configuration files.

Its main implementation methods include the following:

The main processing process is shown in the following figure:

Supported evaluation security standards include: PCI-DSS, GDPR, HIPAA, NIST 800-53, TSC

System call monitoring

This module is mainly aimed at Linux systems and combines audit audit rules for execution. According to the pre-configured rules, audit can record detailed information about the time events occur in the system, and wazuh will form reports with audit information for alarms.

The following three types of rules are supported by audit:

Control rules: Allow modification of the behavior and certain configurations of the audit system.

File system rules: Allow auditing access to specific files or directories.

System call rules: Allow recording system calls made by specified programs.

After adding the corresponding rules using audit in the endpoint system, add the corresponding monitoring content in the wazuh configuration, and wazuh can receive the corresponding audit log content. The configuration items include the following:

This part of the rule executes the audit of command execution, file modification, read, and delete monitoring rules, which requires the addition of audit rules on the endpoint separately, making it more cumbersome and not allowing for unified deployment.

Remote Command Execution Monitoring

In the operating system, some event processing results are not displayed in the logs, but in the output of the command execution. To solve this problem, Wazuh has implemented the monitoring of remote specific command outputs, treating the output content as log content, and the main processing flow is as shown in the figure below:

To implement this feature, it is necessary to enable remote command reception on the agent, add the configuration item in /var/ossec/etc/local_internal_options.conf: logcollector.remote_commands=1, and add the corresponding execution command in the server's configuration file /var/ossec/etc/ossec.conf:

After configuration is complete, the agent will execute commands at the corresponding time intervals based on the configuration items, collect the output results of the commands as log content for analysis and processing, and trigger an alert when the alert conditions are met.

Active Response

Active responses execute policies to address received active threats, such as blocking threat source access to endpoint machines after meeting certain rules. Active responses execute scripts to respond to specific alerts triggered by alert levels or rule groups, but if the response execution is not strong enough, it may increase the system's risk. The main processing flow is as shown in the figure below:

Active responses are configured for specific alerts, alert levels, or rule groups that have been triggered to execute scripts. They are divided into stateful responses and stateless responses. Stateful responses are actions that are revoked after a specified time period, while stateless responses are one-time actions. Each active response will execute its associated commands at the location of the associated command, including: on the agent that triggered the alert, on the manager, on another specified agent, or on all agents including the manager.

Wazuh provides the following active response script content:

wazuh rules

Wazuh alerts, rules

WAZUH system uses custom rules to detect attacks, intrusions, software abuse, configuration issues, application errors, malware, rootkits, system anomalies, or violations of security policies. Based on a set of 'out-of-the-box' rules provided by OSSEC, WAZUH has updated and expanded them to enhance its threat detection capabilities.

Currently, WAZUH supports over 4000 rules, which involve:

WAZUH rule descriptions and threat check examples

Log analysis rules for Netscaler with PCI DSS compliance mapping:

Root check rules for SSH servers, mapped to CIS security benchmarks and PCI DSS compliance:

Directory layout

The directory structure of the rule set folder is shown as follows:

In the ruleset/ folder, you can find all common rules and decoders. All files in this folder will be overwritten or modified during the WAZUH update process, so do not edit files or add custom files in this folder.

If you need to execute some custom rules or change existing rules, use the etc/ folder. You can add your own-defined decoder/rule files here or use the system default local_decoder.xml and local_rules.xml files.

JSON decoder

WAZUH now has an integrated decoder for JSON logs, which can extract data from any format of source data.

This decoder can extract the following data types:

The extracted fields are stored as dynamic fields and can be referenced by rules.

The following example shows how WAZUH decodes JSON logs and generates alerts for events related to Suricata data sources.

Suricata event logs:

The JSON decoder extracts each field from the log data to compare with the rules, so there is no need for a specific Suricata decoder. These rules will be used to identify the data source of JSON events based on the presence of certain fields from specific data sources that generate JSON events.

The following example shows how the rules contained in the file (0470-suricata_rules.xml) work. Initially, there is a parent rule that checks for the presence of 'timestamp' and 'event type' fields to determine the log type (Suricata), and then the child rules display alerts using the values of the extracted fields.

Custom rules and decoders

In the WAZUH rule set, you can modify default rules and decoders, and also add new rules and decoders to enhance the detection capabilities of WAZUH.

Add new decoders and rules

You can make appropriate modifications to the local_decoder.xml and local_rules.xml files to add new decoders and rules. For large-scale changes/additions to existing decoders and rules, it is recommended to create new decoder and rule files. The custom rule <id> range is between 100000 and 120000.

Below is a simple example to describe these processes. This is a program log from a program named example:

First, decode the information of concern, so the first step will add the new decoder to /var/ossec/etc/decoders/local_decoder.xml:

Then, add the following content to /var/ossec/etc/rules/local_rules.xml:

You can use the following method to check if it is valid /var/ossec/bin/wazuh-logtest:

Modify the existing system rules

Changes to any rule file in the folder (/var/ossec/ruleset/rules) will be lost during the version update process. Use the following process to retain custom changes.

If you want to change the alert level value defined in the SSH rule (ID: 5710) from 5 to 10, you need to perform the following operation:

1. Open the rule file /var/ossec/ruleset/rules/0095-sshd_rules.xml.
2. Find and copy the following code from the rule file:

3. Paste the code into /var/ossec/etc/rules/local_rules.xml, modify the alert level value, and add overwrite="yes" to indicate that this rule is overriding the defined rule:

In addition, standard decoders can also be modified.

Changes to any decoder file in the folder (/var/ossec/ruleset/decoders) will be lost during the version update process. Use the following process to retain custom changes.

Unfortunately, there is no tool described by the above rules to cover the decoder. However, changes can be made in any decoder file as shown below:

1. Copy the decoder file /var/ossec/ruleset/decoders/0310-ssh_decoders.xml from the default folder to the user folder /var/ossec/etc/decoders to retain the changes.
2. Exclude the original decoder file from the OSSEC list——ruleset/decoders/0310-ssh_decoders.xml. To do this, you need to use the <decoder_exclude> tag in the conf file. Therefore, the specified decoder will not be loaded from the default decoder folder, but will load the decoder file stored in the user folder.

3. Changes to the executable file /var/ossec/etc/decoders/0310-ssh_decoders.xml.

Alert level

Improving Threat Detection Capabilities with the MITRE ATT&CK Security Knowledge Framework

WAZUH's feature allows users to customize alert information to include specific attack information related to the MITRE ATT&CK security knowledge framework. The MITRE ATT&CK security knowledge framework stores all network attack techniques, detection methods, and defense measures. When users want to learn more about attack details, the knowledge in the ATT&CK security knowledge framework provides clear explanations.

Configuration Example

MITRE ATT&CK assigns an ID to each attack technique. These attack techniques are grouped by the different attack tactics they belong to (such as defense evasion, privilege escalation, etc.), and some techniques may belong to multiple tactics.

The attack technique T1110 in ATT&CK is related to brute force. This technique is very consistent with the following rules (ID: 100002), which detect brute force attacks and generate alerts. The following is an example of how to extend the attack techniques in the ATT&CK security knowledge framework to this rule.

Add the following code to /var/ossec/etc/rules/local_rules.xml

Restart WAZUH for the rule configuration to take effect automatically.

MITRE information appears in the rule information. The alert displays the ID of the attack technique and its related attack tactics and technical descriptions in the MITRE ATT&CK security knowledge framework.

View using Kibana

We can check if the alert is displayed correctly on Kibana. Open it and add a filter.

As of April 24, 2022, the default rule set of the WAZUH system contains 4093 various rules, involving 140 TTP attack techniques.