Threat hunting in cloud environments demands more than static queries and manual log review. It requires repeatable investigation workflows, anomaly detection at scale, and the ability to connect signals across disparate data sources. Ashwin Patil, Senior Security Researcher at Microsoft Security Research, has spent over a decade in security monitoring and incident response. In his current role, he develops Jupyter notebooks for threat hunting investigations across cloud and on-premise data sources using Kusto Query Language (KQL) for Microsoft Sentinel. In this episode, he breaks down how Jupyter notebooks transform investigation workflows, how to operationalize the MITRE ATT&CK framework without boiling the ocean, and why incident preparedness through tabletop exercises is non-negotiable.
You can read the complete transcript of the episode here >
What does cloud-focused threat research actually involve?
Ashwin works within Microsoft’s XDR and SIEM team, focused on threat research rather than penetration testing or bug bounty. The work involves:
- Researching cloud attack paths: Understanding how adversaries move through cloud environments — initial access, lateral movement, privilege escalation — and documenting those techniques.
- Writing detections on cloud data sources: Translating attack path knowledge into KQL-based detection rules that run on Microsoft Sentinel.
- Community-driven contribution: Most detections are published as open source on GitHub. While Microsoft authors many, significant contributions come from the community. This transparency means other organizations can adapt the same detection logic to their platforms.
- Product collaboration: Working with product groups when new features require a researcher’s perspective on security implications and detection requirements.
This differs from traditional red/blue teaming in that threat research is fueled by multiple sources — not just internal red team exercises, but newly published attack paths by external researchers, new telemetry becoming available from cloud vendors, and real-world incident patterns.
How should organizations operationalize the MITRE ATT&CK framework?
The framework is a collection of real-world adversaries and the techniques they use. Ashwin’s guidance on making it actionable:
- Use it as a starting pointer, not the finish line: If you have nothing to guide your detection coverage, MITRE ATT&CK gives you a structured place to start. But do not treat it as a complete picture of all techniques that exist.
- Focus on your actual threat profile: Instead of trying to cover every technique in the framework, assess which actors are likely to target your organization or business sector. Then identify which techniques those actors most frequently use.
- Understand your available telemetry: Before writing detections, map what data sources you actually have. A detection rule is worthless if you do not collect the logs it depends on.
- Accept that one detection does not equal coverage: A single technique can be detected in multiple ways. Having one detection for a technique does not mean you are fully covered against all variants of that technique.
Organizations can refer to MITRE’s own blogs on operationalization, as well as practitioners who have shared how they implemented the framework in their environments. The key principle: threat detection must be context-specific to your architecture, not generic.
What are Jupyter notebooks and how do they apply to security?
Jupyter notebooks are live documents that combine text notes with executable code and inline outputs. While not new technology — they have been used in finance and education for years — their adoption in security has accelerated significantly.
- Not an automation tool: Tools like Logic Apps handle repeatable step-by-step workflows. Jupyter notebooks solve a different problem — they enable complex, interactive investigation where an analyst needs to iterate, visualize, and explore data dynamically.
- Live code execution: Write Python queries, visualization libraries, or ML-based detection approaches directly in the notebook. Run them interactively and see results inline alongside your documentation.
- Investigation playbook with teeth: Instead of a static runbook that says “check these five things,” a Jupyter notebook executes those checks and shows the results — all in one document.
- Flexibility in use cases: Visualization of attack patterns, anomaly detection using ML libraries like isolation forest, data munging across multiple data sources, and publishing enriched outputs back to SIEM platforms.
How does Ashwin use Jupyter notebooks for threat hunting?
The Microsoft Security Research team publishes notebooks for customer scenarios:
- Templatized investigation workflows: When an incident occurs, there are common steps every analyst performs — pivoting across data sources, gathering context, correlating identities and timestamps. Notebooks templatize these steps so analysts do not spend time manually executing repetitive queries.
- Anomaly detection research: Notebooks incorporate ML approaches like isolation forest to surface unusual patterns in cloud data that rule-based detections would miss. This represents anomaly detection at scale. A recent blog post demonstrated this approach with Microsoft Sentinel data.
- Cross-data-source correlation: Cloud investigations often require pulling from identity logs, network telemetry, endpoint data, and application logs simultaneously. Notebooks enable this in a single interactive environment.
The value for incident response teams: less time on mechanical query execution, more time on analytical decision-making.
How should organizations prepare for security incidents?
Ashwin emphasizes that preparedness is the most critical component — especially for organizations that have never handled a real incident:
- Document an incident response plan first: Who gets engaged? What stakeholders need to be informed? What are the initial containment steps? Having this written before an incident occurs prevents chaos during one.
- Conduct tabletop exercises regularly: Simulated incidents reveal preparedness gaps that no document can surface. They answer the question: “if this happened right now, would we actually know what to do?”
- Assess scope through impact analysis: When an incident does occur, the first task is identifying affected systems, cross-referencing against inventory, and determining the blast radius. This scope assessment drives whether mitigation is a patch, a network rule, or a full containment action.
- Close the loop with lessons learned: The final step of every incident should feed back into threat hunting. What was the root cause? How do we detect this earlier next time? How do we prevent recurrence? This creates a virtuous cycle between incident response and detection engineering.
What should top five focus areas be for threat hunting?
Ashwin pushes back on generic top-five lists. The right answer depends on your environment:
- Look at industry trend reports: CrowdStrike’s annual threat report outlines the most commonly used techniques. But recognize that most published data skews toward Windows and on-premise environments. Cloud-specific attack path research may require different sources.
- Focus on initial access techniques relevant to your architecture: Valid accounts, exploitation of public-facing applications, password spraying — these are consistently the entry points. Start detection coverage there.
- Do not fixate on exotic attacks: The Capital One breach used well-known techniques against misconfigured cloud infrastructure. Real-world breaches are overwhelmingly caused by techniques that are known, documented, and detectable — if you are looking for them.
The principle: focus on what is exploitable in your specific architecture rather than chasing the top-five lists that someone else documented for a different environment. This aligns with how AWS-specific threat detection requires understanding your unique telemetry landscape.
How should newcomers start a career in threat hunting?
Ashwin recommends a structured approach:
- Build foundational knowledge: Understand operating systems and system administration first. For cloud security specifically, understand how cloud platforms work and their core components. This foundation pays dividends throughout an entire career.
- Pick a specific role: Threat hunting, detection engineering, and threat research are distinct paths within the broader security space. Understand which one you are aiming for and study accordingly.
- Study open-source detection repositories: Microsoft Sentinel GitHub rules, Elastic’s detection rules, Sigma rule format — these are free learning resources that show how professionals write production detections.
- Follow curated sources: Cloud security newsletters (CloudSec List, TLDR Sec) provide weekly curated content. Build a social media list of researchers in your focus area. You will not understand everything immediately, but over time you will build context that compounds.
The advice echoes the concept from Atomic Habits: small daily knowledge gains compound dramatically over time. One percent better every day adds up to significant expertise over a year.
