If you’re reading this, you’re looking at a completely new Modern Security. Same articles, same URLs, same Microsoft security focus. But under the hood almost nothing is left of the old site.

For years this blog ran on WordPress. It worked, but every month I spent more time maintaining the platform than writing about Microsoft security. Plugin updates, a security plugin to protect the other plugins, a cache plugin to make it fast again, a cookie plugin to explain all the other plugins. At some point I asked myself the question I ask customers all the time: why is the attack surface this big for what it actually needs to do?

So I rebuilt it. Modern Security is now a static site built with Hugo and the Blowfish theme, hosted on Cloudflare Workers. In this post I explain why I made the move, how I migrated every article without breaking a single link, what I built on top of Blowfish, and what changed for you as a reader.

Why leave WordPress?

WordPress isn’t bad. It runs a huge part of the internet for good reasons. But for a blog like this one, the trade-offs had tipped the wrong way.

Over time the old site needed a long list of plugins: Rank Math Pro for SEO, Wordfence for security, LiteSpeed Cache for performance, Complianz for cookie consent, Google Tag Manager, reCAPTCHA for the contact form, and a newsletter plugin. Each of them is code that runs on every request, needs updates, and can have its own vulnerabilities.

For a security blog that felt wrong for three reasons:

• Attack surface: A login page, a database, PHP and a stack of plugins, all reachable from the internet, to serve articles that change a few times a month.
• Maintenance: Updates were never “just” updates. Something always needed checking afterwards.
• Privacy: The cookie policy listed cookies from WordPress, Wordfence, LiteSpeed, Google, Facebook, Twitter and LinkedIn. That’s a lot of third parties for reading an article about Defender XDR.

A static site removes most of that by design. There is no database to inject into, no login page to brute-force and no plugins to patch. The server only hands out files.

The new stack

Hugo turns Markdown files into plain HTML pages in seconds. Blowfish gives a modern, fast theme with dark mode, search and an accessibility panel. Cloudflare Workers builds the site from GitHub on every change and serves it from Cloudflare’s network. Pages are plain files; code only runs for the contact form.

One rule I set myself from day one: never edit the Blowfish theme files. Blowfish is a Git submodule, pinned to a fixed version, and everything that makes the site look like Modern Security lives in my own layouts and styles. Where I had to replace a Blowfish template, it’s documented, so I know exactly what to check when Blowfish releases a new version.

Migrating every article without breaking a link

The scariest part of any migration is SEO. Years of articles are indexed by Google, linked from LinkedIn posts and bookmarked by readers. If URLs change, all of that turns into 404 errors overnight.

So the migration started with an audit, not with a design. I exported everything from the WordPress REST API: posts, pages, categories, media, and the SEO data Rank Math generated for every page. Then a Python converter turned each WordPress article into a Hugo page bundle: one folder per article with the Markdown text and its images next to it.

A few things the converter had to get right:

1. Identical URLs: Every article, category and page keeps exactly the same address as on WordPress. One article even had a non-breaking hyphen (U+2011) in its URL, which Hugo silently strips. That one now has its URL set explicitly.
2. Identical SEO: Titles, meta descriptions and robots settings are copied exactly as Rank Math had them. A comparison script checks the old and new page headers side by side.
3. Tables: Many of my articles are full of tables with KQL queries and settings. The converter checked all 133 tables against the original. That’s how I found that a WordPress math plugin had quietly eaten the $ signs in a PowerShell command at some point.
4. Images: Every screenshot is converted to WebP, and Hugo now creates several sizes of each image, so a phone downloads a small version and a 4K screen a sharp one.
5. KQL highlighting: Hugo’s code highlighter doesn’t know KQL, so the site highlights KQL itself while building. No JavaScript needed in your browser.

The old cookie policy pages for different countries will point to one cookie policy, and the remaining old WordPress addresses get permanent redirects. Google sees the same pages, with the same titles, at the same addresses.

Building the frontend

Blowfish is a great starting point, but I wanted the site to stay recognisably Modern Security: the black top bar, the big logo, black section headings and the photo tiles on the homepage. So most of what you see is built on top of the theme:

• Homepage: a mosaic of featured articles, the Security, Identity and Compliance tiles, and every other article with pagination.
• Articles: a table of contents at the top, a featured posts and categories sidebar, a reading progress bar and code blocks with a copy button.
• Topic pages: a photo banner, an introduction per topic, related topics and the articles in that topic.
• Dark mode and accessibility: a dark-mode switch and Blowfish’s accessibility panel for text size, link underlines and a distraction-free reading mode.
• Sharing without trackers: share buttons for LinkedIn, X, Bluesky and email are plain links. Nothing from those networks loads until you click.
• Mobile: every page type was checked at phone size, so nothing scrolls sideways and every button is big enough to tap.

Privacy and security by design

This is the part I’m most happy with, because it’s where the old site felt most uncomfortable.

Nothing tracks you before you choose: The site uses Google Analytics and Microsoft Clarity to see which articles are read, but only after you allow it in the cookie banner. Before that choice, no Google or Microsoft script is loaded at all. Rejecting is exactly as easy as accepting, and advertising features are switched off in both tools. You can change your mind at any time via the Cookie settings button on the Cookie Policy, linked at the bottom of every page.

The contact form has no database behind it: Messages go through a small Cloudflare Worker that checks Cloudflare Turnstile on the server and sends the message by email through an EU mail provider. No form plugin, no stored submissions.

A security.txt file: If you find a vulnerability, /.well-known/security.txt tells you how to report it, following RFC 9116. Fitting for a security blog, and something the old site never had.

Fewer moving parts: There is no admin login to attack, no database to dump and no plugin to exploit. The most important thing to protect is now the GitHub account that publishes the site, so that’s where the security effort goes.

Writing new articles

Every article is now a Markdown file in a Git repository. I write in VS Code, screenshots go into the same folder as the article, and every change is version-controlled. If I make a mistake, I can roll back. If a reader spots an error, the history shows exactly what changed and when.

For quick fixes away from my laptop, the site is set up for Pages CMS, a simple editor in the browser that commits straight to the repository. When I push a change, Cloudflare builds and publishes the site automatically.

What I learned

1. Audit before you design: Exporting all URLs and SEO data first made every later decision easier. You can’t keep what you never wrote down.
2. Treat a theme like a dependency: Pin the version, don’t edit it, and keep a list of what you override. Upgrades become a checklist instead of a gamble.
3. Check the content, not just the pages: Automated checks on tables and images found problems that had been invisible on the old site for years.
4. Privacy is a design choice: Loading nothing before consent was easier to build from scratch than to bolt onto a plugin stack.
5. Static is a security feature: The safest login page is the one that doesn’t exist.

I’ll share real performance numbers (Lighthouse and Core Web Vitals) once the new site has been live for a few weeks. If you notice anything that looks broken or a link that no longer works, please let me know.

Sources

• Hugo documentation (Hugo)
• Blowfish documentation (Blowfish)
• Cloudflare Workers static assets (Cloudflare)
• Cloudflare Turnstile documentation (Cloudflare)
• Clarity Consent API (Microsoft Learn)
• RFC 9116: A File Format to Aid in Security Vulnerability Disclosure (RFC Editor)
• Pages CMS (Pages CMS)

Conclusion

Moving Modern Security from WordPress to Hugo and Blowfish wasn’t about chasing a new tool. It was about applying the same principles I write about here to my own site: reduce the attack surface, control what runs, and don’t collect more data than you need.

The result is a blog that’s faster to maintain, easier to secure and more respectful of your privacy, with every old link still working.

Same content. Same addresses. Far fewer moving parts.

On September 23, Microsoft announced the Integrated Security Operations Center, or ISOC, in Microsoft Defender. My LinkedIn feed filled up within the hour, and the first question I got was simple: “So is Sentinel dead?”

Short answer: no.

Longer answer: this is the most interesting change to Microsoft’s SOC story since Sentinel moved into the Defender portal, and it changes where many organisations will start. In this post I explain what ISOC is, who it is for, how it compares to Microsoft Sentinel and Defender XDR, and what I would check before using it.

What is ISOC in Microsoft Defender?

The key sentence is in Microsoft’s own FAQ: ISOC is not a new product. It is a benefit on top of Microsoft Defender Suite, Microsoft 365 E5 and E7 that brings SIEM capabilities from Microsoft Sentinel into the Defender portal.

In practice it does two big things:

1. It turns on SIEM features in Defender for organisations that never deployed Sentinel.
2. It uses the Defender data you already have, without separate ingestion, and extends retention from 30 to 90 days on November 15, 2026.

Until now, E5 gave you excellent XDR, but a SIEM meant a separate Sentinel purchase and project. That is the gap ISOC closes.

Microsoft frames the announcement around attackers: they use AI agents to automate at scale, and every handoff between separate protection and operations systems slows defenders down. Microsoft describes a stack of sensors and signals, context, models, a harness, agents and actuators, with ISOC as the foundation.

It’s worth separating the vision from what ships today. The agents come from Project Perception, introduced in July, which is a limited preview for a small, invitation-only group of customers, with its own consumption-based pricing. ISOC itself doesn’t require Perception. I see it as laying the shared data and workflow foundation that agents will need later, and I think it should be judged on what it delivers without them.

What you get on day one

Eligible tenants see these capabilities appear in the Defender portal without extra configuration:

• Case management. Incident cases and generic cases, with tasks, templates, SLA policies and activity history. No workspace needed.
• Workbooks. Dashboards built on advanced hunting queries, with example workbooks to get started.
• Enhanced automation rules.
• Natural-language playbook generation. Describe the automation you want, and the generator writes a Python playbook for you to review, test and activate.

The included data covers Defender for Endpoint, Office 365, Identity, Cloud Apps and Cloud, plus Entra ID Protection logs, and Azure Activity and Office 365 Activity logs through a connector. There is no minimum seat count.

What requires an ISOC workspace

When you need more than native Defender data, you create an ISOC workspace linked to an Azure subscription. That unlocks UEBA, Content hub, CI/CD from repositories, threat intelligence, and non-Microsoft data through more than 500 connectors. From October 1, that non-Microsoft data is billed at $2.40 per GB on a pay-as-you-go meter. Regional pricing may vary.

Two details in the documentation are easy to miss:

• Content hub is connector-only during the preview. If you install a solution, you get its data connectors, but not its analytics rules, hunting queries or workbooks. So budget time for building or porting detection content for every source you add. A connector without detections is just storage.
• UEBA is not part of the licence. Microsoft describes UEBA as an optional paid Sentinel capability that isn’t included with E5. It can analyse supported Defender tables without ingesting them first, which is a nice improvement, but its output is written to Log Analytics and those charges apply. If you want to know what UEBA brings, I covered the UEBA behaviors layer earlier.

One more observation: you create the ISOC workspace under Settings > Microsoft Sentinel > SIEM workspaces, and it requires the Microsoft Sentinel Contributor role. My reading is that this is the Sentinel foundation, packaged and licensed differently, rather than a new SIEM engine. Microsoft’s documentation doesn’t state what kind of resource you end up with but I’ll make a guidance on this soon.

Who is ISOC for?

Right now: organisations with Microsoft Defender Suite, Microsoft 365 E5 or E7 that do not have an active Microsoft Sentinel workspace. You need an Azure subscription if you want the workspace.

From November 15, 2026: existing Sentinel customers who meet the licensing criteria can choose to move to ISOC. Until then, Microsoft’s advice is clear: keep using Sentinel, and don’t disconnect a production workspace to qualify for the preview.

A note on Defender Suite: Microsoft’s documentation lists it as eligible, but the FAQ’s benefit section is written for E5 and E7. If you are on Defender Suite, check that ISOC actually shows up in your tenant, and get the retention and meter confirmed, before you plan around it.

ISOC vs Microsoft Sentinel vs Defender XDR

This is how I see the three side by side, based on what is documented today:

My take: Defender XDR remains the protection and detection engine. Sentinel remains the broad security data platform for organisations with many sources, mature detection content and long retention needs. ISOC is the new front door for E5 organisations that want SOC capabilities without first running a SIEM project.

The part I like most is retention. I have seen plenty of designs where Defender data went into Sentinel mainly to keep it longer than 30 days (apart from data lake). Paying to store Microsoft telemetry inside another Microsoft product never felt right. Ninety days included changes that discussion, and it fits the broader trend I wrote about in my post on lake-only ingestion for Defender XDR tables.

What about existing Sentinel customers?

My advice: evaluate per customer after November 15. There is no single right answer, because the outcome depends on the licence mix, the data sources and the detection content each environment has built. I’d look at five questions per environment:

1. Licensing. Is the tenant fully on E5 or E7, or a mix? Defender Suite needs written confirmation.
2. The E5 grant. Today, E5 includes a Sentinel data grant of up to 5 MB per user per day for eligible Microsoft data. Microsoft’s ISOC documentation doesn’t say whether that grant still applies once a workspace moves to ISOC. How much of your current ingestion does it cover, and what happens if it goes away?
3. Identity detections. Entra sign-in and audit logs aren’t on ISOC’s included list, and they’re core detection data for most SOCs. Defender has its own EntraIdSignInEvents table for interactive and non-interactive sign-ins, and the UEBA documentation even maps it as the “Signin Logs” source. But its schema differs from SigninLogs; conditional access status, for example, is a numeric code instead of text. How many of your analytics rules depend on SigninLogs, and what would porting them cost?
4. Retention-only ingestion. Which Defender tables do you ingest mainly to keep them longer than 30 days? Those are where ISOC’s 90 days pays off.
5. Third-party sources. What would they cost on the $2.40 meter compared to your current rate, and which of them have detection content that Content hub won’t install for you?

Two things Microsoft hasn’t documented yet will also weigh in: what Microsoft data outside the included list costs under ISOC (the billing page only says additional ingestion charges might apply), and what happens to history, retention settings and content when an existing Sentinel workspace moves. Keep in mind that March 31, 2027 is when Sentinel leaves the Azure portal, whether you move to ISOC or not.

Multi-tenant and MSSP considerations

For anyone managing multiple tenants, the ISOC documentation is still thin:

• Creating the workspace requires Security Administrator in Entra ID, plus Owner, or User Access Administrator and Sentinel Contributor, on the Azure subscription. Organisations should think carefully before handing that level of access to a third party.
• In the Defender multitenant portal, GDAP only covers Defender data. Sentinel data requires Entra B2B, and cross-tenant Sentinel queries still require Azure Lighthouse.
• Case management is available in the multitenant portal, but I haven’t found documentation on ISOC workspaces, the benefit or generated playbooks in multi-tenant management.

Limitations and open questions

• It’s a preview. Capabilities and availability can change.
• Identity logs. Entra sign-in and audit logs aren’t on the included list, their cost under ISOC isn’t documented, and EntraIdSignInEvents has a different schema than SigninLogs.
• The E5 grant. ISOC documentation doesn’t address whether the E5 Sentinel data grant still applies after moving.
• Content hub installs data connectors only during the preview.
• UEBA is an optional paid capability, and its output incurs Log Analytics charges.
• Playbook generator limits. Python only, no external libraries, no playbook nesting, up to 100 playbooks per tenant, 5,000 lines per playbook, 10 minutes maximum runtime and 8 million AI tokens per day per tenant. Generated code must be reviewed manually.
• Enhanced alert trigger rules don’t support priority ordering, execute one action per rule, and can only run generated playbooks or update alerts.
• Multi-tenant guidance for ISOC is missing.

How I would get started

If you’re eligible and don’t run Sentinel, here’s the order I’d follow:

1. Sort out permissions first. Automation uses Unified RBAC, with separate permissions for automation admin, rules, integrations and playbooks. Decide who can create and who can execute before anyone starts experimenting.
2. Configure integration profiles. Generated playbooks can only call Microsoft Graph and Azure Resource Manager once those profiles exist, so set them up with least-privilege access from the start.
3. Explore the example workbooks. They’re a quick way to see what your Defender data looks like as dashboards before you build your own.
4. Treat generated playbooks as code. Review, test and put them under change control like any other automation. I wrote about the Sentinel AI playbook generator before, and the same rule applies: easy to create should never mean easy to deploy badly.
5. Add a workspace only with a plan. For each extra source, know the cost and who will write its detections.

I’ll test ISOC hands-on in a lab tenant and follow up with screenshots and findings. If you’re testing it too, I’d love to hear what you run into.

Sources

• Reimagining the SOC for the agentic era in Microsoft Defender (Microsoft Security Blog)
• Integrated Security Operations Center in Microsoft Defender (Microsoft Tech Community, incl. FAQ)
• ISOC in Microsoft Defender overview (Microsoft Learn)
• Data ingestion and billing for ISOC (Microsoft Learn)
• Create an ISOC workspace (Microsoft Learn)
• Use Content hub with ISOC (Microsoft Learn)
• Connect data sources to UEBA with Microsoft 365 E5 (Microsoft Learn)
• Automation with ISOC (Microsoft Learn)
• Create and manage workbooks with ISOC (Microsoft Learn)
• Case management in the Microsoft Defender portal (Microsoft Learn)
• EntraIdSignInEvents table (Microsoft Learn)
• Set up Microsoft Defender multitenant management (Microsoft Learn)
• What is Project Perception? (Microsoft Learn)
• What’s new for Microsoft’s unified security operations (Microsoft Learn)

Conclusion

ISOC is not the end of Sentinel. It is a new starting point. For E5 and E7 organisations without a SIEM, it removes the biggest barrier: they get case management, workbooks, automation and 90 days of Defender data without a separate purchase or project. That alone makes it worth switching on.

For existing Sentinel customers, the picture is less simple. The benefits are real, but so are the open questions around the E5 grant, identity logs, detection content and migration. That is why I would evaluate per customer after November 15, not move by default.

The bigger shift is where the value of a SOC sits. When the platform comes with the licence, the difference is made by good detections, well-governed automation and people who know what to do with an alert. ISOC makes the platform easier. It doesn’t make security operations easier.

I have been through the setup a few times now, both in a lab tenant and in a production Defender portal, and this post walks through the whole process end to end: what the feature is, what changed in August 2026, every prerequisite, the full integration profile setup, and a complete demo where I build a read-only VirusTotal URL enrichment playbook from an empty tenant to a live automation rule.

What is the playbook generator?

The playbook generator is a SOAR authoring experience built on Cline, an AI coding agent hosted inside an embedded VS Code environment in the Defender portal. Instead of dragging connectors around a Logic Apps canvas, you describe the automation logic in a chat interface, and the generator produces a validated, code-based playbook in Python, complete with:

• The complete playbook code
• Automatically generated tests, run against a real alert you provide
• Documentation and a visual flow diagram
• Entity and data mapping based on the alert schema

Generated playbooks accept alert data as input and can call out to Microsoft Graph, Azure Resource Manager, or any third-party API you configure through an integration profile. You do not need prior coding experience, though it helps to be comfortable with concepts like VS Code and Entra ID app registrations, since you will touch both.

Does it cost SCU?

No. As of the August 2026 documentation update, Microsoft states it plainly: the playbook generator does not require a separate Microsoft Security Copilot license or Security Compute Units. This used to be more confusing than it needed to be. Earlier in 2026, the feature technically did not bill SCUs, but your tenant still needed Security Copilot enabled with capacity provisioned as a prerequisite, a distinction that tripped up a lot of people, myself included the first time I set this up.

That prerequisite is gone now. There is no dedicated Security Copilot workspace to provision, no capacity to configure, no data sharing sliders to set. If your tenant has a Sentinel workspace onboarded to the Defender portal, you meet the environment requirement, full stop.

What changed in August 2026

Microsoft published an update on the Sentinel blog and updated the official documentation on August 7, 2026, confirming that Security Copilot enablement is no longer required to use the playbook generator. The older setup path, provisioning a dedicated Security Copilot workspace purely as a technical gate, has been removed from the documentation entirely, not just deprioritized. The feature is now available to all Microsoft Sentinel customers in the Defender portal out of the box, with no Security Copilot dependency and no additional cost.

The required permissions also simplified as part of this change. The older RBAC requirement (Detection tuning manage, plus Security Copilot read) has been replaced with a single Automation permission, covered in the prerequisites below.

If you went through the old Security Copilot workspace setup before this update, nothing breaks, your existing configuration keeps working. If you never got around to trying the feature because provisioning Security Copilot capacity felt like overkill just to test it, that barrier is gone. The steps below reflect the current, simplified setup.

Prerequisites at a glance

Everything you need before you open the playbook generator for the first time, in one table.

One operational note that is easy to miss: RBAC assignments can take up to two hours to propagate. If you are demoing this to a customer or a stakeholder, assign the permissions the day before, not five minutes before the call.

Step 1: Register an Entra ID app for Graph access

Integration profiles are what let a generated playbook actually call out to an API. Almost every playbook touches Microsoft Graph at minimum (to update incidents, disable accounts, send notifications), so this is where you start regardless of what the rest of the playbook does.

1. Sign in to the Azure portal and go to Microsoft Entra ID > Manage > App registrations.

2. Select New registration.

3. Give it a clear name, for example pb-generator-graph-integration, so it is recognizable later when you are auditing app registrations. Leave the default account type and redirect URI settings unless you have a specific reason to change them.

4. Select Register.
5. On the app’s Overview page, copy two values and store them somewhere safe for the next step:
   • Application (client) ID
   • Directory (tenant) ID
6. Go to Manage > Certificates & secrets > Client secrets.
7. Select New client secret, give it a descriptive name (include the expiration date in the name, it saves you a lookup later) and an expiration period, then select Add
8. Immediately copy the secret Value, not the Secret ID. You cannot retrieve the value again once you leave the page. If you lose it, you will need to generate a new secret.

9. While you are in the app registration, go to API permissions and add the Microsoft Graph application permissions your playbook will need. At minimum, add SecurityAlert.Read.All. If your playbook will disable accounts or send notifications, also add the relevant Graph permissions for those actions (User.ReadWrite.All, Mail.Send, and so on), then select Grant admin consent.

Step 2: Create the integration profile

With the app registration in place, connect it to Sentinel as an integration profile.

1. In the Defender portal, go to Microsoft Sentinel > Configuration > Automation
2. Select the Integration Profiles tab

3. Select Create. This opens the wizard on the Provider step
4. Under Select a provider, leave Predefined provider integrations selected and search for or scroll to Microsoft Graph, marked as Featured in the list. Select it, then select Next.

5. Fill in the fields below:

6. Select Next to reach the Summary step, review the details, and select Create

If your playbook needs to reach beyond Graph, for example a ticketing system, a chat platform, or a threat intel enrichment API, check the predefined provider list first, plenty of common services (AbuseIPDB, AlienVault OTX, and more) are already in there and only ask for a name and credentials, no base URL or auth method to configure.

If you ever need a service that is not in the predefined list, switch to Create custom integration instead, that is where you would manually enter a base URL and pick an authentication method from scratch.

Repeat this same wizard for each service before you start generating the playbook. One thing worth planning for either way: you cannot change the API URL or authentication method after a profile is created, only the name and description, so pick the right provider (or double-check a custom base URL) before you finish the wizard.

Step 3: Start the playbook generator

1. In the Defender portal, go to Microsoft Sentinel > Configuration > Automation > Playbooks
2. Select Create > Playbook Generator
3. Give the playbook a clear, descriptive name. I use a naming convention like pb-<trigger>-<action>, for example pb-phishing-disable-account, so the purpose is obvious later in a list of dozens of playbooks

4. Select Continue to continue

An embedded Visual Studio Code environment opens inside the Defender portal, with Cline ready in the chat pane. This is the whole authoring experience, you never leave the browser tab.

Step 4: Work the plan in Plan mode

The session always starts in Plan mode. This is the most important step to get right, a vague prompt produces a vague plan, and you end up going back and forth far more than necessary.

1. In the chat interface, describe your playbook requirements in one message. Be explicit about four things:

   • What data to process: which alert type, which entities on it
   • What actions to perform: the actual response steps
   • What conditions to evaluate: branching logic, if any
   • Expected outcomes: what “done” looks like
     I use just a random simple example prompt to the generation in my example showcase: “Create a playbook that triggers on phishing alerts. Extract the sender email address. Check if the user exists in our directory, and if so, temporarily disable their account and notify the security team.”

2. If the generator needs to fetch external API documentation to write accurate code, it asks for approval first. Approve the request, this is how it learns the correct Graph or third-party API call shape rather than guessing.

3. The generator analyzes your prompt and does one or more of the following:
   • Asks clarifying questions if something is ambiguous
   • Requests API documentation if it cannot resolve the API shape from a web search
   • Flags missing integration profiles
   • Produces a preliminary plan and a visual flow diagram

4. If it flags a missing integration profile:
   1. Select Save and exit the VS Code environment. This preserves your conversation so far
   2. Go create the missing profile under the Integration Profiles tab, exactly as in step 2
   3. Return to the playbook and continue where you left off
5. Review the plan and flow diagram carefully. This is your last checkpoint before any code gets written. If something is off, describe the change in the chat rather than editing anything manually, the generator revises the plan for you.
6. When you are satisfied, follow the on-screen instruction to switch to Act mode

Step 5: Generate the code in Act mode

1. After switching to Act mode, the generator delivers:
   • The complete playbook code, in Python
   • Code validation
   • Comprehensive documentation, including a visual flow diagram and a plain-language description of what the playbook does

4. It then asks for a real Alert ID (get the alert ID from advanced hunting for example – not the Sentinel/XDR alert ID from the portal) to test against. Use an actual alert from your environment, ideally a low-impact one the first time through. Before it runs the test, the generator outlines exactly what changes it is about to apply to your environment and asks for your approval. Read this carefully if the playbook has side effects like disabling an account or blocking an IAM user, this is your chance to catch a misunderstanding before it touches anything real.

