How Security Center and Log Analytics can be used for Threat Hunting

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 AUTHORITY\SYSTEM, 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:\\Windows\\System32"

| where NewProcessName !contains "C:\\Windows\\Syswow64"

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.

Continue reading

How Azure Security Center helps analyze attacks using Investigation and Log Search

Every second counts when you are under attack. Azure Security Center (ASC) uses advanced analytics and global threat intelligence to detect malicious threats, and the new capabilities empower you to respond quickly. This blog post showcases how an analyst can leverage the Investigation and Log Search capabilities in Azure Security Center to determine whether an alert represents a security breach, and to understand the scope of that breach.

Security Center Standard tier users can view a dashboard similar to one pictured below. You can select the Standard tier or the free 90 day trial from the Pricing Tier blade in the Security Center policy. On the below screen click on the Security Alerts graph for a list of alerts. This view will include alerts triggered by Security Center detections as well as integrated alerts from other security solutions. When possible, Security Center combines alerts that are part of chain of an attacker activity into incidents. The three interconnected dots icon highlighted in the screenshot below indicate an incident, while the blue shield icon indicates a single alert.

Clicking on an incident launches the incident details pane showing all the alerts that are part of it. Selecting a particular alert gives more information about that alert. The alert detail blade also includes an Investigate button (highlighted below) that initiates the investigation process for this alert. In the example alert PowerShell is seen using an invoke expression to download a suspicious-looking batch file from Internet. To understand more about this alert and the context of the security incident you can launch an investigation by clicking on the Investigate button. If an investigation has already been started this button will resume that existing investigation.

The investigation dashboard contains a visual, interactive graph of entities such as accounts, machines, and other alerts that are related to the initial alert or incident. Selecting an entity will show other related entities. For example, selecting a user account that has logged on to the machine where the alert occurred will show any other machines where that account logged on and any other alerts involving that account. You can navigate through related entities on the graph, exploring context about the entity and tagging anything that appears related to the security breach to build an investigative dossier. At this stage, the graph shows items that are one or two hops away from the initial alert, but as you click on other nodes in the graph, items related to the newly-selected node will appear.

An investigation will usually start by trying to understand the chronology of the incident, focusing on the logical sequence of events that happened around the time the alert was triggered. To set the time period for analysis the time scope selector dropdown is available on the top left side of the graph. You can use this to specify the exact time range in which to focus, using either a preset time range or a custom range. In the current example the first alert triggered around 9:47 AM. A custom time range from say 9:40 to 9:53 would be a good starting range. The selected time range limits alerts and entities that are added to the graph. As you navigate the graph, related entities will only be added if the relationship occurred in this time range. For example, an account that logged on to the host in this time range would be shown. The time range also limits the events queried in the Exploration tab to those occurring inside the current time range.

In this dashboard, relevant information about a selected entity is shown on the right side of the screen (screenshot below) in a series of tabs. The Info tab shows summary information about the entity, for example, selecting a machine shows OS type, IP address, and geographic location. The Entities tab shows entities, alerts, and incidents directly related to the selected item. In our example, selecting the machine identified in the alert (SAIPROD) shows alerts related to suspicious PowerShell activity, suspicious account creation, attempted AppLocker bypass, and disabling of critical services. Clicking on these alerts gives more details about them. The Search tab shows the event logs available that contain events related to the selected entity. For our example host it shows SecurityEvent, SecurityDetection, and Heartbeat.

Although it is possible to do your own searching through the logs from the Search tab, the Exploration tab can give you quicker access to relevant events and speed up the investigation process.

Let's look a little bit more into the Exploration tab in more detail.

The Exploration tab contains a set of queries that highlight some of the most relevant data for an investigation of activity on a given entity, presenting the data in way that is easily consumable. For example, in the screenshot below the Accounts failed to log on query shows two logon attempts where the user name does not exist. You can click on individual items in this list to see more details about the specific event or click the magnifying glass icon to view all of these events in the Log Search screen. Exploration queries are only shown when there is relevant event data. The queries also differ for different entity types, so expect to see different contents to this tab as you navigate between entities in the graph.

