Now generally available: Discover local AI agents with Microsoft Defender
As local agents have moved from experimentation into everyday work, traditional security visibility is no longer enough. Unlike static software, local agents such as coding assistants, command-line agents, desktop applications, and agentic development environments can operate on endpoints with access to a user's data, credentials, tools, and services. They can also connect to Model Context Protocol (MCP) servers that extend their access to additional tools and data. This change requires security teams to look beyond. They need to understand which local agents are running and where, which users and devices these agents are associated with, and which MCP servers these agents are configured to use. To address this challenge, at Microsoft Build 2026, we introduced new Microsoft Defender capabilities to help security teams discover and protect more than 20 types of local AI agents. Today, discovery of AI agents and their configured MCP servers on Windows and macOS is generally available, with discovery coverage expanded to more than 50 supported agents and MCP servers. On eligible, onboarded devices, Defender discovers supported agents by observing their activity and brings the agent, device, account, and configured MCP context together to give security teams visibility for their local agent environment. Beyond discovery, runtime protection for local agents for Windows continues to be available in preview, helping protect discovered agents as they operate. Teams can deploy runtime protection at scale from either the Microsoft Defender portal or the Microsoft Intune portal, with Intune-based deployment available in preview. Both discovery and runtime protection for local agents will be available for Microsoft Defender for Endpoint P2 and higher customers. See the local agents and associated MCPs operating in your environment In the Defender portal, security teams can see the discovered agents under Assets. The inventory associates each agent with the device and user account where it runs and includes details such as agent name, version, vendor, related process, and discovery history. Examples of supported local AI agents include: CLI agents: Claude Code, Codex CLI, Gemini CLI, GitHub Copilot CLI Desktop applications: ChatGPT Desktop, Claude Desktop, Codex Desktop, GitHub Copilot app, Microsoft Copilot app, Ollama Desktop, Perplexity Desktop Agentic IDEs: Cursor, Devin Desktop, Kiro IDE, Antigravity IDE VS Code extensions: Claude Code, Cline, Codex, Gemini Code Assist, GitHub Copilot, Roo Code Claw-based agents: OpenClaw, Clawpilot, QClaw We will continue expanding support for agents across both discovery and runtime protection. The supported agent list continues to evolve; see AI agent support matrix for the current list. In addition, security teams can see supported local and remote MCP server configurations associated with discovered agents. Depending on the configuration, details such as the MCP server name, type, endpoint, or the command used to start a local server are visible, helping teams understand not only which agents are present, but also the tools and services those agents can access. Assess exposure and investigate local agents After discovering agents, security teams need to understand what those agents are connected to and what risk they may introduce. The exposure graph in Defender provides a clear visual of the agent’s blast radius including the agent associated devices, identities, and MCP context. These data sources can be used to investigate agent activity in advanced hunting, alongside the data from endpoints, identities, email, and cloud. Risk indicators and security recommendations are also available to help teams prioritize risks. For ready-to-use queries, see Discover local AI agents with Microsoft Defender. Secure local agents while they operate AI agents are good for productivity, but they also undeniably introduce new security risks to organizations. For example, prompt injection can be hidden in a file, web page, repository, or tool response that an agent reads. If the agent follows an attacker’s instructions, the attacker could attempt to misuse the user's access, run unwanted commands, modify code, or expose sensitive information. Defender inspects supported points in the agent loop and stops malicious instruction before an agent acts on them. When Defender detects prompt injection, it raises a suspicious AI prompt injection alert with agent and session context. Administrators can view detections and validate accuracy in audit mode, then move selected device groups to block mode for enforcement. In block mode, Defender can stop the action before it continues and notify the user in the agent experience and through Windows. In preview, Defender currently supports runtime protection via agent-native event inspection and network inspection for discovered agents for Windows; coverage varies by agent and inspection approach. Agent-native event inspection (Hooks) uses vendor-supported event interfaces to inspect user prompts, tool requests before execution, and tool responses after execution. Network inspection extends protection to supported agents that don't expose an agent-native event interface by inspecting supported agent-to-model network flows. Security teams can investigate agent-related threats in Defender with the rich context of existing endpoint protection, alerting, incident correlation, and investigation workflows. Deploy runtime protection at scale As local AI agent adoption grows, security teams need a scalable way to deploy runtime protection consistently across managed devices in the organization. In Defender, security teams can create a Windows policy, select the Microsoft Defender AI agent runtime protection profile and configure AI Agent protection settings with one of three values: Default: Runtime protection is disabled. Audit: Defender detects and reports prompt injection while allowing the supported agent action to continue. Block: Defender detects prompt injection and blocks supported agent actions before they run. We recommend beginning with a limited group in Audit mode, reviewing detections for one to two weeks, and then moving to Block mode when your organization is ready to enforce protection. nshot 4: Deploy AI agent runtime protection with Microsoft Defender] In public preview, Microsoft Intune also provides a native AI agent runtime protection for Microsoft Defender endpoint security policies. Security teams can configure agent-native event inspection on enrolled Windows devices without relying on a custom deployment script. Now, security teams can choose either Microsoft Defender portal or Microsoft Intune portal to deploy runtime protection at scale. For configuration requirements and deployment steps, see Set up AI agent runtime protection with Microsoft Defender for Endpoint. To safely validate your configuration on a test device, see AI agent runtime protection demonstration. Learn more: Microsoft Learn: Local AI agent discovery overview Microsoft Learn: Discover local AI agents with Microsoft Defender for Endpoint Microsoft Learn: Local AI agent runtime protection Microsoft Learn: Set up local AI agent runtime protection Microsoft Learn: Local AI agent support matrixDefending Linux in the age of AI-operated attacks
Linux supports cloud services, containers, developer environments, business-critical applications, and a growing share of AI infrastructure. That makes Linux both essential to modern enterprises and increasingly attractive to attackers. AI is compressing the time required to research targets, vary payloads, and adapt when an attempt fails. Customers need protection that can recognize modern attacker behavior at runtime, continuously test effectiveness against realistic attacks, and learn and evolve with the threat landscape. That’s why Microsoft Defender is focused on three priorities for Linux: stronger runtime protection for fileless and in-memory attacks, continuous validation that proves protection remains effective, and AI-powered defense that can help security teams simulate attacks, investigate threats, close protection gaps, and reduce exploitable paths before compromise. A new Linux threat model The threat landscape has evolved from AI-assisted attacks, where people use AI to accelerate individual tasks, to AI-operated attacks, where AI coordinates more of the attack chain, and now it is moving to autonomous AI attacks that can adapt and act with limited human direction. Modern Linux attacks rarely depend on one file; they combine exposed services, stolen credentials, legitimate administration tools, scripts, containers, and cloud-native attack paths. As AI helps attackers generate and modify payloads at scale, adapt when an attempt fails, and move through the attack chain faster, defenders can no longer assume that every payload, script, or binary will resemble something they have seen before. Microsoft Security Research recently observed compromises involving a LiteLLM gateway, a RAGFlow deployment, and a Kestra workflow environment. The intrusion paths differed, but the objectives converged around credential theft, persistence, downstream access, and compute monetization. The broader lesson is that AI gateways, retrieval platforms, and orchestration services are becoming high-value control points where data, credentials, model connectivity, and workload execution meet. These examples also highlight a broader shift: attackers increasingly abuse legitimate services, tools, and workflows rather than relying solely on overtly malicious binaries. Viewed one event at a time, Bash, Python, curl, SSH, and network connections can appear legitimate. The security challenge is to understand their sequence, process relationships, destinations, and runtime context. That is why Linux protection in Defender is grounded in recognizing attacker behavior, not just known files. Behavior-based runtime protection for modern attacks Defender brings together next-generation protection, endpoint detection and response (EDR), vulnerability management, advanced hunting, investigation, and response to provide protection and visibility across the attack lifecycle. Behavioral protection evaluates process relationships, command lines, scripts, and runtime activity to identify malicious execution based on what is happening on the device. This is particularly valuable when attackers use legitimate tools or changing payloads that may not appear suspicious in isolation. Targeted memory inspection, now in public preview, extends protection to supported threats that operate in memory and may leave limited evidence on disk. Defender uses runtime behavior to focus inspection on relevant processes and execution activity. By concentrating inspection where suspicious behavior is observed, Defender delivers in-memory protection while minimizing unnecessary scanning and associated performance overhead. Consider an attacker who gains access through an exposed Linux application, executes commands, moves malicious activity into memory, launches additional processes, and connects to attacker-controlled infrastructure. Defender creates opportunities to block the attack, detect suspicious runtime activity, correlate related signals, and disrupt further impact. These are not isolated protection points. Different layers of Defender work together to build one complete picture as an attack progresses. Changing a payload or technique does not remove the behavioral, process, memory, and network signals that can expose malicious activity. From malicious activity to an actionable incident Defender protection on Linux executes a four-step process: block malicious behavior, detect suspicious runtime activity, correlate related signals into an incident, and disrupt the attack before it causes further impact. 1. BLOCK Malicious behaviour stopped. 2. DETECT Suspicious runtime activity surfaced. 3. CORRELATE Related evidence connected into an attack graph. 4. DISRUPT Malicious activity contained to limit impact. In these sample screenshots, you can see how Defender turns runtime activity into a connected incident that security teams can investigate and respond to. Connecting DNS activity to Active Incidents Microsoft Defender now provides DNS visibility on Linux. Network connections are enriched with the domain being contacted, and DNS activity is attributed to the process that requested it. When these domains are correlated with Microsoft Threat Intelligence, Defender can identify Linux servers reaching out to known malicious infrastructure and connect that activity to the process chain behind it. This gives security teams earlier detection and clearer context when investigating a potentially compromised Linux server. In an attack, a compromised Linux server could execute malicious commands, download payloads, and connect to attacker-controlled infrastructure. The example below shows how DNS activity can appear within the incident, helping investigators trace the connection back to the process behind it. Continuous validation and coordinated defense Protection is only meaningful when it performs against real attacks. Customers continuously validate Linux protection across leading breach-and-attack simulation and penetration-testing platforms, including AttackIQ, SafeBreach, Cymulate, Metasploit, and Picus. Repeatable testing helps expose coverage gaps, identify regressions earlier, strengthen behavioral detections, and verify resilience as payloads and attack paths change. Deterministic scenarios remain the foundation because they provide repeatability and measurable coverage. Over time, specialized security models can complement them by helping teams develop controlled tests for their environment, explore alternative attack paths, and continuously validate that protections are effective. Project Perception outlines Microsoft’s direction for connecting signals, context, security models, and specialized agents into a coordinated defense system that continuously learns while keeping people in control of high-impact decisions. Microsoft’s differentiated advantage is the breadth of its security vantage point: more than 100 trillion security signals processed each day provide the threat intelligence and context to continuously improve detection and defense. For Linux, this direction connects attack simulation, investigation, vulnerability context, and protection improvement into a continuous loop—reducing exploitable paths before compromise, limiting attacker movement during incidents, and extending runtime protection to emerging AI workloads. Looking ahead Linux will remain central to cloud services, developer platforms, and AI infrastructure. Our commitment is to help customers identify critical gaps, test protection against changing attack paths, reduce opportunities for exploitation, and strengthen Linux defense continuously as attackers and defenders operate at AI speed.
Microsoft Defender AMSI false positive — private evidence submission guidance
We're seeking guidance on the official private review process for a suspected Microsoft Defender Antivirus AMSI false-positive detection. Detection: HackTool:PowerShell/ApexToolkit.A The detection occurred during an authorized PowerShell-based .NET development/testing workflow. The original AMSI payload is unavailable. We've collected the official Microsoft Defender diagnostic CAB, but it contains personal and internal system information, along with unrelated security history. Microsoft Support referred us to Tech Community because the consumer support channel could not escalate the investigation directly. Our question: Is there an official private channel for submitting sanitized incident records for initial classification review, or obtaining guidance about secure handling of the full diagnostic CAB? We want to maintain Defender protections and avoid posting sensitive diagnostic evidence publicly. Thank you for any guidance on the appropriate Microsoft review process.Secure Linux desktops with Microsoft Defender
As more developers begin to use Linux desktops, they become more attractive to attackers: high-privilege, high-value, and easy for admins to overlook. A developer using Linux for day-to-day development may interact with source code repositories, continuous integration and continuous delivery (CI/CD) pipelines, cloud infrastructure, container environments and internal development platforms. If their workstation is compromised, an attacker doesn’t just gain access to a laptop, but a foothold in the pipelines that build and ship the organization’s software. As Linux adoption expands beyond the data center, organizations need a consistent approach to protecting Linux wherever it is used. That’s why we’ve extended our industry-leading endpoint protection in Microsoft Defender, bringing enterprise-grade protection, detection, vulnerability management and response capabilities to Linux workstations. Enterprise-grade protection for Linux desktops Defender support for Linux workstations spans all three key areas of endpoint security: Protect and detect Endpoint detection and response (EDR) Microsoft Defender next-gen antivirus Threat analytics Exposure management Microsoft Defender Vulnerability Management Device inventory Security settings management Investigate and respond Advanced hunting Live response Device isolation The result is broader Linux protection, delivered through the tools and processes security teams already trust. Give security teams a consistent and simplified view across the endpoint estate With Defender on Linux desktops, organizations can: Onboard quickly using the deployment methods already validated for Linux servers Reduce operational complexity by protecting Linux desktops and servers with one agent and one security operations experience Improve visibility across heterogeneous endpoint environments Strengthen developer workstation security where users interact with source code, cloud infrastructure and other critical resources Accelerate investigation and response through a consistent security operations experience Defender protects Linux desktops with the same deployment organizations already use to protect Linux servers. There is no separate desktop-specific agent to deploy or maintain, and existing deployment packages, deployment methods and security capabilities on Linux servers extend directly to Linux workstations. Defender automatically identifies whether a Linux device is a server or a workstation, so devices appear correctly within inventory and security workflows without any additional administrative effort. With Microsoft Defender, security operations teams can gain visibility into Linux workstations alongside the rest of their enterprise endpoint estate. They can respond through a single portal, whether Linux is running in the data centre, in the cloud, or on an engineer’s desk. Get started Defender support is based on the underlying Linux distribution and kernel version, regardless of the desktop environment running on top of the distribution. Every distribution currently supported by Microsoft Defender on Linux servers is supported on Linux desktops as well — including RHEL, CentOS, Ubuntu, Debian, SLES, Fedora and Oracle Linux, running GNOME, KDE or other desktop environments. Defender on Linux desktops requires the standalone Microsoft Defender for Endpoint Plan 2 or Microsoft 365 E5 and E7. If your organization runs Linux on developer, engineering or security desktops, now is the time to close that visibility gap. To join the public preview, onboard eligible Linux workstations using any of the existing deployment methods. Before you begin, review what’s new in Defender and complete the pre-requisites. This is another step towards our vision of helping organizations secure every endpoint, no matter which operating system or platform. To learn more about endpoint protection with Microsoft Defender, check out our website. To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.Defender streaming setup and integration with private event hub
Hey team, Do we know Defeneder supports private endpoint only event hubs to ingest data - I think only public is supported Configure Azure Event Hubs for Microsoft Defender XDR event ingestion - Microsoft Defender XDR | Microsoft Learn Could anyone please clarify?
RESYNC MICROSOFT DEFENDER FOR ENDPOINT
hey guys im a junior IT officer and i have been tasked with finding a way to get microsoft defender for enpoint to get fresh data without waiting 24hrs or the 4 hours that microsoft insists the resync will happen,I tried advanced hunting running queries directly there,i tried runnning an anti virus scan but nothing happened and APIs i tried looking for APIs that can initiate a restart but nothing...any ideas ? i read on here there was github repo for using powerBI with defender to get new data https://github.com/microsoft/MicrosoftDefenderForEndpoint-PowerBI but its not clear how that work...any intel would be helpful
Monitoring work from home
My boss has asked me if there is a way to see just how "busy" people who are working from home are. I have this data in Sentinel: Entra sign-in logs Defender for Endpoint logs Office 365 logs Most, if not all, on premise AD login events Netskope (current ZTNA solution) logs I have my known office location IPs so i could just exclude those and look for activity from other IPs however many times people will work in the morning or on the way to work appearing from a non corporate IP, come into the office appearing to come from a corporate IP, and then from home again in the evening. I need a way to query Sentinel looking for people who appear to be working but not coming from Corp IP. If they came from different IPs on the same day including Corp check to see if those non Corp are before and after business hours and exclude those. Anyone know of a good query to achieve this? Or maybe a tool that can extract and generate a report?Defender XDR: Tables not supported for table management
I am trying to extend the table retention of specific tables to allow them to flow to Sentinel Analytics but keep getting the message "This table is not supported for table management" in the Sentinel > Configuration > Tables page. The Sentinel workspace is connected in System > Settings > Microsoft Sentinel. I can see the table type is XDR in the list which seems to be the reason why it can't be managed. Any ideas why this table is not able to be managed.Monthly News-August 2026
Microsoft Defender Monthly news - August 2026 Edition This is our monthly "What's new" blog post, summarizing product updates and various new assets we released over the past month across our Defender products. In this edition, we are looking at all the goodness from July 2026. We are now including news related to Defender for Cloud in the Defender portal. For all other Defender for Cloud news, have a look at the dedicated Defender for Cloud Monthly News here. 🚀 New Virtual Ninja Show episode: Redefining identity security for the modern enterprise One policy engine to govern them all: Securing agentic AI with Microsoft Purview Building a modern detection pipeline with ContentOps Securing local AI agents with Microsoft Defender Microsoft Defender: Extending critical protection for emerging threats in Team Actionable threat insights (find all of them here) Email threat landscape: Q2 2026 trends and insights Enhancing AI security through global AI red teaming Least privilege for AI agents: Identity, access, and tool binding Microsoft Defender (Public Preview) Microsoft Defender now assesses posture risk for AI agents, including enterprise agents and local agents discovered on endpoint devices. Risk levels are based on active risk indicators, such as configuration, access, runtime activity, endpoint and user context, and active alerts. Security teams can use posture risk and recommendations to prioritize risky agents and improve agent security posture. For more information, see AI agent posture risk in Microsoft Defender. (Generally available) The Domain investigation page allows you to investigate an Active Directory domain. It shows Active Directory domain security, including domain properties, deployment health, identity summary, service account breakdown, sensitive entities, active recommendations, group policies, and trust relationships. For more information, see Investigate a domain . (Generally available) With a Microsoft Agent 365 license, Microsoft Defender provides discovery, security posture, threat detection and investigation, and real-time protection for the AI agents in your tenant. Onboarding includes enabling data collection, connecting the Microsoft 365 app connector, and connecting Copilot Studio for real-time protection of Copilot Studio agents. For more information, see Protect AI agents using Microsoft Defender. (Generally available) Improved access to Playbook Generator: Following the GA release of Playbook Generator May 31st, the team focused on streamlining the onboarding experience and reducing friction related to Security Copilot wallet provisioning. Playbook Generator remains included with Microsoft Sentinel and does not consume SCUs for generating, testing, or running playbooks, yet customer feedback highlighted friction around Security Copilot wallet provisioning and initial setup requirements. The team worked on simplifying access and reducing onboarding barriers so organizations can more quickly take advantage of AI-assisted playbook creation, testing, and automation capabilities. For all other Sentinel News, have a look at the "What's new in Microsoft Sentinel blog post - July edition" Identity Security (Generally available) Migration of Defender for Identity sensors from v2.x to v3.x is now generally available. For more information, see Migrate to Defender for Identity sensor v3.x. Migration readiness reasons on the Sensors page: When a server is marked Not ready for migration on the Sensors page, you can now hover over the status to see a tooltip that lists the specific reasons the server doesn't meet the migration prerequisites. For more information, see Troubleshoot "Not ready for migration" status. (Public Preview) Expanded SaaS app support in Password protection. The Password protection page now includes password risks from SaaS apps connected through Defender for Cloud Apps, in addition to Active Directory, Microsoft Entra ID, and Okta. SaaS apps that support SaaS Security Posture Management (SSPM), such as Salesforce and ServiceNow, appear on the Password Hygiene and Password Policies tabs. Each SaaS app requires a Defender for Cloud Apps app connector. For more information, see Investigate identity password protection. Automatic RPC auditing on domain controllers: Defender for Identity now automatically enables RPC auditing on domain controllers when you upgrade to sensor version 3.0.8 or later. You no longer need to apply a tag manually to enable RPC auditing. For more information, see Configure RPC auditing. Microsoft Defender Experts MDR General Availability of Microsoft Defender Experts MDR P2: Microsoft Defender Experts MDR (formerly Microsoft Defender Experts for XDR) is expanding with new third-party and multi-cloud coverage powered by Microsoft Sentinel, with the launch of Defender Experts MDR P2 service. Defender Experts MDR provides a 24/7 managed detection and response service that reduces noise, adds expert context, and drives action. In addition to the Microsoft Defender products, this new service supports key non-Microsoft sources across cloud (AWS), identity (Okta), email (Proofpoint), network (Palo Alto Networks, Cisco, Fortinet, ZScaler), and endpoint (CrowdStrike) that are ingested in Microsoft Sentinel, providing E2E visibility and protection for customers operating heterogenous environments. Defender Experts will continue expanding our scope to other non-Microsoft products to deliver on this promise. For more information, see the Microsoft Defender Experts MDR documentation. Microsoft Security Exposure Management / Defender Vulnerability Management (Private Preview) Codename MDASH - Agentic code scanner is now available in private preview in Microsoft Security Exposure Management. Codename MDASH uses a multi-model agentic AI system to detect code vulnerabilities with greater depth and accuracy than traditional static analysis. Security teams can run scans from Defender CLI or through a GitHub connector, review findings in the Defender portal, and use results to help prioritize code security risks. For more information, see Agentic code security overview. (Private Preview) Codename MDASH - MAI-Augmented scan profile private preview. The MAI-Augmented scan profile is now available in preview as part of Codename MDASH. The MAI-Augmented profile can be used when triggering a scan through the Defender CLI. It includes MAI-Cyber-1-Flash, a new cyber-specialized model that extends the current agentic scanner in addition to the existing required models. Security teams can choose this profile when triggering a scan from Defender CLI or continue using a scan profile based on the existing models. For more information, see Scan with a scan profile. OT data connectors in Microsoft Security Exposure Management: Microsoft Security Exposure Management now supports operational technology (OT) data connectors for Armis, Dragos, and Forescout. OT data connectors bring OT asset and vulnerability data from supported third-party OT platforms into the Defender portal. This helps security teams view OT devices alongside other assets, enrich device inventory with OT context, and investigate vulnerabilities across IT and OT environments. For more information, see OT data connectors. Microsoft Defender for Endpoint (Public Preview) AI agent runtime protection includes these enhancements: - Vendor-supported agent event interfaces now work with standard platform and engine update channels, so no Beta channel configuration is required. Agent-native event inspection now supports Codex CLI and the GitHub Copilot app. - Network inspection is now supported for agents that don't expose vendor-supported event interfaces, including OpenClaw and similar Node.js-based Claw agents. For more information, see AI agent runtime protection with Defender for Endpoint. (Generally available) Available from Defender for Endpoint on Linux version 101.26042.0011 and later. The Defender Deployment Tool for Linux simplifies deployment by combining installation, onboarding, upgrades, and uninstallation into a single workflow. The tool automates prerequisite validation, supports custom installation paths, enables deployment of specific Defender versions from preferred update channels, and works seamlessly in environments that use local repositories. In addition to a simplified deployment experience, customers can now gain complete visibility into deployment progress through Device Timeline integration, providing step-by-step installation, upgrade, and onboarding status, Advanced Hunting queries for fleet-wide deployment monitoring, and detailed error reporting, including deployment stage, status, exit code, and failure reason to simplify troubleshooting. These capabilities help administrators quickly identify deployment issues, track onboarding progress, and understand deployment outcomes across their Linux estate. Microsoft Defender for Office 365 Unified RBAC is the default permission model for new Defender for Office 365 Plan 2 organizations. Starting July 2026, new Defender for Office 365 Plan 2 organizations use the Microsoft Defender unified role-based access control (Unified RBAC) model by default. For more information, see Configure Unified RBAC for Defender for Office 365 and MC1246006. Microsoft 365 E3 now includes Microsoft Defender for Office 365 Plan 1. For more information about what's included in each plan, see Microsoft Defender for Office 365 Plan 1 vs. Plan 2 cheat sheet. Prompt injection protection: Defender for Office 365 now detects prompt injection attacks hidden in inbound email. For more information, see Prompt injection protection in Defender for Office 365.Sentinel - Defender XDR KQL Queries Library
Hello all, I’ve been building something over the past few weeks that I think the security community might find useful. https://goxdr.fyi is a searchable KQL query library for Microsoft Sentinel and Defender XDR. The name comes from a nickname my colleagues gave me (GoX) combined with XDR. I also picked up https://goxdr.fyi as a short and easy to remember domain for it. You can check it out here: https://goxdr.fyi The idea came from my own day to day work as someone working in IAM and SOC operations. I constantly find myself writing and refining KQL queries for threat hunting, detection engineering and incident investigation. Over time I realized I had a growing collection of queries that I kept going back to and I thought why not make these available to others? It currently has 117 queries covering identity security, BEC/AiTM detection, NTLM and LDAP attack hunting, OAuth governance, AI/Copilot security, Sentinel alert trending, SOC performance metrics and more. Some of these queries are ones I wrote from scratch based on real scenarios I encountered in production environments. Others are community queries I tested and validated in my own setup. Only the ones I found genuinely useful and that actually worked against real data made it in. Each query comes with a description explaining what it detects and why it matters, along with severity levels, platform tags (Sentinel, XDR or both) and a copy button so you can paste it directly into Advanced Hunting or use it as the basis for an Analytics Rule. The site is open source, hosted on GitHub Pages and licensed under CC BY 4.0. No sign-up, no paywall, no tracking. The source is available. I’ll keep adding queries as new scenarios come up. If there’s enough interest I’m also considering adding Cortex XQL queries for Palo Alto environments. Suggestions, feedback or ideas for new detections are always welcome. Feel free to reach out. Thanks
