A Few Of My Favorite Things

Today I want to talk about a couple of my favorite things.  Finding bad guys and thinking about finding bad guys.  When I talk about “thinking" I don’t mean fantasizing about the act of finding a successful intrusion, but rather, what steps do I need to incorporate or modify that will increase my chances of locating evil on my network.  I’ve actually been wanting to write this post for a while and I finally got a bit of motivation after a few tweets this past week.

I believe attackers will always leave traces of their activity.  No matter how subtle the indicators may be, it is our job to be able to find and interpret those so that we can respond accordingly.  So the question is, how do we go about finding these indications that attackers are in our network?  To answer this question I think it helps to focus our thoughts in a way that will help us understand relationships between the things we are trying to identify.  By focusing on these relationships we can then begin to surface patterns in our data.  Sitting down and mapping out the things you know about adversary activity is a great place to start.  I think it should be said that I don’t care about mapping the TTP’s of a specific actor at this point.  I simply want to lump everything together so that I can get an idea of the things I should be looking for and what is the state of my detection at this point in time.  To aid us in this quest we can pull data from internal response actions that we’ve performed, public reporting, private sharing or even hunches that we have (don’t ever discount these).  Aside from internal response actions, one of the best sources for this type of data gathering is definitely Mitre’s ATT&CK Framework.  There is a wealth of information in the framework as well as their Cyber Analytic Repository.  

Earlier this year, as I was recovering from open heart surgery, I felt like I needed a project to keep my mind busy so I sat down and did just what I described above.  I took a look at what I knew as well as what I could find regarding KC7 activity and mapped those actions to, what I see as, adversary needs.  It was a really good exercise in my opinion.  It not only helped me focus on the things I should be looking for, but visually be able to see my ability to map behaviors through multiple stages of an intrusion.  I tweeted these maps earlier this year which can be found here:

Authentication: https://twitter.com/jackcr/status/895735784497496064

Data Movement: https://twitter.com/jackcr/status/894998989279506432

Enumeration: https://twitter.com/jackcr/status/893520579663466496

Execution: https://twitter.com/jackcr/status/893064222732693504

Credentials: https://twitter.com/jackcr/status/892108945883619333

Next we need to understand what logs we have available as well as how to interpret these logs.  Do you know the above actions well enough to know what a positive example would look like in logs that you have?  If the answer is no, prepare to spend some time testing.  Do you know these log sources well enough to know what you can and can’t detect in them (note that surfacing a single action may very well be a correlated event that spans multiple log sources). If the answer is no, prepare to spend some time in them.  Keep in mind that we can often surface needed data by writing rules in our existing tools to log whenever a certain event has been identified.  I believe this is a great way to maximize the use of our current logs.  Don’t forget to consider both the source and destination when trying to determine what can and can’t be found.  For actions that can’t be detected due to gaps in coverage, make sure to document these as well as a log source or sources that would provide the needed visibility (be ready to provide management with a solution to a problem).

So if you set out to create detection for credential theft and only wanted to look for static indicators you could do that.  You could write detection for, and alert on AV threat names, service names, or specific filenames, but ask yourself, why do adversaries keep going back to these tools?  Because, for various reasons, they work and go undetected a large percentage of the time.  I am no way saying that it's a waste of time to try and detect those static ioc’s.  We should, hands down, have detection and alerting for those.  But when we have completed that task we shouldn’t assume that we are finished.   There is much more that can be done.  Lets take a look at a sample scenario involving invoke-mimikatz.

1. Attacker mounts C$ share on a remote machine
2. Attacker copies malicious batch script to the mapped share
3. Attacker issues wmic command to execute batch script on remote machine
4. Batch script executes powershell that will download and execute invoke-mimikatz
5. File that is created with the output of invoke-mimikatz is copied from mounted share to local filesystem. 

The above actions taken by the attacker would fall into the maps under the following:

Need	Action
Authentication	Network Logon: Mounting Share
Data Movement	Admin Shares: Copy .bat script
Execution	WMIC: Execute against remote machines
Authentication	Rare Explicit logon
Data Movement	HTTP: Download of tool
Credential	DLL Loading
Execution	Powershell: Command Arguments
Data Movement	Copy: Dump File

As you can see, the act of dumping credentials involved 4 out of 5 needs.  It should also be noted that not one of the above detections is specifically related to finding Invoke-Mimikatz, but instead related to surfacing an action (or building block) with the intent of bubbling up a malicious chain of events.  The more effort that is put into defining, gaining visibility and alerting on these building blocks, the more dynamic your detection may become.  By looking for clusters of events across multiple needs you should be able to quickly spot anomalous activity.