5. The generator may request approval at intermediate steps of code generation. To skip repeated approval prompts, select the Edit checkbox under Auto-approve. I leave auto-approve off for the first run of any new playbook. Once I trust its behavior on a given automation pattern, I turn it on for iteration speed.

Step 6: Validate and save

1. Manually review the generated code and documentation. The generator does not run automatic code validation beyond the test you just performed, correctness is on you.

2. To preview the generated documentation in Markdown format, press Ctrl+Shift+V on Windows or Linux, Cmd+Shift+V on macOS.

3. Select Save at the top left of the editor. One easy mistake here: selecting Save inside the chat only saves the current conversational step and confirms your approval for it, it does not save the entire playbook. Use the Save button in the editor itself.

4. The playbook is created in a disabled state by default. Close the editor when you are done.

Step 7: Enable the playbook

1. On the Automation page, go to the Active Playbooks tab
2. Find your newly created playbook in the list
3. Switch its status to Activate

Nothing runs automatically yet, even after activation, until you connect it to a trigger in the next step.

Step 8: Create the enhanced alert trigger

1. Go to the Automation Rules tab
2. Select Create to define a new rule using the enhanced trigger

3. Configure the trigger:

4. Select Save.

Enhanced Alert Trigger rules run at the tenant level and can cover multiple workspaces and alert sources in a single rule, a meaningful step up from the old alert-triggered playbook model inside analytics rules. These rules live in a separate Automation Rules table from Standard Alert Trigger rules, there is currently no automatic migration between the two, so if you are moving an existing use case over, you rebuild the trigger logic here rather than porting it.

Step 9: Monitor execution

1. Open the incident that contains the relevant alert
2. Select the Activities tab
3. Find the row labeled run playbook to see execution status and detail

One gap worth flagging if you build monitoring dashboards: automation rule run results for generated playbooks show up in the incident Activities tab, but are not written to the Sentinel Health Table. If your existing playbook health reporting depends on that table, generated playbooks will not appear there, and you will want to track them separately or via the incident activity feed instead.

Demo: building a VirusTotal URL enrichment playbook end to end

To make the steps above concrete, here is the full run I did in my lab tenant, from an empty Automation tab to a live rule enriching alerts with VirusTotal data. This is a good first playbook for anyone trying the generator for the first time: it is read-only, has no side effects on identities or devices, and it is genuinely one of the most common SOC enrichment tasks there is, so the value is obvious the moment you see it work.

Scenario: when an alert contains a URL entity, look that URL up on VirusTotal and add the verdict as a comment on the incident, so an analyst gets threat context without leaving Sentinel.

Prerequisites specific to this playbook: a VirusTotal API key (the free public API tier is enough for testing, get one from your VirusTotal account under API Key) and a second integration profile for VirusTotal, in addition to the Graph profile from step 2.

Creating the VirusTotal integration profile:

VirusTotal is one of the predefined providers in the wizard, so this is the fastest profile you will set up in this whole guide, just a name and an API key, no base URL or auth method to configure.

1. In the Defender portal, go to Microsoft Sentinel > Configuration > Automation > Integration Profiles > Create
2. On the Provider step, search for VirusTotal in the predefined provider list, select it, and select Next.

3. On the Name and authentication step, fill in:

4. Select Next, review the Summary step, and select Create.

Because VirusTotal is predefined, Sentinel already knows the base URL and how to authenticate against it, you only supply the credential. This is worth knowing before you set up any other third-party service: check the predefined list first, since a growing number of common threat intel and enrichment providers only need a name and an API key rather than the full custom integration flow.

Name and start: I created a new playbook named pb-url-enrichment-virustotal and selected Continue to open the VS Code environment.

The Plan mode prompt:

“Create a playbook that triggers on alerts containing a URL entity. Look up the URL using the VirusTotal integration and retrieve the analysis stats, including malicious and suspicious detection counts. Add a comment to the related incident summarizing the VirusTotal verdict, including the detection counts and a link to the full VirusTotal report.”

What came back: The generator confirmed it found the VirusTotal integration profile and asked one clarifying question, whether to submit the URL for a fresh scan if VirusTotal had no existing analysis on file, or only report on existing data. I chose to check existing analysis first and only trigger a new scan if nothing was on file, since that keeps the playbook fast for URLs VirusTotal already knows about. It then produced a flow diagram: alert trigger, extract URL entity, VirusTotal lookup, conditional branch on analysis availability, incident comment action.

Reviewing the plan: The proposed flow matched what I asked for, so no revisions needed. I switched to Act mode.

Act mode and testing: The generator produced the Python code, ran its own validation pass, and generated documentation with the same flow diagram rendered from the actual code path. It then asked for an Alert ID. I pointed it at a real alert in my lab workspace that had a URL entity attached. Before executing, it listed the exact change it was about to make, posting one incident comment with the VirusTotal verdict, and asked for approval. Since this playbook has no destructive side effects, I approved without hesitation.

Result: The test run queried VirusTotal, retrieved the detection stats, and posted a comment on the incident with the malicious and suspicious counts plus a link to the full report. The generator confirmed the test passed. I reviewed the generated Python briefly (the VirusTotal API call, the header-based authentication, the comment formatting) before moving on.

Save and enable: I saved the playbook from the editor’s Save button (not the chat), which left it in a disabled state as expected. I then went to Active Playbooks and switched it to Activate.

The automation rule: In Automation Rules, I created a new rule with the enhanced trigger: condition set to alert entities contains a URL type, workspace scoped to my lab workspace, action set to Run Playbook targeting pb-url-enrichment-virustotal.

Live verification: I triggered a new test alert containing a known URL entity and confirmed in the incident’s Activities tab that the run playbook entry appeared with a successful status, and the VirusTotal comment was visible on the incident.

Total time from opening the Automation tab to a live, working rule: around 15 minutes, most of which was creating the VirusTotal API key and the integration profile. If you already have the Graph profile from earlier in this guide, adding a second read-only integration like this one is fast.

More example prompts to try

A few prompts that map well to common SOC automation requests, beyond the VirusTotal example above:

• “Create a playbook that triggers on phishing alerts, extracts the sender email address, checks if the user exists in our directory, and if so, temporarily disables their account and notifies the security team.”
• “Create a playbook that blocks an AWS IAM user, assigns the alert to John, and adds a remediation comment when a high severity alert includes an IAM user entity.”
• “Create a playbook that triggers on impossible travel alerts, extracts the affected user, revokes their active sign-in sessions via Graph, and posts a comment with the two sign-in locations and timestamps involved.”
• “Create a playbook that triggers on malware alerts with a device entity, isolates the device, and notifies the on-call channel with the device name, alert severity, and a link to the incident.”

The pattern that works best is the same across all of them: name the trigger condition, the entity to act on, the action to take, and how to record what happened. The more precisely you name the entity field (sender email, device name, IAM user), the fewer clarifying questions you get back. Note that the phishing, IAM block, and device isolation examples above all involve a real side effect, unlike the VirusTotal demo, so test those against a low-impact alert first and review the approval prompt in Act mode carefully before confirming.

Limitations to know before you build

Worth reading before you commit a production use case to this feature:

• Language: only Python is supported for playbook authoring
• Input: playbooks currently accept alerts as the only input type, no scheduled or manual triggers yet
• Editing: one user can edit a given playbook at a time, though different users can work on different playbooks simultaneously
• External libraries: not currently supported
• Code validation: no automatic validation beyond the test run you perform, review manually
• Scale limits per tenant: up to 100 playbooks, up to 500 integrations, up to 500 active automation rules
• Playbook size: up to 5,000 lines per playbook
• Runtime: 10 minutes maximum per execution
• AI interactions: 8M tokens per day per tenant
• Playbook nesting: not supported. A generated playbook cannot invoke another playbook, so orchestration across multiple playbooks needs a different pattern for now
• Graph and ARM integrations: not enabled by default, you have to create them manually even though they are the most common target
• Enhanced Alert Trigger rules: no priority ordering or expiration dates yet, and only one action per rule

None of these are dealbreakers for typical detection-to-response automation, but the 10-minute runtime and single-action-per-rule limits are worth designing around if you are used to building more complex multi-step Logic Apps.

Why this matters for MSSPs and MDR providers

For a multi-tenant MDR operation, the interesting part of this feature is not that it writes code, it is that it lowers the skill floor for building tenant-specific response automation without pulling in a developer every time. A L2 analyst who can clearly describe a response workflow can now get a working, tested playbook without touching Logic Apps designer or writing Python from scratch.

The August 2026 change matters here specifically because it removes a real adoption barrier: provisioning Security Copilot capacity purely to unlock an automation feature was a hard sell across a customer base where Copilot adoption timelines vary a lot. With that dependency gone, this becomes something you can realistically standardize as part of an automation intake process rather than a feature that only shows up in tenants that already invested in Security Copilot.

The generated documentation and flow diagrams are also worth calling out for anyone running a service with change management requirements. Having an auto-generated description and visual flow per playbook makes it much easier to keep an automation runbook current without a separate manual documentation pass every time something changes.

Resources

Microsoft documentation

• Generate playbooks using AI in Microsoft Sentinel
• Create and manage Microsoft Sentinel playbooks
• Automate and run Microsoft Sentinel playbooks

Tech Community blogs

• Introducing the next generation of SOC automation: Sentinel playbook generator, original announcement, June 2026
• AI-powered playbook generator, now available to more customers, Security Copilot requirement removed, August 2026

Final thoughts

The playbook generator is one of those features where the interesting part is not the AI, it is what the AI removes from your path: the Logic Apps designer, the connector hunting, the JSON debugging that used to gatekeep SOAR maturity behind whoever on the team happened to know Logic Apps well. Combined with the August 2026 change dropping the Security Copilot dependency, there is very little reason left not to try this in a lab tenant this week.

Start small. Pick one repetitive triage action your analysts do by hand today, describe it precisely in Plan mode, and see what comes out the other side. The limitations around runtime and single actions per rule mean this fits enrichment and single-step response actions best right now, not full incident orchestration, but that is exactly where most automation backlogs live anyway.

Got questions about setting this up in a multi-tenant MDR environment, or ran into something not covered here? Leave a comment or reach out via the contact page.

Bring Your Own Vulnerable Driver, or BYOVD, is not new. But what is new is how reliably it shows up and how professionally it is being packaged and distributed. This post covers what has changed, why your current setup probably has a gap even with tamper protection enabled, and what to actually do about it step by step on the Microsoft stack.

What changed recently

BYOVD used to require real operational knowledge. You needed to find a suitable driver, understand its IOCTL interface, write code to interact with it, and test it against the target EDR. That kept the barrier high enough that most RaaS affiliates skipped it.

That is no longer the case.

In June 2026, ESET published a detailed investigation into a RaaS operation called Gentlemen. The short version: Gentlemen does not leave EDR evasion up to its affiliates. The operator centrally develops and maintains its own EDR killer framework, named GentleKiller by ESET, and ships it to every affiliate as part of the onboarding package. The framework has at least eight variants, targets more than 400 processes across 48 security products, and is designed to allow fast driver swaps when a new proof-of-concept goes public.

ESET confirmed the gang can operationalise a newly disclosed BYOVD PoC within days of it going public. The affiliate package also bundles three externally sourced tools: HexKiller, ThrottleBlood, and HavocKiller. By the time the ESET report was published, separate ransomware tracking data had linked the group to 478 victims across 66 countries.

A separate ESET analysis from earlier in 2026 counted 54 distinct EDR killer tools abusing 35 separately signed vulnerable drivers. Attackers only need one that still works. Defenders need to cover all 35.

Also worth flagging: in February 2026 Huntress documented an intrusion where attackers loaded a revoked EnCase forensic driver from 2006, still loadable due to a legacy exception from 2015. Once running, it called its termination routine every second against 59 hardcoded security processes. Any service that tried to restart was killed immediately. The machine was completely blind before encryption started.

On June 30, 2026, Marcus Hutchins (MalwareTech) published a technical analysis via Expel documenting a zero-day used by the Gentlemen group in an April intrusion: ktapi.sys, a Kontron industrial driver that was not present on any public blocklist at time of publication. The relevant defender takeaway is that ktapi.sys was a legacy cross-signed driver.

Starting with Windows 10 1607, Microsoft tightened kernel-mode driver signing requirements so newly signed drivers generally had to go through Microsoft’s Hardware Dev Center signing process. Previously signed legacy drivers were grandfathered in. Starting from Windows 11 25H2 (kernel build 10.0.26100.32690+), that grandfathering ended. Millions of old, unmaintained drivers that were still loadable on earlier versions are now blocked by default, and ktapi.sys is one of them. If your fleet is already on 25H2, that is a free win with no configuration needed. If it is not, it is worth factoring into your upgrade planning.

That is where we are in 2026. EDR evasion via BYOVD is a feature in an affiliate kit, and the drivers being used are sometimes zero-days that no blocklist covers.

How BYOVD actually works

By the time BYOVD runs, the attacker already has local admin on the machine. This is post-compromise activity, not initial access. They have usually been in the environment for some time, done their reconnaissance, identified what EDR is running, and are now preparing for the final stage before encryption.

The sequence from that point:

1. The attacker drops a legitimate, signed kernel driver to disk. Often an old anti-cheat driver, an OEM hardware monitoring tool, or a legacy security product component. Not malicious by design, just old and unpatched.
2. Windows loads it without objection. The signature is valid, the certificate came from a real vendor. The OS trusts it.
3. The attacker sends crafted IOCTL requests to the loaded driver. Depending on the flaw, this gives ring 0 capability to terminate arbitrary processes, remove kernel callbacks, suppress ETW providers, or patch memory in ways that blind the sensor entirely.
4. The EDR or AV agent is killed from kernel mode. No alert fires. The thing that would raise the alarm is the thing that just got taken out.
5. With the security tooling blind or dead, encryption starts. The window between EDR kill and encryption is frequently under an hour.

To make this concrete, look at the actual cases this post is about. The Gentlemen operators specifically choose drivers that are not on any public blocklist. Their GentleKiller variants use custom rootkits and obscure anti-cheat drivers that most defenders have never heard of. When the Expel team investigated the April 2026 intrusion, the attacker used ktapi.sys, a Kontron industrial driver not present on any public blocklist at the time. Gentlemen can operationalise a newly disclosed driver proof-of-concept within days of it going public.

The attacker does not need a well-known, already-blocked driver. They need one driver that works and is not blocked yet. This is why HVCI and App Control are in this post: they do not depend on knowing a driver is bad in advance.

Why tamper protection does not help here

Tamper protection is designed to prevent unauthorized changes to Defender configuration and common attempts to impair its services and sensor. It is not a driver admission or kernel code-integrity control.

If an attacker succeeds in loading and exploiting a vulnerable kernel driver, the attack has crossed a trust boundary that requires controls such as ASR, the vulnerable driver blocklist, HVCI, and App Control. A kernel driver does not request permission to kill a process. It calls a kernel function directly.

Prerequisites: BYOVD needs local admin first

Loading a kernel driver via sc.exe create type= kernel requires SeLoadDriverPrivilege, which by default only local administrators hold. This is a post-compromise technique. The attacker has already obtained elevated access before BYOVD runs.

Two things follow from this:

First, local admin hygiene is a meaningful pre-control: remove admin rights from standard users, enforce LAPS, and limit admin role assignments. This raises the cost of reaching BYOVD without making it impossible. Credential Guard protects LSASS credentials from being dumped, limiting the attacker’s ability to use credential theft to move laterally and reach admin on other systems. It is covered in Step 2.

Second, if you detect an EDR kill event, assume the attacker has local admin at minimum. Treat it as a pre-encryption signal, not an isolated incident.

What drivers are actually being abused: LOLDrivers.io

LOLDrivers.io is the community-maintained catalogue of living-off-the-land drivers, signed drivers with known vulnerabilities or malicious uses. Searching by driver name or hash shows what CVEs are linked, what capabilities the flaw exposes, and whether a driver appears in known toolkits. It is a useful baseline check before deployment.

The caveat: sophisticated operators like Gentlemen specifically pick drivers not yet on any blocklist. ktapi.sys was not on LOLDrivers.io at time of discovery. GentleKiller’s variants use obscure anti-cheat and hardware drivers that ESET documented after the fact. The real threat is what is not on the list yet, which is why HVCI and App Control matter. They do not depend on knowing a driver is bad in advance.

Drivers appearing in 2025 and 2026 BYOVD toolkits include Iobitunlocker.sys (IObit Unlocker), revoked forensic drivers from Guidance Software (EnCase), and GentleKiller variants using Safetica ProcessMonitor and Zemana WatchDog drivers. The Microsoft vulnerable driver blocklist is largely derived from LOLDrivers plus Microsoft’s own research.

What we are going to deploy

Four controls, each intercepting at a different point in the attack chain. None is sufficient alone. They cover different stages and different threat scenarios.

Step 1: Enable the ASR rule that blocks the driver from landing on disk

Important for servers: ASR rules only enforce when Microsoft Defender Antivirus is running in Active mode. If a server has a third-party AV product installed and Defender is running in Passive or EDR-only mode, this rule will not block anything. Verify Defender is in Active mode before relying on this step, especially on Windows Servers where third-party AV is common.

The rule you need is Block abuse of exploited vulnerable signed drivers. GUID: 56a863a9-875e-4185-98a7-b882c64b5ce5.

This is one of three ASR rules Microsoft explicitly recommends enabling directly in Block mode without an audit period. The others are the LSASS credential theft rule and WMI persistence. The vulnerable driver rule has a low false positive rate in practice.

One thing to understand clearly before deploying: this rule prevents an application from writing a vulnerable signed driver to disk. It does not prevent a driver that is already sitting on the system from loading. Those are two separate problems and need two separate controls. This step closes the delivery problem. Steps 3 and 4 address the driver-load problem. Step 2 hardens what an exploited driver can do once it has loaded.

Deploy via Intune:

1. Open the Intune admin center (intune.microsoft.com) and sign in with Endpoint Security Manager rights or equivalent.
2. Navigate to Endpoint security > Attack surface reduction.
3. Click Create Policy.

4. Under Platform select Windows 10, Windows 11, and Windows Server. Under Profile select Attack Surface Reduction Rules. Click Create.
5. Give the policy a clear name, for example BL-WIN-USR-P-ASR-Attack Surface Reduction rules-v1.0. Click Next.
6. On the Configuration settings page, find Block abuse of exploited vulnerable signed drivers (and all the others if you haven’t configured it yet) and Block.

7. Click Next through Scope tags. On Assignments, target your device groups. This rule does not typically generate helpdesk noise, so I would not scope it narrowly for a first deployment.
8. Review and Create.

Verify with Advanced Hunting after deployment:

Give it 24 to 48 hours, then run:

DeviceEvents
| where Timestamp > ago(48h)
| where ActionType == "AsrVulnerableSignedDriverBlocked"
| project Timestamp, DeviceName, FileName, FolderPath,
    InitiatingProcessFileName, SHA256
| order by Timestamp desc

If this returns results, review each one. If something legitimate in your environment is being blocked, that is the exception to investigate rather than a reason to disable the rule.

You can also review ASR activity in the Defender portal under Reports > Attack surface reduction rules. The effective policies can also be checked here:

Step 2: Verify and enforce HVCI across your fleet

HVCI is a kernel hardening control, not a driver admission control. That distinction matters. A legitimately signed vulnerable driver, including ktapi.sys, satisfies HVCI’s code integrity requirements and can still load. What HVCI does is remove and constrain the exploit primitives that a driver would use to cause harm: it prevents unvalidated executable kernel code, restricts certain memory operations, and protects the code-integrity enforcement mechanism itself. It also enforces the built-in Microsoft vulnerable driver blocklist automatically as a side effect.

Concretely: in the Hutchins/Expel case, kCFG (which HVCI enables) would have stopped the shellcode execution step even after ktapi.sys loaded, because kCFG prevents kernel-mode indirect calls from targeting anything outside a list of valid approved entry points. Expel notes explicitly that a different exploit technique against the same driver could have worked around that. HVCI is not a guarantee. A sufficiently restrictive App Control policy is.

The value of HVCI for BYOVD defence is: it removes or constrains the exploitation chain, it enforces the blocklist automatically, and it makes writing reliable kernel exploits significantly harder. For most RaaS affiliates using off-the-shelf EDR killer toolkits, that is often enough. Against a determined operator writing custom exploits, it is one layer of several.

Most new Windows 11 hardware ships with HVCI enabled by default. The problem I keep running into in practice is that it gets silently disabled during imaging when a hardware vendor supplies a driver that is not HVCI-compatible, and nobody notices afterward.

One additional thing worth knowing: enabling HVCI also activates Kernel Control Flow Guard (kCFG). kCFG enforces that kernel-mode indirect calls can only target valid, approved function entry points. This is specifically what would have stopped the Hutchins/Expel exploit at its shellcode execution step, even if everything else in the chain had succeeded. It is not the headline feature of HVCI but it is part of why enabling memory integrity raises the bar beyond just blocklist enforcement.

Verify on a device via Windows Security:

Open Windows Security > Device Security > Core isolation. Memory Integrity should show as On. If the toggle is greyed out and reads “Memory integrity is off. Your device may be vulnerable”, something is blocking it.

Enable HVCI via Intune (Settings Catalog):

1. Open the Intune admin center and navigate to Devices > Configuration > Create > New Policy.
2. Platform: Windows 10 and later. Profile type: Settings Catalog. Click Create.
3. Give the policy a name, for example BL-WIN-USR-P-DEVCONF-MDM Security Baseline version number-SC-DEV-Virtualization Based Technology-v1.0.
4. Click Add settings and search for Hypervisor Enforced Code Integrity under the Virtualization Based Technology category.
5. Add the setting and set Hypervisor Enforced Code Integrity to Enabled with UEFI lock. The UEFI lock option prevents local disablement without physical UEFI access, which is the right default for managed devices.

6. Assign to your device groups and deploy.

Note: HVCI requires a reboot to take effect and some older or OEM drivers are not HVCI-compatible. Run the policy on a pilot group first and check Windows Security > Core isolation on affected devices before broad enforcement. If a driver is incompatible, Windows Security will report a specific conflict. You need to update or remove that driver before HVCI can fully activate.

Enable Credential Guard alongside HVCI:

Since HVCI and Credential Guard both depend on VBS and share the same hardware prerequisites, deploy them together on endpoint devices. Credential Guard isolates LSASS credentials in the VBS container, preventing tools like Mimikatz from dumping them even when an attacker has kernel-level code execution. Expel specifically calls this out in their ktapi.sys mitigations: if Credential Guard is active, the attacker’s ability to pivot to admin using stolen credentials is significantly limited, which means BYOVD becomes harder to reach in the first place.

Important: Microsoft does not recommend enabling Credential Guard on domain controllers and explicitly states it provides no additional security benefit on DCs. It is also unsupported on Exchange Server. Apply this to workstations and member servers only. Use a separate scoped policy, not the same policy as your HVCI deployment targeting server OUs.

1. In a Settings Catalog policy scoped to workstations and member servers (not DCs), search for Credential Guard under the Device Guard category.
2. Set Credential Guard to Enabled. Microsoft’s default enablement is deliberately without UEFI lock to allow remote disablement if needed. Use Enabled with UEFI lock only for high-security PAWs where you specifically need to prevent remote disablement and accept that rollback requires physical UEFI access.
3. Assign and deploy.

The same compatibility notes apply: requires VBS, Secure Boot enabled, and virtualization extensions active in UEFI. Run on a pilot group first.

Step 3: Apply the current vulnerable driver blocklist

Since Windows 11 2022 Update, the blocklist ships enabled by default and is automatically enforced when HVCI is active. So if Step 2 (HVCI) is fully deployed, the built-in blocklist is already running on those devices.

Step 3 adds value in two scenarios. For devices where HVCI cannot run, the standalone blocklist gives you driver load protection independently. For devices where HVCI is active, the standalone XML from aka.ms/VulnerableDriverBlockList is slightly more complete than the OS built-in version. Microsoft holds back some entries for compatibility reasons while vendors ship patches.

If HVCI is confirmed active across your entire fleet, this step is a completeness measure. If you have devices where HVCI is not running, it is more important for those specifically.

Deploy via Intune (recommended):

Intune deploys the driver block list as an App Control for Business policy using the XML file published by Microsoft. The XML contains Allow All rules plus specific deny rules for known vulnerable drivers, so it does not block legitimate software and can be deployed directly in enforce mode.

1. Download the driver block rules XML from aka.ms/VulnerableDriverBlockList. Save the enforced version locally.
2. In the Intune admin center, go to Endpoint security > App Control for Business.
3. Select the App Control for Business tab and click Create Policy.

4. Give the policy a name, for example BL-WIN-USR-P-ASR-Driver Block rules-v1.0. Click Next.
5. On Configuration settings, set Configuration settings format to Enter xml data.
6. Paste the full XML content from the file you downloaded in step 1.

7. Click Next through Scope tags. On Assignments, assign to your device groups.
8. Review + create.

Note: Microsoft recommends deploying this policy alongside any existing App Control policies rather than merging them. If you do plan to merge it with an existing allowlist policy, remove the Allow All rules from the XML before merging.

Deploy manually via SiPolicy.p7b (alternative for non-Intune environments):

If you need to deploy outside Intune or want the most current version of the blocklist rather than waiting for the next policy update:

1. Download the App Control policy refresh tool.
2. Download and extract the vulnerable driver blocklist binaries.

