The previous previous blog post is part 5 in this series.
Azure Sentinel provides features for Hunting as a proactive step of looking for security threats for security analysts through the mountains of data collected.
According to this article Threat Hunting Vs. SIEM by Infosec, hunting is defined as
“Threat hunting is the act of aggressively tracking and eliminating adversaries from your corporate network as soon as possible. Threat hunting discovers attacks, reduces the detection delta and stops adversaries from compromising your critical systems.”
In the Hunting blade, the following are a list of built-in queries to detect for threats and attacks across some of the Azure resources and services.
By clicking into one of the queries, you can see more details in a right pane and run query to see any results.
You can run all the queries and they run quickly. Here there are no results or N/A.
The neat aspect of this capability is that you can run many queries on demand that you don’t want alerts running often. These queries may be for uncommon threats or very broad and generic which are more suited for on-demand hunting.
Creating custom query
Let’s say for the App Gatway WAF, we wanted to have a query SQL Injection for hunting purposes, we can create the query by clicking on New Query.
Click Save and run the query. Here we see some results.
Clicking into the results, we see the result records that a security analyst can use to investigate further if there are any positive threats.
Here we can see (partially redacted) at least the host domain, IP address and URL. The URL contains query string parameters injecting to execute CMD to invade and disrupt the application. If there is some vulnerability in the application and infrastructure, the CMD with its parameters may be executable in the web server. Thereby a security analyst may investigate further with their own custom log queries to understand the threat. So Hunting can be a technique to broadly scan and query all connected diagnostics and logs via Azure Sentinel to proactively detect where alerts made to be more specific may not detect threats.
2 thoughts on “Using Azure Sentinel with Azure App Gateway to Investigate Web Attacks – Part 6 Hunting”
Pingback: Using Azure Sentinel with Azure App Gateway to Investigate Web Attacks – Part 5 Incidents – Roy Kim on Azure, Office 365 and SharePoint
Pingback: Using Azure Sentinel with Azure App Gateway to Investigate Web Attacks – Part 1 Intro – Roy Kim on Azure, Office 365 and SharePoint