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!

It always happens on Friday afternoon, a high severity incident is created just before you want to start your weekend. After you have triaged the incident you suspect that an threat actor gained access to your environment. From that moment questions are starting to pop up in your head; what happened on this device? Are more devices impacted? What do I need to do to contain the incident? Will I be in time for dinner with my wife?

Encoding is a something that has exsisted for decades and not new a new created concept for information technology. In essence, encoding is the transformation of data into a specific format or structure for secure storage or efficient transmission. In ancient times, civilizations used rudimentary encoding methods like the Caesar cipher to protect sensitive messages from adversaries. As technology advanced, more sophisticated encoding techniques were created, especially since computers could easily decypher the contents.

In recent years Kusto Query Language (KQL) has gotten a more and ever increasing place in the cyber security world. The language offers a powerful arsenal of functions and capabilities that can be leveraged for SOC operations, incident investigation, threat hunting, and detection engineering. In this blog, we explore several KQL functions. We will uncover how security teams can use KQL to get insight into new query possibilities. Whether you use KQL in 365 Defender, Sentinel or Azure Data Explorer, all the functions can be used in all of the places regardless of where your logs are stored.