Starting your ransomware detection journey: Detection Engineering approaches
It’s 2023, Ransomware is still the top dog for cyber threats. We’ve seen the recent introductions of data lake technology to SIEM, we’ve seen XDR become a (albeit unagreed definition across the industry) thing, ‘insert any pillar here’ posture management… But no silver bullet detecting & preventing ransomware, coincidence? Nope.
The emerging science behind detection engineering has provided the industry with a fresh outlook on how to research threats, prioritise them, and detect them. In this blog, I’ll show you a simple approach to getting started.
It’s important to note that detection engineering starts with visibility, you might not be aware of what specific visibility you have into your data sources, but you should have an idea of what sources you need to detect the behaviour. You should create multiple detections across multipe data sources for unique behaviours, to make it difficult as possible for threat actors to evade your detection. Isolating your detection efforts to say Sysmon (or endpoint telemetry) can also isolate your detection capabilities. You should consider detections for (not limited to):
- DNS
- Firewall
- Cloud
- Identity
The aim of detection engineering is to create chokepoints in the attack chain, forcing the attacker down unavoidable paths. An unavoidable path is created by having TTP-level detections whereby if the attacker changed the behaviour, the rest of their chain is impacted. You also want to have detections that are going to set you up nicely for the “strike zone”, consider your response to alerts here, will the detection be too late? i.e. ransomware encryption. Conversely, will the detection alert too soon, and not provide your analysts with enough context or evidence of an attack? Intent is always important too, if the detection is too soon in the chain, there might not be enough of an indicator of malicious intent.
An example of a chokepoint can be conceptualised as writing a detection for your holiday trip.
- You get in a taxi
- You get to the airport
- You go on a plane
My detection would be at step 2, personally. The ideal chokepoint, unavoidable step, and perfect to set me up for the strike zone of responding and preventing. At the airport, I haven’t boarded the plane, but I have appeared there, showing intent, and took actions beforehand that could be observed, too. If I wanted to avoid this detection, I’d now have to consider not using a plane at all, affecting the majority of my behaviour chain.
With all that considered, let’s look at Detection Engineering for Ransomware.
What you’ll need
- Cyberchef (Don’t worry, recipes provided)
- Google Sheets or Excel
- ATT&CK Navigator
One thing I’m interested in starting the journey with is, the most common TTP’s. For this, we’re going to use CISAs StopRansomware advisories as our source of intelligence. You can always expand this to things like:
- DFIR Report
- RedCanary Threat Report
- Crowdstrike Overwatch Report
etc. etc.
By taking all of these blogs, importing into CyberChef (Recipe link here) and adding them all to a spreadsheet, we should have all the TTP’s extracted using regex.
Repeating this for all blogs, can give you a list of all TTP’s. You can then use the “Count Occurence” feature in Cyberchef for each TTP and create a heatmap:
Great, a heatmap, what now?!
Just visually, we can see the top TTP’s:
- Phishing
- Exploit public facing application
- External remote services
- Valid accounts
You could use this approach to select the most viable TTP’s for detection engineering based on prevalance alone. As it seems the threat actor groups CISA have advised about all seem heavily reliant on these 4 TTP’s in particular, creating chokepoints for these behaviours, will be a good start in your journey.
