{"id":3883,"date":"2016-10-16T17:27:34","date_gmt":"2016-10-16T17:27:34","guid":{"rendered":"http:\/\/www.hexacorn.com\/blog\/?p=3883"},"modified":"2016-10-16T22:17:08","modified_gmt":"2016-10-16T22:17:08","slug":"the-threat-hunting-the-anomaly-hunting-the-data-eyeballing","status":"publish","type":"post","link":"https:\/\/www.hexacorn.com\/blog\/2016\/10\/16\/the-threat-hunting-the-anomaly-hunting-the-data-eyeballing\/","title":{"rendered":"The Threat Hunting -> the anomaly hunting -> the data eyeballing"},"content":{"rendered":"

In my last post I described my opinion about current state of affairs of the fashionable IR trend called threat hunting<\/a>. Since I am advocating it myself for a number of years I probably shoot myself in a foot by being openly critical about its potentials, but if there is one way for this discipline to progress it is to question your own doing…<\/p>\n

Since I posted it I received a rebuttal from Jack Crook<\/a> and a couple of answers on Twitter. Jack’s rebuttal starts by hinting at my inexperience in a field and then goes all the way to promote the very wishful thinking that I decided to criticize. The simple answer to Jack’s post is this: theory vs. practice. The fundamental problem of threat hunting is not how we detect specific things, or how we generate better ideas how to correlate data for specific cases. This is easy. Once you have that data, that correlation engine in place and that specific idea – you just implement it. It is a simple engineering work. The ‘fun’ begins afterwards – the tweaking. When I brought up a couple of examples of potential (but naive) threat hunting rules that could be used to detect badness in the environment, it was not to highlight them as examples of rules that could be potentially improved. We can always do so, and can\/should look at more holistic way these events correlate with each other. I agree, I actually do, because I practice it too and quite a lot. Yet, I don’t want these two points I made to be missed:<\/p>\n

    \n
  1. The threat hunting _is_ signature writing. How far is it from IOCs, yara and lo and behold – virus signatures? And we know it doesn’t work.<\/li>\n
  2. The error of availability makes us a subject to naive assumptions – one that complex correlations will help us to get rid of False Positives easily (which we are not aware of until we test it on large corpora of data)<\/li>\n<\/ol>\n

    I have already covered the signature writing, let me discuss the error of availability a bit more. We write rules for what we have seen (btw. antivirus works the same, reactive way). Our exposure to the knowledge about BAD actors and behaviors is limited, but we are getting better and better at it. Yet I can bet that neither you nor myself know, or remember all the tricks of the trade. Will your threat hunting cover everything? Does it cover everything inside the Rtfm-Red-Team-Field-Manual<\/a> and Post Exploitation Wiki<\/a>? I published over 40 posts about various persistent mechanisms<\/a> in last couple of years – I bet most of the threat hunters do NOT look at these cases (full disclosure: I don’t). The avalanche of clever tricks developed by SubTee<\/a> is definitely NOT covered by most of us either. Add to it the variations of OS commands, tools, various WMI, kiosk-escape, pentesting kung-fu trickery, and also unpublished research, and a few thousands blogs one would need to follow (and constantly discover new ones: don’t forget Chinese, Korean, Arabic, Spanish, etc. blogospheres) to stay on top of things and you know that we would still be behind. I did mention before that we want to detect the insider threat too. Wishful thinking it is.<\/p>\n

    But let’s – for the sake of the argument – assume that we read all blogs, APT reports, did our homework and collected all the trickery in our head and we know what to hunt for. Here comes the error of availability number two – our exposure to the knowledge about GOOD actors and behaviors. It is extremely limited. And it is the latter that makes the Threat Hunting extremely challenging. Because while we successfully leverage our (limited) knowledge about the BAD guys, most of the time we completely ignore the one about the GOOD guys. Once we apply this approach in practice, the False Positives show up immediately. I have already listed a number of examples of GOOD actors’ behaviors in my previous posts. If you simply ignore them in a discussion then I suspect you don’t have the exposure to a corpora of real security events from a large organization. Support\/Admin scripts often launch a number of lateral movement tools one by one, people use Excel and Word to launch cmd.exe, and other tools, the enterprise solutions use psexec, autoruns, cmd, cscript, xcmd, nmap, WMI, MSI, they load drivers, create scheduled tasks, services, google chrome with its updates is a ‘nice’ event generator, people use crazy number of variants of putty, kitty, ssh, winscp placed all over their systems, they download files using wget, curl, even bitsadmin is used either by good guys, or by software, then there is cygwin, a number of users learning hacking in-house, and so on and so forth… Having a tree and ability to correlate the events is often NOT enough. The sad truth is that behaviors of BAD and GOOD guys are often indistinguishable!<\/p>\n

    The lack of public data for researchers’ consumption is a problem in this space and one that can be hopefully addressed one day. The threat hunting discussions need to be very data-specific. Threat hunting today is data eyeballing. Just saying that ‘we need to look at better rules or correlations and leverage our knowledge about bad actors’ is simply vague. And vague Threat Hunting cannot be. I guess it’s really time to engage data scientists.<\/p>\n

    Being critical is constructive only if we discuss next steps. I believe that there is a list of must-do things for any threat hunter – they may act as an eye opener:<\/p>\n