Exploit monitoring

In the last article, we collected data in order to monitor the exploitation of a vulnerability in Windows Server, which has the role of a domain controller. In this article, we will try to understand whether it is possible to monitor other classes of exploits using ELK, Zabbix or Prometheus tools.

Exploit classification from a monitoring point of view

Vulnerability is software imperfection. In the simple case, this is the reason why the application cannot complete its task and terminates abnormally.

Can all vulnerabilities be traced? Let’s try to put the facts together. Fact number 1 vulnerabilities from the point of view of their use to achieve the goals of compromising or disabling an information system can be roughly divided into:

  1. Application crash vulnerabilities

  2. Vulnerabilities allowing to run additional commands on a vulnerable system

It is worth noting that for both groups, we can only monitor the consequences or dependent events.

The first group of vulnerabilities is easily monitored by ELK, Zabbix and Prometheus systems. The inaccessibility of the affected system will immediately be displayed for general monitoring.

Not so simple with the second type. The fact is that these particular vulnerabilities have a fairly large number of variations. And as a rule, they are associated with those subsystems where the order and speed of the system’s actions are important. It is very difficult to add mechanisms for collecting information for monitoring into these subsystems.

to understand how many of these vulnerabilities are, their list by popularity in software can be found here

Fact number 2 – all classes of vulnerabilities documented – 699. An interesting figure, but this is also a high-level abstraction, in fact, these 699 vulnerabilities also have variations.

What is special among the 699 vulnerability groups? The peculiarity lies in the fact that most of these vulnerabilities, by their nature, are quite problematic to detect. For example, the group CWE-120… A group of vulnerabilities, the main meaning of which is that the programmer did not correctly calculate the amount of memory that the application needed to work with a certain object. As a result, the attacker has the ability to influence the memory filling of the process. In some cases, this can lead to the execution of commands transmitted by the attacker.

Very rarely, modern operating systems provide events in their logs that allow detecting such vulnerabilities. Moreover, these vulnerabilities, if any in the software, can be studied or detected only if the application is switched to debug mode, which is not the usual mode of operation for most applications.

It turns out that the memory for monitoring is not available? In fact, this is not the case. Any monitoring system and even operating system logs can include information about how applications consume memory. You can observe this data in real time using various software such as VMMap… The software can show the number of memory pages that are in use, released, reserved, etc. What does this give us?

None of the vulnerabilities described above can be useful to an attacker without a special method of exploiting it. All 699 groups have their own methods and approaches that allow the vulnerability to be exploited to execute commands. Sometimes they are separate programming patterns, sometimes they are a set of sequences of functions, and sometimes they are just a list of vulnerabilities that are used together to perform the resulting operation. Therefore, to detect the fact of exploitation, we need:

  • understand how the exploit works, ideally if there is a source code

  • be able to expand the set of events in the OS system logs

Detection tactics based on the Miter list

Vulnerabilities by themselves may not be visible on monitoring tools. When using the capabilities of the operating system only. Sometimes the vendors themselves, seeing the popularity of the vulnerability, can create separate events that help to localize the exploitation of the vulnerability.

In the case of the CVE-2020-1472 vulnerability, Microsoft has added special events that are generated when the system uses vulnerable algorithms. We will have to look for patterns on our own and use these patterns for monitoring. You may even have to resort to third-party software products.

For an example of collecting such patterns, we will use the exploit for the CVE-2020-0796 vulnerability. The main problem of the vulnerability is an overflow of an integer element, which is used to control the size of the memory allocated by the application. There are 2 scenarios for exploiting the vulnerability on the Internet:

  1. Remote Code Execution

  2. Local priveledge escalation

The first is very unstable, it is quite difficult to get commands from it to execute. However, due to the fact that the vulnerability is in the kernel, the OS crash will be registered by monitoring by default.

Let’s try to figure it out with the second one. The github project provides source code in the C ++ programming language. Let’s try to localize the main operations performed by the exploit.

Its initialization code can be found below:

A socket is created on the loopback interface and port 445. Next, the exploit will create a packet in a special format and send it to the created socket. There will be an overflow of the size of the allocated memory in the OS kernel and the code will overwrite the memory that belonged to the primary token of the main process. With this data, a new cmd.exe process will be created. How is this process created? This data can be found in the source:

Unfortunately, we could not find anything among the log events, since all actions worked dynamically in RAM and did not use standard mechanisms for gaining access to objects. The Security log will also not contain any information. What to do? There are 2 options:

  1. Use IDS for loopback interface

  2. Use Endpoint Protection

We will choose the 3rd path. In Windows OS it is possible to expand the list of events that will be generated by the system. This can be done using the tool SysMon… In order for the tool to generate the necessary events, it needs a config, which lists the necessary data. Already have ready… Moreover, if we want to track events with the loopback interface, we need to remove the following lines:

...
<RuleGroup name="" groupRelation="or">
        <NetworkConnect onmatch="exclude">
            ...
            <DestinationIp condition="is">127.0.0.1</DestinationIp> <==удалить
            <DestinationIp condition="begin with">fe80:0:0:0</DestinationIp> <==удалить
        </NetworkConnect>
    </RuleGroup>
...

All data on events is laid out in the system logs. For Windows 10, you can use this path: Applications and Services Logs Microsoft Windows Sysmon Operational.

To install the config and Sysmon into the system, you need to type the following command:

sysmon.exe -accepteula -i sysmonconfig-export.xml

Let’s launch the exploit and look at the Sysmon log:

And here is our file lit up, which was used for operation. Now it will be easy to write a template for this event and monitor them in Zabbix. We suggest the reader to customize it yourself. This, by the way, can be done according to a similar scenario from the previous article.

PS For Linux-based systems, too, will soon be SysMon

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *