Supercharged SecOps Series — Automated Infostealer IOC Triage with Azure Logic Apps & CrowdStrike Falcon XDR
Welcome back to another instalment of the ‘supercharged secops’ blog series. In this blog, I’ll show you how to alert on IOC patterns in CrowdStrike and utilise the following to auto-triage before it hits your SOC queue:
- Webhooks
- CrowdStrike Scheduled Searching
- Azure Logic Apps
- Abuse.CH ThreatFox API
Setting the Scene
SOCs are seeing a significant uptick in infostealer actors utilising particular Top Level Domains (TLD) to host their DNS infrastructure upon. Historically, certain TLDs come as no shock to some SOC teams that they’re inherently suspicious or worthy of some investigation.
Not sure what an infostealer is? Scroll to the bottom for the blog FAQ!
The threat intelligence | Infostealers
Example 1 — AbuseCH Threat Fox | Lumma Stealer
As seen below, just highlighting some of these TLDs to demonstrate the frequency that ‘Lumma’ rely on ‘.shop’ really highlights the prevalence. Digging into the abusech data more, there are also TLDs such as:
- .site
- .biz
- .online
Example 2 — ‘Malicious TLDs’ by Spamhaus
Spamhaus maintain some amazing projects that safeguard organisations around the world. One of those projects is documenting general and country code TLDs that are commonly associated with malicious behaviour.
Hypothheses > Hunt > Triage > Automate
Okay, let’s treat the rest of the blog as this process:
- Form a hypotheses
- Create analytics and queries, try to find results by hunting
- Triage any findings
- Automate the last 3 steps to make a real-time detection
Our hypotheses here is that actors will attempt to abuse rare TLDs to bypass filtering and human awareness. Let’s create a very quick query to identify the top 2 TLDs we know Lumma are using in CrowdStrike Advanced Event Search:
(DomainName=”*.shop” OR DomainName=”*store”) | groupBy([ComputerName, DomainName])
Now we have some results, we can of course check those to perform some historical hunting and also validate our query, as it may need some refining. If you’re a Chris Moyles fan, his online shop is hosted at chrismoyles.shop, so let’s exclude that.
(DomainName=”*.shop” OR DomainName=”*store”) DomainName!=”chrismoyles.shop”| groupBy([ComputerName, DomainName])
Now with our query refined and our results validated, I did note that there were over 70 unique domains found in the last 30 days, we have to take into account that unless we automate the initial triage of the domain, we could be adding around 700 minutes of work to our SOC team (assuming average of 10 minutes per alert). Perhaps we could automate this by using a Logic App to check if the domain is in typical CTI databases, or check the domain reputation… Generally things a SOC analyst could waste time doing.
Automating with Azure Logic Apps
So let’s make this a scheduled search and send the resulting matches to an Azure Logic App.
I will pre-face the creation of this Azure Logic App with the following tips:
- Don’t create API keys that have more permissions than they need
- Store the client secret in a vault and audit access and usage
- Enable secure inputs and outputs on your logic apps
- Restrict access to webhooks
- You will need to configure a webhook in the CrowdStrike store
Setting up the Scheduled Search is super easy and can be configured to send any results as JSON to a webhook:
Note that your query should group by the domain field, ideally. Otherwise you may have issues when looping through multiple results later on. I’d add
| groupBy([DomainName])
Or if you’re managing multiple CIDs, use the below so you can link the DomainName finding to the right child CID.
| groupBy([#repo.cid, DomainName])
Now that we have results going to Azure Logic Apps, let’s build the logic app so that it retrieves the results and parses them:
Notes on the above:
- I’m using Azure Key Vault to securely store and retrieve the client secret
- To get the bearer token for CS API, I’m using this endpoint: https://api.eu-1.crowdstrike.com/oauth2/token
- I’m then using this endpoint to download the search results: https://api.eu-1.crowdstrike.com using the ‘api_download_uri’ field that I parsed from the initial trigger payload
Integrating AbuseCH threat intelligence API
Now that we’re receiving and parsing results from the CrowdStrike search when it finds something, we need to send these results to the AbuseCH API and check if the domain in question has been reported as an indicator.
AbuseCH Threatfox API docs: ThreatFox | API
Now we can loop through each result (If there’s more than one domain found in your scheduled search window) and check if it exists in AbuseCH ThreatFox. If it does, there could be a general assumption that this event is worthy of further investigation and create a ticket for the SOC team queue. It’s worth noting that not every IOC is in an intel list and you may want to do further checks beyond ThreatFox based on reputation, which is why I haven’t wrote a blog just to ingest ThreatFox and call it a day ;) Hunting takes refinement.
FAQ
What is an infostealer?
Infostealers are a form of malicious software, created to breach computer systems to steal sensitive information — including login details, financial information, and other personally identifiable information. This information is typically sold on the dark web to facilitate access to enterprises for ransomware and generally financially motivated attacks.