3. Start with the audit only version. Rename the file to SiPolicy.p7b.
4. Copy SiPolicy.p7b to %windir%\system32\CodeIntegrity.
5. Run the refresh tool as administrator to activate and apply the policy.
6. Open Event Viewer. Browse to Applications and Services Logs > Microsoft > Windows > CodeIntegrity > Operational. Filter on Event ID 3099.
7. Confirm the PolicyNameBuffer and PolicyIdBuffer match the values in the policy XML you downloaded. If they do, the blocklist is active.
8. Run in audit mode for a period that covers your normal driver install activity. If nothing legitimate triggers a block, swap in the enforced version and repeat the refresh step.

Note: if a vulnerable driver is already loaded when you apply the policy, it will not be evicted until reboot. Plan a reboot window into the rollout, especially on servers.

For fleet deployment via Intune or ConfigMgr, deploy SiPolicy.p7b to the CodeIntegrity folder using a Win32 app or a PowerShell remediation script, then run the refresh tool post-copy as a second step. Validate on a representative pilot group across your hardware diversity before broad enforcement.

Step 4: App Control for Business for your most critical assets

Steps 1 and 3 are blocklist-based. They stop drivers that are known to be bad. ktapi.sys, the zero-day used in the Gentlemen intrusion, was not on any public blocklist when it was deployed. A sufficiently restrictive App Control for Business policy stops it anyway, not because it knows ktapi.sys is bad, but because it was never on the approved list. With a restrictive policy, an unapproved driver simply does not load.

Most organisations are not here yet. Deployment complexity is real and a misconfigured policy can prevent Windows from booting. Get Steps 1 through 3 in place first, then plan this for your highest-risk assets. App Control lets you allowlist by publisher certificate so new driver versions from the same vendor pass automatically. You can also set a minimum build number to prevent downgrade attacks.

Start with the assets where the driver set is most predictable:

• Domain controllers: stable driver set, crown jewel of every ransomware intrusion
• Jump boxes and PAWs: standardised images, minimal variation
• File servers: high-value targets with generally predictable hardware

Step-by-step: App Control Wizard

Download the wizard from webapp-wdac-wizard.azurewebsites.net or install via winget install --id Microsoft.AppControlPolicyWizard. The welcome page has three options: Policy Creator, Policy Editor, and Policy Merger.

1. Create your base policy in audit mode (Policy Creator)

1. Select Policy Creator.
2. On the Policy Type screen, select Multiple Policy Format and then Base Policy. Multiple Policy Format supports Windows 10 1903 and newer, including all modern Windows Server versions. Single Policy Format is for Windows Server 2016 and 2019 only. AppIdTagging is a different feature and not relevant here.

3. Choose a template. For servers and DCs use Default Windows Mode, which allows Windows components, Store apps, and third-party WHQL-compatible drivers. Note: because it trusts WHQL-compatible drivers, an unknown vulnerable driver that passed WHQL could still load. For the tightest driver control, review and restrict the driver signing rules after creating the base policy. For workstations, Signed and Reputable Mode is a broader starting point that also trusts reputable signed software.
4. Name the policy, for example BYOVD Protection - DC Audit, and choose an output folder.

5. On the Policy Rules page, leave Audit Mode enabled. No drivers are blocked yet while you collect data. Two specific toggles worth noting here:
   • Hypervisor-protected Code Integrity is off by default. Leave it off. HVCI is managed separately through the Intune Settings Catalog policy in Step 2. Enabling it here as well creates a conflict in management scope.
   • Require WHQL is off by default. Leaving it off does not introduce a gap. The driver block rules you merge in the next step add explicit deny entries for known-bad WHQL-compatible drivers, which is a more targeted approach than requiring WHQL for everything.

6. On the File Rules page, add publisher rules for software you know runs on these assets. A standard DC may need nothing beyond the template defaults.
7. Click Next. The wizard outputs both an .xml file and a .cip binary.

2. Merge the driver block rules (Policy Merger)

1. On the welcome page, select Policy Merger.
2. Add your base policy XML from the previous step.
3. Add the driver block rules XML from aka.ms/VulnerableDriverBlockList.
4. Set the output path and click Merge. The result allows your approved software and explicitly denies known-bad drivers.

3. Deploy in audit mode and collect events

DCs, file servers, and jump boxes are domain-joined, not Intune-managed. Deploy the compiled binary via PowerShell, either run directly or packaged as a startup script via Group Policy or SCCM targeting the relevant server OUs.

Convert the XML to binary. The filename must match the PolicyID GUID from inside the XML exactly. Use this snippet to extract it automatically:

$PolicyId = ([xml](Get-Content ".\MergedPolicy.xml")).SiPolicy.PolicyID
ConvertFrom-CIPolicy `
    -XmlFilePath ".\MergedPolicy.xml" `
    -BinaryFilePath ".\$PolicyId.cip"

Copy the binary to the target server and reboot:

Copy-Item ".\$PolicyId.cip" -Destination "C:\Windows\System32\CodeIntegrity\CiPolicies\Active\"
Restart-Computer

Monitor audit events in Advanced Hunting for two to four weeks:

DeviceEvents
| where ActionType == "AppControlCodeIntegrityPolicyAudited"
| where FileName endswith ".sys"
| where DeviceName in ("YourDC1", "YourDC2")
| project Timestamp, DeviceName, FileName, FolderPath, SHA256
| order by Timestamp desc

Review every driver that shows up. If everything is legitimate, proceed to enforcement.

4. Switch to enforcement (Policy Editor)

1. In the wizard, select Policy Editor and load your merged policy XML.
2. On the Policy Rules page, toggle Audit Mode off.
3. The wizard saves a new versioned XML file, for example MergedPolicy_v10.0.0.1.xml.
4. Convert to binary and redeploy using the same PowerShell steps above. The reboot activates enforcement.

Detection: catch the driver event before the kill

ASR vulnerable-driver activity

Start with the control itself. This query shows when the Block abuse of exploited vulnerable signed drivers ASR rule was triggered in Audit or Block mode.

DeviceEvents
| where Timestamp > ago(7d)
| where ActionType in (
    "AsrVulnerableSignedDriverAudited",
    "AsrVulnerableSignedDriverBlocked"
)
| project Timestamp, DeviceName, ActionType, FileName,
    FolderPath, InitiatingProcessFileName, SHA256
| order by Timestamp desc

Driver file dropped to an unusual location:

Legitimate driver installs rarely write .sys files to user-writable paths. This query catches the delivery step before the load.

DeviceFileEvents
| where Timestamp > ago(1d)
| where FileName endswith ".sys"
| where FolderPath has_any (
    "\\Temp\\", "\\AppData\\", "\\Users\\Public\\",
    "\\PerfLogs\\", "\\Downloads\\", "\\ProgramData\\"
)
| project Timestamp, DeviceName, FileName, FolderPath,
    InitiatingProcessFileName, SHA256
| order by Timestamp desc

Behavioral BYOVD detection: correlate driver drop and load

Known hashes only catch drivers we have already seen. A stronger complementary approach is to correlate an unusual .sys file drop with a driver load shortly afterwards and prioritize drivers that are rare across the environment.

DeviceFileEvents
| where Timestamp > ago(7d)
| where FileName endswith ".sys"
| where FolderPath !startswith @"C:\Windows"
| where FolderPath !startswith @"C:\Program Files"
| where isnotempty(SHA1)
| project
    DropTime = Timestamp,
    DeviceId,
    DeviceName,
    SHA1,
    DriverFileName = FileName,
    DriverPath = FolderPath,
    DroppingProcess = InitiatingProcessFileName,
    DroppingProcessCommandLine = InitiatingProcessCommandLine
| join kind=inner (
    DeviceEvents
    | where Timestamp > ago(7d)
    | where ActionType == "DriverLoad"
    | where isnotempty(SHA1)
    | project
        LoadTime = Timestamp,
        DeviceId,
        SHA1,
        LoadedDriver = FileName,
        LoadedDriverPath = FolderPath
) on DeviceId, SHA1
| where LoadTime between (DropTime .. DropTime + 30s)
| project
    DropTime,
    LoadTime,
    DeviceName,
    DriverFileName,
    DriverPath,
    DroppingProcess,
    DroppingProcessCommandLine,
    LoadedDriver,
    LoadedDriverPath,
    SHA1
| order by DropTime desc

ktapi.sys and was.exe IOCs from the Hutchins/Expel report (June 2026):

The hashes below are published in the Expel investigation. Expel notes that the recovered ktapi.sys sample came from a third-party source and could not be confirmed as the exact copy used during the intrusion. Treat these hashes as hunting pivots rather than relying on hash-only blocking.

DeviceFileEvents| where Timestamp > ago(30d)| where FileName in~ ("ktapi.sys", "was.exe")    or SHA256 in (        "7ee17efef04bb7c9de90d5210263ed6993f867e5a11f86e65e3bb1362c7de237",        "9ca9432b0d29204cb5420a1a6b01533d4552130c2a8a5ecd7837efadefb4a046",        "89ba754861e11d9db4440b2b5db61fd5bee16752e4623c4271b8fdd0a666c677",        "c277ae5a4dd62f51de5278790796cd2700de7f77ea17762e97729f27872d076b"    )| project Timestamp, DeviceName, FileName, FolderPath,    InitiatingProcessFileName, SHA256| order by Timestamp desc

Hunt for known LOLDrivers in MDE

LOLDrivers publishes a Microsoft Defender query that compares actual driver-load events against its live catalogue of vulnerable and malicious drivers. The query is credited by LOLDrivers to Mehmet Ergene (@Cyb3rMonk).

let LOLDrivers = externaldata (Category:string, KnownVulnerableSamples:dynamic, Verified:string ) [h@"https://www.loldrivers.io/api/drivers.json"]
    with (format=multijson, ingestionMapping='[{"Column":"Category","Properties":{"Path":"$.Category"}},{"Column":"KnownVulnerableSamples","Properties":{"Path":"$.KnownVulnerableSamples"}},{"Column":"Verified","Properties":{"Path":"$.Verified"}}]')
| mv-expand KnownVulnerableSamples
| extend SHA1 = tostring(KnownVulnerableSamples.SHA1), SHA256 = tostring(KnownVulnerableSamples.SHA256)
;
// you can filter the drivers further based on category or verified status
DeviceEvents
| where ActionType == "DriverLoad"
| join kind=inner (LOLDrivers | where isnotempty(SHA256)) on SHA256
| union (
  DeviceEvents
  | where ActionType == "DriverLoad"
  | join kind=inner (LOLDrivers | where isnotempty(SHA1)) on SHA1
)

This gives you a continuously updated hunt for known vulnerable or malicious drivers that were actually loaded in your environment.

Hunt for rare driver loads

A newly introduced driver that appears on only one or two systems deserves attention, particularly on servers and other assets with a stable driver baseline. Rarity is also one of the signals used in the Ransom-ISAC behavioral detection methodology.

DeviceEvents
| where Timestamp > ago(7d)
| where ActionType == "DriverLoad"
| where FileName endswith ".sys"
| summarize
    FirstSeen=min(Timestamp),
    LastSeen=max(Timestamp),
    Devices=dcount(DeviceId),
    DeviceList=make_set(DeviceName, 10)
    by SHA1, SHA256, FileName, FolderPath
| where Devices <= 2
| order by FirstSeen desc

A more advanced variation published query by Bert-JanP identifies recently created driver files on an endpoint with low global prevalence. It then cross-references these files with Windows Event ID 3004, where Windows Code Integrity validates the digital signature of kernel-mode drivers during memory loading. This detection can potentially highlight BYOVD (Bring Your Own Vulnerable Driver) scenarios.

let DriverwithLowPrevalence =
DeviceFileEvents
| where ActionType == "FileCreated"
| where FileName endswith ".sys"
| invoke FileProfile(SHA1,1000)
| where GlobalPrevalence <= 150 or isempty(GlobalPrevalence)
| join kind=leftouter DeviceFileCertificateInfo on SHA1
| project FileName;
DeviceEvents
// Event ID 3004 - Kernel-mode Driver Validation
| where ReportId == "3004"
| where ActionType == @"DriverLoad"
| where FileName has_any(DriverwithLowPrevalence)

Kernel driver registration through sc.exe

Many BYOVD chains register the vulnerable driver as a kernel service before loading it. Hunting for explicit sc.exe create ... type= kernel activity gives you another attack-chain signal that does not depend on a known driver hash.

DeviceProcessEvents
| where Timestamp > ago(30d)
| where FileName =~ "sc.exe"
| where ProcessCommandLine has "create"
| where ProcessCommandLine has "type= kernel"
| project
    Timestamp,
    DeviceName,
    AccountName,
    ProcessCommandLine,
    InitiatingProcessFileName,
    InitiatingProcessCommandLine
| order by Timestamp desc

Ransom-ISAC also identifies service/driver loading and the surrounding process chain as useful telemetry when investigating BYOVD activity.

Low-prevalence driver followed by tampering

A particularly interesting correlation is a rare driver being loaded on a device followed by Defender tampering activity. SlimKQL published this approach specifically for detecting EDR-killing tooling that uses BYOVD.

let DriverwithLowPrevalence =
DeviceFileEvents
| where ActionType == "FileCreated"
| where FileName endswith ".sys"
| invoke FileProfile(SHA1, 1000)
| where GlobalPrevalence <= 150 or isempty(GlobalPrevalence)
| join kind=leftouter DeviceFileCertificateInfo on SHA1
| project FileName;

let DevicewithLPDriverActivated =
DeviceEvents
| where ActionType == "DriverLoad"
| where FileName has_any(DriverwithLowPrevalence)
| distinct DeviceName;

DeviceEvents
| where ActionType == "TamperingAttempt"
| where DeviceName in (DevicewithLPDriverActivated)
| project Timestamp, DeviceName, ActionType, FileName, AdditionalFields
| order by Timestamp desc

This is a higher-confidence hunt than rarity alone because it combines a low-prevalence kernel driver with subsequent security-control tampering.

Security-tool termination

BYOVD is often used specifically to disable EDR or antivirus processes. This query looks for common command-line attempts to stop security tooling. Adjust the process names to match the products deployed in your environment.

DeviceProcessEvents
| where Timestamp > ago(1d)
| where ProcessCommandLine has_any (
    "sc stop",
    "taskkill /F",
    "net stop"
)
| where ProcessCommandLine has_any (
    "MsMpEng",
    "Sense",
    "WdNisSvc",
    "CSFalconService",
    "SentinelAgent",
    "SepMasterService",
    "mbamservice",
    "Sophos"
)
| project
    Timestamp,
    DeviceName,
    AccountName,
    ProcessCommandLine,
    InitiatingProcessFileName,
    InitiatingProcessCommandLine
| order by Timestamp desc

This is not BYOVD-specific, but it is useful as a supporting signal and also catches simpler user-mode EDR-killing attempts.

Gentlemen-specific hunting

Finally, keep one campaign-specific hunt. ESET observed the Gentlemen ransomware operation staging tooling under GentlemenCollection, while the later Expel investigation documented ktapi.sys being used against EDR.

DeviceFileEvents
| where Timestamp > ago(30d)
| where FileName in~ ("ktapi.sys", "was.exe")
    or FolderPath contains "GentlemenCollection"
    or InitiatingProcessFolderPath contains "GentlemenCollection"
| project
    Timestamp,
    DeviceName,
    FileName,
    FolderPath,
    SHA1,
    SHA256,
    InitiatingProcessFileName,
    InitiatingProcessCommandLine
| order by Timestamp desc

One more thing worth mentioning here: if you are streaming telemetry to Microsoft Sentinel, events that have already left the endpoint before the EDR kill are still available in Sentinel even if Advanced Hunting goes dark. Getting telemetry off-box quickly is a meaningful compensating control when the on-box agent is compromised.

What to do when this fires

The detection section above establishes that BYOVD activity is a pre-encryption signal. That changes how you respond. You are not investigating an isolated event. You are racing encryption.

If you see any of the following: an ASR vulnerable driver block, an attempted driver-based tamper alert, an unexplained loss of MDE sensor telemetry, or an EDR process termination event, treat it as a high-severity ransomware precursor and act immediately.

Immediate steps:

1. Isolate the host. Use MDE device isolation if the sensor is still alive. If the EDR agent has already been killed, device isolation may not be available. Have an out-of-band containment path ready through your network layer, NAC, firewall policy, or virtualisation platform. Do not assume MDE isolation is still functional once a kill event has fired.
2. Investigate how admin was obtained. BYOVD requires local admin. Look for credential theft, lateral movement, and privilege escalation activity in the hours before the driver event.
3. Hunt estate-wide immediately. Search for the same driver filename, hash, and service name across all enrolled devices. A single detection likely means the attacker has already moved laterally.
4. Check whether other devices stopped reporting. If the EDR sensor was killed on one device, look for devices that went silent around the same time.
5. Revoke compromised credentials. If the attacker reached local admin via credential theft, assume those credentials are compromised across the environment.
6. Preserve evidence where it does not delay containment. Memory, event logs, and the driver binary are valuable. Do not delay isolation of an actively compromised system to collect them. Containment comes first.

What MDE alerts fire when this happens

Even when BYOVD is attempted, MDE will raise alerts at the tamper layer before or during the attack if it catches the behavior. Knowing the alert titles helps you recognize them in your queue and triage them appropriately.

Alert titles you may see related to BYOVD and EDR kill attempts:

• Attempt to bypass Microsoft Defender for Endpoint client protection
• Attempt to stop Microsoft Defender for Endpoint sensor
• Attempt to tamper with Microsoft Defender on multiple devices
• Attempt to turn off Microsoft Defender Antivirus protection
• Suspicious driver installation detected

For the vulnerable signed driver rule specifically, Microsoft’s ASR reference confirms that the activity is surfaced through the ASR Report and Advanced Hunting rather than as a dedicated EDR alert. Separate Defender tamper and suspicious-driver detections can still generate alerts when related behavior is detected:

If your Sentinel workspace is connected, these tamper alerts will also appear as SecurityAlert records from the MicrosoftDefenderForEndpoint source, queryable via:

SecurityAlert
| where ProductName has "Microsoft Defender"
| where AlertName has_any (
    "Attempt to bypass",
    "Attempt to stop",
    "tamper with Microsoft Defender",
    "Suspicious driver"
)
| project TimeGenerated, AlertName, AlertSeverity, Entities, Description
| order by TimeGenerated desc

Validate your coverage across the fleet

Check your Secure Score in the Defender portal under Secure Score > Improvement actions, filtered by Device. It surfaces HVCI and ASR rule gaps as scored improvement actions with implementation guidance.

Coverage percentages per rule are also visible there. A 95% coverage reading means 5% of devices are not receiving the policy, which is worth understanding before you call it done.

Intune Security Baselines as a shortcut:

The Windows Security Baseline and MDE Baseline in Intune ship with HVCI and several core ASR rules pre-configured. If you are not already using them, check Endpoint security > Security baselines before manually configuring everything in this post. Step 3 still needs to be done manually, but the baselines close a lot of ground quickly.

Non-BYOVD EDR killers: the parallel trend to watch

BYOVD is not the only method in use. Several 2026 reports documented EDR killers that work without loading any kernel driver. Techniques include:

• Process suspension: repeatedly suspending EDR agent threads to avoid the process restart watchdog
• WFP-based blocking: using Windows Filtering Platform rules to block the EDR agent’s network traffic, cutting off telemetry without killing the process
• Handle manipulation: obtaining handles to protected processes through indirect means to inject or manipulate memory

The service termination query in the detection section catches some of these. HVCI and App Control do not protect against them. They require their own detection logic.

Troubleshooting

ASR rule is not triggering anything after deployment:

• Confirm Microsoft Defender Antivirus is in active mode. ASR does not function in passive mode.
• Confirm cloud-delivered protection is enabled. Several ASR rules depend on it, including this one.
• Allow 30 minutes for Intune policy sync after creation. Check rule status under Endpoint security > Attack surface reduction in the Intune portal.
• Run a test: use a known vulnerable driver hash from LOLDrivers.io in a test environment to confirm the rule fires before declaring production clean.

HVCI shows “Not enabled” after policy deployment:

• The most common cause is an incompatible driver. Check Event Viewer under System for Code Integrity or Hyper-V related warnings immediately after the policy applies and the device reboots.
• Check that VBS (Virtualization Based Security) itself is running in msinfo32 before HVCI. HVCI depends on VBS; if VBS is not active, HVCI cannot start.
• Some devices require UEFI settings changes (enable Secure Boot and virtualization extensions) before VBS can activate. Check BIOS/UEFI for Intel VT-x or AMD-V, and for Secure Boot status.
• HVCI with UEFI lock requires a reboot to fully activate. Do not check immediately after policy sync, check after reboot.

Blocklist policy (SiPolicy.p7b) did not apply:

• Verify the file is in %windir%\system32\CodeIntegrity on the target machine.
• Run the refresh tool as an administrator, not as a standard user.
• Check for Event ID 3099 in the CodeIntegrity Operational log. If absent, the policy did not activate. If present but with unexpected policy names, you may have a policy conflict with an existing App Control policy on the machine.

A legitimate driver is being blocked by the blocklist:

• Do not exclude it by adding a hash exception to the ASR rule. The right fix is updating the driver to a version that is not on the blocklist.
• Contact the vendor for an updated driver version. If none exists yet, work with the vendor on getting the block lifted from the Microsoft blocklist for patched versions via the Microsoft Security Intelligence Driver Submission portal (link in references).
• As a temporary measure, apply the blocklist in audit mode while working through the vendor update.

References

• Attack surface reduction rules reference – Microsoft Learn
• Microsoft recommended driver block rules – Microsoft Learn
• Enable virtualization-based protection of code integrity (HVCI) – Microsoft Learn
• App Control for Business overview – Microsoft Learn
• Tamper resiliency in Microsoft Defender for Endpoint – Microsoft Learn
• Credential Guard overview – Microsoft Learn
• App Control Wizard (formerly WDAC Wizard)
• LOLDrivers.io – living off the land drivers catalogue
• ESET: Killing me gently – Inside Gentlemen’s EDR killer framework (June 2026)
• Marcus Hutchins / Expel: Not very gentlemanly – Analyzing a zero-day exploit used by The Gentlemen ransomware to disable targets’ EDRs (June 2026)
• Expel: The feature that stops BYOVD – App Control for Business deployed via Active Directory
• Huntress: How attackers disable AV and EDR (May 2026)
• The Hacker News: 54 EDR killers use BYOVD to exploit 35 signed vulnerable drivers (March 2026)
• Microsoft Vulnerable Driver Blocklist download
• Microsoft Security Intelligence Driver Submission

Conclusion

None of these four controls is enough on its own, and they are not all equal in priority either.

The ASR rule stops a vulnerable driver from being written to disk but not one already sitting on the system. The blocklist stops known-bad drivers from loading, but on devices where HVCI is already active the built-in OS blocklist is already running. The standalone version adds completeness for a small number of additional entries and is most important for devices where HVCI cannot run. HVCI hardens kernel execution, constrains exploit primitives, and enforces the blocklist automatically. It is the most impactful control to deploy for most environments but it does not prevent a legitimately signed vulnerable driver from loading. App Control gives you the strongest guarantee of all, because it controls which drivers are admitted in the first place.

Put together: ASR in Block mode closes the delivery step. HVCI enforced fleet-wide hardens kernel execution and gives you blocklist coverage automatically. The standalone driver block list covers devices where HVCI is not running. App Control for Business on your highest-risk assets removes the dependency on any list entirely, covering even zero-day drivers no blocklist has seen yet.

From an MDR perspective, I treat HVCI status and ASR vulnerable-driver-rule Block coverage as fleet-wide metrics tracked on a dashboard, not one-time onboarding checkboxes. Gentlemen adopted two new BYOVD techniques within days of their public release. The blocklist updates quarterly, with additional entries delivered through monthly Windows Update servicing. That gap is real and it drifts faster than most environments expect if nobody is watching it.

Have a question or something to add? Drop it in the comments below.

The final phase of the Microsoft Defender Threat Intelligence (MDTI) convergence went generally available in the Defender portal on 1 August 2026. The legacy standalone portal and the legacy Intel Explorer are retired, and Microsoft threat intelligence now lives in the Threat intelligence section of the Defender portal, in entity pages, in Threat analytics, and in Sentinel through a free connector.

I want to walk through what actually changed, how to enable the connector step by step, how to call the Graph API, and where I would still be careful before calling it done in a tenant. I checked every claim below against Microsoft’s current documentation, and where the documentation disagrees with itself I say so.

What actually changed

• The legacy experience is retired. Microsoft’s Learn documentation states that the legacy standalone Microsoft Threat Intelligence portal and the legacy Intel Explorer experience were retired on 1 August 2026. The Threat intelligence section of the Defender portal now has two primary pages: Overview and Intel explorer.
• The data is delivered through the free connector. Microsoft’s Message Center notice (MC1192257) says all MDTI data has been published via the free connector in Microsoft Sentinel, with new Threat Analytics APIs replacing retired MDTI APIs.
• The licensing is simpler. The same notice says that after 1 August 2026 MDTI capabilities require an active Defender or Sentinel license. Microsoft’s Learn pages add that publicly available Microsoft Threat Intelligence data, including entity enrichments, is available to Defender XDR customers at no additional cost.

One thing to do before anything else: if you built something on the old MDTI APIs, read the Message Center notice. It tells you to update your internal documentation for the new Threat Analytics APIs and connector availability, so check older integrations rather than assuming they carried over.

Intel explorer: searching and managing threat intelligence

Intel explorer is the search and investigation page in the Threat intelligence section (left bar). You search by keyword or value, pick a threat intelligence type, and narrow the results with filters. Per Microsoft’s documentation the types are campaigns, indicators, attack patterns, identities, threat actors, tools, vulnerabilities, and reports, and threat analytics reports are available directly from it.

