Sunday, September 11, 2016

Categories of Abnormal

First, a rant.  If you are a twitter fan and have spent any time looking at the #ThreatHunting hash tag you may have seen that a lot of people and companies talk about hunting, but never really explain the methodologies they use or why they use them in the first place.  It’s really more of a why you should be hunting.  I think this is a disservice to those that want implement this type of strategy, but find it difficult to get started.  I would love to see more people share their experiences and less of why we should be doing it.  Ok, rant over, sorry.

I spend a lot of time thinking about and studying intrusions while trying to define similarities between all of them.  I think that the more similarities I can find across different intrusions and actors, the harder it will be for any adversary to go unnoticed for prolonged length of time.  In a way, I believe this is a step above detecting at the TTP level.

Picture the following scenario.   
  1. A web server running Tomcat is compromised by weak administrative credentials. 
  2. The attacker uploads a war file and installs a webshell.
  3. The attacker accesses the webshell and executes whoami which returns the system account.
  4. The attacker executes several os commands to determine where he is and where he can go. (ipconfig.exe net.exe, ping.exe…)  
  5. The attacker uploads and executes mimikatz to collect credentials that can be used for lateral movement.
  6. The attacker attempts to mount the c$ share on several remote machines using the credentials obtained via mimikatz.
  7. Tools are eventually pushed to the c$ share on a remote machine and executed via wmic.

This example may be overly simplistic and only a small piece of an intrusion, but I think it illustrates the point that I’m going to make.  Every intrusion will introduce abnormal into your environment.  These abnormalities are typically seen in the following ways:
  1. Communication between machines
  2. User authentication
  3. Processes execution
  4. Filesystem activity

Just like developing a detection strategy that looks for IOC’s across various points of the kill chain, I think it’s also important to devise a strategy to hunt for anomalies that will need to exist when an intrusion occurs.  The benefit of hunting for these anomalies is that we are targeting the effects of behaviors and should be agnostic of specific tools or actors. 

It is often said that you need to baseline your environment before you can begin detecting anomalous behavior.  I’m not sure that I fully agree with this.  I think at some point you need to understand what the difference between normal and abnormal looks like, but I don’t think it always hinges on baselining.  If we build generic queries around least occurrence and first seen we have a chance of identifying the above as well as many other types of lateral movement or actions on objective.

Least occurrence:
  1. Inbound HTTP POST requests with compression extensions by URI path.
  2. Operating system commands executed by a web server process.
  3. Explicit logon events by count and time.
  4. Explicit logon events by process name.
  5. $share access by source host and username 

First seen:
  1. Process creation spawned by web server process.
  2. Files being written by web server process.
  3. Explicit logon by user, hostname and process.
  4. Failed authentication by source host and username count.
  5. Files being written to $ share

Distinguishing normal from abnormal can often be difficult, especially if you look at events singularly. Administrators will generate anomalous events just by their daily activities.  Users may generate anomalous events just because a new application was installed or they are working on a new project.  I believe that if you devise a strategy to hunt for the above 4 categories of abnormal and start looking at sum of events in different categories vs singular events you can begin to bubble the things that need to be investigated to the top.  It may take quite a bit of work to get to this level, but the detection capability will last far beyond a single adversary and single intrusion.

As always, I would love to know what you think.  Feel free to reach out on twitter ($jackcr) or use the comments section. 


  1. > If you are a twitter fan and have spent any time looking at the
    > #ThreatHunting hash tag you may have seen that a lot of people
    > and companies talk about hunting, but never really explain the
    > methodologies they use or why they use them in the first place.
    > It’s really more of a why you should be hunting.

    That's because it's Twitter and not something that can be explained in 140 char. The disservice is that to much of the DFIR and threat hunting community restrict themselves solely to Twitter as a means of communication.

  2. <--- guilty. > companies talk about hunting, but never really explain the methodologies they use or why they use them in the first place

    Threat Hunting is in it's hype cycle - like teenage sex: everyone talks about it, few do it, and those who do probably don't do it well. It'll pass - hopefully by the time it does a real definition will emerge and IDS companies will stop calling their product a hunt platform. Hell, when you get down to it, my own product is really a compromise assessment tool, but "hunt" is what everyone searches for so... ¯\_(ツ)_/¯

  3. As to the content: I personally find logon events and SMB events to be incredibly noisy. Most DFIR and hunt teams I work with have about 1 guy they can rely on to see signal within there, the rest have their eyes glazed over within the first splunk query.

    Personally, I like to first look for non-perishable indicators of compromise that identify entire classes of remote access tools or backdoors:
    Malware that use SMB for lateral movement generally use a static named pipe. Often they will enable the allownullsessionpipes key on hosts they route through. This is almost always a 0 so a REALLY quick query of hosts for a 1 has been effective against that entire class of malware (zero-day or not).

    Second, browser exploits often inject fully formed DLLs into iexplorer process memory with RWX permissions. I wrote a powershell function within my survey script which looks for those here:

    All my stuff is endpoint interrogation style. Searching through logs is usually a frustrating experience for most people so i've strayed away from it. Of course, most companies don't authorize hunters to rummage through endpoint process memory either...

  4. Chris...

    "...enable the allownullsessionpipes key..."

    What is that? I can't find an "allownullsessionpipes key".


    1. $KeyName = 'HKLM:\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters'
      $KeyValue1 = 'NullSessionPipes'
      $KeyValue2 = 'NullSessionShares'
      $KeyValue3 = 'RestrictNullSessAccess'

      I have some notes in there as well. It's not the MOST tested thing in the world so some of the assumptions could be slightly wrong. I just know it's worked for me in several instances.