We also see data in the rarely used process often employed by attacker. This shows processes and commandlines of operating system executables that are often used by the attackers.

In this case looking at command line activity (above) as displayed by rarely used process we can see the attacker first issues the “whoami” command, which displays who the current logged on user is. We also see a range of other suspicious-looking activity like a user account being added, adding a registry value to the Windows run key, PowerShell being used to download a batch file, and the installation and startup of a Windows service. The tab view for this query may show only a subset of the available data. If there is more data, the View all link is shown at the bottom of the query results. Clicking this will take you to the Log Search and will display all of the data. Click on the TimeGenerated column header to order by time so that you get a true chronological picture.

To return to the investigation graph be sure to click on the Investigation Dashboard breadcrumb item at the top of the Log Search screen. Using the browser Back button will take you out of the investigation altogether.

As we find interesting artifacts related to the incident they can also be added to it. For example, the creation of a new user account adninistrator generated an alert around suspicious account creation. Looking at the sequence of command lines, it seems that this is related to the current incident, so we can add these to it as shown in screenshot below. The whole idea being that as we add more artifacts to the incident we get a better summary of how the attack progressed. Adding this account could help you extend the graph to a second virtual machine (VM) in case the attackers used it for lateral movement or if we’d see unusual processes run by that account on other VM’s. All such VM’s found could be added as additional machines to the incident.

One interesting thing that jumps out from this expanded view is that the Logonid (0x144a52) for all attacker command is the same, meaning that all of these commands were executed by the same account in the same logon session. This is a good analysis data point, often used in investigations. Focusing on the activity within the particular logon session from which the alert originated will tell you a lot about what else the attacker was doing or alternatively allows you to quickly determine that the alert might be a false positive in cases where there is no additional suspicious activity.

Log Search

Security Center uses Log Analytics search to retrieve and analyze your security data. Log Analytics includes a query language to quickly retrieve and consolidate data. From Security Center, you can use Log Analytics search to construct queries and analyze collected data. You may find it easier to use one of the exploration queries (clicking on “View All” or the magnifier icon to get to Log Search) as a starting point for your query.

Once in Log Search, you can set the event type to look for. In this case we used “Event ID == 4688” for Windows Process Creation events. These contain the CommandLine data that we are interested in. We narrow this further to show only events where the SubjectLogonId == "0x144a52".  Adding the project command, displays only the field that we are interested in. The search gives you result somewhat like below.

Looking at the search results reveals the following:

• An attacker tried to login using brute force techniques and succeeded. Please note that this is not shown in the 4688 events, but suggested by the failed logon attempts we saw earlier.
• Once logged in, the attacker launched a command prompt and issued the “whoami” command, which displays who the current logged on user is. The attacker then ran "systeminfo" to get the detailed configuration information about the host VM. The "qwinsta" command was also issued to get information about RDP sessions and other sessions on the VM.
• PowerShell was used to run an invoke expression to download a batch file from the Internet. The subsequent commands are likely contained in the batch file which we see executed at 9:49:07 since we can see the execution times of the following processes occurring within the same second.
• The batch file first disables the firewall. This is a known attacker technique. Once the initial compromise is achieved they often take steps to lower the security settings of a system such as disabling the firewall, Antivirus, and Shared Access.
• Next, we see the addition of a new user account called 'adninstrator'. The account name closely resembles our standard windows account in order to avoid being noticed by a human administrator.
• Then a suspicious service called "svvchost" is created and started.
• The search also shows a registry addition that installs an auto-run command. On closer analysis, this looks like an attempt to bypass AppLocker restrictions. AppLocker can be configured to limit which executables are allowed to run on a Windows system. The command line pattern looks like the attacker is attempting to circumvent AppLocker policy by using regsvr32.exe to execute untrusted code. On hosts where tight AppLocker executable and script rules are enforced, attackers are often seen using regsvr32 and a script file located on Internet to get a script bypass and run their malicious script.

Continue reading