Getting ready to investigate incidents
Is it possible to fully protect against cyber attacks? Perhaps you can, if you surround yourself with all existing means of protection and hire a huge team of experts to manage the processes. However, it is clear that in reality it is impossible: the budget for information security is not infinite, and incidents will still occur. And if they happen, it means you need to prepare for them!
In this article, we will share typical scenarios for investigating malware-related incidents, tell you what to look for in the logs, and give technical recommendations on how to configure information protection tools in order to increase the chances of an investigation success.
The classic process of responding to a malware-related incident involves such stages as detection, deterrence, recovery, etc., but all of your capabilities are essentially determined at the preparation stage. For example, the rate of detection of infections depends on how well the company is set up an audit.
')
Classic SANS Incident Response Cycle
In general, the actions of analysts during the investigation are as follows:
Of course, there is no point in testing all possible hypotheses - at least because time is limited. Therefore, here we will consider the most likely versions and typical scenarios for the investigation of incidents involving malware.
As part of the development of this version, you should perform three simple steps:
Displays all running processes and services in Event Log Explorer
In theory, this is quite a trivial process. However, in practice there are a number of pitfalls, which should be prepared.
First, the standard Windows audit setting does not log the facts of the processes launch (event 4688), so it must be enabled in advance in the domain group policy. If it so happens that this audit was not enabled in advance, you can try to get a list of executable files from other Windows artifacts, for example, from the Amcache registry. You can extract data from this registry file using the AmcaheParser utility.
Example of extracting the facts of starting processes from Amcache.hve
However, this method is not very reliable, since it does not give accurate information about when exactly and how many times the process was launched.
Secondly, evidence of launching processes such as cmd.exe, powershell.exe, wscript.exe and other interpreters will be of little use without information about the command line with which the processes were started, since it contains the path to a potentially malicious script file.
Run the script interpreter without information that the script was running
Another feature of Windows is that the audit of the command line of the process being started is done by separately setting the domain group policy: Computer Configuration -> Policies -> Administrative Templates -> System -> Audit Process Creation -> Include line in process creation events . At the same time, the quite popular Windows 7/2008 does not log the command line without the KB3004375 update installed , so install it in advance.
If it so happens that you did not set anything up in advance or forgot about the update, you can try to find out the location of the script in the Prefetch files ( utility to help ). They contain information about all files (mostly DLLs) loaded into the process in the first 10 seconds of life. And the script contained in the command line arguments of the interpreter will most certainly be there.
An example of finding a “lost” command line argument in Prefetch
But this method is not at all reliable - at the next launch of the Prefetch cache process, it will be reset.
Preparing for the investigation:
One of the options for responding to such alarms may be to check which process made the connection - if it is an Internet browser, then in the absence of other facts indicating a compromise, the incident can be considered a false alarm.
There are many ways to find out which process initiated a connection: you can run netstat and see the current sockets or collect a memory dump and then set a volatility on it that can show including already completed connections. But all this is long, not scalable, and the most important thing is not reliable. It’s much safer to get all the necessary information from the Windows security log.
Correlation of the “access to malicious IP-address” event in the HPE Arcsight SIEM system and the corresponding process in the Windows security log
Preparation for the investigation
To run this script on a user machine, you must enable the security log of all network connections. This can be done based on the audit events of the filtering platform and the audit of packet dropping .
At the same time, the magazine can start to get quickly clogged, so increase its size to 2-3 GB. In our experience, on a regular user host of such volume, it takes about 3 days to record all sockets, and this period is enough for a successful investigation.
On high-load servers, such as domain controllers, web-servers, etc., you should not do this, the log will fill up much faster.
If potential intelligence is carried out from a single host, you can investigate it, including using the logs of running processes. However, if there are many hosts, and attacks of the same type (occurred at the same time, or the same set of entities was requested from AD), then it makes sense first of all to exclude a typical false response. For this you need to create and check the following versions:
The statistical analysis of the logs will help to detect these key points (general user or process). We have demonstrated this method in one of the previous articles in relation to DNS server logs . However, using such effective investigation methods will not work if the storage of data has not been organized in advance.
Preparation for the investigation
It is necessary to organize long-term storage of, at a minimum, the following data from the logs of common network services:
Suppose a terrible thing happened: you found that the domain administrator account was compromised.
Responding to such an incident includes a very large amount of work, including an analysis of all actions taken under this account. Part of this investigation can be carried out using only domain controller logs. For example, you can study the events related to the issuance of Kerberos tickets in order to understand where they went from under this account. Or, you can analyze events related to changes in critical AD objects to check whether the composition of highly privileged groups (of the same domain administrators) has changed. Naturally, all this requires a pre-configured audit.
However, there is a problem related to the fact that an attacker with domain administrator rights can modify AD objects using the DCShadow technique, which is based on the replication mechanism between domain controllers.
Its essence lies in the fact that the attacker himself is represented by the domain controller, makes changes to AD, and then replicates (synchronizes) these changes with legitimate controllers, thus bypassing the object change audit that is configured for them. The result of such an attack may be the addition of a user to the domain administrators group or trickier attachments through a change in the SID History attribute or a modification of the AdminSDHolder ACL object.
In order to check the version of the presence of unfixed changes in AD, it is required to examine the controller replication logs: if the replication involved IP addresses that are not domain controllers, it can be said with a high degree of confidence that the attack was successful.
Remove unknown domain controller from AD replication
Preparing for the investigation:
In this article, we talked about some typical scenarios for investigating security incidents and measures of preventive preparation for them. If you are interested in this topic and you are ready to go further, I recommend paying attention to this document describing in which Windows events you can find traces of the use of popular hacker techniques.
To finish, I would like to quote from a recent study of a company working in the field of cybersecurity:
In this article, we will share typical scenarios for investigating malware-related incidents, tell you what to look for in the logs, and give technical recommendations on how to configure information protection tools in order to increase the chances of an investigation success.
The classic process of responding to a malware-related incident involves such stages as detection, deterrence, recovery, etc., but all of your capabilities are essentially determined at the preparation stage. For example, the rate of detection of infections depends on how well the company is set up an audit.
')
Classic SANS Incident Response Cycle
In general, the actions of analysts during the investigation are as follows:
- Formation of versions explaining the causes of the incident (for example, “the malware was installed on the host because the user launched it from a phishing email” or “the incident is a false alarm because the user visited a legitimate site located on the same hosting as the management server malware ”).
- Prioritization of versions according to probability. The probability is calculated (or rather, it pretends) on the basis of statistics of past incidents, the severity of the incident or system, and also on the basis of personal experience.
- Study of each version, search for facts proving or refuting it.
Of course, there is no point in testing all possible hypotheses - at least because time is limited. Therefore, here we will consider the most likely versions and typical scenarios for the investigation of incidents involving malware.
Scenario 1
You suspect that an uncritical system has been compromised by malware. Due to the non-criticality of the system, very little time is allotted for checking.The first thing that most response engineers do is launch antivirus checks. However, as we know, antivirus is not so difficult to get around. Therefore, it is worthwhile to form and work out the following highly probable version: the malware is a separate executable file or service.
As part of the development of this version, you should perform three simple steps:
- Filter the Security log by event 4688 - so we get a list of all the running processes.
- Filter the System log on event 7045 - so we get a list of the settings of all services.
- Identify new processes and services that were not previously in the system. Copy these modules and analyze them for the presence of malicious code (scan with several antiviruses, check the validity of the digital signature, decompile the code, etc.).
Displays all running processes and services in Event Log Explorer
In theory, this is quite a trivial process. However, in practice there are a number of pitfalls, which should be prepared.
First, the standard Windows audit setting does not log the facts of the processes launch (event 4688), so it must be enabled in advance in the domain group policy. If it so happens that this audit was not enabled in advance, you can try to get a list of executable files from other Windows artifacts, for example, from the Amcache registry. You can extract data from this registry file using the AmcaheParser utility.
Example of extracting the facts of starting processes from Amcache.hve
However, this method is not very reliable, since it does not give accurate information about when exactly and how many times the process was launched.
Secondly, evidence of launching processes such as cmd.exe, powershell.exe, wscript.exe and other interpreters will be of little use without information about the command line with which the processes were started, since it contains the path to a potentially malicious script file.
Run the script interpreter without information that the script was running
Another feature of Windows is that the audit of the command line of the process being started is done by separately setting the domain group policy: Computer Configuration -> Policies -> Administrative Templates -> System -> Audit Process Creation -> Include line in process creation events . At the same time, the quite popular Windows 7/2008 does not log the command line without the KB3004375 update installed , so install it in advance.
If it so happens that you did not set anything up in advance or forgot about the update, you can try to find out the location of the script in the Prefetch files ( utility to help ). They contain information about all files (mostly DLLs) loaded into the process in the first 10 seconds of life. And the script contained in the command line arguments of the interpreter will most certainly be there.
An example of finding a “lost” command line argument in Prefetch
But this method is not at all reliable - at the next launch of the Prefetch cache process, it will be reset.
Preparing for the investigation:
- Enable advanced audit of creation and termination of processes.
- Enable logging of process command line arguments.
- Install the update KB3004375 on Windows 7 / Server 2008.
Scenario 2
A call to the malware management server was fixed on the perimeter router. The IP address of the malicious server was obtained from a medium-reliability threat intelligence subscription.In one of the previous articles, we told that TI-analysts sin by adding to the lists of indicators a compromise of IP addresses of servers that host both malware control centers and legitimate websites. If you have just started to formulate response processes, then at the first stages it is better to abandon the use of such indicators, because every attempt by a user to access a legitimate website will look like a full-fledged incident.
One of the options for responding to such alarms may be to check which process made the connection - if it is an Internet browser, then in the absence of other facts indicating a compromise, the incident can be considered a false alarm.
There are many ways to find out which process initiated a connection: you can run netstat and see the current sockets or collect a memory dump and then set a volatility on it that can show including already completed connections. But all this is long, not scalable, and the most important thing is not reliable. It’s much safer to get all the necessary information from the Windows security log.
Correlation of the “access to malicious IP-address” event in the HPE Arcsight SIEM system and the corresponding process in the Windows security log
Preparation for the investigation
To run this script on a user machine, you must enable the security log of all network connections. This can be done based on the audit events of the filtering platform and the audit of packet dropping .
At the same time, the magazine can start to get quickly clogged, so increase its size to 2-3 GB. In our experience, on a regular user host of such volume, it takes about 3 days to record all sockets, and this period is enough for a successful investigation.
On high-load servers, such as domain controllers, web-servers, etc., you should not do this, the log will fill up much faster.
Scenario 3
Your NG / ML / Anti-APT anomaly detection system reports that reconnaissance is taking place from 30 hosts in order to obtain the same accounts.When they enter a new network, attackers, as a rule, try to find out which services are present in it and which accounts are used - this helps a lot in the process of further movement through the infrastructure. In particular, this information can be obtained from Active Directory itself using the net user / domain command.
If potential intelligence is carried out from a single host, you can investigate it, including using the logs of running processes. However, if there are many hosts, and attacks of the same type (occurred at the same time, or the same set of entities was requested from AD), then it makes sense first of all to exclude a typical false response. For this you need to create and check the following versions:
- Intelligence is fixed on 30 hosts in relation to the same AD objects, because the same legitimate user, the administrator, launched the net command.
- Intelligence is fixed on 30 hosts in relation to the same AD objects, because it made the same legitimate software.
The statistical analysis of the logs will help to detect these key points (general user or process). We have demonstrated this method in one of the previous articles in relation to DNS server logs . However, using such effective investigation methods will not work if the storage of data has not been organized in advance.
Preparation for the investigation
It is necessary to organize long-term storage of, at a minimum, the following data from the logs of common network services:
- Domain controllers - logins, account outlets, and Kerberos ticket issuance ( Account Logon category in advanced audit settings).
- Proxy servers - addresses, source and external server ports, as well as the full URL.
- DNS servers - successful and unsuccessful DNS queries and their source within the network.
- Perimeter routers - Built and Teardown for all TCP / UDP connections, as well as connections that attempt to violate logical access rules: for example, attempts to send a DNS request to the outside directly, bypassing the corporate DNS server.
Scenario 4
Your domain has been compromised, and it bothers you that an attacker could gain a foothold in the infrastructure using the DCShadow technique.
Suppose a terrible thing happened: you found that the domain administrator account was compromised.Responding to such an incident includes a very large amount of work, including an analysis of all actions taken under this account. Part of this investigation can be carried out using only domain controller logs. For example, you can study the events related to the issuance of Kerberos tickets in order to understand where they went from under this account. Or, you can analyze events related to changes in critical AD objects to check whether the composition of highly privileged groups (of the same domain administrators) has changed. Naturally, all this requires a pre-configured audit.
However, there is a problem related to the fact that an attacker with domain administrator rights can modify AD objects using the DCShadow technique, which is based on the replication mechanism between domain controllers.
Its essence lies in the fact that the attacker himself is represented by the domain controller, makes changes to AD, and then replicates (synchronizes) these changes with legitimate controllers, thus bypassing the object change audit that is configured for them. The result of such an attack may be the addition of a user to the domain administrators group or trickier attachments through a change in the SID History attribute or a modification of the AdminSDHolder ACL object.
In order to check the version of the presence of unfixed changes in AD, it is required to examine the controller replication logs: if the replication involved IP addresses that are not domain controllers, it can be said with a high degree of confidence that the attack was successful.
Remove unknown domain controller from AD replication
Preparing for the investigation:
- In order to investigate actions performed by a compromised account, you must enable in advance:
- Audit of entries, exits of an account and issuance of Kerberos tickets (category Account Logon in advanced audit settings).
- Audit of changes to accounts and groups (category Account Management ).
- To investigate versions related to possible applications of the DCShadow attack:
- Enable detailed directory service replication auditing.
- Organize long-term storage of events 4928/4929, in which the source of events is not a legitimate domain controller (DCShadow attribute).
Conclusion
In this article, we talked about some typical scenarios for investigating security incidents and measures of preventive preparation for them. If you are interested in this topic and you are ready to go further, I recommend paying attention to this document describing in which Windows events you can find traces of the use of popular hacker techniques.
To finish, I would like to quote from a recent study of a company working in the field of cybersecurity:
“Russian information security directors are mostly inclined to give pessimistic answers [to research questions]. So, half (48%) believes that the budget will not change in any way, and 15% think that funding will be reduced. ”For me personally, this is a signal that it is better to spend the remaining budget in the new year not to purchase new-fashioned GIS like Machine Learning detectors, another IDS of a new generation, etc., but to fine-tune the GIS that already exists. And the best SZI is correctly configured Windows logs. IMHO.
Source: https://habr.com/ru/post/434176/
All Articles