Beyond searching, the same page is where Sentinel threat intelligence is managed. Microsoft lists these capabilities for Intel explorer:

• Create STIX threat intelligence objects.
• Manage threat intelligence with ingestion rules.
• Manage relationships between objects, and add tags.
• Investigate indicators and related infrastructure (DNS, resolutions, WHOIS, subdomains, certificates, services, trackers, components, cookies).
• Query threat intelligence with advanced hunting.
• Export to TAXII 2.1 destinations.

For IP address and domain indicators you can also review GeoLocation and WhoIs enrichment. Microsoft marks that enrichment as preview.

To create or manage Sentinel threat intelligence here you need Microsoft Sentinel Contributor or higher. One practical warning from the documentation: do not paste suspicious indicators into a browser. Search them in Intel explorer instead, and remove the brackets from defanged values like contoso[.]com first.

Entity pages: reputation, infrastructure, and IoCs in context

Domain, IP address, URL, and file entity pages now carry a Threat Intelligence Insights tab. All Defender XDR customers can use it with publicly available Microsoft Threat Intelligence data at no extra cost.

What you get depends on the entity type. IP addresses and domains get reputation, attributed threat reports, and infrastructure relationships (DNS records, WHOIS, host pairs, subdomains, TLS/SSL certificates, services, components, trackers, cookies). URLs and files get reputation, attributed threat reports, and sandbox analysis.

The reputation score is worth understanding rather than glancing at, since it is what you will triage against:

Microsoft is explicit that the score should be read holistically. The combination of signals (top-level domain, hosting provider, name server, registrar, TLS certificate characteristics) predicts maliciousness, not any single rule.

You reach the tab from an incident (select an entity in the evidence or alert details), from global search, from advanced hunting results, or by direct navigation. On the entity page it sits next to the Overview tab.

Threat analytics: reports and IoCs

Threat analytics is Microsoft’s in-product threat reporting. Each report has an Overview, an Analyst report, Related incidents, Impacted assets, Endpoints exposure, Recommended actions, and an Indicators tab.

The Overview gives you the threat at a glance: aliases (names used by other vendors), origin, related intelligence, targeted countries and industries, and observed MITRE ATT&CK techniques. It then shows what the threat means for your organization through related incidents, impacted assets, endpoint exposure, and recommended actions.

The Indicators tab lists the IoCs tied to the threat. Microsoft researchers update them in real time, and expired IoCs stay in the list so you can investigate past activity. It is marked preview, and only verified customers can access it.

One licensing detail from the documentation: you need a license for at least one Microsoft Defender product to use Threat analytics, and Sentinel SIEM customers only get certain sections or tabs.

Step by step: enabling the connector in Sentinel

Before you start, you need the Microsoft Sentinel Contributor role at the resource group level to install content, and read and write permissions on the Sentinel workspace to configure the connector. Sentinel in the Azure portal is scheduled to move to the Defender portal only after 31 March 2027, so I use the Defender portal paths below.

1. Go to Microsoft Sentinel > Content management > Content hub. This is where you install any Sentinel solution, threat intelligence included.
2. Find the Threat Intelligence solution and select Install/Update.
3. Go to Microsoft Sentinel > Configuration > Data connectors. In my tenant the connector is listed as Threat Intelligence (NEW), next to the older Microsoft Defender Threat Intelligence connector. Microsoft’s documentation does not use that name yet, it still refers to the standard and premium Defender Threat Intelligence data connectors.
4. Open the connector page and select Connect. It is not connected by default in a new workspace, so nothing syncs until you do this.
5. Wait for the status to change to Connected. Once it does, indicators start flowing into your workspace.

6. Confirm it is actually working. Go to Logs and run this:

ThreatIntelIndicators
| where TimeGenerated > ago(1d)
| summarize count() by SourceSystem

Rows within a few minutes means ingestion is working. The ingested intelligence is then available to the TI map... analytics rule templates and to hunting.

Which table? Sentinel now stores threat intelligence in the ThreatIntelIndicators and ThreatIntelObjects tables. Microsoft stopped ingesting into the legacy ThreatIntelligenceIndicator table in 2025, so queries, rules, and workbooks that still read from it need migrating. Microsoft’s Learn documentation shows how to rewrite those queries for the new schema.

The Graph API side

For enrichment or SOAR automation, the Microsoft Graph Threat Intelligence API is the piece to use. It sits under /security/threatIntelligence and covers hosts, passive DNS, WHOIS, SSL certificates, intelligence profiles, vulnerabilities, and articles. The overview page states that the APIs are available to all customers with a Defender XDR and/or Sentinel license, with no separate license required.

The quickest way to try it is Graph Explorer, Microsoft’s own tool. You sign in with your own account, so there is no app registration, secret, or token to handle. The method reference pages list ThreatIntelligence.Read.All as the least privileged permission, and Graph Explorer uses it as a delegated permission on your signed-in account.

1. Open Graph Explorer. Go to https://developer.microsoft.com/graph/graph-explorer.
2. Sign in. Select Sign in to Graph Explorer and use an account from your Defender or Sentinel tenant.
3. Consent to the permission. Open the Modify permissions tab under the request bar, search for ThreatIntelligence, and select Consent next to ThreatIntelligence.Read.All. If consent is blocked, an admin needs to approve it for the tenant.
4. Enter the request. Set the method to GET, the version to v1.0, and paste this URL:

https://graph.microsoft.com/v1.0/security/threatIntelligence/hosts/newsplits.com/reputation

5. Select Run query. The status shows 200 OK and the Response preview tab shows the JSON.

newsplits.com is the domain from the entity page screenshots above. It is only a lookup value in the URL, so don’t browse to it. This is the response I got in Graph Explorer:

It lines up with the portal view of the same domain: score 100, classification malicious, and one high severity Cyber Threat Intelligence rule with the description “Daffodil Gust”. The id is just the host name, base64 encoded. The relatedDetailsUrl is a link into Threat analytics in the Defender portal, which is how you get from a verdict to the research behind it.

The score and classification pair is what I would use as an automation gate: if classification comes back malicious or suspicious, branch the playbook into containment or further enrichment, otherwise keep it as passive context on the incident.

6. Try WHOIS. Change the URL and run it again:

https://graph.microsoft.com/v1.0/security/threatIntelligence/hosts/newsplits.com/whois

If something fails:

• 403: the permission was not consented, or your account lacks the license or role.
• 401: sign in again.
• A licensing error: see the inconsistency below.

Microsoft’s API overview groups the rest of the surface by use case. These are the ones I would reach for during an investigation:

Graph Explorer runs as you, with delegated access. For automation you would register an app and use application permissions with a client secret or certificate, which is a different identity and a different setup.

For a quick phishing check: pull the domain from an incident, call reputation for a fast verdict, and fall back to whois or passiveDns if it is inconclusive.

Doc inconsistency to know about: the hostReputation and host reference pages (and possibly others) still say the API requires an active Defender Threat Intelligence Portal license and API add-on license. That contradicts the API overview and Microsoft’s Message Center notice. If a call fails on licensing, that stale note is likely why.

What I would still check before calling this done

• Preview labels. The entity page Insights tab, the Indicators tab on reports, and the GeoLocation and WhoIs enrichment in Intel explorer are all still marked Preview in Microsoft’s docs. Build accordingly.
• Table migration. Anything still reading ThreatIntelligenceIndicator is reading a table that no longer receives new data.
• Duplicate connectors. If you run both the older Microsoft Defender Threat Intelligence connector and the newer one, check SourceSystem on ThreatIntelIndicators for duplicates before assuming this was a free upgrade with zero cost impact.
• Old rules and old names. Detections scoped to a specific connector or source need a check.
• Licensing wording. Some Learn pages still talk about a separate license, including the Graph reference pages above and the premium prerequisite on the connector page. The Message Center notice says an active Defender or Sentinel license is enough. Confirm in your own tenant.
• Rollout. Do not assume every tenant looks the same. Check the Threat intelligence menu per tenant.

Sources

• Microsoft Tech Community: MDTI convergence in Microsoft Sentinel and Defender XDR is complete
• Microsoft Message Center notice MC1192257: Microsoft Defender Threat Intelligence: Convergence with Microsoft Defender and Microsoft Sentinel (mirror)
• Microsoft Learn: Threat intelligence in Microsoft Defender
• Microsoft Learn: Transition to the new Threat intelligence experience
• Microsoft Learn: Use Intel explorer in Microsoft Defender
• Microsoft Learn: View threat intelligence in entity pages
• Microsoft Learn: Threat analytics in Microsoft Defender
• Microsoft Learn: Enable the Microsoft Defender Threat Intelligence data connector
• Microsoft Learn: Work with STIX objects and indicators in Microsoft Sentinel
• Microsoft Learn: Microsoft Threat Intelligence APIs overview (Microsoft Graph)
• Microsoft Learn: Get hostReputation (Microsoft Graph API reference)

Bottom line

For anyone running Sentinel or Defender XDR, this puts Microsoft threat intelligence inside the tools your analysts already use: entity pages during triage, Intel explorer for pivoting, Threat analytics for reporting, and the Graph API for automation. The catch is not the convergence itself. It is making sure your connectors, tables, analytics rules, and cost baselines do not quietly assume the old setup.

If a coding agent fetches a project’s documentation to answer a question, and that page contains hidden text instructing the agent to read the local .env file and post its contents to an external URL, the agent has no way to tell that instruction apart from the legitimate page content. It just read it. Runtime protection is what catches that moment and blocks it before anything leaves the device.

What runtime protection detects

The target is prompt injection: malicious instructions hidden inside otherwise legitimate content that an agent reads and then acts on. Defender inspects the three points where content enters or leaves the agent’s reasoning: the prompt itself, the tool call the agent is about to make, and the tool’s response once it comes back. It doesn’t matter where the injected instruction came from, a file, a web page, a repository, or a tool response, all three surfaces get inspected.

How AI agent runtime protection works

This runs on agent hooks, defined points in an agent’s execution flow where an external tool can inspect and act before the agent continues. Claude Code and GitHub Copilot CLI both expose these hook points natively, which is what lets Defender plug in without touching the underlying model.

Three stages get inspected:

• User prompt: the prompt submitted to the agent
• Pre-tool call: the tool invocation request, before it executes
• Post-tool response: the tool’s response, after it comes back

Each of these is a fast inline check at a single point, not continuous monitoring of the whole agent process, so the latency hit is minimal.

The three modes

• Block: Defender stops the action, notifies the user in the agent UI and via a Windows toast, records the detection in protection history, and raises a security alert correlated into an incident for the SOC.
• Audit: Defender lets the action continue but still records the detection and raises the alert, just as informational rather than something requiring triage.
• Disabled: no inspection at all.

Microsoft’s own recommendation is to start in audit mode, watch what comes in, and only flip to block once you trust the accuracy. Worth noting the setting itself is protected by tamper protection, so it can’t be quietly switched off once you’ve enabled it.

Prerequisites

Right now the supported agent list is short: Claude Code and GitHub Copilot CLI. That’s noticeably narrower than the list of agents Defender can merely discover, so don’t assume every agent your discovery inventory picks up is also covered by runtime protection.

The rollout Microsoft recommends, and I’d actually follow it

1. Test: enable runtime protection in audit mode on a small set of devices where the supported agents are actively used.
2. Review: watch alerts in the Defender portal for one to two weeks, and submit any false positives to Microsoft.
3. Deploy: roll out audit mode to additional device groups.
4. Enforce: switch to block mode once you’ve validated the alerts are accurate and actionable.

Skipping straight to block mode on a feature that’s still in preview is asking for a frustrated developer at your service desk.

Enabling it on a single device

For testing or validation, this is a PowerShell job, no Intune policy exists for this yet.

1. Open an elevated PowerShell session.
2. Put the device on the Beta update channel:

Set-MpPreference -PlatformUpdatesChannel Beta
Set-MpPreference -EngineUpdatesChannel Beta

3. Force three signature updates. This is required for preview validation, not optional:

Update-MpSignature
Update-MpSignature
Update-MpSignature

4. Confirm the signature version is 1.451.224.0 or later:

Get-MpComputerStatus | Select-Object AntivirusSignatureVersion

5. Enable runtime protection in your chosen mode:

Set-MpPreference -AiAgentProtection Audit

Replace Audit with Block or Disabled depending on where you are in the rollout.

6. Verify it’s actually set:

Get-MpPreference | Select-Object AiAgentProtection

Deploying at scale with Intune

There’s no native Intune policy for this setting, so scale means pushing the same PowerShell command as a script:

1. Create a script containing the mode you want for that rollout phase:

Set-MpPreference -AiAgentProtection Block

2. Deploy it to target device groups using PowerShell scripts in Intune.

Same command, same logic as the single-device test, just fanned out to a device group with Audit while you’re still validating and Block once you’re confident.

What an alert actually looks like

When runtime protection catches something, Defender raises a Suspicious AI prompt injection alert. In block mode the severity lands on Critical, High, Medium, or Low depending on assessed risk. In audit mode it’s Informational, so your analysts aren’t stuck triaging something that never actually ran.

For the end user, a block shows up two ways: a message in the agent’s own terminal explaining what was blocked and why, and a Windows toast notification regardless of whether that terminal window is even focused. They can also check Windows Security > Virus & threat protection > Current threats and Protection history for the same detection.

For the SOC, it’s a normal alert in the Defender portal, process tree, detection details, and recommended actions included, and it correlates into incidents the same way any other endpoint detection does. No new investigation workflow to learn.

Testing it yourself with a benign prompt injection

Before you trust any of this in front of a client, validate it on a throwaway test device. The trick is building a test that’s realistic enough to trigger the hook inspection, but genuinely harmless.

Drop something like this into a folder Claude Code has access to, saved as instructions.txt. Then ask the agent something completely ordinary, “Can you summarize instructions.txt for me?”, and see what happens.

A few things can happen from there. The model itself might recognize the injected instruction and refuse or flag it, independent of Defender entirely, which is worth noting as defense in depth rather than a failed test.

If the agent does attempt the call, that’s the pre-tool-call hook’s moment to catch it, and in block mode you should see the Suspicious AI prompt injection alert land in the portal shortly after.

Resources

• AI agent runtime protection with Microsoft Defender for Endpoint (Preview)
• Set up AI agent runtime protection with Microsoft Defender for Endpoint
• Local AI agent discovery with Microsoft Defender for Endpoint
• Claude Code hooks
• GitHub Copilot hooks
• Use PowerShell scripts on Windows devices in Intune
• Protect AI assets from emerging threats and vulnerabilities using Microsoft Defender

Where this fits and what’s still missing

Two supported agents is a real limitation right now, not a minor caveat. If your client’s developers are running Cursor, Windsurf, or any of the desktop apps that discovery already picks up, none of that traffic gets inspected yet. Runtime protection and discovery aren’t the same coverage footprint, and conflating them in a client conversation is an easy way to over promise.

The Beta update channel requirement is the other one to flag internally. That’s not something you want live on a production fleet during preview, and it’s easy to forget you’ve put a device there once the preview period drags on.

What it does solve, cleanly, is the actual attack surface these agents introduce. Prompt injection isn’t hypothetical anymore, and having an inline check at the exact moment an agent is about to act on unverified content is a meaningfully different posture than hoping the model itself resists it.

Start in audit mode, watch it for a couple of weeks, and don’t be surprised if your first alert comes from something completely unintentional rather than a real attack.

All feature details, prerequisites, PowerShell commands, and rollout guidance were verified against official Microsoft Learn documentation at time of writing. This is a preview feature and may change before general availability.

In this post I go through what the deployment tool and deployment packages actually do differently, when it makes sense to use it over your existing onboarding method, how to generate a package, and where I think this still needs work before I would trust it for a large, multi-tenant estate.

One thing worth setting expectations on upfront: as of Microsoft’s most recent update to the documentation, the Windows version of the tool is no longer flagged as preview. The Linux version of the deployment tool still is, so if you run a mixed estate, don’t assume both are at the same maturity level.

From onboarding scripts to deployment packages

The old model was straightforward but brittle: download an onboarding package (a script or GPO blob) from the Defender portal, push it out through your management tool of choice, and hope the device picked it up correctly. There was no built-in expiry, no central view of which packages were still valid, and if that onboarding file leaked or sat on a file share for two years, it stayed usable.

The Defender deployment tool changes the model in a few concrete ways:

• The onboarding configuration is now embedded directly into a single executable rather than shipped as a separate blob or script.
• Generating a package requires setting an expiration date, up to a year, after which the package stops working.
• Running the tool requires an access key generated in the portal at package-creation time, so having the executable alone is not enough to onboard a device.
• Onboarding and offboarding events are now visible in the device timeline and in advanced hunting, instead of giving you a bare exit code and nothing else.
• The tool skips redundant installation if Defender is already present, and gives UI feedback with error descriptions rather than a bare exit code when something goes wrong.
• Onboarding and offboarding can proceed even without connectivity, using offline mode, and resume once connectivity returns.
• There is a dedicated deployment packages overview under Settings > Endpoints > Deployment packages, where you can filter by active, expired or hidden packages.

For anyone managing a multi-tenant or multi-customer estate, that last point alone is a meaningful improvement. Before this, tracking which onboarding packages were still floating around for a customer meant asking them, or trusting documentation that was rarely kept current.

When this tool actually applies

Before switching anything over, it is worth being clear on where the deployment tool fits, because it is not meant to replace every onboarding path you already have running.

• Windows client devices managed through Intune: Microsoft’s own Intune connector guidance labels the automatic onboarding option (“auto from connector”) as the recommended path once the service-to-service connection between Intune and Defender for Endpoint is set up. There’s no reason to route Intune-managed devices through the deployment tool instead.
• Devices not enrolled in Intune: this is where the tool is genuinely useful, for devices managed through SCCM, GPO, or another orchestration tool, or not centrally managed at all.
• On-premises Windows Servers: the tool works alongside whatever orchestration you already use to distribute software, since it exposes the same command-line and configuration-file options regardless of how it gets pushed out.
• Servers connected through Azure Arc, and Azure virtual machines: Microsoft’s Defender for Cloud documentation confirms that once the Defender for Servers plan is enabled, onboarding is auto-provisioned through the MDE.Windows or MDE.Linux extension, with no separate onboarding package needed. For new subscriptions this integration is enabled automatically and covers supported Windows Server and Linux machines. That makes the deployment tool mainly relevant for servers that are not (yet) Arc-connected or covered by Defender for Servers.

For an operations team managing many devices, that narrows things down to a fairly specific but common gap: non-Intune-managed Windows devices and servers that fall outside Defender for Servers auto-provisioning. That is exactly the group that used to depend on the older onboarding scripts and blobs, so it is a sensible place to start piloting this.

The tool also carries its own legacy-OS story worth knowing about: it’s what installs the Defender endpoint security solution on Windows 7 SP1 and Windows Server 2008 R2 SP1, and that legacy solution itself has now reached general availability. It runs on a different underlying implementation than newer OS versions, though, so don’t assume full feature parity, and check the specific prerequisites first (the SHA-2 code signing update KB4474419, the servicing stack update KB4490628, and .NET 3.5 or later on Server 2008 R2 SP1).

Generating a deployment package

The workflow for creating a new package sits in the same place onboarding always has, but with an extra step:

1. In the Microsoft Defender portal, go to System > Settings > Endpoints > Onboarding
2. Choose Windows as the operating system
3. Under deploying by downloading and applying packages or files, select Onboard

4. On the package configuration page, give the package a unique, descriptive name and set an expiration date. Microsoft’s own guidance here is to keep the validity period as short as your rollout realistically allows, which lines up with how I would treat any credential with a long shelf life.

5. Select Generate. You get an access key on screen, which you need to copy and store somewhere sane, because the tool prompts for it during onboarding.

6. Download the tool as either a .zip or a standalone .exe.

That access key is the part I would flag to anyone building a runbook around this. It behaves like a short-lived secret, not a public download link, so it needs to go through the same handling as any other deployment credential rather than sitting in a shared onboarding folder in plaintext.

Running the tool: interactive and non-interactive

For one-off machines or small pilots, the interactive double-click flow is the quickest option:

1. Double-click the executable to launch it.
2. Confirm you want to start onboarding when the dialog appears.

2. Enter the access key you copied from the portal and continue

1. Wait for installation to complete. No reboot is required in most cases, and if one is needed the tool tells you clearly rather than leaving you to guess from an exit code.

For anything beyond a handful of devices, the command-line interface is where this becomes usable at scale. A few examples straight from the tool’s own help output:

DefenderDeploymentTool_Name.exe -PreCheck

Checks for prerequisites and logs results but does not proceed with installation or onboarding.

DefenderDeploymentTool_Name.exe -Quiet

Runs onboarding without any prompts, using the onboarding file in the same directory.

DefenderDeploymentTool_Name.exe -Proxy:192.168.0.255:8080 -AllowReboot -Quiet

Onboards through a proxy and allows an automatic reboot if one is required, without showing a console window.

DefenderDeploymentTool_Name.exe -File:\\server\share\Defender.onboarding -Quiet

Points the tool at an onboarding file on a network share, useful if you are not distributing it alongside the executable itself.

One thing the docs don’t spell out: your actual download isn’t literally named DefenderDT.exe, that’s just the generic name Microsoft uses in its examples. After running it, the tool drops a DefenderDT.exe copy into C:\ProgramData\Microsoft\DefenderDeploymentTool alongside its log file, which you can use directly for any follow-up commands.

For repeatable deployments, generating a config file with -MakeConfig and editing the resulting MdeConfig.txt is worth doing early. It saves you from maintaining long command-line strings across GPO, SCCM or whatever orchestration tool you use, and it makes the deployment auditable, since the config file itself documents exactly what was run.

A couple of the less obvious parameters are worth calling out specifically, since they solve real operational problems rather than just being flags for the sake of flags:

DefenderDeploymentTool_Name.exe -PreCheck -Verbose -Quiet

Runs a full prerequisite check and logs the results without touching the device. I would run this as a standalone step ahead of any bulk rollout, since it turns “why did onboarding fail on these forty machines” into something you can catch beforehand instead of after the fact.

For low-bandwidth sites or staged rollouts, the tool can also pre-download the installation files without onboarding anything yet:

DefenderDeploymentTool_Name.exe -Stage

Documented as downloading updates and installation files to the current directory for later use, this is worth combining with a config file if you are pushing to devices over a slow or unreliable link, so the actual onboarding step doesn’t also have to pull the full package down first.

The -UpdateOnly parameter is documented the same way: it installs the latest updates and platform components without performing onboarding, even if an onboarding file is present, which is useful for keeping already-onboarded fleets current without re-running the full onboarding sequence.

The full set of parameters exposed through the config file, straight from Microsoft’s own reference:

Run DefenderDeploymentTool_Name.exe -? on your own copy of the tool for the authoritative, up-to-date list, since this is exactly the kind of thing Microsoft tends to extend between releases.

Where this fits in a GPO or orchestrated rollout

If you are still using Group Policy for onboarding, the steps look like this:

1. Place the executable and the onboarding file (and a config file, if you generated one) on a network share that the target devices can reach.
2. In the Group Policy Management Console, create a new Group Policy Object or open an existing one for editing.
3. Go to Computer configuration > Preferences > Control panel settings.
4. Right-click Scheduled tasks, point to New, and select Immediate Task.
5. On the General tab, set the task to run as the SYSTEM account, with Run whether user is logged on or not and Run with highest privileges both selected.
6. On the Actions tab, point the task at the executable using its full UNC path, and add any command-line parameters you need in the arguments field, for example a -file: pointing at an onboarding file that is not in the tool’s working directory.
7. Save the GPO and link it to the organizational unit containing your target devices.

The difference from the previous approach is mainly what you are pointing the scheduled task at: one self-contained executable with its own onboarding configuration, instead of a script plus a separate onboarding package.

If you are placing the tool behind a firewall or proxy allowlist, note that it downloads and updates itself from the definitionupdates.microsoft.com domain. Since those files are served from a content distribution platform, there is no static or predictable IP range to whitelist instead, so the domain needs to be reachable by name rather than by IP.

Offboarding a device

Offboarding follows a similarly short, two-part flow:

1. In the Defender portal, go to System > Settings > Endpoints > Device management > Offboarding, select Windows, and download the offboarding package. This gives you a .zip file containing the .offboarding file (at least temporary – I am pretty sure Microsoft will release an easier way).

2. Copy the extracted file to the target machine, open an elevated command prompt, and run the executable with the offboarding switch, for example:

DefenderDT.exe -Offboard -File:WindowsDefenderATP_valid_until_2025-05-06.offboarding

When prompted Are you sure you want to offboard? Yes(Y)/No(N)?, type Y to proceed. A successful run reports:

Microsoft Defender deployment tool completed, exit code: 0 [Success]

For a fully unattended offboarding, add -Yes -Quiet to the same command to skip the confirmation prompt entirely. As with onboarding packages, the offboarding file itself is time-limited (seven days from download), so this is not something you can generate once and keep on a share indefinitely.

Tracking packages centrally

For anyone managing many customer tenants, the deployment packages page is where the day-to-day value shows up: it replaces asking a customer what onboarding method they used eighteen months ago with a direct answer. Expired or forgotten onboarding packages are exactly the kind of loose end that shows up in a security review and is hard to explain away, so having them visible and filterable in one place closes a real gap.

Troubleshooting a failed run

Before opening a support case, Microsoft’s own guidance points to a few places worth checking first:

