If you’ve spent any amount of time in a security operations center (SOC), you know that receiving an alert from a security information and event management (SIEM) or endpoint solution is only the beginning when it comes to discovering a possible incident. In addition, the amount of value derived from the investigation is directly proportionate to the amount of time it takes your analyst to retrieve and analyze critical information from the target host. As a community we’ve come to call the techniques that gather actionable intelligence and help prevent further damage during a Digital Forensics and Incident Response (DFIR) investigation. However, few SOCs have established DFIR standards and procedures that ensure critical information is captured in a timely manner and that the root of the compromise is correctly identified and remediated.
Using Powershell for Digital Forensics and Incident Response
So, what do most companies do when they realize their DFIR capability is lacking? They fall back on the age-old cybersecurity mantra of “Buy me the newest, buy me the greatest, defer my liability.”
Allow us to introduce an alternative – “Use what you have, rely on the community, and actually achieve measurable results.” There is a large community supporting the use of Powershell for DFIR. The scripts that have been developed allow analysts to gather information and respond to potential incidents all while using well-defined and tested processes.
For the next three posts, we will show how Swimlane and Powershell solves real-world use cases using community-sourced scripts centered around the DFIR process.
SIEM, Swimlane and Powershell Working Together
The following use case is based on a SIEM tool within a company’s security environment, which alerts on three consecutive failed logins to an internal user’s workstation. Swimlane then ingests this alert and proceeds to run the defined automation and orchestration playbooks for incident response. The alert contains information about the hostname of the user’s machine as well as the user trying to logon. The first step in the playbook gathers as much information about the incident as possible including the context of the user and the user’s workstation.
In this case, the user trying to login is jeff.thompson, the targeted machine’s IP is 192.168.100.32, and the host’s owner is alex.smith. We will be using the “Logged on User” and “Last Logon Time” Powershell integrations for information gathering and the “Lock AD User Account” and “Logout User from Host” for the response.
The “Logged on User” integration is run against the workstation detailed in the SIEM alert. The Powershell integration then returns all users currently logged on to the host. In this particular case, the integration shows that jeff.thompson, a legitimate user in the domain but not the owner of the workstation, is logged in.
Knowing that the user jeff.thompson should not be logged on to alex.smith’s machine, we can assume the SIEM alert is a legitimate incident. To correlate the alert with the user’s login attempt to alex.smith’s machine, we can run the “Last Logon Time” integration and pull in the time in which the user actually logged in to the host.
The next step in the DFIR playbook is to isolate the malicious user and isolate any damage that may have been done. The first step is to use the “Lock AD User Account” integration so the user cannot pivot to any other hosts in the domain.
Once that step is complete, the “Logout User from Host” integration is run to log jeff.thompson out of alex.smith’s workstation.
In the next blog post, we will continue the DFIR playbook by gathering process and service information of the host and then leveraging that information to grab dumps of potentially bad processes while using the Swimlane and Powershell integrations.
The post Enhance the DFIR Process with Powershell and Swimlane – Part 1 appeared first on Swimlane.