Thread by @jwunder

(thread) One of the things we talked about on the @redcanaryco @CarbonBlack_Inc @MITREattack webinar today was how to start with one attack and use that to build a stronger defensive program.

But people also ask, how do I even start with one analytic? Well, here's one approach. I don't want to repeat the webinar, so let's use an ATT&CK technique as an example: attack.mitre.org/techniques/T11…

How do you build an analytic for that? Where do you even start?

Well, first, you need to understand the attack and how it's used by adversaries. Use the ATT&CK page to do that. Dig in to some of the reports and search for the relevant part and what immediately surrounds it.

Then, abstract that out to a set of general patterns for how the attack can work. Atomic Red Team from @redcanaryco can be a good start. github.com/redcanaryco/at…

In this case, you can see the general pattern of the Squiblydoo attack (h/t @subtee), non-HTTP based scriptlet execution, and executing malicious DLLs directly.

You'll definitely want to execute those attacks yourself! Use your lab environment, download some VMs and try it at home, do something. This doesn't mean being a red-teamer but it does mean understanding what a red-teamer does at that step.

Don't have a lab yet? Try github.com/clong/Detectio… or even just a Windows VM with Splunk free, ELK, or some other SIEM and Sysmon (though note standalone test VMs won't get you certain things in particular for lateral movement and credential access)

After carrying out the attack, see what it looks like in the logs. Figure out what event IDs you need, whether Sysmon is necessary, or whether your EDR can see the behavior. Threat Hunter Playbook is a great resource: github.com/Cyb3rWard0g/Th…

Then just write a search that you know will catch the attack. In software dev, this is called red/green/refactor. You have a failing test (attack that gets through) -- turn it green by writing a detection.

In this case, you probably want to look at process creations for regsvr32.exe and examine the command line. How do I know? Because that's what shows up in the logs when you execute the attack (also, the threat hunter playbook told me).

Next, refactor. Try the attack in a slightly different way until it "fails". Tune the query or add more queries to make sure you can still catch it. Here, the ATT&CK page and atomic red team should give you some ideas. As can your red team friends.

Then introduce some noise. You'll need to try this on the production network that you want it to run on, or you'll be shocked by just how many false positives you can generate! Run those searches and filter out events until you get an acceptable level of true positives.

In this case, Squiblydoo is likely pretty distinctive but the more generic execution might be tough to identify without doing some baselining/stacking (meaning, manually look for anomalies that seem weird in your env)

Look at filtering by different aspects of the data. When it's bad, does it always have certain command-line arguments? Is it followed by other distinct events (e.g., network traffic)? ThreatHunter-Playbook may give you some ideas here.

In this case, do you see any legitimate usage of regsvr32 accessing the internet?

Then just keep going and going until you have a set of searches that detect the bad and very little good.

And don't forget, it might be done already! Check out car.mitre.org, github.com/Neo23x0/sigma, eqllib.readthedocs.io/en/latest/anal…. They might also be inspiration for you to pivot off of.

Well that thread kind of got away from me but there you go. Eventually I'll blog on this with more links and screenshots.