• The tool’s own log, at C:\ProgramData\Microsoft\DefenderDeploymentTool\DefenderDeploymentTool-<COMPUTERNAME>.log.
• The Windows Application event log, under the sources WDATPOnboarding and WDATPOffboarding.
• The services themselves, with sc.exe query sense and sc.exe query windefend. Both should report STATE: 4 RUNNING on a healthy device.

The tool also returns a documented exit code on completion, which is worth wiring into whatever orchestration or RMM tool triggers it, rather than only checking the log after the fact:

This is a trimmed list of the ones I’d actually watch for in day-to-day operations; Microsoft’s reference has the complete set, including several more granular codes for update and uninstall failures.

Considerations and limitations

A few points worth being upfront about, straight from Microsoft’s own documentation, rather than presenting this as a finished, edge-case-free solution:

• If a reboot is required during the interactive experience, you have to sign back in after the reboot for the sequence to resume. Skipping that step leaves the device only partially onboarded.
• On Windows Server 2016 and later, if the Defender Antivirus feature was previously uninstalled or removed, you may hit a documented error during the Enabling Feature ‘Windows-Defender’ step (exit code 710, error 14081, “The referenced assembly could not be found”). Microsoft is explicit that this isn’t caused by the Defender Antivirus feature or source files themselves, and recommends opening a support case for Windows Servers if you hit it.
• On Windows 7, passive mode is set with the -passive parameter, but there is currently no equivalent to the ForceDefenderPassiveMode registry key that servers use to flip back to active mode afterwards. Switching back means offboarding, uninstalling, and running the tool again without the passive parameter.
• No integration with existing onboarding methods yet means you cannot simply layer this on top of an Intune or SCCM-based fleet without deciding how the two coexist; the tool remains its own onboarding methodology for now.

References

• Deploy Microsoft Defender endpoint security to Windows devices using the Defender deployment tool: Microsoft Learn
• Onboard previous versions of Windows on Microsoft Defender for Endpoint: Microsoft Learn
• What’s new in Microsoft Defender for Endpoint: Microsoft Learn

Closing thoughts

This is a genuine improvement over the old script-and-blob approach, mainly because it finally gives onboarding a lifecycle: an expiry, an access key, and a place to see what is still active. For teams managing many customer tenants specifically, the centralised deployment packages view is the detail I would point a customer to first, since it directly addresses the “which onboarding package is this device even using” question that used to require manual digging.

If you are planning a migration to this tool across an existing estate, start small, keep expiry windows short, and treat the access key with the same care you would give any other deployment credential.

Worth noting for mixed estates: a Linux version of the deployment tool exists as well, combining installation and onboarding the same way. I have not tested it myself yet, but it is on my list for a follow-up post once I have run it against a real Linux fleet.

This isn’t a bug. It’s by design. Until recently, your only real options were to deploy Sysmon alongside Defender for Endpoint, managing another agent, another configuration, and a completely different schema.

Custom data collection, which reached general availability in May 2026, gives you a way to collect the specific telemetry you need without those workarounds. This guide covers what problem it actually solves, what it costs, and how to configure it end to end.

The real problem: Defender for Endpoint drops events

Olaf Hartong and the team at FalconForce have done thorough work documenting how Defender for Endpoint works under the hood. Their MDE Internals blog series is required reading for anyone doing detection engineering with Defender.

Here’s the short version:

Defender for Endpoint applies caps and sampling to limit how much telemetry gets uploaded to the cloud. For many event types, you’ll only see one event per 24 hours for each unique combination of field values. Run the same process a hundred times with identical parameters you’ll see it once in Advanced Hunting.

The reason is straightforward. Defender for Endpoint is sold at a fixed price per device. If every customer could upload unlimited telemetry, backend costs would be unpredictable. So Microsoft made a trade-off: enough data for most use cases, but capped volume.

For day-to-day security operations, this is generally fine. The alerts fire, incidents get created, you can investigate. But for custom detections or proactive threat hunting, these gaps become a real problem. A concrete example: malware that beacons to a C2 server every 10 minutes. With standard Defender for Endpoint telemetry, you might see only a handful of connections to that server because once Defender for Endpoint logs the first connection with a specific process/destination combination, duplicate connections don’t appear for 24 hours. The beaconing pattern that would make detection trivial? Invisible.

The table that suffers most is DeviceImageLoadEvents. DLL loads are sampled so aggressively that FalconForce describes it as “very unreliable.” No events in the portal genuinely does not mean nothing happened on the machine.

What custom data collection actually does

Custom data collection lets you define rules that collect specific events and send them to Microsoft Sentinel without the standard Defender for Endpoint caps. The data lands in separate tables so it doesn’t interfere with your normal Defender for Endpoint data.

There is still a limit: 75,000 events per rule, per device, per day (raised from 25,000 at GA). This is a protective cap to prevent runaway costs, not a sampling mechanism. A well-scoped rule will never hit it.

Supported tables:

One thing worth noting on DeviceScriptEvents: AMSI events from that table are not available in standard Advanced Hunting, but custom collection routes them to DeviceCustomScriptEvents in Sentinel. So for script-based attack detection, custom collection gives you visibility you simply cannot get any other way through the MDE stack.

Notice what’s missing: no registry events, no named pipes, no driver loads. If you need those, you still need Sysmon. Custom data collection is a targeted solution for specific gaps, not a complete replacement.

The custom tables share the same schema as their standard counterparts, with three additional fields: RuleName, RuleLastModificationTime, and Type. These make it easy to identify which rule needs tuning when you’re reviewing results.

Which scenarios are worth implementing

Custom data collection is included with Defender for Endpoint P2, but every event you collect goes to Microsoft Sentinel and gets billed at Sentinel ingestion rates. Before creating any rules, be clear about what gaps you’re actually filling.

High priority usually worth implementing:

Advanced use cases worth considering:

Approach with caution: can get expensive fast:

Prerequisites

Licensing

Supported operating systems

Defender for Endpoint client requirements

Query to check client versions across your environment:

DeviceInfo
| where Timestamp > ago(1d)
| summarize arg_max(Timestamp, *) by DeviceId
| project DeviceName, OSPlatform, OSVersionInfo, ClientVersion
| where ClientVersion < "10.8805"
| order by DeviceName

Portal and permission requirements

Configuration prerequisites

If you plan to scope rules to specific device groups, configure dynamic tags before creating rules. If you deploy org-wide, you can skip this.

Step 1: Connect your Microsoft Sentinel workspace

Even if you already have Sentinel connected to Defender for other features, you need to explicitly select it for custom data collection.

1. Open the Microsoft Defender portal at security.microsoft.com
2. Click Settings in the left navigation
3. Select Endpoints
4. Scroll down to Rules
5. Click Custom Data Collection

You’ll see the overview page showing any existing rules.

In the top-right corner, click the Microsoft Sentinel workspace dropdown or link, select your workspace from the list, and click Save.

Important limitation: You can only connect one Sentinel workspace per Defender tenant for custom data collection. If you have multiple workspaces, decide which one receives the custom telemetry before you start.

Step 2: Configure dynamic tags

Dynamic tags are needed if you want to scope rules to specific device groups rather than deploying to all devices. If you skip this and choose “all applicable client devices” when creating rules, you can come back and configure tags later when you want more targeted deployment.

Dynamic tags are automatically applied to devices based on rules you define in Asset Rule Management. Unlike static tags, they update as your environment changes.

Create a dynamic tag

1. In the Defender portal, go to Settings → Microsoft Defender XDR
2. Click Asset rule management
3. Click Create rule

Configure the tag rule

• Rule name: Something descriptive “Custom Data Collection Pilot Group”
• Description: Explain what devices this targets
• Conditions: Define which devices get this tag

Example conditions:

• Tag to apply: Enter the tag name that will be stamped on matching devices e.g., “CustomCollectionPilot”
• Click Submit

Wait for propagation

Dynamic tag rules run approximately every hour. After creating the rule, wait for it to run at least once before using the tag in collection rules. Verify tags are applied by going to Assets → Devices, selecting a device, and checking the Tags field.

Step 3: Create your first custom data collection rule

With your Sentinel workspace connected and your pilot tag ready, create the following rule:

This example uses DeviceScriptEvents with the AmsiScriptContent action type. AMSI script events are not available in standard Advanced Hunting: DeviceScriptEvents is not queryable in the portal without custom data collection. This is exactly the gap the feature is designed to fill: telemetry that MDE collects on the endpoint but never exposes in Advanced Hunting under normal circumstances.

Start the rule wizard

1. From the Custom Data Collection page, click Create rule

Configure general information

Enter the following:

• Rule name: AMSI script content collection
• Description: Captures AMSI script content events from PowerShell for script-based attack detection. DeviceScriptEvents is not available in standard Advanced Hunting.
• Enabled: Toggle ON
• Click Next

Define the collection rule

Configure as follows:

• Table: DeviceScriptEvents
• Action type: AmsiScriptContent

Add filter conditions

Configure the following conditions. The top-level operator is AND, with a subgroup using OR for the command line exclusions.

Top level (AND):

This condition is always true: no real SHA1 hash will ever equal “1”. It serves as a catch-all to collect all events while still satisfying the filter requirement.

Add subgroup (OR), excludes known MDE-internal scripts:

The OR subgroup excludes two known MDE-native script executions that would otherwise generate noise. Add further exclusions here as you identify other internal processes in your environment.

Define rule scope

The portal gives you two options:

All applicable client devices, deploys to every Windows device enrolled in Defender for Endpoint. Corresponds to scope: Organization in TelemetryCollectionManager. Simple to configure but highest potential cost, so only use this for critical rules you genuinely need everywhere.

Specific devices that include dynamic tags, deploys only to devices with the selected tag. Use this for testing, cost control, or scenario-specific monitoring such as web servers or domain controllers.

If you choose tag-based scoping, the tags must be dynamic (configured in Asset Rule Management), not manual static tags.

Click Next, review your settings, then click Submit.

Deployment timeline: Rules take 20 minutes to 1 hour to propagate to devices.

Step 4: Verify data is flowing

After creating rules and waiting for deployment, verify everything works.

Check rule status

Go to Settings → Endpoints → Rules → Custom Data Collection, find your rule, and confirm the status column shows Enabled.

Query custom tables in Advanced Hunting

Check for any events from your rules:

DeviceCustomScriptEvents
| where TimeGenerated > ago(1h)
| where RuleName == "AMSI script content collection"
| take 10

What if no data appears?

Wait at least 1 hour after rule creation before troubleshooting. If still no data:

• Verify client version: Query DeviceInfo for your test devices needs to be 10.8805 or higher
• Check tag assignment: Verify the device has the dynamic tag applied
• Broaden your rule temporarily: Create a rule with minimal filters to see if anything flows at all
• Reboot a test device: Sometimes the Defender for Endpoint service needs a restart to pick up new rules

Step 5: Build detections on custom tables

Now that data is flowing, create an analytics rule in Sentinel to detect suspicious script content.

Create an analytics rule in Sentinel

1. In the Microsoft Defender portal at security.microsoft.com
2. Navigate to Microsoft Sentinel in the left navigation
3. Select your workspace
4. Go to Analytics → Create → Scheduled query rule

Configure the rule

General tab:

• Name: Suspicious PowerShell script content detected via AMSI
• Severity: High
• MITRE ATT&CK: T1059.001 – PowerShell

Rule logic tab:

DeviceCustomScriptEvents
| where RuleName == "AMSI script content collection"
| where ScriptContent has_any (
    "IEX",
    "Invoke-Expression",
    "DownloadString",
    "DownloadFile",
    "FromBase64String",
    "Invoke-Mimikatz",
    "Invoke-Shellcode",
    "Invoke-ReflectivePEInjection",
    "AmsiUtils",
    "-EncodedCommand",
    "-enc "
)
| project
    TimeGenerated,
    DeviceName,
    InitiatingProcessFileName,
    InitiatingProcessAccountName,
    InitiatingProcessCommandLine,
    ScriptContent,
    ScriptContentSHA256

ScriptContent contains the decoded script text captured by AMSI: what the script actually does, regardless of how it was obfuscated on the command line. ScriptContentSHA256 lets you pivot to other devices where the same script was executed, which is useful during incident response.

• Run query every: 5 minutes
• Lookup data from: Last 5 minutes
• Alert threshold: Greater than 0

Incident settings:

Enable incident creation. Group alerts by DeviceName so multiple suspicious script executions on the same device create one incident.

Managing rules at scale with TelemetryCollectionManager

If you followed the walkthrough in Step 3, you already experienced what building a single rule in the portal feels like: click through the wizard, add filter conditions one line at a time, one value per line, no way to paste a list, no validation until you submit. For one rule that’s manageable. For ten rules across five device groups, it becomes a real operational problem.

There is no bulk import, no version history, no way to review what changed between last Tuesday and today, and no way to roll back a misconfigured rule without manually recreating it. If a colleague builds a rule and you need to understand what it does, you open the portal, find the rule, and click through the wizard read-only. There is no export to a readable format.

FalconForce released TelemetryCollectionManager to solve exactly this. It is a CLI tool that lets you define rules as YAML files, validate them against the MDE schema locally, and deploy them via the Defender API. Your Git repository becomes the single source of truth: rules are reviewed before deployment, changes are tracked, and rollback is a git revert.

Benefits:

Installation

Download from GitHub: FalconForceTeam/TelemetryCollectionManager. Releases available for Windows, macOS, and Linux.

All rules in the repository are disabled by default review and enable what’s appropriate for your environment before deploying.

Basic usage

Step 1: Set up your rules directory

rules/
├── lsass-access.yaml
├── unsigned-dll-loads.yaml
├── non-standard-ports.yaml
└── powershell-unusual-location.yaml

Step 2: Validate rules locally

./TelemetryCollectionManager --validate-only

Step 3: Authenticate

The tool requires a user-based token. There is currently no support for service principals, managed identities, or app registrations. This is an API limitation on Microsoft’s side, not a tool limitation. The two options are:

Option A: Azure CLI (recommended)

az login
# Tool automatically uses your session

Option B: Manual bearer token (if Azure CLI is not an option)

export AZURE_TOKEN="your-token-here"
# Retrieve via browser developer tools: Defender portal > F12 > Network > filter getToken?resource=MATP

Step 4: Deploy rules

./TelemetryCollectionManager --post-rules

Step 5: List existing rules

./TelemetryCollectionManager --list-rules

Step 6: Delete rules (use with care)

# Delete specific rules
./TelemetryCollectionManager --delete-rules "rule-id-1,rule-id-2"

# Delete ALL rules
./TelemetryCollectionManager --delete-rules=all

TelemetryCollectionManager also supports converting existing portal rules to YAML, useful if you built rules in the portal before adopting the tool. Check the README for the exact flag.

YAML schema reference

Basic structure:

# yaml-language-server: $schema=../rule-schema.json
name: Rule name here
description: What this rule does and why
enabled: true
platform: Windows
scope: Organization
table: DeviceProcessEvents
actionType: ProcessCreated
filters:
  operator: And
  expressions:
    - filter: Equals
      source: FileName
      values: ["example.exe"]

The scope field accepts Organization to deploy the rule to all applicable client devices, which is the equivalent of the “all applicable client devices” option in the portal wizard. To target a specific device group instead, replace it with the name of your dynamic tag, for example scope: CustomCollectionPilot. Static tags are not supported; if you use tag-based scoping it must be a dynamic tag configured in Asset Rule Management.

Nested logic example: PowerShell from a suspicious location, excluding a known management tool:

filters:
  operator: And
  expressions:
    - group:
        operator: Or
        expressions:
          - filter: Contains
            source: FolderPath
            values: ["\\temp\\"]
          - filter: Contains
            source: FolderPath
            values: ["\\downloads\\"]
    - filter: NotEquals
      source: InitiatingProcessFileName
      values: ["ManagementTool.exe"]

Practical rule examples

The following five rules are taken directly from the TelemetryCollectionManager repository, authored by FalconForce. All ship disabled by default which is really awesome, review and enable what fits your environment 🙂

Example 1: lsass starting lsass

An attack technique where lsass.exe forks and spawns another instance of itself, commonly used to dump credentials from memory. This process creation event is not logged by default in MDE, making it a textbook case for custom data collection. Look for InitiatingProcessParentFileName not being werfault.exe when hunting results.

# yaml-language-server: $schema=../rule-schema.json
name: lsass_starting_lsass
description: An attack technique where lsass.exe 'forks' and spawns another instance of itself, often used to dump credentials. Look for the InitiatingParentProcessFileName not being werfault.exe. This is not logged by default in MDE.
enabled: false
platform: Windows
scope: Organization
table: DeviceProcessEvents
actionType: ProcessCreated
filters:
    operator: And
    expressions:
        - source: FileName
          filter: Contains
          values:
            - lsass.exe
        - source: InitiatingProcessFileName
          filter: Contains
          values:
            - lsass.exe

Example 2: Executions from uncommon locations

Malware staging and living-off-the-land attacks frequently execute processes from user-writable locations like temp folders, AppData, Downloads, or Desktop.

# yaml-language-server: $schema=../rule-schema.json
name: executions_from_uncommon_locations
description: Processes executing from uncommon locations such as temp folders or user profile paths. MDE logs only 1 attempt per process, so this rule will show the repeated executions of the same process.
enabled: false
platform: Windows
scope: Organization
table: DeviceProcessEvents
actionType: ProcessCreated
filters:
    operator: Or
    expressions:
        - source: FolderPath
          filter: Contains
          values:
            - 'C:\PerfLogs\'
            - 'C:\$Recycle.bin\'
            - 'C:\Users\Default'
            - 'C:\Users\Public\'
            - '\Temp\'
            - 'C:\Windows\Prefetch\'
            - '\AppData\Local\'
            - '\AppData\Roaming\'
            - '\Local Settings\Temp\'
            - '\Temporary Internet Files\'
            - 'C:\Windows\Fonts\'
            - 'C:\Windows\Media\'
            - 'C:\Windows\Help\'
            - '\htdocs\'
            - '\wwwroot\'
            - '\Downloads\'
            - '\Desktop\'

Example 3: .NET CLR loaded outside .NET framework folder

DeviceImageLoadEvents is heavily sampled in standard MDE. Loading .NET CLR DLLs (clr.dll, clrjit.dll, mscoree.dll) from processes outside the .NET framework folder is a strong indicator of in-memory .NET assembly execution: used by Cobalt Strike, execute-assembly techniques, and similar post-exploitation frameworks. Without custom collection, these DLL loads are largely invisible.

# yaml-language-server: $schema=../rule-schema.json
name: dotnet_clr_loaded
description: The .NET CLR DLLs being loaded by processes outside of the .NET framework folder, which may indicate assemblyloads into injected processes. Tune based on your environment to reduce noise.
enabled: false
platform: Windows
scope: Organization
table: DeviceImageLoadEvents
actionType: ImageLoaded
filters:
  operator: And
  expressions:
    - source: FileName
      filter: Contains
      values:
        - clr.dll
        - clrjit.dll
        - mscoreei.dll
        - mscoree.dll
        - mscorlib.dll
        - mscoreeis.dll
        - mscorlib.ni.dll
    - source: InitiatingProcessFolderPath
      filter: NotContains
      values:
        - 'C:\Windows\Microsoft.NET\'

Example 4: Rundll32 loading comsvcs.dll for minidump

rundll32.exe loading comsvcs.dll with MiniDump in the command line is a classic post-exploitation credential dump technique. It creates a memory dump of LSASS without using dedicated tooling. Again, DeviceImageLoadEvents is where standard MDE telemetry fails; this specific DLL load pattern may never appear in standard Advanced Hunting.

# yaml-language-server: $schema=../rule-schema.json
name: rundll32_minidump
description: Rundll32 loading comsvcs.dll to create a minidump, often used in post-exploitation activity.
enabled: false
platform: Windows
scope: Organization
table: DeviceImageLoadEvents
actionType: ImageLoaded
filters:
  operator: And
  expressions:
    - source: FileName
      filter: Contains
      values:
        - comsvcs.dll
    - source: InitiatingProcessFileName
      filter: Equals
      values:
        - rundll32.exe
    - source: InitiatingProcessCommandLine
      filter: Contains
      values:
        - MiniDump

Example 5: Kirbi file creation

.kirbi files are Kerberos ticket files created by Mimikatz during credential theft operations (sekurlsa::tickets /export or kerberos::list /export). Their presence on disk is essentially unambiguous. There is no legitimate reason for .kirbi files to be created in normal operations.

# yaml-language-server: $schema=../rule-schema.json
name: kirbi_file_creation
description: Kirbi file creation detection, often used by Mimikatz for credential dumping.
enabled: true
platform: Windows
scope: Organization
table: DeviceFileEvents
actionType: FileCreated
filters:
    operator: Or
    expressions:
        - source: FolderPath
          filter: EndsWith
          values:
            - .kirbi

See the rest of the rules here

Understanding the costs

What’s included vs extra

Sentinel pricing (approximate, varies by region)

Always verify current pricing at aka.ms/sentinelpricing these figures shift with regional pricing updates.

Cost calculation example

That’s manageable. The risk is broad rules:

Cost optimization tips

• Start narrow begin with specific filters, expand only if needed
• Scope to device groups don’t collect from every device if not necessary
• Monitor ingestion: use Sentinel’s Usage workbook regularly
• Remove unused rules if nobody queries the data, delete the rule
• Consider commitment tiers if collecting >100 GB/day, commit for savings

Custom data collection vs Sysmon

For years, Sysmon has been the go-to solution for filling MDE’s telemetry gaps. When MDE didn’t give you DLL loads, you added Sysmon. When you needed registry events for persistence detection, Sysmon. Named pipes, driver loads, WMI events: Sysmon covered what MDE didn’t. The trade-off was always the operational overhead: a separate agent to deploy, a separate XML configuration to maintain, a separate data schema to write detections against, and a log collection agent on top of that to get the events into Sentinel.

Custom data collection changes that trade-off significantly. Process, file, network, and image load events now have a native MDE solution that uses the same schema you already query in Advanced Hunting, deploys without an additional agent, and integrates directly with Sentinel. For many organizations, this is enough to remove Sysmon entirely or at least substantially reduce its scope.

Honestly, you probably still need both.

Comparison

Recommendation

Use a hybrid approach:

• Custom data collection for process, file, network, and DLL events where you need complete visibility
• Sysmon slimmed down to registry, pipe, and driver events only

This reduces Sysmon’s footprint while maintaining visibility that custom data collection can’t provide.

Alternative for DLL loads only:

If you only need reliable DLL load telemetry without the full custom data collection setup, consider WDACme a WDAC audit-mode policy that generates CodeIntegrity events for specified DLLs in the DeviceEvents table. That said, custom data collection is more flexible and easier to manage at scale.

Troubleshooting common issues

No events appearing

Hitting the 75,000 event cap

Your rule is too broad. Solutions:

• Add more specific filters
• Scope to fewer devices
• Split into multiple targeted rules

Events in wrong table

Custom data collection uses DeviceCustom* tables, not standard Device* tables:

// Wrong - standard table
DeviceProcessEvents | where ...

// Right - custom table
DeviceCustomProcessEvents | where ...

Rule not deploying to device

• Verify device meets OS and client version prerequisites
• If using dynamic tags, verify the tag is applied to the device and the tag rule has run in Asset Rule Management
• Try rebooting the device

Useful diagnostic query

search in (DeviceCustomProcessEvents, DeviceCustomNetworkEvents, DeviceCustomFileEvents, DeviceCustomImageLoadEvents, DeviceCustomScriptEvents) *
| where DeviceId == "your-device-id"
| where TimeGenerated > ago(24h)
| summarize EventCount = count() by RuleName, $table
| order by EventCount desc

References

• Microsoft Learn: Custom data collection in Defender for Endpoint
• Microsoft Learn: Create custom data collection rules
• FalconForce: MDE Internals 0x06 – Custom Collection
• FalconForce: MDE Internals 0x03 – Telemetry Unreliability
• FalconForce: MDE Internals 0x01 – Sysmon vs MDE
• GitHub: FalconForce TelemetryCollectionManager
• GitHub: WDACme – DLL load telemetry workaround
• Microsoft Sentinel pricing
• Configure dynamic rules for devices

Conclusion

Custom data collection fills a real gap that detection engineers working with Defender for Endpoint have dealt with for years. The event capping in standard telemetry isn’t going away it’s a structural trade-off in how MDE is priced and operated. This feature gives you a legitimate, supported path to collect the specific events you actually need, without bolting on another agent or working around the schema.

That said, it’s not a fire-and-forget feature. Every rule you create is an ongoing cost, and broad rules will surface that cost quickly. The organizations that get the most value from this are the ones that start from a concrete detection gap a technique they couldn’t detect reliably, a table they knew was being sampled and work backwards to the minimum rule that closes it.

The hybrid approach with Sysmon still makes sense for most environments. Custom data collection covers process, file, network, and DLL events well. Sysmon still wins on registry, pipes, and driver loads. Using both, scoped appropriately, gives you more complete coverage than either alone.

The identity attack graph is the most useful of those managed graphs. Enable two connectors, turn on the graph, wait for the initial build, and you have a query-able model of how identities in your tenant connect to Azure resources through permissions and group memberships. No notebooks, no schema design, no GQL to write upfront.

The graph is currently in preview

What it shows you

The identity attack graph models three things: identities (users, service principals, managed identities, groups), Azure resources (subscriptions, resource groups, VMs, storage accounts, Key Vaults), and the access relationships connecting them via role assignments and group memberships.

The focus is lateral movement paths, not just direct access. A user who is a member of a group that has a role assignment on a subscription containing a Key Vault is three hops from that Key Vault. That chain doesn’t appear in a flat permissions table. It appears in a graph because each of those relationships is modelled as an edge you can traverse.

