Application of SIEM for incident investigation

In the case of tens and hundreds of servers generating events, it is best to use specialized SIEM (Security Information and Event Management) solutions designed to manage security events. In addition to centralized storage of security events, SIEM can also analyze incoming events for compliance with correlation rules to detect incidents, and this is what we will talk about in this article. As examples of logs, both Windows OS event logs and Linux will be considered.

What is an incident

First, let's define the concept of an incident. We will call one or more undesirable information security events incidents, as a result of which business operations may be compromised and information security threatened. It should be understood that it is almost impossible to completely avoid incidents, but you can learn to respond correctly to their occurrence and minimize the likelihood of similar incidents recurring. Also, with the help of SIEM solutions, we can learn to effectively detect incidents. In this article, we will not focus on any specific SIEM, as the main goal will be to analyze the general principles of creating correlation rules for various types of incidents.

Stages of attack development

To present the main actions that a hacker can take to carry out an attack, we will use the MITRE matrix. The MITRE ATT&CK matrix describes the tactics and techniques that attackers use in their attacks on corporate infrastructure. In the figure below, the tactics are listed horizontally: Reconnaissance, Resource Development, Initial Access, and so on. And the techniques corresponding to each tactic are listed vertically.

Identifying Reconnaissance

Identifying the intentions of an attacker before they attempt to gain access somewhere is a difficult task. Open sources, publicly available information, and much more that cannot be logged can be used for reconnaissance.

But in the case of an internal violator, we can try to log some suspicious commands. In general, it may look suspicious if some accountant or manager starts running various commands on their machine intended for information gathering. But for an attacker who, for example, has just gotten onto a machine using malware, these commands will help them understand where they have landed and what they can do here.

For example, systeminfo. Running this command allows you to find out the basic information about the operating system being used.

systeminfo | findstr /B /C:"OS Name" /C:"OS Version"

Similarly, the hostname and whoami commands are unlikely to be needed by a regular user too often, except when communicating with technical support.

Finally, commands related to obtaining information about system users and detailed information about a specific user.

net users

net user username

If the machine is part of a domain, the set command will help the attacker learn a lot about system settings and interaction with AD.

In general, it would not hurt to set up correlations in your SIEM to detect the execution of these commands at least on user machines.

Gaining Access

Next, let's talk about the Initial Access tactic. Within this tactic, the attacker tries to gain access to the targeted system. They can do this in various ways, from searching for valid accounts and guessing passwords to exploiting various vulnerabilities. Accordingly, we need to build our rules to be able to detect such activities. In the simplest case, a password guessing attempt will look something like this:

Therefore, we need to catch such events and handle them properly. Various scenarios are possible here, from the banal several (three or more) unsuccessful login attempts from one node to more interesting scenarios when access attempts are made from several different nodes to one or vice versa, the attacker tries to log in from one node to several. At the same time, one login or several can be used.

Also, to detect Initial Access, it is worth paying attention to various error messages in the logs of the applications themselves. For example, a buffer overflow attempt may lead to the appearance of messages about application failures in the logs, such as accessing a forbidden memory page.

It is worth noting here that such messages, when it comes to Windows logs, usually appear not in the Security section, but in Application and possibly in System. Accordingly, security personnel, when connecting sources to SIEM, should not forget about the existence of other logs besides Security.

It would be nice to link events recorded earlier, such as the launch of suspicious commands at the reconnaissance stage with password guessing attempts or vulnerability exploitation. The linking element can be the IP address, node name, or attacker's login. Sometimes, using such links can significantly simplify the subsequent investigation of the incident.

Execution Stage

At the Execution stage, the attacker needs to execute various scripts and commands, load the necessary libraries to start preparing for persistence in the system. Special attention should be paid to Windows events 4103 and 4104 related to script execution.

Also, it would not be superfluous to pay attention to the launch of various protocols designed for file loading, such as SMB or FTP.

Under Linux, SSH (SCP) is usually used as transport, so activating SSH on a machine that does not imply remote access via this protocol is also very suspicious activity.

Persistence and Privilege Escalation

I have combined the next two stages together, as in practice, very often, in order to effectively persist in the system, the attacker first needs to obtain administrative rights.

Speaking of Linux, the reason for successful privilege escalation here may be the careless distribution of sudo rights or setting SUID bits.

So in the example below, having sudo rights on the find command allowed obtaining a root session.

In Windows, there is also the possibility of careless configuration of security policy rights. But we should not forget about the trivial vulnerabilities. So in the example below, the execution of the systeminfo command with SYSTEM rights was recorded in the logs. The reason for this was the implementation of the good old Ettrenalblue on a vulnerable Win 7SP1 machine.

Having obtained privileged user rights, the attacker will need to hide their activity in the attacked network as much as possible. To do this, they can create a user, add them to certain groups. They can also make changes to the autostart mechanisms in order to launch their own backdoor during the system boot process to organize remote access.

Thus, when developing correlation rules, we need to pay special attention to various commands related to adding users, changing rights, escalating privileges, and other privileged activities.

Conclusion

In conclusion, it should be noted that in many modern SIEMs, including free ones, correlation rules come out of the box. That is, you do not need to write your own rules from scratch, but instead you can use ready-made ones. For many of the attacks presented in the article, such rules already exist. However, I would like to caution against thoughtlessly enabling all the rules that come with SIEM. The fact is that correlation rules will inevitably give false positives, resulting in many incidents that are not actually incidents.

Therefore, the best solution would be to gradually enable only the necessary rules to identify the corresponding activities of intruders.