Saturday, February 15, 2014

Resolving some trigger GUIDs

My last post here on triggers as a Windows persistence mechanism, see http://trustedsignal.blogspot.com/2014/02/triggers-as-windows-persistence.html, gave an example of a Windows Scheduled Task that would run a script when a specific event id appeared in the Microsoft-Windows-Security-Auditing log (i.e. the Security event log).

I added a collector for Windows Service triggers to Mal-Seine, a script for collecting host artifacts during "breach hunts," (https://github.com/davehull/Mal-Seine). Breach hunts are undertaken by security teams who proactively look for evidence of adversaries in their systems and networks, rather than merely waiting for monitoring systems to fire alerts. Breach hunt activities may lead to new detections for those monitoring systems, but I digress.

When I wrote the new collector for Service triggers, I found the collected data pretty opaque. Here's an example:





















If you're wanting to analyze this data across many systems, say to identify outliers, this presentation leaves something to be desired. Mal-Seine includes a post-collection script to convert this output to separated values (https://github.com/davehull/Mal-Seine/blob/master/Convert-SvcTrigToSV.ps1) suitable for stack ranking or loading into Excel or other tools for further analysis, yielding something like the following:










Even in a separated values format, I still find the values in the "Condition" field leave something to be desired. Fortunately, some of the GUIDs can be replaced with human-readable values. Each of the entries that end with "[ETW PROVIDER UUDI]" corresponds to a Windows Event Log Provider, so we can at least get the provider name and the script above will perform this for us, if run with the -NameProviders flag, giving us:










Replacing the GUIDs makes the data a little more approachable. Searching for the remaining GUIDs online will reveal some information for the ones that are followed by information in brackets, but I've not found much on the ones that are not followed by information in brackets.

How would I use this data in a breach hunt? I would begin by stack-ranking the data from many similar systems and looking for outliers that I would mark for follow up investigation.

No comments:

Post a Comment

Other thoughts from Lean In

My previous posts in this series have touched on the core issues that Sheryl Sandberg addresses in her book  Lean In: Women, Work, and the W...