It’s built to answer questions like:

• What resources could an attacker reach if this account is compromised?
• Which identities have indirect paths to privileged roles?
• Which service principals can reach VMs, and via how many hops?
• Are there circular group memberships creating unintended privilege inheritance?

The predefined queries surface these without any GQL knowledge required. You can also write your own once you’re familiar with the schema.

Prerequisites

Both connectors are bundled in their respective Sentinel solution packages. If not yet installed, find them in Content Hub under Microsoft Sentinel > Content Management > Content Hub.

Asset data snapshots are taken once every 24 hours. After enabling a connector, data can take up to 24 hours to arrive in the lake. Initial graph processing after that can take up to 48 hours. Enable this well before you need it for an investigation.

One thing most guides don’t mention: ARG connector coverage

The Azure Resource Graph connector has a coverage limitation worth understanding before you enable it.

When enabled, its managed identity is automatically granted the Reader role only on subscriptions where you have the Owner role. If you don’t have Owner across your entire Azure estate (most people don’t), the connector ingests a partial view. The graph gets built, but it won’t include resources from subscriptions the managed identity can’t read.

In my case I had the owner permissions and the identity was correctly setup:

To get full tenant coverage, someone with elevated permissions needs to assign the Reader role to the connector’s managed identity at a broader scope if it failed. The managed identity is named msg-resources- followed by an alphanumeric ID, for example msg-resources-b05e. Reader can be assigned at:

• Tenant root management group covers all subscriptions in the tenant
• A specific management group covers a subset
• Individual subscriptions covers only those

Steps to assign:

1. Navigate to the scope you want to cover, for example Tenant Root Group > Access control (IAM)

2. Select + Add > Add role assignment

3. Assign the Reader role to the managed identity

4. Locate the msg-resources-* managed identity and complete the assignment

After the assignment propagates, the next ingestion cycle picks up the additional resources. Up to 24 hours for the new data to appear in the lake.

If your graph is missing subscriptions or resources you’d expect to find, this is almost certainly the reason.

Setting up the identity attack graph

Step 1: Navigate to Graphs

In the Microsoft Defender portal, go to Microsoft Sentinel > Graphs.

Step 2: Set up the graph

Find the identity attack graph card and select Set up graph.

Step 3: Enable the required connectors

The setup flow walks you through both connectors:

• Microsoft Entra ID Assets covers identity data, group memberships, and service principals
• Azure Resource Graph covers Azure subscriptions and resource hierarchy

If either is not yet installed, go to Content Hub first and install the relevant solution. Already installed but not enabled, the setup flow will prompt you to turn them on.

This is also the point to think about ARG connector coverage. If full tenant coverage matters for your use case, sort out the managed identity Reader assignment before continuing.

Step 4: Turn on the graph

Select Turn on graph. The graph starts ingesting data and building its relationship model.

Initial processing can take up to 48 hours. The graph is not query-able until the first build completes.

Step 5: Open the query interface

When the graph shows as ready, select Query graph on the identity attack graph tile.

Querying the identity attack graph

Step 6: Review the schema

Before running anything, open the Schema tab.

The schema defines what you can match in GQL. Node types include Entra users, groups, service principals, managed identities, Azure subscriptions, resource groups, VMs, storage accounts, and Key Vaults. Edge types include group memberships and role assignments. Checking the schema before writing queries saves time.

Worth being explicit: the query language here is GQL (Graph Query Language), not KQL. The syntax looks familiar in places but the logic is different. GQL uses MATCH (x)-[y]->(z) patterns to traverse relationships. You follow edges between nodes rather than joining rows. The predefined queries are a good way to see what working GQL looks like before writing your own.

Step 7: Start with the predefined queries

Start with the predefined queries before writing custom GQL. They cover the most useful scenarios and show you the query structure.

Select Edit query on any of these to copy the GQL into the editor, then adjust filters, change the target node type, or add conditions for your specific investigation.

Step 8: Run and explore

Select Run GQL query. Results render as an interactive graph (in this case I used the Visualize any graph as base):

From here:

• Select any node to open the details pane with account status, department, role assignments, and last password change
• Right-click a node and select Explore connected assets to traverse one hop further without a new query
• Switch to Table view to see results in rows and export to CSV
• Hover over a node to highlight its direct connections and mute everything else
• Use the filters in the top right of the canvas to narrow by node type or edge relationship

What to look for

Short paths to privileged roles. The fewer hops between an identity and a privileged directory role, the more exposed you are. An identity two hops from Global Administrator via a nested group chain and a role assignment is a different risk profile than one eight hops away.

Service principals with unexpected resource access. Service principals reaching VMs or Key Vaults via indirect role assignments, through inherited group memberships or role assignments higher up the subscription hierarchy, often come from earlier deployments that were never cleaned up.

Circular group memberships. These create privilege inheritance chains that are invisible from the portal’s flat group membership view. The graph shows them immediately as cycles.

Identities whose access exceeds their apparent role. Someone in a non-privileged department with indirect access to production Key Vaults via three layers of group nesting. Not malicious activity, just environment drift. The graph surfaces it; the follow-up is a permissions review.

Billing and data retention

The identity attack graph is billed under the Sentinel graph meter. Two cost elements to know about:

• Asset data ingestion: charges apply for ingesting data through the Entra ID Assets and Azure Resource Graph connectors
• Asset data retention: default retention is 30 days, expandable up to 12 years, and you pay for whatever period you configure

Check the Sentinel pricing page for current rates on the graph meter and asset ingestion.

Limitations

• Up to 48 hours for initial build: The graph is not queryable during this window.
• ARG connector ingests partial coverage by default: Only subscriptions where the enabling user has Owner. Expand manually for full tenant coverage (see the ARG section above).
• Schema is Microsoft-managed: You can query what’s there but cannot add custom node or edge types.
• Asset data refreshes once every 24 hours: The graph is a point-in-time snapshot. Recent permission changes may not appear until the next ingestion cycle.
• Preview: Functionality and query behavior are subject to change before GA.

Resources

• What is the identity attack graph? (preview)
• Asset data ingestion in the Microsoft Sentinel data lake
• What is Microsoft Sentinel graph?
• Visualize graphs in Microsoft Sentinel (preview)
• GQL reference for Sentinel custom graph

Closing

I find these graphs a pleasant way to investigate identity risk. No query to write, no schema to design. Just enable, wait, and start exploring paths you didn’t know existed. What I appreciate most is that the predefined queries do the heavy lifting. You don’t need to know what you’re looking for; the graph shows you anyway.

What would make this even more powerful is the ability to take action directly based on what you find: trigger a remediation, flag a path for review, kick off a Conditional Access change. That’s the natural next step and I hope Microsoft moves in that direction.

Curious to see which managed graphs Microsoft ships next. The identity attack graph is clearly the first of several and the foundation is solid. I’ll might cover here more as they become available.

OpenCTI is developed by the French company Filigran and is built around the STIX 2.1 data model from the ground up. Where MISP started as an event-sharing platform and grew into something more, OpenCTI was designed from day one as a structured threat intelligence platform: with native support for threat actors, campaigns, TTPs, and kill chains. It is gaining serious ground in the threat intelligence space, and for good reason.

In this post I’ll walk through the full process: installing OpenCTI on a clean Ubuntu server, adding free threat intelligence feeds and then wiring it up to Microsoft Sentinel so your IOCs automatically flow into your SIEM and become usable in analytics rules.

What is OpenCTI and why does it matter?

OpenCTI is an open-source threat intelligence platform that lets you store, organize, visualize, and share knowledge about cyber threats. It uses the STIX 2.1 standard for data representation, which means everything is structured and consistent: threat actors, malware families, attack patterns, indicators, observables, relationships, all connected.

The key difference from MISP is depth of context. In MISP you work with events and attributes. In OpenCTI you work with entities and relationships: a SHA-256 hash is connected to a malware family, which is connected to a threat actor, which maps to MITRE ATT&CK techniques. You can visually navigate that graph and understand the full picture around a single IOC.

For an MDR context, this is where OpenCTI starts to shine. When an alert fires in Sentinel and you’re looking at a malicious domain, being able to pull up OpenCTI and immediately see which campaigns have used that domain, which malware family dropped it, and what the associated ATT&CK technique is. That’s real context, not just a score.

Microsoft Sentinel ships with built-in threat intelligence, but in my experience it is always worth layering additional sources on top, especially when you want coverage beyond what Microsoft’s feeds provide.

Architecture overview

This post covers the setup and configuration only, not a deep dive into how to use OpenCTI as a platform. Before we dive in, here is what we are building:

OpenCTI runs on Ubuntu via Docker Compose in my demo (for production environments look into splitting resources/roles and use K8s). Threat intel connectors pull data from external sources on a schedule. A Live Stream connector pushes indicators to Microsoft Sentinel in real time using the Graph API tiIndicators endpoint. Sentinel analytics rules then match those indicators against ingested logs.

Part 1: Installing OpenCTI

System requirements

RAM note: Elasticsearch is the main memory consumer. On an 8 GB server you’ll feel the pressure during the initial sync of all connectors simultaneously. 16 GB is strongly recommended for a production deployment.

Install Docker

OpenCTI’s official deployment method is Docker Compose. All dependencies, Elasticsearch, Redis, RabbitMQ, MinIO, run as containers. But again: for production environments cluster all your servers and infrastructure 🙂

# Remove legacy Docker packages
sudo apt remove docker.io docker-compose docker-compose-v2 \
  docker-doc podman-docker containerd runc 2>/dev/null || true

sudo apt update
sudo apt install -y ca-certificates curl

# Add Docker's official GPG key
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg \
  -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

# Add Docker repository
sudo tee /etc/apt/sources.list.d/docker.sources <<EOF
Types: deb
URIs: https://download.docker.com/linux/ubuntu
Suites: $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}")
Components: stable
Signed-By: /etc/apt/keyrings/docker.asc
EOF

sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io \
  docker-buildx-plugin docker-compose-plugin

# Run Docker without sudo
sudo usermod -aG docker $USER
newgrp docker

Set vm.max_map_count

Elasticsearch needs this or it will crash on startup. Do not skip this step.

sudo sysctl -w vm.max_map_count=1048575
echo 'vm.max_map_count=1048575' | sudo tee -a /etc/sysctl.conf

Clone the OpenCTI Docker repository

git clone https://github.com/OpenCTI-Platform/docker.git /opt/opencti
cd /opt/opencti

Configure .env

Generate the values you’ll need:

# UUIDs
cat /proc/sys/kernel/random/uuid

# Encryption key (base64)
openssl rand -base64 32

# Strong password
openssl rand -base64 18 | tr -d '/+=' | cut -c1-20

Create /opt/opencti/.env:

###########################
# DEPENDENCIES            #
###########################
MINIO_ROOT_USER=opencti
MINIO_ROOT_PASSWORD=YourStrongPassword
RABBITMQ_DEFAULT_USER=opencti
RABBITMQ_DEFAULT_PASS=YourStrongPassword
SMTP_HOSTNAME=localhost
OPENSEARCH_ADMIN_PASSWORD=YourStrongPassword
ELASTIC_MEMORY_SIZE=4G

###########################
# COMMON                  #
###########################
XTM_COMPOSER_ID=8215614c-7139-422e-b825-b20fd2a13a23
COMPOSE_PROJECT_NAME=xtm

###########################
# OPENCTI                 #
###########################
OPENCTI_HOST=opencti.yourdomain.com
OPENCTI_PORT=8080
OPENCTI_EXTERNAL_SCHEME=https
OPENCTI_ADMIN_EMAIL=admin@yourdomain.com
OPENCTI_ADMIN_PASSWORD=YourAdminPassword
OPENCTI_ADMIN_TOKEN=<uuid>
OPENCTI_HEALTHCHECK_ACCESS_KEY=<random-string>
OPENCTI_ENCRYPTION_KEY=<base64-32-bytes>

###########################
# OPENCTI CONNECTORS      #
###########################
CONNECTOR_EXPORT_FILE_STIX_ID=dd817c8b-abae-460a-9ebc-97b1551e70e6
CONNECTOR_EXPORT_FILE_CSV_ID=7ba187fb-fde8-4063-92b5-c3da34060dd7
CONNECTOR_EXPORT_FILE_TXT_ID=ca715d9c-bd64-4351-91db-33a8d728a58b
CONNECTOR_IMPORT_FILE_STIX_ID=72327164-0b35-482b-b5d6-a5a3f76b845f
CONNECTOR_IMPORT_DOCUMENT_ID=c3970f8a-ce4b-4497-a381-20b7256f56f0
CONNECTOR_IMPORT_FILE_YARA_ID=7eb45b60-069b-4f7f-83a2-df4d6891d5ec
CONNECTOR_IMPORT_EXTERNAL_REFERENCE_ID=d52dcbc8-fa06-42c7-bbc2-044948c87024
CONNECTOR_ANALYSIS_ID=4dffd77c-ec11-4abe-bca7-fd997f79fa36

###########################
# OPENCTI DEFAULT DATA    #
###########################
CONNECTOR_OPENCTI_ID=dd010812-9027-4726-bf7b-4936979955ae
CONNECTOR_MITRE_ID=8307ea1e-9356-408c-a510-2d7f8b28a0e2

ELASTIC_MEMORY_SIZE: Set to roughly 50% of your total RAM. On 8 GB set 2G, on 16 GB set 6G.

Fix docker-compose.yml

The default docker-compose.yml needs three corrections before you start.

Fix 1: Bind OpenCTI to localhost:

Find the opencti service ports section and change:

# Before
ports:
  - "${OPENCTI_PORT}:8080"

# After
ports:
  - "127.0.0.1:8080:8080"

Fix 2: Bind MinIO to localhost:

Find the minio service ports section and change:

# Before
ports:
  - "9000:9000"

# After
ports:
  - "127.0.0.1:9000:9000"

Fix 3: Remove port from APP__BASE_URL:

Find the opencti service environment and change:

# Before
- APP__BASE_URL=${OPENCTI_EXTERNAL_SCHEME}://${OPENCTI_HOST}:${OPENCTI_PORT}

# After
- APP__BASE_URL=${OPENCTI_EXTERNAL_SCHEME}://${OPENCTI_HOST}

Without this fix, every link inside OpenCTI will have :8080 appended, which breaks navigation when you access it through nginx on port 443.

Install and configure nginx

sudo apt install -y nginx
sudo systemctl enable nginx

Create /etc/nginx/sites-available/opencti:

server {
    listen 80;
    server_name opencti.yourdomain.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    server_name opencti.yourdomain.com;

    ssl_certificate     /etc/ssl/opencti/origin.crt;
    ssl_certificate_key /etc/ssl/opencti/origin.key;
    ssl_protocols       TLSv1.2 TLSv1.3;
    ssl_ciphers         HIGH:!aNULL:!MD5;
    ssl_prefer_server_ciphers on;

    location / {
        proxy_pass         http://127.0.0.1:8080;
        proxy_set_header   Host $host;
        proxy_set_header   X-Real-IP $remote_addr;
        proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header   X-Forwarded-Proto $scheme;

        # WebSocket support - required by OpenCTI
        proxy_http_version 1.1;
        proxy_set_header   Upgrade $http_upgrade;
        proxy_set_header   Connection "upgrade";

        proxy_read_timeout 3600s;
        proxy_send_timeout 3600s;
    }
}

WebSocket support is mandatory. OpenCTI uses WebSockets for live UI updates. Without the Upgrade headers, the interface will partially break.

Enable and start:

sudo ln -s /etc/nginx/sites-available/opencti /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl start nginx

Configure SSL

I’m using Cloudflare for SSL all the way, you can also use LetsEncrypt (bot) to generate SSL certificates. After you obtained a certificate and key:

1. Set hostname to opencti.yourdomain.com for the SSL certificate
2. Copy the Origin Certificate and Private Key

sudo mkdir -p /etc/ssl/opencti
sudo nano /etc/ssl/opencti/origin.crt   # paste the certificate
sudo nano /etc/ssl/opencti/origin.key   # paste the private key
sudo chmod 644 /etc/ssl/opencti/origin.crt
sudo chmod 600 /etc/ssl/opencti/origin.key

Add a DNS A record at your domain registrar:

I would not recommend exposing OpenCTI directly to the internet. If possible, restrict access to specific IP ranges or put it behind a VPN. For an MDR context where multiple analysts need access, a site-to-site VPN or a zero-trust solution is a cleaner approach than opening it up publicly.

Reload nginx:

sudo nginx -t && sudo systemctl reload nginx

Start OpenCTI

cd /opt/opencti
docker compose up -d
docker compose logs -f opencti

Initial startup takes 2–5 minutes. Elasticsearch initializes first, then OpenCTI creates the admin user. Once you see a log entry confirming the admin is ready, navigate to https://opencti.yourdomain.com and log in.

Part 2: Adding threat intelligence feeds

This is where OpenCTI starts earning its keep. Out of the box it already pulls in MITRE ATT&CK and OpenCTI’s own datasets (marking definitions, identities, locations). But you want IOCs, and for that you need external connectors.

Here is what I added, just an example of a few free feeds. You can also move onto paid feeds like Recorded Future. For my POC this is just enough to demonstrate:

Generate UUIDs for each connector

Each connector needs a unique UUIDv4:

for i in 1 2 3 4 5 6 7; do cat /proc/sys/kernel/random/uuid; done

Update .env

Add this section to your .env:

###########################
# THREAT INTEL CONNECTORS #
###########################
CONNECTOR_ABUSECH_ID=<uuid-1>
CONNECTOR_URLHAUS_ID=<uuid-2>
CONNECTOR_ALIENVAULT_ID=<uuid-3>
ALIENVAULT_API_KEY=<your-alienvault-api-key>
CONNECTOR_THREATFOX_ID=<uuid-4>
CONNECTOR_MALWAREBAZAAR_ID=<uuid-5>
CONNECTOR_CISA_KEV_ID=<uuid-6>
CONNECTOR_VIRUSTOTAL_ID=<uuid-7>
VIRUSTOTAL_API_KEY=<your-virustotal-api-key>

Get your API keys:

• AlienVault OTX: https://otx.alienvault.com → Settings → API Key
• VirusTotal: https://www.virustotal.com → Profile → API Key

Add connectors to docker-compose.yml

Add the following services to your docker-compose.yml under the threat intel section:

  connector-abusech:
    image: opencti/connector-abuse-ssl:latest
    environment:
      - OPENCTI_URL=http://opencti:8080
      - OPENCTI_TOKEN=${OPENCTI_ADMIN_TOKEN}
      - CONNECTOR_ID=${CONNECTOR_ABUSECH_ID}
      - CONNECTOR_NAME=AbuseCH
      - CONNECTOR_SCOPE=ipv4-addr,ipv6-addr,domain-name,url,file
      - CONNECTOR_AUTO=true
      - CONNECTOR_CONFIDENCE_LEVEL=80
      - ABUSE_SSL_INTERVAL=43200
    restart: always
    depends_on:
      opencti:
        condition: service_healthy

  connector-urlhaus:
    image: opencti/connector-urlhaus:latest
    environment:
      - OPENCTI_URL=http://opencti:8080
      - OPENCTI_TOKEN=${OPENCTI_ADMIN_TOKEN}
      - CONNECTOR_ID=${CONNECTOR_URLHAUS_ID}
      - CONNECTOR_NAME=URLhaus
      - CONNECTOR_SCOPE=urlhaus
      - CONNECTOR_AUTO=true
      - CONNECTOR_CONFIDENCE_LEVEL=40
      - URLHAUS_CSV_URL=https://urlhaus.abuse.ch/downloads/csv_recent/
      - URLHAUS_IMPORT_OFFLINE=true
      - URLHAUS_CREATE_INDICATORS=true
      - URLHAUS_INTERVAL=3
    restart: always
    depends_on:
      opencti:
        condition: service_healthy

  connector-alienvault:
    image: opencti/connector-alienvault:latest
    environment:
      - OPENCTI_URL=http://opencti:8080
      - OPENCTI_TOKEN=${OPENCTI_ADMIN_TOKEN}
      - CONNECTOR_ID=${CONNECTOR_ALIENVAULT_ID}
      - CONNECTOR_NAME=AlienVault
      - CONNECTOR_SCOPE=alienvault
      - CONNECTOR_AUTO=true
      - CONNECTOR_CONFIDENCE_LEVEL=80
      - ALIENVAULT_BASE_URL=https://otx.alienvault.com
      - ALIENVAULT_API_KEY=${ALIENVAULT_API_KEY}
      - ALIENVAULT_TLP=White
      - ALIENVAULT_CREATE_OBSERVABLES=true
      - ALIENVAULT_CREATE_INDICATORS=true
      - ALIENVAULT_PULSE_START_TIMESTAMP=2020-01-01T00:00:00
      - ALIENVAULT_REPORT_TYPE=threat-report
      - ALIENVAULT_REPORT_STATUS=New
      - ALIENVAULT_GUESS_MALWARE=false
      - ALIENVAULT_GUESS_CVE=false
      - ALIENVAULT_EXCLUDED_PULSE_INDICATOR_TYPES=FileHash-MD5,FileHash-SHA1
      - ALIENVAULT_ENABLE_RELATIONSHIPS=true
      - ALIENVAULT_ENABLE_ATTACK_PATTERNS_INDICATES=false
      - ALIENVAULT_INTERVAL_SEC=1800
    restart: always
    depends_on:
      opencti:
        condition: service_healthy

  connector-threatfox:
    image: opencti/connector-threatfox:latest
    environment:
      - OPENCTI_URL=http://opencti:8080
      - OPENCTI_TOKEN=${OPENCTI_ADMIN_TOKEN}
      - CONNECTOR_ID=${CONNECTOR_THREATFOX_ID}
      - CONNECTOR_NAME=ThreatFox
      - CONNECTOR_SCOPE=threatfox
      - CONNECTOR_AUTO=true
      - CONNECTOR_CONFIDENCE_LEVEL=40
      - THREATFOX_API_KEY=
      - THREATFOX_CREATE_INDICATORS=true
      - THREATFOX_CREATE_OBSERVABLES=true
      - THREATFOX_IMPORT_OFFLINE=true
      - THREATFOX_INTERVAL=3
    restart: always
    depends_on:
      opencti:
        condition: service_healthy

  connector-malwarebazaar:
    image: opencti/connector-malwarebazaar-recent-additions:latest
    environment:
      - OPENCTI_URL=http://opencti:8080
      - OPENCTI_TOKEN=${OPENCTI_ADMIN_TOKEN}
      - CONNECTOR_ID=${CONNECTOR_MALWAREBAZAAR_ID}
      - CONNECTOR_NAME=MalwareBazaar
      - CONNECTOR_SCOPE=malwarebazaar
      - CONNECTOR_AUTO=true
      - CONNECTOR_CONFIDENCE_LEVEL=50
      - MALWAREBAZAAR_CREATE_INDICATORS=true
      - MALWAREBAZAAR_INTERVAL=3
    restart: always
    depends_on:
      opencti:
        condition: service_healthy

  connector-cisa-kev:
    image: opencti/connector-cisa-known-exploited-vulnerabilities:latest
    environment:
      - OPENCTI_URL=http://opencti:8080
      - OPENCTI_TOKEN=${OPENCTI_ADMIN_TOKEN}
      - CONNECTOR_ID=${CONNECTOR_CISA_KEV_ID}
      - CONNECTOR_NAME=CISA KEV
      - CONNECTOR_SCOPE=identity,vulnerability
      - CONNECTOR_AUTO=true
      - CONNECTOR_CONFIDENCE_LEVEL=100
      - CISA_CATALOG_URL=https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json
      - CISA_CREATE_INFRASTRUCTURES=false
      - CISA_TLP=TLP:CLEAR
      - CISA_INTERVAL=3
    restart: always
    depends_on:
      opencti:
        condition: service_healthy

  connector-virustotal-livehunt:
    image: opencti/connector-virustotal-livehunt-notifications:latest
    environment:
      - OPENCTI_URL=http://opencti:8080
      - OPENCTI_TOKEN=${OPENCTI_ADMIN_TOKEN}
      - CONNECTOR_ID=${CONNECTOR_VIRUSTOTAL_ID}
      - CONNECTOR_NAME=VirusTotal
      - CONNECTOR_SCOPE=StixFile,Artifact
      - CONNECTOR_AUTO=true
      - CONNECTOR_CONFIDENCE_LEVEL=50
      - VIRUSTOTAL_API_KEY=${VIRUSTOTAL_API_KEY}
      - VIRUSTOTAL_MAX_TLP=TLP:AMBER
      - VIRUSTOTAL_CREATE_INDICATORS=true
      - VIRUSTOTAL_CREATE_OBSERVABLES=true
      - VIRUSTOTAL_INTERVAL_SEC=300
    restart: always
    depends_on:
      opencti:
        condition: service_healthy

Apply the changes:

cd /opt/opencti
docker compose down
docker compose up -d

Checking connector status

Go to Data → Ingestion → Connectors. All connectors should turn green within a few minutes. AlienVault takes the longest on first sync. It pulls historical pulses going back to 2020 in my config, so give it time.

Once data starts flowing, you can browse it at:

• Observations → Indicators: all IOCs with source, type, TLP, and confidence
• Threats → Malware: malware families from MITRE and connectors
• Threats → Threat Actors: APT groups and their associated campaigns
• Techniques → Attack Patterns: MITRE ATT&CK techniques

Part 3: Connecting OpenCTI to Microsoft Sentinel

This is where the integration becomes operationally relevant. We’re going to push OpenCTI indicators into Sentinel’s Threat Intelligence blade in real time, so they can be used in analytics rules to match against ingested logs.

