Digging Into Open Reporting

As many readers of this blog are aware, I often find great value in open reporting, but that I also see the value in taking that open reporting a step (or three) further beyond where it exists now. In more than a few instances, something extra can be pulled from open reporting, something not presented or discussed in the article that can be of significant value to readers in domains such as DFIR, detection engineering, MSS/SOC monitoring, etc. As a result, I've spent a great deal of time during my career looking for alternate means for detecting activity (user, threat actor, malware) presented in open reporting, largely due to gaps in that reporting.

For example, there's a great deal of open reporting that is based solely on RE and analysis of malware that is part of the final stage of the attack (ransomware, etc.), without addressing anything that occurred prior to the final malware deployment, beginning with initial access. Now, I understand that not everyone has access to DFIR data to support this level of open reporting, but some do, and tremendous value can be derived if that information is shared. I understand that in some instances, authors feel that they can't share the information but very often it may simply be that they don't see the value in doing so.

MS DART and MSTIC recently published some excellent open reporting on Tarrask that I found quite fascinating, based initially on the title alone (which, oddly enough, is what also catches my eye with respect to beers and books). I mean, the title refers to using Scheduled Tasks for defense evasion...when I read that, I immediately wanted to know more, and I have to say, the DART and MSTIC teams did not disappoint. 

The article itself is full of "stuff" that can be unpacked. For example, there were some interesting statements in the article, such as:

Further investigation reveals forensic artifacts of the usage of Impacket tooling for lateral movement and execution...

So, what does that look like? I searched on the web and found that someone shared some forensic artifacts associated with the use of Impacket tooling about 2 yrs ago. While this is a great resource, unfortunately, many of the Windows Event Log records described are not available via the default logging configuration and require additional steps to set up. For example, while generating Security-Auditing records with event ID 4688 is just a matter of enabling Process Tracking, including the full command line for the process in the event record requires an additional Registry modification. Throughout my time in DFIR, there have been very few instances where the audit configuration of compromised systems was beyond default, and more than a few instances where threat actors took steps to disable the logging that was available.

Note that the article has a similar comment to that effect:

Neither of these are audited by default and must be explicitly turned on by an administrator. 

Ah, there you go! There are these great Windows Event Log artifacts that are available if the default audit configuration is modified prior to an attack taking place! 

Note: Even after an attack starts, there are ways to manipulate Windows Event Logs as a means of defense evasion. This is NOT part of the MS DART/MSTIC blog post, and is mentioned here to bring attention to issues with default audit configuration and monitoring systems for modifications to the audit configuration.

From the guidance section of the article:

Enumerate your Windows environment registry hives looking in the HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree registry hive and identify any scheduled tasks without SD (security descriptor) Value within the Task Key...

Issues with nomenclature aside, this is pretty solid advice. Not having access to proactive threat hunting, I opted to create a simple RegRipper plugin for use in DFIR analysis and hunting. Actively threat hunting across endpoints in your environment for the same condition is a great way to go about detecting such things much earlier in the attack cycle. 

Something else to unpack from all of this is that, per the article, SYSTEM level privileges are required in order to remove the "SD" value from the Registry on a live, running system. As such, the threat actor first needs to access the system, and then escalate privileges...both of which provide opportunities for detection. If such activity is detected and responded to in a timely manner, the rest of the attack chain can be obviated.

Closing Thoughts

Not everyone has the ability to ingest STIX/TAXII, or Sigma rules, or other means of automated tooling, and as such, greater value can be derived from open reporting if observables are shared. This way, analysts from across the cyber spectrum...DFIR, detections, threat hunting, etc...can look at the data, see what things "look like" on systems and within their infrastructure, and then determine how best to apply them within the realm of their capabilities. As a DFIR analyst, I look for what I can use to create artifact constellations to increase the fidelity of detections, either for live monitoring/response within an enterprise, or during a more traditional "dead box" or "triage" DFIR process.

Additional Item of Note

Apparently, on more recent server versions of Windows, when process tracking is enabled, hashes are recorded in the AppLocker Event Log.