Cyber for all
Stay informed, stay secure, and stay one step ahead of adversaries with KQL
It is great to see that more and more repositories, blogs and other sources share security related KQL content. Therefore this post provides an updated list of KQL Security Sources to start the new year. These sources can help you to kickstart your KQL knowledge for the upcoming year, by providing learning material, detection rules, hunting queries and many more.
The image below shows the increase in KQL repositories and the adoption from the community, they are becoming more and more popular, due to companies shifting to Microsoft Security solutions.
Kusto Query Language (KQL) can be your friend when it comes to prioritizing vulnerabilities, specifically when dealing with critical vulnerabilities from the CISA Known Exploited Vulnerabilities Catalog. This blog will explain what this catalog is and how KQL and/or CISAPy can help you to prioritise the vulnerabilities based on your application stack and needs. Multiple KQL examples are provided which can directly be used in your environment to determine which vulnerabilities from the catalog are still active and how they and new ones can be prioritized.
Threat intelligence reports are an essential source to be able to identify and mitigate security threats. However, the process of converting the information in these reports into actionable queries (such as Kusto Query Language (KQL)) can be challenging. In this blog post, we will explore the steps involved in going from a threat intelligence report to a KQL hunting query. This is done based on two #StopRansomware reports of the joint Cybersecurity Advisory (CSA).
If you query data that contains IP addresses this blog is something for you! It does not matter if you are a SOC Analyst, Detection Engineer, Network Engineer or a Developer all the logs that you use on a daily basis will contain IP addresses. This can be in Sentinel, Defender For Endpoint, Application Insights, Azure Firewall and many other sources.
This blog will discuss some basic network related operations, before diving into useful network related KQL functions.
This is it, the last part of the Incident Response series. In the past weeks, insight was given on how KQL can be used to perform incident response, even if the data is not ingested in Sentinel or Microsoft 365 Defender. Part three marks the last part which discusses how you can leverage Live Response, which is available in Defender For Endpoint.
The incident response series consists of the following parts:
The second part of the Incident Response series is here! In the last blog, we were lucky enough to have the logs already available in Microsoft 365 Defender or Sentinel. But what could you do if you do not ingest the logs in your SIEM or it is not logged by your EDR? This blog will explain how you can still perform incident response using KQL. Spoiler: Azure Data Explorer is your best friend!