The connector is opencti/connector-sentinel-intel and it works via OpenCTI’s Live Stream feature: a server-sent events stream that pushes indicator create/update/delete events to the connector, which then forwards them to Sentinel via the Microsoft Graph API.

Azure App Registration

The connector authenticates to Microsoft’s Graph API using an Entra ID app registration. This gives OpenCTI permission to write threat indicators into your Sentinel workspace.

Register the application:

1. Go to portal.azure.com
2. Navigate to Microsoft Entra ID → App registrations
3. Click New registration
4. Fill in the details:
   • Name: OpenCTI-Sentinel-Connector
   • Supported account types: Accounts in this organizational directory only
   • Redirect URI: leave empty
5. Click Register

You will land on the app overview page. Note down two values. You’ll need both later:

• Application (client) ID: this is your CLIENT_ID
• Directory (tenant) ID: this is your TENANT_ID

Add API permissions:

The connector needs permission to read and write threat indicators. This permission is on the Microsoft Threat Intelligence API, not Microsoft Graph.

1. In the left sidebar click API permissions
2. Click Add a permission
3. Scroll down and select Microsoft Threat Intelligence
4. Select Application permissions (not Delegated)
5. Expand the list and check ThreatIndicators.ReadWrite.OwnedBy
6. Click Add permissions

After adding the permission, it will show as Not granted. You need to grant admin consent:

7. Click Grant admin consent for [your tenant name]
8. Confirm by clicking Yes

The permission status should now show a green checkmark and read Granted for [your tenant].

This step requires a Global Administrator or Privileged Role Administrator role in Entra ID. If you don’t have that role, ask your Azure admin to grant consent.

Create a client secret:

The connector uses a client secret to authenticate. Think of it as a password for the app registration.

1. In the left sidebar click Certificates & secrets
2. Click Client secrets tab
3. Click New client secret
4. Set a description (e.g. opencti-connector) and an expiry period
5. Click Add

Azure will show the secret in the list. It has two columns:

6. Copy the Value column immediately

Enable Threat Intelligence in Sentinel

Before Sentinel can receive indicators from OpenCTI, you need to enable the Threat Intelligence solution and its data connector.

Install the Threat Intelligence solution:

1. Go to Microsoft Sentinel → your workspace
2. In the left sidebar click Content Hub
3. In the search box type Threat Intelligence
4. Click on the Threat Intelligence solution by Microsoft
5. Click Install in the right panel

Wait for the installation to complete. It installs the data connector, workbooks, and analytics rule templates.

Enable the Threat Intelligence Platforms data connector:

1. In Microsoft Sentinel → Data connectors
2. Search for Threat Intelligence Platforms
3. Click on it and then click Open connector page
4. Click Connect to enable it

This connector is what receives the indicators pushed via the Microsoft Graph API. Without enabling it, no data will flow into Sentinel even if the OpenCTI connector is running correctly.

Verify the connector is active:

After connecting, the status should show as Connected with a green indicator. The Data received section will show the first data once indicators start flowing from OpenCTI.

Create a Live Stream in OpenCTI

1. Go to Data → Data Sharing → Live Streams
2. Click +, give it a name (e.g. Sentinel), leave it private, click Create
3. Copy the generated Stream ID

Get the Sentinel Workspace ID

In Microsoft Sentinel → Settings → Workspace settings, copy the Workspace ID

Add connector to docker-compose.yml

Generate a UUID for the connector:

cat /proc/sys/kernel/random/uuid

Add to .env:

###########################
# SENTINEL INTEGRATION    #
###########################
CONNECTOR_SENTINEL_INTEL_ID=<uuid>
SENTINEL_STREAM_ID=<stream-id-from-opencti>
SENTINEL_TENANT_ID=<directory-tenant-id>
SENTINEL_CLIENT_ID=<application-client-id>
SENTINEL_CLIENT_SECRET=<client-secret-value>
SENTINEL_WORKSPACE_ID=<sentinel-workspace-id>

Add to docker-compose.yml:

  ###########################
  # SENTINEL INTEGRATION    #
  ###########################

  connector-sentinel-intel:
    image: opencti/connector-sentinel-intel:latest
    environment:
      - OPENCTI_URL=http://opencti:8080
      - OPENCTI_TOKEN=${OPENCTI_ADMIN_TOKEN}
      - CONNECTOR_ID=${CONNECTOR_SENTINEL_INTEL_ID}
      - CONNECTOR_LIVE_STREAM_ID=${SENTINEL_STREAM_ID}
      - CONNECTOR_LIVE_STREAM_LISTEN_DELETE=true
      - CONNECTOR_LIVE_STREAM_NO_DEPENDENCIES=true
      - "CONNECTOR_NAME=Microsoft Sentinel Intel"
      - CONNECTOR_SCOPE=sentinel
      - CONNECTOR_CONFIDENCE_LEVEL=80
      - CONNECTOR_LOG_LEVEL=error
      - SENTINEL_INTEL_TENANT_ID=${SENTINEL_TENANT_ID}
      - SENTINEL_INTEL_CLIENT_ID=${SENTINEL_CLIENT_ID}
      - SENTINEL_INTEL_CLIENT_SECRET=${SENTINEL_CLIENT_SECRET}
      - SENTINEL_WORKSPACE_ID=${SENTINEL_WORKSPACE_ID}
      - "SENTINEL_INTEL_TARGET_PRODUCT=Azure Sentinel"
      - SENTINEL_INTEL_LOGIN_URL=https://login.microsoftonline.com
      - SENTINEL_INTEL_BASE_URL=https://graph.microsoft.com
      - SENTINEL_INTEL_RESOURCE_PATH=/beta/security/tiIndicators
      - SENTINEL_INTEL_EXPIRE_TIME=30
      - SENTINEL_INTEL_ACTION=alert
    restart: always
    depends_on:
      opencti:
        condition: service_healthy

Apply:

cd /opt/opencti
docker compose up -d connector-sentinel-intel
docker compose logs -f connector-sentinel-intel

The connector will show KeyError: 'data' errors on stream heartbeat messages. This is a known bug in the connector and does not affect functionality. What you should not see is authentication errors or Invalid URL 'NoneNone'.

Verifying indicators in Sentinel

Go to Microsoft Sentinel → Threat Intelligence. Indicators should start appearing within a few minutes:

Once indicators are in Sentinel you can query them in KQL:

ThreatIntelIndicators
| where TimeGenerated > ago(24h)
| where isnotempty(ObservableKey)
| extend IndicatorType = tostring(split(ObservableKey, ":", 0)[0])
| summarize Count = count() by IndicatorType
| order by Count desc

Match IP indicators against CommonSecurityLog (firewalls, proxies):

