Table of Contents
Before diving into manual query execution, it’s vital to comprehend what hunting queries are. They’re typically written in a query language, such as Kusto Query Language (KQL), and are used to search, aggregate, and analyze data from various sources like logs, network data, and other telemetry.
Kusto Query Language is the primary language utilized in Azure Sentinel, Microsoft’s cloud-native SIEM (Security Information and Event Management) platform. KQL allows analysts to write complex queries to filter through large volumes of data efficiently.
To run a hunting query manually in Azure Sentinel, you follow these steps:
To illustrate, here is a simple example of a hunting query that searches for any login attempts that have failed multiple times within the last 24 hours:
SigninLogs
| where ResultType != “0” // non-successful logins
| where TimeGenerated >= ago(24h)
| summarize Count = count() by UserPrincipalName
| where Count > 5 // looking for more than 5 failed attempts
Security analysts may need to run comparative queries to understand patterns and anomalies over time. Below is a table that contrasts two different hunting queries, showing how queries can be tailored for distinct investigative purposes:
Purpose | Query |
---|---|
Failed Logins Detection | SigninLogs | where ResultType != “0” | where TimeGenerated >= ago(24h) |
Anomaly Detection (Outliers in Resource Access) | AuditLogs | where OperationName == “Access resource” | summarize Count = count() by ResourceId | where Count > percentile(Count, 95) |
When running hunting queries manually, consider the following best practices to improve efficiency and accuracy:
In the realm of security operations, the skill to construct and run hunting queries manually is invaluable. The SC-200 exam underscores the importance of understanding how to write effective KQL queries, interpret the results, and customize queries to fit the investigative needs of the security analyst. By employing these manual hunting techniques, security professionals can proactively detect and address threats, reinforcing the organization’s overall security posture.
Answer: A) True
Explanation: Custom hunting queries can indeed be created using Kusto Query Language within the Microsoft 365 Defender portal to search for potential security threats across data sources.
Answer: D) All of the above
Explanation: Hunting queries in Microsoft 365 Defender can be used to query across multiple data sources such as email, device, and network data to identify threats.
Answer: D) Automatic remediation actions based solely on the query results
Explanation: While hunting queries can help identify threats, they do not automatically trigger remediation actions without further analysis or confirmation of the threat.
Answer: B) False
Explanation: Users are not limited to pre-defined templates and can create custom hunting queries to meet specific needs.
Answer: B) Daily
Explanation: In Microsoft 365 Defender, you can schedule hunting queries to run on a daily basis.
Answer: A) True
Explanation: Appropriate permissions are required to run hunting queries manually in Microsoft 365 Defender, ensuring that only authorized personnel can execute and view results from such queries.
Answer: B) To hunt for potential security threats and anomalous behavior
Explanation: The primary purpose of running hunting queries is to proactively search for possible security issues and unusual activities that may indicate a threat.
Answer: A) True
Explanation: Results from hunting queries can be shared with Azure Sentinel, allowing for a deeper and more integrated analysis across security tools.
Answer: B) To provide contextual information and indicators related to known threats
Explanation: Threat intelligence plays a key role in crafting effective hunting queries by providing relevant context and indicators of compromise associated with known security threats.
Answer: B) They may produce false positives that require further investigation.
Explanation: While hunting queries are a powerful tool for identifying potential threats, they may also yield false positives, necessitating additional scrutiny.
Answer: B) False
Explanation: While it is important to run hunting queries against relevant historical data, querying excessively large datasets may lead to performance issues and is not always practical or necessary. Queries should be balanced between depth of history and performance.
If this material is helpful, please leave a comment and support us to continue.