Quantcast
Channel: Blog – Swimlane
Viewing all articles
Browse latest Browse all 72

Enhance the DFIR Process with PowerShell and Swimlane – Part 2

$
0
0

As you saw in part one of this series, PowerShell is a very powerful tool when it comes to the digital forensic and incident response (DFIR) process. As a recap, the current example use case centers around a legitimate domain user, jeff.thompson, logging on to a system in which they did not own. Based off of this alert, Swimlane was able to pull information about the logged on user, as well as respond by logging off of the host and locking the user account from the domain. The next step in this particular playbook is to investigate the host machine in which the potentially nefarious user has been logged on to.

Investigating the Host Machine

At this point in the DFIR playbook, the more information about the host that the analysts can obtain, the better chance they have at remediating the situation. Swimlane, using Powershell, has the ability to pull back information around the context of the host and the services and processes running on that host. The first piece of information Swimlane pulls in from the infected host is the running process info. As you can see in the screenshot below, the running process integration pulls information including the process name, the process ID (PID), memory usage, the user running the service, and CPU time.

Swimlane - Process Info

The next two integrations center around the services running on the host. The service info integration returns the installed services on the host and details surrounding the service state, the service start mode, and the description of the service.

Swimlane - Service Info

The running services integration only returns the services in the running state, without the ancillary context returned in the service information integration.

Swimlane - Running Services

Swimlane is also able to pull information about  the installed software on the host machine. This context is important to understand if the user, jeff.thompson, has installed any software on the system that could be malicious or  not a part of the approved software list.

Installed Software Swimlane

The last information gathering integration is the Get-InjectedThread task. So far we’ve gathered information around the services and the processes, but this information might not necessarily lead to finding potentially malicious activity. The Get-InjectedThread integration looks for fileless malware (i.e. malware that resides in memory) that uses memory injection to get code execution. Typical memory injection techniques are classic injection, which includes OpenProcess, VirtualAllocEX, WriteProcessMemory, and CreateRemoteThread, as well as Reflective DLL Injection and Memory Module. As seen in the screenshot below, the Get-InjectedThread integration found an instance of the lsass.exe process running in memory, which is an indication that the process could have been manipulated by some sort of malware.

Swimlane - Get-InjectedThread

Using the Swimlane Minidump Integration

Now that we have determined that there is a malicious process running on the infected host, we can use the minidump integration to pull back a dump of the running process within Swimlane. The minidump task remotes into the infected host and runs a PowerShell script that creates a dump of the process and appends it to the record within Swimlane.

Swimlane - MiniDump Process

Now that Swimlane has enriched the initial alert information, the analyst can use the service information, running services, process information, installed software, and attached minidump file to look for additional indicators of compromise and continue to build a case around the initial alert.

Coming Soon: Enabling Incident Response and Remediation

In part one of this series, we saw how Swimlane and PowerShell can automate the detection and response of a potential incident by pulling in host information based on the type of alert that was ingested. In this case, the alert was based around a user logging into a machine that they should have not had access to; therefore, Swimlane pulled in information around the context of the user. As DFIR analysts work through the investigation, they need to be able to gather as much information as possible to make an informed decision with respect to the response and remediation of the incident. This post demonstrates how Swimlane and PowerShell can assist analysts in automating and orchestrating the data gathering aspects of a typical DFIR playbook.  

In part three of this series, we will review the process of gathering network details of the infected host, as well as an integration that enables incident response and remediation by blocking the host from the network.

The post Enhance the DFIR Process with PowerShell and Swimlane – Part 2 appeared first on Swimlane.


Viewing all articles
Browse latest Browse all 72

Trending Articles