Using Intrusion Intelligence

In his book, "Call Sign Chaos", Jim Mattis made the statement that 'your own personal experiences are not enough to sustain you."  This statement was made in the context of reading for professional development, and it applies to much more than just warfighting.  It also applies equally well in the DFIR field, including DFIR analysis, threat hunting, and developing intrusion intelligence.  This is due to the fact that our own experiences are not enough to sustain us, neither as individual analysts nor as teams.  None of us want to go to an auto mechanic or a neurosurgeon who stopped their education the moment they received their diploma; as such, it's incumbent upon each of us to further our education and professional development through whatever means works for us.  Sometimes, that's as simple as reading...really reading...what someone else has written, and then incorporating what we learn into our own analysis process or methodology.

I recently read this excellent article from the Elastic team regarding their insights into the Gamaredon Group. I found that the article included a good bit of detail, not just in how the Elastic team goes about running down an incident, but also detail with respect to findings written in a manner that can be incorporated into threat hunting and DFIR analysis methodologies with little effort.

I've written and spoken often on the topic of threat actors modifying the target environment to meet their needs.  This has been about much more than just modifying the Windows firewall to allow an application to access the Internet; threat actors have been observed making what appear to be subtle changes to target environments, but when those changes are fully understood, they're actually very significant.  From enabling systems to store credentials in memory in plain text to disabling security tools, threat actors have been observed making significant modifications to the target environment.

In figure 12 in the Elastic article, we see where, via the macro, the actors modified the infrastructure to permit the execution of untrusted macros, as well as disabled warnings. However, this is nothing new.  Mari discussed the VBAWarnings Registry value in Feb, 2016, and the value was mentioned on TechNet as far back as 2012. 

As stated in the Elastic article, These small changes can end up having larger implications, and defenders can look for them as symptoms of more serious security issues. This is absolutely the case.  The article goes on to identify additional entities that have been observed modifying target environments in a similar manner.

Okay...so what? 

Well, there are a number of ways you can make use of this information...and this isn't all of the information from the article.  There are a total of 25 figures in the article, and the information discussed above is from three of those figures, two of which are EQL queries.  Depending upon the EDR solution you're using, you can monitor for modifications to the Registry, and specifically for that key path, and those values.  If you're in a position where you're not able to employ an EDR solution, or if you're limited to just DFIR analysis or retro-active threat hunting, you can check that the values exist, and if so, their data, in order to see if there is or was an issue.  If you do find the value data set in accordance with the article, the key LastWrite time may provide a suitable pivot point for analysis.