Using SIEM for incident investigation
Incident detection is one of the main tasks of information security specialists. Incidents can be detected in various ways. For example, you can manually analyze event logs to look for suspicious activity messages of interest. You can develop scripts based on grep and regular expressions that will search for the necessary events in a more or less automated mode. Also, the logs themselves can be stored locally on the same machine, or they can be centrally stored and analyzed on a separate server. However, all these home-made tools are good when it comes to several servers and not too much event flow.
If we have tens or hundreds of servers that generate 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 information security events, SIEM can also analyze incoming events for compliance with correlation rules to identify incidents, and this is what we will talk about in this article. Both Windows and Linux event logs will be considered as examples of logs.
What is an incident
First, let's define the very concept of an incident. We will refer to information security incidents as one or more undesirable information security events, as a result of which business operations may be compromised and an information security threat. It should be understood that it is almost impossible to completely avoid the occurrence of incidents, but you can learn to respond correctly to their occurrence and minimize the likelihood of similar incidents reoccurring. Also, with the help of SIEM solutions, we can learn to identify incidents effectively. In this article, we will not focus on any specific SIEM, since the main goal will be to analyze the general principles of drawing up correlation rules for various types of incidents.
Stages of attack development
In order to present the main actions that a hacker can take to implement an attack, we will use the MITER matrix. The MITER 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 go vertically.
Revealing intelligence
Identifying an attacker’s intentions before he tries to gain access somewhere is not an easy task. For reconnaissance, open sources, publicly available information, and much more that cannot be recorded in logs can be used.
But in the case of an insider, we can try to capture some suspicious commands. In general, it may look suspicious if some accountant or manager started running various commands on his machine designed to collect information. But for an attacker who, for example, just got onto a machine with the help of malware, the commands will help him understand where he got to and what he can do here.
For example systeminfo. Running this command allows you to find out basic information about the OS you are using.
systeminfo | findstr /B /C:"Название ОС" /C:"Версия ОС"
Likewise, the hostname and whoami commands are unlikely to be needed by the average user very 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 имя_пользователя
If the machine is part of a domain, then the set command will help the attacker learn a lot about system settings and interaction with AD.
In general, it would be a good idea to configure correlations in your SIEM to detect the launch of these commands at least on user machines.
Gaining access
Next, let's talk about Initial Access tactics. As part of this tactic, the attacker attempts to gain access to the attacked system. He can do this in various ways, from searching for valid accounts and selecting passwords for them, to exploiting various vulnerabilities. Accordingly, we must build our rules in such a way as to be able to identify such activities. In the simplest case, an attempt to guess passwords will look something like this:
Accordingly, we need to catch such events and process 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. In this case, either one login or several can be used.
Also, to identify Initial Access, it is worth paying attention to various error messages in the logs of the applications themselves. Thus, an attempt to perform a buffer overflow can lead to log messages about application failures, for example, about accessing a prohibited memory page.
It is worth noting here that such messages, if we talk about Windows logs, usually appear not in the Security section, but in Application and, possibly, in System. Accordingly, when connecting sources to SIEM, security professionals should not forget about the existence of logs other than Security.
Here it would be nice to link events recorded earlier, for example, the launch of suspicious commands at the reconnaissance stage with attempts to guess a password or exploit a vulnerability. The connecting element can be the attacker's IP address, host name, or login. Sometimes, the use of such links can significantly simplify the subsequent investigation of the incident.
Execution stage
At the Execution step, the attacker needs to execute various scripts and commands, load the necessary libraries in order to begin preparations for attaching to the system. Here, special attention should be paid to Windows events 4103 and 4104 associated with the launch of scripts.
Also, it would be useful to pay attention to the launch of various protocols designed for downloading files, for example SMB or FTP.
Under Linux, SSH (SCP) is usually used as a transport, so activating SSH on a machine that does not allow remote access via this protocol is also a very suspicious activity.
Securing and elevating privileges
I linked the next two stages together, since in practice very often, in order to effectively gain a foothold in the system, an attacker must first obtain administrative rights.
If we talk about Linux, then the reason for successful elevation of privileges may be inaccurate distribution of sudo rights, or setting SUID bits.
So in the example below, having sudo rights to the find command allowed us to obtain a root session.
In Windows, it is also possible to inaccurately configure information security policy rights. But we also shouldn’t forget about banal vulnerabilities. So in the example below, the logs record the execution of the systeminfo command with SYSTEM rights. The reason for this was the implementation of the good old Ettrenalblue on a vulnerable Win 7SP1 machine.
Having received privileged user rights, the attacker will need to hide his activity on the attacked network as much as possible. To do this, he can create a user and add him to certain groups. It can also make changes to the autorun mechanisms in order to launch its own backdoor during the system boot process for organizing remote access.
Thus, when developing correlation rules, we need to pay special attention to the various commands associated with adding users, changing rights, increasing privileges and other privileged activities.
Conclusion
In conclusion, I would like to note 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 this article, such rules already exist. However, I would like to warn against thoughtlessly including all the rules that come with a SIEM. The fact is that correlation rules will definitely give false positives, as a result of which you will have many incidents that are not actually incidents.
Therefore, the best solution would be to gradually enable only the necessary rules to identify relevant attacker activities.
In conclusion, let me remind you about the upcoming lessons on SIEM:
November 6, “Setting up security auditing in Windows for SIEM integration.” As a result of this lesson, you will learn how to work with audit logs and configure other monitoring tools. Sign up via link
November 20, “Using SIEM for Incident Investigation.” We'll discuss how to effectively use logs to quickly identify security incidents and conduct detailed investigations into cyberattacks. Sign up via link
