Organizations today are constantly under attack. Azure Security Center (ASC) uses advanced analytics and global threat intelligence to detect malicious threats, and the new capabilities that our product team is adding everyday empower our customers to respond quickly to these threats.
However, just having great tools that alert about the threats and attacks is not enough. The reality is that no security tool can detect 100 percent of the attack. In addition, many of the tools that raise alerts are optimized for low false positive rates. Hence, they might miss some suspicious outlier activity in your environment which could have been flagged and investigated. This is something that Security Center and the Azure Log Analytics team understands. The product has built-in features that you can use to launch your investigations and hunting campaigns in addition to responding to alerts that it triggers.
In the real world, if you need to do threat hunting, there are several considerations that you should consider. You not only need a good analyst team, you need an even larger team of service engineers and administrators that worry about deploying an agent to collect the investigations related data, parsing them in a format where queries could be run, building tools that help query this data and lastly indexing the data so that your queries run faster and actually give results. ASC and Log Analytics take care of all of this and will make hunting for threats much easier. What organizations need is a change in mindset. Instead of being just alert driven, they should also incorporate active threat hunting into their overall security program.
What is Threat Hunting?
Loosely defined it is the process of proactively and iteratively searching through your varied log data with the goal of detecting threats that evade existing security solutions. If you think about it, Threat Hunting is a mindset. A mindset wherein – instead of just reacting to alerts you are proactive about securing your organization’s environment and are looking for signs of malicious activity within your enterprise, without prior knowledge of those signs. Threat hunting involves hypothesizing about attackers’ behavior. Researching these hypotheses and techniques to determine the artifacts that would be left in the logs. Checking if your organization collects and stores these logs. Then verifying these hypotheses that you derived – in your environment’s logs.
Hunting teaches you how to find data, how to distinguish between normal activity and an outlier, gives a better picture of your network and shows you your detection gaps. Security analysts who do regular hunting are better trained to respond and triage during an actual incident.
Today, we are going to look at some examples of these simple hunts that an analyst can start with. In our previous posts, we have already touched a little bit about this. You can read more about detecting malicious activity and finding hidden techniques commonly deployed by attackers and how Azure Security Center helps analyze attacks using Investigation and Log Search.
Scenario 1
A lot of security tools look for abnormally large data transfers to an external destination. To evade these security tools and to reduce the amount of data sent over the network, attackers often compress the collected data prior to exfil. The popular tools of choice for compression are typically 7zip/Winzip/WinRar etc. Attackers have also been known to use their own custom programs for compressing data.
For example, while using WinRar to compress the data a few of the switches that seem to be most commonly used are “a -m5 –hp.” While the ” a ” switch specifies adding the file to an archive, the “ -m5” switch specifies the level of compression where “5” is the maximum compression level. The “-hp” switch is used to encrypt content and header information. With the knowledge of these command line switches, we may detect some of this activity.
Below is a simple query to run this logic where we are looking for these command line switches. In this example, if we look at the result we can see that all the command line data looks benign except where Svchost.exe is using the command line switches associated with WinRAR. In addition, the binary Svchost.exe is running from a temp directory when ideally it should be running from %windir%/system32 folder. Threat actors have been known to rename their tools to a well-known process name to hide in plain sight. This is considered suspicious and a good starting point for an investigation. An analyst can take one of the many approaches from here to uncover the entire attack sequence. They can pivot into logon data to find what happened in this logon session or focus on what user account was used. They can also investigate what IP addresses may have connected to this machine or what IP address this machine connected to during the given time frame.
SecurityEvent | where TimeGenerated >= ago(2d) | search CommandLine : " -m5 " and CommandLine : " a " | project NewProcessName , CommandLine
Another good example like this could be the use of popular Nirsoft tools like mail password viewer or IE password viewer being used maliciously by attackers to gather passwords from email clients as well as password stored in a browser. Knowing the command line for these tools, one may find interesting log entries if they search for command line parameters such as: /stext or /scomma, which allows discovery of potentially malicious activity without needing to know the process name. To provide a previously seen example, seeing a command line like “notepad.exe /stext output.txt” is a good indication that notepad might be a renamed Nirsoft tool and likely malicious activity.
Scenario 2
Building on the earlier example where we saw Rar.exe being renamed to svchost.exe. Malware writers often use windows system process names for their malicious process names to make them blend in with other legitimate commands that the Windows system executes. If an analyst is familiar with the well-known Windows processes they can easily spot the bad ones. For example, Svchost.exe is a system process that hosts many Windows services and is generally the most abused by attackers. For the svchost.exe process, it is common knowledge that:
- It runs from %windir%/system32 or %windir%/SysWOW64.
- It runs under NT AUTHORITYSYSTEM, LOCAL SERVICE, or NETWORK SERVICE accounts.
Based on this knowledge, an analyst can create a simple query looking for a process named Svchost.exe. It is recommended to filter out well-known security identifiers (SIDs) that are used to launch the legitimate svchost.exe process. The query also filters out the legitimate locations from which svchost.exe is launched.
SecurityEvent | where TimeGenerated >= ago(2d) | where ProcessName contains "svchost.exe" | where SubjectUserSid != "S-1-5-18" | where SubjectUserSid != "S-1-5-19" | where SubjectUserSid != "S-1-5-20" | where NewProcessName !contains "C:WindowsSystem32" | where NewProcessName !contains "C:WindowsSyswow64"
Additionally, from the returned results we also check if svchost.exe is a child of services.exe or if it is launched with a command line that has –k switch (e.g. svchost.exe -k defragsvc). Filtering using these conditions will often give interesting results that an analyst can dig further into in order to find if this is the normal activity or if it is part of a compromise or attack.
There is nothing new or novel here. Security analysts know about it. In fact, a lot of security tools including ASC will detect this. However, the goal here is a change in mindset of not only responding to alerts but proactively looking for anomalies and outliers in your environment.
Scenario 3
After initial compromise either through Brute Force attack, spear phishing or other methods, attackers often move to the next step which can loosely be called network propagation stage. The goal of the Network Propagation phase is to identify and move to desired systems within the target environment with the intention of discovering credentials and sensitive data. Sometimes as part of this one might see one account being used to log in on unusually high number of machines in the environment or lot of different account authentication requests coming from one machine. Say if this is the second scenario where we want to find machines that have been used to authenticate accounts more than our desired threshold we could probably write a query like below:
SecurityEvent
| where EventID == 4624
| where AccountType == "User"
| where TimeGenerated >= ago(1d)
| summarize IndividualAccounts = dcount(Account) by Computer
| where IndividualAccounts > 4
If we also wanted to see what alerts fired on these machines we could extend the above query and join them with the SecurityAlerts table.
SecurityEvent
| where EventID == 4624
| where AccountType == "User"
| where TimeGenerated >= ago(1d)
| extend Computer = toupper(Computer)
| summarize IndividualAccounts = dcount(Account) by Computer
| where IndividualAccounts > 4
| join (SecurityAlert
| extend ExtProps=parsejson(ExtendedProperties)
| extend Computer=toupper(tostring(ExtProps["Compromised Host"]))
)
on Computer
If you want some more hands-on guide or are interested to validate ASC security detections against attacks you could also look at the Azure Security Center Hunting Threats Playbook. This playbook presents some nice hunting examples for a post-breach scenario that you can work through using Log Analytics and Security Center.
These are just a few examples. The possibilities are endless. With practice, a good analyst knows when to dig deeper and when to move on to the next item on their hunting journey. Nothing in the world of cyber gets better unless victims start defending themselves more holistically. Enabling our customers on this journey and providing them with the tools to protect themselves when they move to Azure is what drives us every day.
Happy Hunting!