let dt_lookBack = 1h;
let ioc_lookBack = 14d;
let IP_Indicators = ThreatIntelIndicators
    | extend IndicatorType = replace(@"\[|\]|\""", "", tostring(split(ObservableKey, ":", 0)))
    | where IndicatorType in ("ipv4-addr", "ipv6-addr", "network-traffic")
    | extend TI_ipEntity = toupper(ObservableValue)
    | where TimeGenerated >= ago(ioc_lookBack)
    | where ipv4_is_private(TI_ipEntity) == false
    | where isnotempty(TI_ipEntity)
    | summarize arg_max(TimeGenerated, *) by TI_ipEntity;
IP_Indicators
| join kind=innerunique (
    CommonSecurityLog
    | where TimeGenerated >= ago(dt_lookBack)
    | extend CS_ipEntity = toupper(DestinationIP)
    | where isnotempty(CS_ipEntity)
) on $left.TI_ipEntity == $right.CS_ipEntity
| project
    TimeGenerated,
    TI_ipEntity,
    SourceIP,
    DestinationIP,
    DeviceVendor,
    Activity,
    Confidence,
    Tags
| order by TimeGenerated desc

Match domain indicators against DNS events:

let dt_lookBack = 1h;
let ioc_lookBack = 14d;
let Domain_Indicators = ThreatIntelIndicators
    | where ObservableKey == "domain-name:value"
    | extend TI_domainEntity = tolower(ObservableValue)
    | where TimeGenerated >= ago(ioc_lookBack)
    | where isnotempty(TI_domainEntity)
    | summarize arg_max(TimeGenerated, *) by TI_domainEntity;
Domain_Indicators
| join kind=innerunique (
    DnsEvents
    | where TimeGenerated >= ago(dt_lookBack)
    | extend DNS_Name = tolower(Name)
    | where isnotempty(DNS_Name)
) on $left.TI_domainEntity == $right.DNS_Name
| project
    TimeGenerated,
    TI_domainEntity,
    ClientIP,
    Confidence,
    Tags
| order by TimeGenerated desc

Match file hash indicators against Defender for Endpoint:

let dt_lookBack = 1h;
let ioc_lookBack = 14d;
let Hash_Indicators = ThreatIntelIndicators
    | where ObservableKey has "file:hashes"
    | extend TI_hashEntity = toupper(ObservableValue)
    | where TimeGenerated >= ago(ioc_lookBack)
    | where isnotempty(TI_hashEntity)
    | summarize arg_max(TimeGenerated, *) by TI_hashEntity;
Hash_Indicators
| join kind=innerunique (
    DeviceFileEvents
    | where TimeGenerated >= ago(dt_lookBack)
    | extend File_SHA256 = toupper(SHA256)
    | where isnotempty(File_SHA256)
) on $left.TI_hashEntity == $right.File_SHA256
| project
    TimeGenerated,
    TI_hashEntity,
    DeviceName,
    FileName,
    FolderPath,
    Confidence,
    Tags
| order by TimeGenerated desc

Closing thoughts

Coming from MISP, OpenCTI took me a little while to get used to: the mental model is different. But once you start navigating the entity graph and seeing how everything connects, it clicks. A malware hash becomes more than a hash: it’s part of a campaign, tied to a threat actor, mapped to ATT&CK techniques. That context is what makes the difference in an investigation.

The Sentinel integration is genuinely useful for an MDR operation. You maintain one source of truth for threat intelligence and it flows automatically into your SIEM without any manual steps. No CSV exports, no copy-pasting, no manual watchlist updates.

In a follow-up post I’ll look at using the imported indicators in Sentinel analytics rules and how to build workbooks around the threat intelligence data. For now. This stack is running, the indicators are flowing, and it’s already looking AND working good. Need to get more familiar with OpenCTI but honest: it’s promising.

In a previous post on modernsecurity.nl, I walked through the classic installation of Microsoft Defender for Identity (MDI) using the v2.x sensor: prerequisites, gMSA configuration, Windows event auditing, NTLM auditing, and the manual download-and-install process. If you’ve deployed MDI before, you’ll remember the overhead: downloading an installer package, running it on each domain controller, creating and maintaining a gMSA account, configuring audit GPOs, and dealing with Npcap.

That process is now behind us.

With the general availability of the Microsoft Defender for Identity sensor v3.x in early 2026, and the release of the portal-based migration wizard in March 2026, Microsoft has completely changed how MDI sensors are deployed and managed. The new sensor runs as an extension of Microsoft Defender for Endpoint (MDE): if MDE is already on your domain controllers (as it should be), MDI protection is now a matter of a few clicks from the portal.

This guide covers everything you need:

• What changed and why it matters
• Prerequisites for both fresh deployments and migrations
• Deploying the sensor from the Defender portal
• Migrating existing v2.x sensors to v3.x with zero downtime
• Post-deployment and post-migration configuration: RPC auditing, automatic Windows auditing, and gMSA removal

All steps are verified against Microsoft Learn documentation and tested in live environments.

What changed with the MDI sensor v3.x

The biggest change is architectural. The v3.x sensor is not a standalone agent. It runs as a component within the MDE/SENSE service already present on your domain controllers. This is the long-awaited unification of endpoint and identity telemetry into a single agent.

Beyond deployment simplicity, v3.x also brings detection improvements: it uses the Windows Filtering Platform (WFP) for deeper network inspection, adds enhanced RPC auditing for advanced identity attack detections, and caps resource usage at 30% CPU and 1.5 GB memory.

Prerequisites

Before diving into the requirements, a quick note on scope. The v3.x sensor applies to domain controllers running Windows Server 2019 or later. Two scenarios still require the v2.x classic sensor:

• Domain controllers running Windows Server 2016 or earlier
• Standalone servers running AD FS, AD CS, or Microsoft Entra Connect without a DC role: v3.x will never apply here since the sensor only runs on domain controllers

DCs that also run AD FS, AD CS, or Entra Connect alongside the DC role are supported by v3.x as of March 2026, but the migration wizard does not support them yet. Those require a fresh deployment. See Supported server roles and the following decision tree:

Licensing and permissions

One of the following licenses is required:

To deploy, you need one of the following:

Server requirements

The March 2026 cumulative update is a hard dependency. Without it, activation or migration will fail. Apply it to all domain controllers before proceeding. The KB number varies by OS version: KB5078766 is for Windows Server 2022.

If you are doing a fresh deployment, the target DC must not already have a v2.x sensor installed. If you are migrating, the v2.x sensor must be installed and running. Those prerequisites are listed separately in the Migration from v2.x to v3.x section.

Supported server roles

As of April 2026:

Validating prerequisites

Microsoft provides two useful PowerShell scripts from the DefenderForIdentity module. Both are optional but recommended before a large rollout. Both can be found in the portal from: Identities > Tools:

Test-MDIReadiness checks sensor prerequisites: connectivity, permissions, MDE deployment, and overall sensor readiness:

Install-Module -Name DefenderForIdentity
Test-MDIReadiness

New-MDIConfigurationReport generates an HTML report of your current Windows event auditing configuration, showing exactly which audit policies and SACL settings are missing or misconfigured:

New-MDIConfigurationReport -Path "C:\Reports" -Mode Domain -OpenHtmlReport

Test-MDIReadiness is also available directly in the Defender portal at Identities > Tools (Preview), no download required. New-MDIConfigurationReport requires the PowerShell module installed locally.

Deploying the sensor

Activating the sensor

Microsoft recommends activating the sensor on all domain controllers, including read-only domain controllers (RODCs). For complete coverage, make sure every DC, including RODCs, has MDE deployed and the March 2026 cumulative update installed before proceeding.

Navigate to the Microsoft Defender portal and go to System > Settings > Identities > Activation.

The portal auto-discovers your domain controllers from the Device Inventory (populated by MDE onboarding). Each server is listed with its current activation state:

In some portal versions the label may show as “Activate sensor v3.x” instead of “Activate new sensor”: both mean the same thing.

When you first land on this page with no sensors deployed, you may see a “Simplify Your Installation Process” dialog. Click Activate servers to proceed with the new activation-based flow, no installer download needed.

You’ll also see two activation modes:

• Automatically activate eligible servers: MDI activates sensors as soon as eligible DCs are discovered. Good for consistent environments.
• Manually select servers to activate: You control which DCs get activated. Recommended for phased rollouts and MSSP/MSP multi-tenant management.

To activate:

1. Select one or more domain controllers from the list.
2. Click Activate in the toolbar.
3. In the “Activate New Sensor” confirmation dialog, verify the selected servers and click Activate.

No installer download, no remote execution, no reboot required. When activation completes, a green success banner appears, click Click here to see the onboarded servers to go directly to the Sensors page.

Verifying sensor status

Navigate to Settings > Identities > On-premises > Sensors

After activation, sensors will initially appear with the following status. This is expected:

Wait 15–30 minutes and refresh. A healthy sensor will show:

The first activation on a tenant can take up to 1 hour to show as Running. Subsequent activations typically reflect within 5 minutes. No restart is required.

Configuring RPC auditing

RPC (Remote Procedure Call) is a core Windows protocol heavily used in Active Directory for authentication, replication, and directory access. Attackers abuse it for lateral movement and privilege escalation. The v3.x sensor supports enhanced RPC auditing for advanced identity attack detections, but this must be explicitly enabled by applying the Unified Sensor RPC Audit tag via an asset rule.

Navigate to Settings > Microsoft Defender XDR > Asset rule management and click Create a new rule

In the wizard:

1. On Name and description, enter Unified Sensor RPC Audit as the rule name, add a description, and click Next.

2. On Rule conditions, define which devices the rule targets. Use Device name with Starts with conditions to match your DC naming convention. Use OR logic to cover multiple DCs. You can also filter by Domain or Device tag. Click Next.

   Only target devices that already have the MDI v3.x sensor installed and running. The tag has no effect on devices without the v3.x sensor.

3. On Select actions, expand Apply a tag and select or type Unified Sensor RPC Audit. Click Next.

4. On Review and finish, verify the rule name, tag, and number of affected devices. Click Submit.

The rule can take up to 1 hour to take effect. To remove RPC auditing from a device later, delete the rule or update the conditions to exclude it.

Enabling automatic Windows auditing

Windows event log collection is the foundation of MDI’s detection engine. The sensor relies on events such as 4662 (object access), 4776 (NTLM authentication), and 4688 (process creation) to detect suspicious activity.

In the v2.x era, this required manually configuring Group Policy Objects, SACL entries on the domain root, and NTLM auditing registry values. With v3.x there’s a preview feature that handles all of this automatically.

Navigate to Settings > Identities > General > Advanced features

The Automatic Windows auditing configuration (preview) toggle is set to Off by default. Toggle it to On and click Save preferences.

What this configures automatically on each eligible DC:

• Directory Services advanced auditing (SACL on the domain root object)
• NTLM auditing via Windows Registry
• Domain object auditing (SACL on the Configuration partition)
• AD FS auditing (SACL on the AD FS configuration container)
• Windows audit policy subcategories via Local Security Authority (LSA) APIs

The check runs once every 24 hours, so it will self-correct any auditing drift over time, not just at initial deployment.

GPO conflict warning: GPO settings applied to domain controllers can conflict with local settings applied by the sensor. If you have existing GPOs enforcing audit policies, check for conflicts after enabling this feature. The health alerts in Settings > Identities > Health issues will surface any configuration gaps that couldn’t be auto-corrected.

This feature only applies to domain controllers with the v3.x sensor installed and updated to the latest cumulative update. Manual GPO-based configuration still works if you prefer. See the Microsoft Learn documentation.

Migration from v2.x to v3.x

If you have existing MDI v2.x sensors, this section walks through the migration. The migration itself is portal-driven and non-disruptive: the v2.x sensor keeps running until the v3.x sensor is fully ready. After migration completes, there are a few configuration steps to apply, including switching away from gMSA.

Migration prerequisites

Important: The migration wizard does not support domain controllers that also run AD FS, AD CS, or Entra Connect roles, even though v3.x itself now supports these DCs via fresh deployment. If your DC carries one of these additional roles, uninstall the v2.x sensor manually and then activate v3.x from the Activation page instead of using the Migrate button.

Common issue: If a DC doesn’t appear as “Ready for migration”, check the MDE/SENSE service version first. An outdated MDE sensor can block the migration. Update MDE to the latest version and try again.

Running the migration

Navigate to Settings > Identities > On-premises > Sensors. Eligible servers show Ready for migration in the Migration state column.

1. Select the DCs you want to migrate. You can select all at once or work in batches.
2. Click Migrate in the toolbar.
3. In the confirmation dialog, verify the server names and click Migrate.

Migration takes up to 20 minutes per batch. During this time:

• The v2.x sensor continues running and sending telemetry, no detection gap
• The v3.x sensor is installed and initialized in the background
• Switchover happens automatically once v3.x is ready
• No reboot is required

The Migration state column will progress: Ready for migration → Migrating → Already V3 sensor.

Once complete, confirm the sensors show Service status Running, Sensor status Up to date, and version 3.0.7.419 or later.

Post-migration configuration

After migration completes, apply the following configuration steps:

Remove gMSA

The v3.x sensor uses the Local SYSTEM account for all Active Directory queries and response actions. There is no longer a need for a Group Managed Service Account.

Critical: If gMSA remains enabled after migration, response actions will stop working. This includes disabling compromised accounts, resetting passwords, and forcing password expiration, both automated and manual.

Navigate to Settings > Identities > General > Manage action accounts, select Automatically use the sensor’s local system account, and click Save.

If you’re running a phased migration with some DCs still on v2.x, switch all sensors to local system accounts now. Mixing gMSA and local system in the same environment causes inconsistencies in response actions.

Configure RPC auditing

If the Unified Sensor RPC Audit asset rule doesn’t exist yet, create it following the steps in the Configuring RPC auditing section above. If the rule already exists, update the conditions to include the newly migrated DCs.

Enable automatic Windows auditing

Navigate to Settings > Identities > General > Advanced features and enable the Automatic Windows auditing configuration (preview) toggle if not already active. Existing auditing settings from the v2.x sensor are preserved during migration, but enabling automatic auditing will validate and correct any gaps.

Cleaning up the v2.x sensor

After confirming the v3.x sensor is healthy, remove the legacy components from each DC.

Uninstall the v2.x sensor: Go to Settings > Apps (or Add/Remove Programs) and uninstall “Azure Advanced Threat Protection Sensor”.

This may require a server reboot. Plan it during a maintenance window. After uninstalling, the sensor entry is automatically removed from the portal. If it persists, delete it manually from Settings > Identities > Sensors.

Remove Npcap: The v2.x sensor installed Npcap for network packet capture. The v3.x sensor does not use it. Unless another application on the DC requires Npcap, uninstall it via Add/Remove Programs.

Health alerts

After deployment, keep an eye on Settings > Identities > Health issues for these two alerts:

Frequently asked questions

Do I need to uninstall v2.x before activating v3.x?
For fresh deployments on a clean DC, yes: a DC cannot have both sensors simultaneously. For migrations, the portal wizard manages the transition automatically without a manual uninstall first.

What are the known limitations in v3.x?
Known limitations of v3.x are: no VPN integration, no syslog notifications, and limited Azure ExpressRoute compatibility.

Will I lose detection coverage during migration?
No. The v2.x sensor continues running and reporting until the v3.x sensor is fully initialized. There is no detection gap.

My DC runs Windows Server 2016: can I use v3.x? No. v3.x requires Windows Server 2019 or later with the March 2026 cumulative update. Either upgrade the OS or continue with the v2.x sensor.

Is the March 2026 cumulative update a hard requirement?
Yes. Without it, activation or migration will fail. Apply it before starting.

Can I still configure Windows auditing manually?
Yes. Automatic auditing is a preview feature and optional. Manual GPO-based configuration continues to work with v3.x.

What about AD FS or AD CS servers?
For standalone servers not running a DC role, continue with v2.x: v3.x does not apply there. For DCs that also run AD FS, AD CS, or Entra Connect roles, v3.x support is rolling out as of March 2026. Note that the migration wizard does not support these DCs. They require a fresh v3.x deployment: uninstall v2.x manually, then activate v3.x from the Activation page.

The RPC audit rule is applied, how do I verify it’s working? Check Settings > Identities > Health issues. If the tag is correctly applied and the sensor is running, the “Sensor v3.x RPC audit misconfigured” alert will not appear. Allow up to 1 hour after rule creation.

References

Install Microsoft Defender for Identity (classic v2.x guide), modernsecurity.nl

Defender for Identity sensor v3.x prerequisites: Microsoft Learn

Activate the Defender for Identity sensor v3.x: Microsoft Learn

Migrate from sensor v2.x to sensor v3.x: Microsoft Learn

Configure Windows event collection: Microsoft Learn

What’s new in Microsoft Defender for Identity: Microsoft Learn

Conclusion

The Microsoft Defender for Identity sensor v3.x is a major improvement in how identity security is deployed and operated. By building on MDE infrastructure already present on your domain controllers, Microsoft has removed most of the friction that made MDI deployments time-consuming. No more installer packages, no gMSA accounts to manage, no manual audit GPOs, no Npcap to maintain.

For MSSP and enterprise teams managing MDI across multiple tenants, this simplification is significant. Activation is portal-based and takes minutes. Post-deployment configuration, RPC audit tagging and automatic Windows auditing, runs without touching Group Policy.

If you’re still running v2.x, the migration path is now stable and production-ready. Check the March 2026 cumulative update, confirm MDE is deployed and healthy on your DCs, and use the built-in migration wizard. Once migration completes, switch from gMSA to local system and apply the RPC audit tag. The v2.x sensor stays running until v3.x is ready, no maintenance window needed.

The approach: enable the XDR connector and use a Workspace Transformation DCR to redirect data from the original XDR table into that custom table. It worked: the analytics tier was skipped and data landed in the lake at a much lower cost.

But it was a workaround. You had to create and maintain custom tables, manually map schemas, and keep the transformation DCR in sync with any table changes. The XDR connector still needed to be active, and the whole setup was kind of fragile compared to a native solution.

This month Microsoft made that workaround obsolete 🙂

Lake-only ingestion for Defender XDR Advanced Hunting tables is now generally available. You can configure supported tables to stream directly into the Sentinel data lake from the Defender portal: no custom tables, no DCR, no schema mapping to maintain. The same outcome, natively supported.

This post covers what changed, which tables are supported, the key limitations to understand before switching, and a step-by-step configuration walkthrough the portal.

The problem with the old approaches

Before this release, there were four ways to handle Defender XDR Advanced Hunting data in Sentinel:

What lake-only ingestion actually means

When you configure a table for lake-only ingestion, a copy of the data is streamed directly from Defender XDR into the Sentinel data lake tier. The data never touches the analytics tier in your Log Analytics workspace.

Defender XDR still retains the data in its own native tier for 30 days. Advanced Hunting in the Defender portal continues to work normally for that window. Custom detection rules and automated response rules are unaffected.

What changes is what happens beyond 30 days: instead of the data disappearing or requiring an expensive analytics pipeline, a copy flows continuously into the data lake for up to 12 years. There are important limitations to understand before switching. See the limitations section below.

Supported tables at GA

Lake-only ingestion is supported for the following Defender XDR Advanced Hunting tables across three Defender workloads. Microsoft Defender for Identity (MDI) and (UEBA) behaviors support is not yet available but is on the roadmap.

Defender for Endpoint (MDE)

Defender for Office 365 (MDO)

Defender for Cloud Apps (MDA)

Prerequisites

Before configuring lake-only ingestion, the following must be in place:

How to configure lake-only ingestion (step by step)

The entire configuration lives in the Defender portal under table management. No DCR creation, no Azure Monitor Agent, no connector deployment in the Azure portal.

Step 1: Open table management

In the Defender portal, expand Microsoft Sentinel in the left navigation bar. Go to Configuration > Tables.

Step 2: Find the table you want to configure

Use the search bar to filter by table name, for example DeviceNetworkEvents. The overview shows the current tier, analytics retention, and total retention for all tables in your workspace.

Step 3: Open data retention settings

Select the table to open the side panel, then click Data retention settings.

Step 4: Select data lake tier

In the retention settings panel, select the Data lake tier option. You will notice that the analytics retention control is locked at 30 days. This is the included XDR license retention. Set the total retention period you want in the data lake (up to 12 years).

Step 5: Save

Click save. New data will start flowing directly into the data lake. Expect a delay of 90–120 minutes before data appears in the lake.

Note: switching to data lake tier only applies to new incoming data. Existing data already in the analytics tier is not moved or back filled. If you previously had a table ingesting into the analytics tier and want to migrate, plan the transition window accordingly.

How to query data in lake-only tables

Data in the data lake tier is not available through the regular Sentinel Logs blade or through Log Analytics workspace queries. You access it through the data lake exploration experience in the Defender portal.

Navigate to Microsoft Sentinel > Data lake exploration > KQL queries and run your KQL query against the table name as normal. Full KQL capabilities are supported including join and union operators.

For scheduled or large-scale retrospective queries, use KQL jobs. These run against the full retention window in the lake and can promote results back into the analytics tier if needed for further investigation.

Limitations to know before you switch

This is the part that matters operationally. The lake-only tier is not a full replacement for the analytics tier.

One important distinction: Defender XDR custom detection rules continue to work when you switch to lake-only, as they run against the native XDR tier in the Defender portal, not against Sentinel’s analytics tier.

What stops working is the Sentinel side: analytics rules, hunting queries, workbooks, and playbooks that reference that table. If any of those are in use, switching to lake-only will break them silently: the table simply won’t have data in the analytics tier anymore.

The practical guidance: if you run active Sentinel analytics rules or Sentinel hunting queries referencing a specific XDR table, keep that table in the analytics tier. If a table is primarily used for investigation, forensics, or retrospective hunting, and detections only live on the Defender XDR side, lake-only is the right choice.

Good candidates for lake-only: DeviceFileCertificateInfo, DeviceImageLoadEvents, DeviceNetworkInfo, EmailUrlInfo, UrlClickEvents.

Tables to evaluate carefully before switching: DeviceProcessEvents, DeviceNetworkEvents, DeviceLogonEvents. These are commonly used in custom Sentinel analytics rules.

Cost considerations

The cost difference is significant for high-volume tables.

When data goes through the analytics tier first, you pay the analytics ingestion rate for every GB. When data goes directly to the data lake tier, you pay the data lake ingestion rate ($0.05/GB in East US) plus storage, but avoid analytics tier ingestion costs entirely. There is also a data processing charge ($0.10/GB) for data ingested directly to lake tier. This does not apply to data mirrored from the analytics tier.

For tables like DeviceNetworkEvents or CloudAppEvents that generate significant daily volume, this difference is substantial. If you were previously not ingesting these tables at all due to cost, lake-only ingestion makes long-term retention financially realistic.

Note: always verify current pricing in the Microsoft Sentinel pricing page as rates vary by region and are subject to change.

Migrating from the DCR workaround

If you followed the approach in my older post and are currently running the Workspace Transformation DCR workaround with custom _CL tables, here is how to migrate cleanly to the native solution.

Before you switch:

• Verify that no active Sentinel analytics rules or Sentinel hunting queries reference the custom _CL table you created. If they do, update them first to reference the new native table.
• Note your current retention setting on the custom table. You will want to match this when configuring the native lake-only retention.
• Accept that historical data in the custom _CL table stays there. Switching to native lake-only ingestion does not migrate or merge existing data. The two datasets will exist in parallel until the custom table’s retention expires.

Steps to migrate:

1. Configure the original XDR table (e.g. DeviceProcessEvents) for lake-only ingestion using the steps in this post.
2. Wait 90–120 minutes for data to start flowing into the native table in the data lake.
3. Verify data is arriving in the data lake by running a KQL query in Microsoft Sentinel > Data lake exploration > KQL queries.
4. Once confirmed, remove the Workspace Transformation DCR rule for that table, or update it to drop all rows to source | take 0 if other tables share the same DCR and you are not ready to remove it entirely.
5. Optionally reduce the retention on the custom _CL table once the historical data is no longer needed.

The main benefit beyond simplicity: the native table preserves the original schema exactly, including all columns. The DCR workaround required manual schema mapping and often dropped columns or required ongoing maintenance when Microsoft updated the source table structure.

Sources

Microsoft Sentinel data lake overview: Microsoft Learn

Microsoft GA announcement: Tech Community, February 11, 2026

Manage data tiers and retention in Microsoft Sentinel: Microsoft Learn

Summary

Lake-only ingestion for Defender XDR Advanced Hunting tables removes the biggest practical barrier to long-term XDR data retention. You no longer need a DCR pipeline, you no longer pay analytics ingestion rates for data that’s primarily used for historical hunting, and you configure everything natively in the Defender portal in a few clicks.

If you have Sentinel data lake enabled, this is one of the first things worth reviewing. Go through the supported table list, identify which tables you don’t have active Sentinel analytics rules on, and switch those to lake-only. Start with the high-volume candidates and work from there.

For the full Sentinel data lake setup and background, check out my implementation guide.

In DFIR scenarios where every minute counts, that lack of a centralized, ready-to-go script library is a real operational problem. You’re context-switching between the investigation and hunting for tools that should already be at your fingertips. That pain point is now addressed. Microsoft introduced library management for live response, which entered public preview in February 2026 and reached general availability in March 2026.

If you’re new to live response itself, I covered the foundations, including selective isolation and how it enables safe forensics during containment, in my earlier post: Selective Isolation in Defender for Endpoint – Combining tools like Velociraptor for DFIR. This post builds on that and focuses specifically on the new library management experience.

What is live response library management?

Library management is a dedicated section in the Microsoft Defender portal that provides a centralized, tenant-level repository for all scripts and files used during live response sessions. Before this feature existed, the only way to add a script to the library was from within an active session, not ideal during an escalating incident.

The problem it solves is a familiar one: scripts scattered across personal laptops, shared drives, and GitHub repos with no consistent versioning, no team-wide visibility, and no audit trail. Library management consolidates all of that into a single managed location inside Defender itself.

Prerequisites and licensing

What you can do with it

All operations are available outside of an active live response session, which is the key improvement over the previous experience:

• Upload PowerShell scripts, batch files, and other response utilities in advance
• View script contents directly in the Defender portal without switching to an external editor
• Download files back to your workstation when needed
• Delete outdated or redundant scripts in a single click
• Analyze scripts using Microsoft Security Copilot (license required)

The Copilot analysis is worth highlighting. Select a script and choose Analyze, and Security Copilot generates a natural-language summary covering what the script does, the methods it uses, any network calls or privilege operations, and potential execution risks. This is especially useful when analysts are working with inherited toolsets. Without a Copilot license, you can still view script contents. You just won’t get the automated analysis.

How to set it up

Navigate to the library management page via Settings → Endpoints → Library management in the Microsoft Defender portal. You can also reach it directly from within an active live response session.

To upload a script:

1. Select Upload from the top menu
2. In the upload panel, select Upload file to library and choose your file
3. Add a file description. This is the only documentation other analysts will see, so make it count
4. If you’re replacing an existing script, check Overwrite file
5. Optionally add a parameters description if the script accepts arguments
6. Select Submit to complete the upload

The file is immediately available to all authorized analysts across the tenant. There are no per-device or per-device-group restrictions at the library level.

Audit logging

All library management actions are tracked in the Microsoft Defender audit log: uploads, downloads, deletions, and file listings, each recorded with user context and a timestamp. To view these logs, go to Settings → Audit and filter using the following criteria:

• Activities – friendly names: Ran live response session
• Record types: MSDEResponseActions For managed service environments where multiple analysts share access to the same tenant library, this gives you full visibility into who changed what and when.

What this means for SOC teams

Library management shifts the mindset from reactive to prepared. Instead of scrambling mid-incident, teams can now pre-stage a standard toolkit before any alert fires, triage scripts, forensic collectors, persistence checkers, and keep it versioned through the description field. New analysts can explore the team’s standard toolset through the portal, with Copilot to explain anything unfamiliar.

In an MSP or MSSP context, this has immediate operational value. Inconsistent script collections across customer tenants are the norm when you’re managing 50+ environments. A centralized, auditable library per tenant brings consistency that previously required custom automation around the Live Response API.

A word on security

Live response runs in a privileged context on endpoints. A centralized script library increases the blast radius if an account is compromised or if scripts aren’t reviewed before upload. A few things worth enforcing: separate upload and execute permissions in RBAC so not every analyst who can run scripts can also add new ones, restrict live response on tier-0 assets unless a formal escalation process is in place, and don’t treat Copilot analysis as a security gate. It provides context, not sandboxing. Test scripts in a controlled environment before they land in a shared tenant library.

Resources

Selective Isolation in Defender for Endpoint – modernsecurity.nl

Manage the live response file library in Microsoft Defender for Endpoint – Microsoft Learn

Live response command examples – Microsoft Learn

What’s new in Microsoft Defender for Endpoint – Microsoft Learn

Monthly news – March 2026 (February updates) – Microsoft Tech Community

Summary

Library management for live response is one of those features that quietly makes a significant operational difference. It removes friction from incident response preparation, brings consistency across analyst teams, and adds an audit trail that managed service providers have needed for a while. The feature entered public preview in February 2026 and reached general availability in March 2026.

Microsoft’s new UEBA behaviors layer in Microsoft Sentinel changes that. Instead of forcing analysts to reconstruct the story from raw telemetry, it produces it for them: normalized, enriched, MITRE-mapped behavioral summaries that explain “who did what to whom” in plain language. It went generally available in early 2026, and if you’re running Sentinel with non-Microsoft data sources like AWS CloudTrail, Palo Alto, or GCP, this is something you should enable today.

In this post I’ll walk you through what the behaviors layer is, how it works under the hood, how to enable it, and what you can do with it: including practical KQL queries for investigation, threat hunting, and detection.

What is the UEBA behaviors layer?

Before this feature existed, Microsoft Sentinel’s UEBA already provided anomaly detection, flagging when a user deviated from their behavioral baseline. That’s valuable, but anomalies are event-level: a single unusual API call, a first-time login from a new location.

The behaviors layer sits in a different spot in the stack. Rather than flagging individual events, it aggregates and sequences related events across a time window into a single, structured behavior record. Think of it as the difference between:

“User performed s3:GetObject 847 times between 14:00–15:00″

versus raw CloudTrail telling you nothing without a KQL query to make sense of it.

There are two types of behaviors:

• Aggregation behaviors: volume-based patterns. Example: “User accessed 50+ AWS resources in 1 hour.” Useful for spotting data exfiltration attempts or compromised accounts doing bulk operations.
• Sequencing behaviors: multi-step chains. Example: “Access key created → used from new IP → privileged API calls made.” These surface the kind of attack progressions that are invisible when you look at individual events.

Every behavior record includes:

• A plain-language title and description
• MITRE ATT&CK tactic and technique mapping
• Entity roles (who was the actor, what was the target)
• References back to the raw log events that contributed to it

Crucially, behaviors are not alerts. They don’t fire because something is malicious. They fire because a pattern was detected. That distinction matters: behaviors give you neutral, factual context that you then interpret in light of other signals.

How it’s built: generative AI under the hood

The behaviors layer uses generative AI to create and scale the behavior logic. Microsoft uses AI to develop the detection patterns, map entities, perform MITRE mapping, and generate the natural-language explanations: all with quality guardrails to keep outputs consistent and auditable.

This is worth understanding because it explains the current scope: the initial release focuses on non-Microsoft data sources that traditionally lack easy behavioral context in Sentinel. Microsoft’s own data sources (Entra ID, Defender for Endpoint, etc.) already have rich signal: the gap has always been the third-party telemetry.

Supported data sources

At GA, the behaviors layer covers:

Important: coverage is expanding over time, but you need to verify your specific vendor logs are supported before expecting results. If your CommonSecurityLog connector ingests data from unsupported vendors, the behaviors layer will simply not generate records for that data. It won’t error, it’ll just be silent.

How to enable the UEBA behaviors layer

Prerequisites

• Microsoft Sentinel workspace onboarded to the Defender portal: the Azure portal path does not support the behaviors layer
• One or more supported data sources ingested into the Analytics tier (not Auxiliary or Summary Rules tier, behaviors only process Analytics-tier data)
• Currently supported for a single workspace per tenant, so choose the one with the most relevant ingestion

Enabling the behaviors layer

1. In the Defender portal, go to Settings → Microsoft Sentinel → SIEM workspaces
2. Select your workspace
3. Go to Entity behavior analytics → Configure UEBA
4. Navigate to the Behaviors layer tab. This is separate from the main UEBA toggle
5. Enable the feature and connect your supported data sources

Note that data sources here are configured independently from regular UEBA. Even if you already have AWSCloudTrail enabled for UEBA anomalies, you need to explicitly enable it for the behaviors layer too.

Once enabled, two new tables appear in your Log Analytics workspace:

• SentinelBehaviorInfo: the behavior records (title, description, MITRE mapping, time window)
• SentinelBehaviorEntities: the entities involved in each behavior (account, device, IP, etc.)

In Advanced Hunting, these tables appear without the “Sentinel” prefix, so BehaviorInfo and BehaviorEntities. If you already have Defender XDR behaviors enabled (e.g. from Defender for Cloud Apps), these queries will return results from both XDR and UEBA behaviors combined.

Querying behaviors: practical KQL

Investigating an entity during an incident

When you’re triaging an incident and want to understand what a specific account was doing:

let targetAccount = "user@yourdomain.com";
let lookback = 24h;
let behaviorIds =
    BehaviorEntities
    | where TimeGenerated > ago(lookback)
    | where AccountUpn == targetAccount
    | project BehaviorId;
BehaviorInfo
| where TimeGenerated > ago(lookback)
| join kind=inner (behaviorIds) on BehaviorId
| project TimeGenerated, Title, Description, AttackTechniques, Categories, BehaviorId
| order by TimeGenerated desc

This gives you a timeline of what that account did: at the behavior level, not the raw event level. Instead of reviewing hundreds of API calls, you see 3–5 meaningful summaries.

Threat hunting across the MITRE ATT&CK chain

Looking for entities that hit multiple tactics within a short window, a classic indicator of an active attack in progress:

let lookback = 12h;
let tacticFilter = dynamic(["Persistence", "Discovery", "PrivilegeEscalation"]);
let behaviorInfo =
    BehaviorInfo
    | where TimeGenerated > ago(lookback)
    | where Categories has_any (tacticFilter)
    | project BehaviorId, Categories, Title, TimeGenerated;
BehaviorEntities
| where TimeGenerated > ago(lookback)
| extend EntityName = coalesce(AccountUpn, DeviceName, CloudResourceId)
| join kind=inner (behaviorInfo) on BehaviorId
| summarize
    TacticsCovered = make_set(Categories),
    BehaviorTitles = make_set(Title),
    TotalBehaviors = count()
    by EntityName
| where array_length(TacticsCovered) >= 2
| order by TotalBehaviors desc

Entities showing up across multiple MITRE tactics in a 12-hour window are worth a closer look.

Finding the rarest behaviors

Rare behaviors are a natural hunting signal: if something only happened once or twice in your environment, it’s worth understanding why:

BehaviorInfo
| where TimeGenerated > ago(7d)
| summarize
    Occurrences = dcount(BehaviorId),
    FirstSeen = min(TimeGenerated),
    LastSeen = max(TimeGenerated)
    by Title, AttackTechniques
| order by Occurrences asc
| take 20

This gives you a ranked list of the rarest behavior types seen in the last 7 days, a good starting point for building analytics rules on top of behaviors rather than raw logs.

Filtering by MITRE technique

If you want to scope an investigation to a specific technique: say you’ve had a threat intel tip about T1552 (Unsecured Credentials):

let targetTechniques = dynamic(["T1552", "T1078"]);
let behaviorInfoFiltered =
    BehaviorInfo
    | where TimeGenerated > ago(48h)
    | where AttackTechniques has_any (targetTechniques)
    | project BehaviorId, AttackTechniques, Title;
BehaviorEntities
| where TimeGenerated > ago(48h)
| join kind=inner (behaviorInfoFiltered) on BehaviorId
| project TimeGenerated, AccountUpn, CloudResourceId, Title, AttackTechniques
| order by TimeGenerated desc

The UEBA behaviors workbook

Microsoft also released the UEBA behaviors workbook as part of the UEBA essentials solution in the Content Hub. It provides three pre-built tabs:

• Overview: high-level metrics, MITRE coverage heatmaps, behavior type distribution trends. Good for SOC managers and daily pulse-checks.
• Investigation: entity-centric timeline view, built for incident responders who need to drill into a specific user or resource.
• Hunting: anomaly detection overlaid with behaviors, designed for threat hunters doing proactive discovery.

To deploy it: Microsoft Sentinel → Content Hub → search “UEBA essentials” → Save. The workbook is one of the content items in that solution alongside prebuilt hunting queries.

What to watch out for

Cost

Behaviors are stored as Log Analytics records and billed at standard Sentinel ingestion rates. The volume depends entirely on how much raw telemetry you’re ingesting from the supported sources. Before enabling in production, check your current CloudTrail or GCPAuditLogs ingestion volume and estimate how many behavior records that might generate. High-volume sources like active AWS environments can add up quickly.

Single workspace limitation

At GA, this only works on one workspace per tenant. If you have a multi-workspace architecture, choose the workspace that ingests the most relevant non-Microsoft data.

Analytics tier requirement

Behaviors only process data in the Analytics tier. If you’ve moved AWS or GCP logs to the Auxiliary tier for cost reasons, those logs won’t feed the behaviors layer.

Supported vendors only

CommonSecurityLog is a catch-all table. Just because you have a CEF connector sending data doesn’t mean behaviors will fire. Only CyberArk Vault and Palo Alto Threats are supported at this time for CommonSecurityLog.

Why this matters for MSSPs and MDR providers

Running an MSSP or MDR service across a multi-tenant environment, the behaviors layer is particularly interesting because it abstracts away log schema complexity. Your analysts don’t need to memorize every AWS service API or Palo Alto log field: the behavior record gives them the story in plain language, with MITRE context already attached.

For detection engineering, it raises the abstraction level for rule authoring. Instead of writing analytics rules that join multiple raw tables and handle schema variations, you can build on top of BehaviorInfo as a normalized, enriched foundation. That means faster rule development and rules that are easier to explain to clients.

Resources

Microsoft documentation

• Translate raw security logs to behavioral insights using UEBA behaviors in Microsoft Sentinel
• Advanced threat detection with UEBA in Microsoft Sentinel
• Enable entity behavior analytics
• UEBA reference, tables and fields

Tech Community blogs

• Turn complexity into clarity: introducing the new UEBA behaviors layer: GA announcement, January 2026
• Accelerate your UEBA journey: introducing the Microsoft Sentinel behaviors workbook: February 2026

Video

Final thoughts

The UEBA behaviors layer is one of those features that’s easy to overlook because it doesn’t announce itself with a dramatic alert. But it’s doing something genuinely useful: turning high-volume, low-context telemetry from non-Microsoft sources into security-grade intelligence that analysts can actually act on.

If you’re running Sentinel with AWS, GCP, or Palo Alto data, enable it, deploy the workbook, and start building hunting queries on top of it. The normalized behavioral layer is a better foundation for detection than raw logs, and the KQL you write against BehaviorInfo will be cleaner and more maintainable than anything you’d write directly against AWSCloudTrail.

Got feedback or questions about how you’re using the UEBA behaviors layer in your environment? Leave a comment or reach out via the contact page.

Microsoft Defender for Cloud Apps AI agent monitoring was introduced as a preview feature to address exactly this. With real-time protection landing this month, the full stack is now available. This guide covers how it works and how to set it up.

Why Copilot Studio AI agents are a security risk

Copilot Studio agents can call external APIs, process user input, and take actions, often with permissions that were set up quickly and never reviewed. Attackers can abuse this in a few ways:

• Injecting malicious prompts to manipulate what the agent does
• Triggering tool calls the agent wasn’t designed to make
• Exploiting connected data sources to escalate privileges or exfiltrate data

The people building these agents are usually not security-aware, and there’s no enforcement gate before an agent goes live. Microsoft Defender for Cloud Apps AI agent monitoring is designed to fill that gap.

What Microsoft Defender for Cloud Apps AI agent monitoring does

Defender for Cloud Apps covers three things here:

AI agent inventory

Defender automatically discovers all Copilot Studio agents in your tenant and surfaces them in a central view. You can see what agents exist, who owns them, and what their security posture looks like, without requiring agent builders to do anything.

Audit logging and threat detection

Once the inventory is enabled and the Microsoft 365 connector is active, Defender collects audit logs for all Copilot Studio agents and monitors them for suspicious activity. Detections come through as alerts in the XDR incidents and alerts experience.

Real-time protection during runtime

This is what landed in December 2025. Defender inspects tool invocations before the agent executes them. If a prompt looks suspicious, the tool call is blocked, the user gets a notification, and an alert is created in the Defender portal. Active blocking, not detection after the fact.

One important caveat: if Defender doesn’t respond to a tool invocation check within one second, the agent proceeds and the tool call is allowed. This fail-open behavior is worth understanding if you’re relying on real-time protection as a hard control.

Prerequisites

Before enabling Defender for Cloud Apps AI agent monitoring, make sure you have:

• Microsoft Defender for Cloud Apps license until the 1st of july 2026 (included in Microsoft 365 E5) > Note this has been changed and you need the Agent 365 / E7 license to use this feature
• Microsoft Defender preview features enabled for Defender for Cloud Apps, Defender for Cloud, and Microsoft Defender XDR
• Microsoft 365 app connector connected in Defender for Cloud Apps
• Access to your Power Platform administrator onboarding spans both the Defender portal and the Power Platform admin center

Step 1: Enable the AI agent inventory

This is the foundation. Without it, monitoring and real-time protection won’t work.

1. Sign in to the Microsoft Defender portal as a system administrator
2. Go to System > Settings > Cloud Apps > Copilot Studio AI agents
3. Toggle Copilot Studio AI agents on. This confirms you’ve accepted the terms

Your Power Platform administrator then needs to complete the other side:

1. Go to the Power Platform admin center
2. Navigate to Security > Threat Protection
3. Select Microsoft Defender – Copilot Studio AI agents
4. Enable it

When connected, a green status indicator appears in the AI agents inventory section in the Defender portal. Allow up to 30 minutes for the initial connection, and potentially longer for the full inventory to populate in larger environments.

Step 2: Enable real-time protection during runtime

This step involves three parties: you as the security admin, a Power Platform administrator, and an Entra admin (or someone with app registration permissions). The order matters.

Get the webhook URL from the Defender portal

1. In the Defender portal, go to System > Settings > Cloud Apps > Copilot Studio AI agents
2. Check the Microsoft 365 app connector status: if it’s not connected, enable it first. Without it, real-time blocking still works, but alerts won’t appear in the Defender portal
3. Copy the webhook URL (endpoint) shown in the real-time protection section. You’ll need this for the Entra app registration

Register a Microsoft Entra application

This step creates the secure, secretless authentication bridge between Copilot Studio and Defender. You need someone with app registration permissions in Entra.

Option A: PowerShell (recommended):

Download the Create-CopilotWebhookApp.ps1 script and run it with the following parameters:

.\Create-CopilotWebhookApp.ps1 `
  -TenantId "your-tenant-id" `
  -Endpoint "https://endpoint-from-defender-portal" `
  -DisplayName "Copilot Studio - Defender Real-time Protection" `
  -FICName "DefenderFIC"

The script outputs an App ID: copy it, you’ll need it in the next steps.

Option B: manually via Azure portal:

1. Go to Azure portal > Microsoft Entra ID > App registrations > New registration
2. Give it a name, select Accounts in this organizational directory only, and register
3. Copy the App ID
4. Go to Certificates & secrets > Federated credentials > Add credential
5. Select Other issuer as the scenario
6. Set the issuer to: https://login.microsoftonline.com/{your-tenant-id}/v2.0
7. Set the subject using the following PowerShell to generate the base64-encoded values:

# Encode tenant ID
$tenantId = [Guid]::Parse("your-tenant-id")
$b64TenantId = [Convert]::ToBase64String($tenantId.ToByteArray()).Replace('+','-').Replace('/','_').TrimEnd('=')

# Encode endpoint URL
$endpoint = "https://endpoint-from-defender-portal"
$b64Endpoint = [Convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes($endpoint)).Replace('+','-').Replace('/','_').TrimEnd('=')

Write-Output "/eid1/c/pub/t/$b64TenantId/a/m1WPnYRZpEaQKq1Cceg--g/$b64Endpoint"