Threat Hunting with Gusto, using Azure Kusto

By: Max van der Horst, Security Officer
Cyber Security can be daunting. Blue teams always have to be alert for attacks while the number of false positives keep rising. Eventually, that situation could lead to security alert fatigue. This brings us, in our opinion, a million-dollar question: how do we make Cyber Threat Hunting efficient and more importantly, sustainable again? This blogpost discusses how to detect threats using Azure Sentinel, projected onto a single case. 


Kusto Query Language
Let us start off with a quick look back in the past. In 2018, Microsoft announced the release of Azure Data Explorer. Azure Data Explorer offered a new, optimised and SQL-like query language in the form of KQL. KQL stands for Kusto Query Language and is named after the French explorer Jacques Cousteau. KQL is read-only, in contradiction to SQL, and cannot update or delete data. This does not make it any less useful for responding to certain events, such as security incidents. Do you see the connection?


Detecting Threats with KQL
KQL can be used for many things, but the ones we are interested in is log analytics within products like Azure Sentinel and Microsoft Defender ATP. This is done by creation of detection rules that create an incident once a certain condition becomes true. Overall, the formula for these detection rules is straightforward. An example of detecting something as simple as a brute force attack on an account would be as follows:

Create an incident when multiple failed login attempts occur on an account AND if the amount of different IP addresses in the past six hours is greater than five.

This will also be the case discussed for the remainder of this blogpost. Because how do we translate that requirement into a KQL detection rule to increase the chance of survival from such an attack? This could be an indication of a leaked password or even a larger data leak. Pretty important information in general. The appropriate response to such an incident would be to lock the user’s account and take action to make the user reset their password.


Writing the KQL Detection Rule
KQL provides a way to detect certain events, but as mentioned, these events need to be found in the logs first. So that is what we will do. We can specify different criteria which the detection rule can search for. The Security Event ID for this scenario would be 4625, which means failed login. This is a great start, as we can start to count these Event ID’s for a particular user. Next, we would have to sort and count the different IP addresses that attempt to log in and see if there are more than five. When this is the case, return the IP addresses. If we process that into a KQL rule, we will get the following:

1. SecurityEvent
2. | where AccountType == “User” and EventID == 4625 and TimeGenerated > ago(6h)
3. | summarize IPCount = dcount(IpAddress), makeset(IpAddress)  by Account
4. | where IPCount > 5
5. | sort by IPCount desc


Adding This Rule to Azure Sentinel and Creating Automated Responses
I will not bore you with the steps of adding a custom KQL rule to Azure Sentinel. If you require the steps to do so, you may find them here [https://docs.microsoft.com/nl-nl/azure/sentinel/tutorial-detect-threats-custom] in the Microsoft documentation. The real question is, what do we need to automate a response once this detection rule gets a response? 

This would most likely be the largest part of the process and is done with something called Sentinel Playbooks (or Logic Apps). Playbooks can be linked to the detection rule right after defining the rule. When an incident is created due to the detection rule getting a hit, the linked Playbook will automatically be run. Probably the most often used purpose for such Playbooks would be to send an email to alert security engineers, incident response teams, security officers and so forth. Another use would be to execute a fixed set of actions, such as the earlier discussed response. This Playbook does not have to be executed immediately but can also be ran at a later stage such as when a security engineer decides it is a true positive and requires direct action.

Figure 1: Playbook Configuration

What’s next?
Gaining more control over your organization’s security can be intimidating but is worthwhile if executed properly. KQL offers the tools to increased Incident Response and has loads of potential to securing businesses as the possibilities are endless. For any vulnerability imaginable, a fitting KQL-rule can be created. Of course, it is very understandable if you require someone to offer assistance in your journey to great cyber security, or for migrating to the cloud to benefit from this functionality for that matter. If this is the case, feel free to give us a call or email us at info@digitalsurvivalcompany.com so that your organization can use Kusto, with gusto, as well!

Footer_logo


//Let's talk about your next big project.

 

Adress: Nevelgaarde 6, 3436ZZ
City: Nieuwegein

Phone: 088 - 8765678
Mail: info@digitalsurvivalcompany.com