In part one of this blog series, Swimlane pulled in information centered around the user context in response to a potential incident. Part two of the series dealt with gathering host based information, including running processes and services. In both cases, Swimlane triggered integrations that responded and reacted to the information gathered. Swimlane then locked the unauthorized user’s domain account, logged them off the compromised computer, and killed the malicious process running on the host. In this final post in the PowerShell series, we will focus on the network side of the digital forensic and incident response (DFIR) process.
Pulling Back Network Information from the Host
At this stage in the playbook, we know that a user had unauthorized access to a machine, and there was a process running in memory that we suspect is malicious. The next step is to determine if that process opened up any type of network connection that could potentially be used to exfiltrate important data or as a back door into the company’s environment.
There are three Swimlane integrations that leverage Powershell to pull back network information from a particular host:
- Firewall Rules Integration
- Routes
- Arp Cache of Host Machine
- Netstat Established Connection and Process PowerShell Script
The first, firewall rules integration, is seen in the screenshot below, and is where all of the enabled firewall rules on the host are pulled in to the current record. The information displayed includes the state of the firewall rule, the direction, remote ip, remote port, local port, and the application name associated with the specific rule.
The second integration leveraging PowerShell is the routes task. This integration gathers information around the static routes defined on the host. Depending on the type of incident, this information is important to see if the malicious host has enabled any routes to undisclosed networks or subnets.
Swimlane also has the ability to pull in the arp cache of the host machine. This Swimlane PowerShell integration gives the analyst the ability to see when a hostname is resolved to an IP address and then to a MAC address so that the computer can resolve the IP. In the case of this particular incident, the host has connected to three IP addresses – the first being the domain controller (192.168.100.5), the second is the instance of Swimlane (192.168.100.20) and the third is an unknown system on the network but in the same subnet as the affected host (192.168.100.50). The analyst, knowing that a connection shouldn’t be present to another host on the same subnet, would want more context around this type of connection. The 192.168.100.50 host could be a redirector that is potentially forwarding company data to an outside command and control (C2) server.
The last Swimlane integration is the netstat established connection and process PowerShell script. This integration populates the record with the local address, remote port, process name, remote address, local port, protocol, state and pid. In this particular situation, the compromised host has an established connection to the 192.168.100.50 address on port 80 and is associated with PID 488. If you remember from part two of this blog, PID 488 is the same pid associated with the malicious process found using the Get-InjectedThread integration.
Because Swimlane was able to pull in actionable network information around the context of the affected host, the analyst can make an informed decision to respond and react to this incident. In order to mitigate any further potential risk to the company’s environment, the affected host machine should be pulled from the network. This would allow the DFIR team to run further analysis on the system while protecting any sensitive information from being exfiltrated. The Swimlane disconnect NIC integration uses PowerShell to allow the analyst to remotely disable the host’s NIC.
As we’ve shown in the last three posts in this series, PowerShell can be a very effective tool in the DFIR process. Due to the overwhelming community support around PowerShell and its use in the incident response process, Swimlane will be able to integrate and utilize future techniques to l allow analysts to quickly respond and react to potential threats. The ability to run native PowerShell code within the platform, gives Swimlane a distinct advantage over other security orchestration and automations tools.
The post Enhance the DFIR Process with PowerShell and Swimlane – Part 3 appeared first on Swimlane.