As security teams navigate the movement to remote work and the transition to cloud-hosted infrastructure, endpoint visibility remains a high priority for just about everyone. Whether we are monitoring a server in AWS or a remote employee’s laptop, cloud-native endpoint security platforms like CrowdStrike remain a vital part of our infrastructure.
However, the enhanced visibility and machine learning detections of a tool like CrowdStrike do have the potential to overwhelm our security operations centers with an overabundance of alerts. When these alerts pile up, analysts need a way to quickly gather more information related to the threat, determine the risk level, and respond immediately. That’s where an automation and orchestration tool comes in to save the day! Splunk Phantom is a SOAR tool that can orchestrate decisions and actions to more quickly investigate, triage, and respond to this high volume of alerts and reduce the manual burden of repetitive analysis.
The combination of Crowdstrike and Splunk Phantom together allows for a more smooth operational flow from detecting endpoint security alerts to operationalizing threat intelligence and automatically taking the first few response steps – all in a matter of seconds!
In this blog, I’ll walk you through an out-of-the-box playbook that you can set up in Phantom to triage malware detections from Crowdstrike and automate a variety of responses based on an informed decision by an analyst. This allows the analyst to skip the repetitive queries and jump into the investigation phase as soon as they see the alert. The playbook also uses the Custom Indicator of Compromise feature in CrowdStrike to correlate with previous infections related to the same malware and to tune future detections with false positive and true positive policies. This allows the analyst to not only respond more quickly to one alert in particular, but also to reduce future work by ignoring false positives and avoiding repeated analysis of the same malware.
This playbook walks through the steps that are performed automatically by Phantom to triage file hashes ingested from Crowdstrike.
As shown in the screenshot, there are a number of paths this playbook can take. The initial decision and filter ensure that the playbook is processing a detection with a SHA256 file hash. Next, the Custom Indicator table in CrowdStrike is queried to see if the hash represents a known file from a previous detection. If so, the bottom half of the playbook does a reduced workflow relying on the policy in place for that hash, allowing quarantine of the device if the hash is known malicious, and closing the event if the hash is known benign. The top half of the playbook does more investigation because the file hash is not a known quantity. The “hunt file” and “get process details” actions show other hosts in your environment with the same hash on disk and the behavior of other processes executing the same file. All of this information is summarized in the prompt and action widgets on the investigation page, allowing the analyst to make two decisions.
First, the analyst can ignore the indicator, create a false positive policy for the indicator (a policy of “none” in CrowdStrike), or create a true positive policy (a policy of “detect”). Second, the analyst can decide whether or not to immediately quarantine the endpoint, blocking all network traffic to and from, except for the configured allowlist of network addresses that can access the system during investigation. In CrowdStrike, the Configuration->Containment Policy page allows you to customize the quarantined device allowlist.
See It In Action
The video below walks through the deployment steps, how each block of the playbook works, and a demonstration of the playbook in use:
Deploying the Playbook
In order to get this playbook up and running you will just need to configure the CrowdStrike app on Phantom, then activate the playbook.
Here are the deployment steps shown in the video above:
- If you don’t already have Phantom, you can sign up and download the free community version here
- Create an API Client on CrowdStrike
- In the Falcon console navigate to Support->API Clients and Keys->Add New API Client
- Give it a name such as “Phantom” and permission to read Detections, Incidents, and Hosts, as well as read and write permissions for IOCs
- Configure an asset for the CrowdStrike app on Phantom
- On your Phantom instance, navigate to Home>Apps>Unconfigured Apps>Search for CrowdStrike OAuth API>Configure New Asset.
- Give the asset a name such as “crowdstrike_oauth”.
- On the Asset Settings page, provide the client ID, client secret, and App ID from the CrowdStrike API client
- On the Ingest Settings page choose a label such as “crowdstrike” and an ingestion interval such as once every 10 minutes
- Save and test connectivity to make sure the asset is functional.
- Configure and activate the playbook
- Navigate to Home>Playbooks and search for “crowdstrike_malware_triage”. If it’s not there, use the “Update from Source Control” button and select “community” to download new community playbooks.
- Click on the playbook name to open it.
- Resolve the playbook import wizard by selecting the newly created CrowdStrike OAuth asset (if you used a different asset name).
- If you want to use another time instead of 90 days to determine if an account is stale, change the “amount_to_modify” field in the “calculate_start_time” block.
- Set the label to “crowdstrike” or whichever label was created in the CrowdStrike asset configuration.
- Set the playbook to “Active.”
- Save the playbook.
Taking It Further
As every analyst knows, there are endless different directions a malware investigation can go. As with any automated incident response, the best way to expand on this playbook is to see it in action for a trial period and keep a close feedback loop to add the most common manual actions that analysts are taking after its execution.
For example, if you have access to a threat intelligence platform such as VirusTotal, Recorded Future, ReversingLabs, or one of dozens of others that Phantom integrates with, it would just take a minute to add a few “file reputation” actions to this playbook. Similarly, a malware sandbox could provide a report on the behavior of the executable and compare it to similar executables.
Of course, querying Splunk could provide all sorts of useful supporting information, such as other similar command line executions across your environment, details about the network communications of the host around the time of the incident, and information about the assets and identities involved in the incident. With hundreds of apps and thousands of actions in Phantom, there are a wide range of possibilities to consider for endpoint alerts, and this playbook has just scratched the surface of those capabilities.
This blog is part of a series called “SOAR in Seconds” where our distinguished Splunk Phantom experts guide you through how to use out-of-the-box playbooks to automate repetitive tasks.