Example of incident investigation with KUMA

Detecting an attack in the organization IT infrastructure using KUMA includes the following steps:

1. Preliminary steps
2. Assigning an alert to a user
3. Check if the triggered correlation rule matches the data of the alert events
4. Analyzing alert information
5. False positive check
6. Determining alert severity
7. Incident creation
8. Investigation
9. Searching for related assets
10. Searching for related events
11. Recording the causes of the incident
12. Response
13. Restoring assets operability
14. Closing the incident

The description of the steps provides an example of response actions that an analyst might take when an incident is detected in the organization's IT infrastructure. You can view the description and example for each step by clicking the link in its title. The examples are directly relevant to the step being described.

For conditions of the incident for which examples are provided, see the Incident conditions section.

For more information about response methods and tools, see the Incident Response Guide. On the Securelist website by Kaspersky, you can also find additional recommendations for incident detection and response.

Incident conditions

Parameters of the computer (hereinafter also referred to as "asset") on which the incident occurred:

• Asset operating system – Windows 10.
• Asset software – Kaspersky Administration Kit, Kaspersky Endpoint Security.

KUMA settings:

• Integration with Active Directory, Kaspersky Security Center, Kaspersky Endpoint Detection and Response is configured.
• SOC_package correlation rules from the application distribution kit are installed.

A cybercriminal noticed that the administrator's computer was not locked, and performed the following actions on this computer:

1. Uploaded a malicious file from his server.
2. Executed the command for creating a registry key in the \HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run hive.
3. Added the file downloaded at the first step to autorun using the registry.
4. Cleared the Windows Security Event Log.
5. Completed the session.

Step 1. Preliminary steps

Preliminary steps are as follows:

1. Event monitoring.

   When a collector is created and configured in KUMA, the program writes information security events registered on controlled elements of the organization's IT infrastructure to the event database. You can find and view these events.

2. Creating a correlator and correlation rules.

   When a sequence of events that satisfy the conditions of a correlation rule is detected, the program generates alerts. If the same correlation rule is triggered for several events, all these events are associated with the same alert. You can use correlation rules from the distribution kit or create them manually.

3. Configuring email notifications about an alert to one or more email addresses.

   If notification is configured, KUMA sends a notification to the specified email addresses when a new alert is received. The alert link is displayed in the notification.

4. Adding assets.

   You can only perform response actions for an asset (for example, block a file from running) if the asset is added to KUMA.

   Performing response action requires integrating KUMA with Kaspersky Security Center and Kaspersky Endpoint Detection and Response.

   Example The analyst has carried out the following preliminary steps: Installed the SOC_package correlation rules from the distribution kit and linked them to the correlator. Configured the sending of alert notifications to the analyst's email. Imported assets from Kaspersky Security Center to KUMA. According to the incident conditions, after the administrator logged into their account, a malicious file was run, which the attacker had added to Windows autorun. The asset sent Windows security event log events to KUMA. The correlation rules were triggered for these events. As a result, the following alerts were written to the KUMA alert database: R223_Collection of information about processes. R050_Windows Event Log was cleared. R295_System manipulations by a non-privileged process. R097_Startup script manipulation. R093_Modification of critical registry hives. The information about the alert contains the names of the correlation rules based on which the alerts were created, and the time of the first and last event created when the rules were triggered again. The analyst received alert notifications by email. The analyst followed the link to the R093_Changes to critical registry hives alert from the notification.

Step 2. Assigning an alert to a user

You can assign an alert to yourself or to another user.

Step 3. Check if the triggered correlation rule matches the data of the alert events

At this step, you must view the information about the alert and make sure that the alert event data matches the triggered correlation rule.

Step 4. Analyzing alert information

At this step, analyze the information about the alert to determine what data is required for further analysis of the alert.

Step 5. False positive check

At this stage, make sure that the activity that triggered the correlation rule is abnormal for the organization IT infrastructure.

Step 6. Determining alert severity

You can change the alert severity level, if necessary.

Step 7. Incident creation

If steps 3 to 6 reveal that the alert warrants investigation, you can create an incident.

Step 8. Investigation

This step includes viewing information about the assets, accounts, and alerts related to the incident in the incident information section.

Information about the impacted assets and accounts is displayed on the Related assets and Related users tabs in the incident information section.

Step 9. Searching for related assets

You can view the alerts that occurred on the assets related to the incident.

Step 10. Searching for related events

You can expand your investigation scope by searching for events of related alerts.

The events can be found in the KUMA event database manually or by selecting any of the related alerts and clicking Find in events in the alert details (Incidents → the relevant incident → Related alerts → the relevant alert → Related endpoints → Find in events). The found events can be linked to the selected alert, however, the alert must be unlinked from the incident before that.

Step 11. Recording the causes of the incident

You can record the information necessary for the investigation in the incident change log.

Step 12. Incident response

You can perform the following response actions:

1. Isolate the asset from the network.
2. Perform a virus scan.
3. Prevent the file from running on assets.

   The listed actions are available if KUMA is integrated with Kaspersky Security Center and Kaspersky Endpoint Detection and Response.

   Example The analyst has information about the incident-related assets and the indicators of compromise. This information helps select the response actions. As part of the incident being considered, it is recommended to perform the following actions: Start an unscheduled virus scan of the asset where the file was added to autorun. The virus scan task is started by means of Kaspersky Security Center. Isolate the asset from the network for the period of the virus scan. The asset isolation is performed by means of Kaspersky Endpoint Detection and Response. Quarantine the ChromeUpdate.bat file and create the execution prevention rules for this file on other assets in the organization. An execution prevention rule for a file is created by means of Kaspersky Endpoint Detection and Response.

Step 13. Restoring assets operability

After the IT infrastructure is cleaned from the malicious presence, you can disable the prevention rules and asset network isolation rules in Kaspersky Endpoint Detection and Response.

Step 14. Closing the incident

After taking measures to clean up the traces of the attacker's presence from the organization's IT infrastructure, you can close the incident.