Scenario: The cloud-native endpoint security platform CrowdStrike is a vital part of your infrastructure. However, the enhanced visibility and machine learning detections sometimes overwhelm your security operations centers with an overabundance of alerts. You need a way to quickly gather more information related to the threat, determine the risk level, and respond immediately when the alerts pile up. You want to triage malware detections from Crowdstrike and automate a variety of responses based on an informed decision by an analyst. This will allow your analysts to skip repetitive queries, ignore false positives, and jump into the investigation phase as soon as they see the alert.
To succeed in implementing this use case, you need the following dependencies, resources, and information.
How to use Splunk software for this use case
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 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. To use the playbook:
- 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 “SOAR” 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 Splunk SOAR.
- On your Splunk SOAR instance, navigate to Home>Apps>Unconfigured Apps>Search for CrowdStrike OAuth API>Configure New Asset.
- Give the asset a name, for example, “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, click Update from Source Control 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.
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 Splunk SOAR integrates with, it takes only 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.
Querying your Splunk Platform could also 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.
These additional Splunk resources might help you understand and implement this use case: