AttacktheSOC / Azure-SecOps

Collection of different Azure/Entra focused solutions (Deployable templates, Function Apps, etc)
MIT License
0 stars 0 forks source link

Temporal Proximity in KQL for NRT custom detection rules? #1

Open c3rberus opened 4 weeks ago

c3rberus commented 4 weeks ago

Hi Dylan,

I read your blog post regarding Practical Temporal Proximity in KQL and it was very interesting, and while I am no SOC expert, do you know if similar concept can be applied to MSFT Defender custom detection rules that are NRT?

I have a similar custom detection rule that alerts on potential reconnaissance activity, basically looking for execution of specific tools that you often see in DFIR reports.

Here is a basic example of the rule I use:

DeviceProcessEvents
| where FileName has_any (
    "nslookup.exe",
    "ping.exe",
    "ipconfig.exe",
    "netstat.exe",
    "arp.exe",
    "systeminfo.exe",
    "whoami.exe",
    "route.exe",
    "nltest.exe",
    "nbtstat.exe",
    "arp.exe",
    "wmic.exe",
    "secedit.exe",
    "auditpol.exe",
    "bcdedit.exe",
    "adfind.exe"
    )

Because this obviously generates a lot of false positive noise, I have a massive list of excludes, and I was wondering if I could combine temporal proximity into this to reduce the FP noise.

Support desk will trigger a lot of FP noise, or some programs, because they run these utilities, but a combination of these within a certain time span would definitely be a more interesting finding, and much less noise, and a cleaner KQL query with much less excludes.

Is it possible to do this using custom detection rules that are NRT as opposed to using Sentinel NRT Analytic rules?

AttacktheSOC commented 1 week ago

Hey @c3rberus, sorry for the long wait. Caught me during a move and as things have settled down again I've been meaning to get back to you.

Yeah you can absolutely make a NRT Custom Detection like this you just have to be wary of the constraints when creating a NRT rule in the Defender portal vs a Sentinel NRT Analytics rule. IIRC, Microsoft recommends creating Continuous (NRT) frequency rules when possible vs the every (3, 12,2 4 etc etc) hours. Constraints: Queries you can run continuously In fact, NRT can make a lot of detections so much easier cause you don't have to do any weird Timestamp dance, you just say "where XX == NN". Or to use the blog post as an example, using NRT we could just do a lookback of 10 minutes and do a summarize + count and if the threshold of distinct commands that were run was hit, then alert. A lot easier, just keep in mind the constraints.

I think there are a few other ways you can tackle this too. One is to really cut out the noise. For example, something like ping is really only used by the helpdesk to troubleshoot issues or sysadmins to confirm comms with a server etc. Even when used by TAs its use is not distinct enough to call it out as definitely malicious let alone suspicious. I love this idea and definitely is in the spirit of shifting-left but you'll be exhausting yourself with false positives and trying to keep up with those exclusions. Instead you might focus on using security controls vs detections here. The basics, ensure MFA, audit and ensure the health of your security agents across the fleet, control user rights. If possible implementing application allow listing would be great here.

Sticking to detections though, what you could try to do is carve some of those noisier commands out into their own detections and build conditions around them. Such as alert when this command is used within 5 minutes of a type 3 network logon event occurring. Or by a user that hasn't run that command in the past x days. Something to make alerts for those specific commands more reliable and less noisy, while also having a high fidelity detection for some of these bigger commands with more impact. This doesn't only bring down the SOC fatigue false-positives have but opens you up to have more confidence in the alert when it rolls in. You'll know exactly what you're looking for and be able to move quicker. Maybe even after some time and after the reliability of the detection has been solid you can build automated actions on it.

Let me know what you think or if you have any other questions, if I said too much too little. Hope you get this working exactly how you want and need! Good luck ☠