rss.livelink.threads-in-node

Detecting CVE-2026-54121 (Certighost) with Microsoft Defender

EdanZwick — Fri, 31 Jul 2026 17:41:07 GMT

What is CVE-2026-54121?

CVE-2026-54121 is an authentication-bypass vulnerability in Active Directory Certificate Services that allows an attacker to obtain certificates for arbitrary domain computer accounts, including Domain Controllers. A valid Domain Controller certificate enables escalation to full domain compromise: it can be used to obtain Kerberos tickets that authenticate the attacker as a Domain Controller. Those tickets can then be used to perform attacks such as DCSync, or to recover the Domain Controller's password hash for later use.

The flaw lies in an AD CS enrollment fallback known as a chase, which occurs when the CA cannot resolve the requester. In such cases, the vulnerable CA contacts a client-supplied Domain Controller, specified in the cdc attribute, to retrieve fresher identity data and incorporates the response into the issued certificate, without verifying that it is communicating with a legitimate Domain Controller. The chase fallback occurs only for templates that require a DNS name, and only on CAs with the EDITF_ENABLECHASECLIENTDC flag enabled.

A public proof of concept was released on July 24, 2026. Microsoft has not observed confirmed threat-actor exploitation, and the activity seen so far appears consistent with security testing. Organizations with affected AD CS configurations should apply the July 14 security update. Organizations should identify exposed Certificate Services hosts, confirm whether the required environmental conditions exist, enable the recommended AD CS auditing, and monitor for the suspicious authentication and certificate-enrollment activity described below.

More details about VCE-2026-54121 can be found here.

What to do

The response follows a simple order: know your exposure, patch it, instrument it, and watch for the activity.

1. Identify affected systems

Certighost affects Windows Server 2012 through Windows Server 2025, including Server Core installations, but several conditions must all be present for a given environment to be exploitable:

An Enterprise Certification Authority integrated with Active Directory
Enrollment through the machine certificate template
A default ms-DS-MachineAccountQuota value, or a machine account already controlled by the attacker
Network reachability between the Certification Authority and the attacker's host over SMB and LDAP
A valid domain account, with no administrative privileges required

2. Patch

The primary and durable remediation is the July 14, 2026 security update, applied to every AD CS host that runs an Enterprise Certification Authority. The update validates the lookup target before the Certification Authority contacts it, rejecting invalid or attacker-controlled targets before enrollment continues. Nothing else in this post replaces patching. The monitoring below gives you defense in depth and visibility, not an alternative to the fix.

3. Turn on AD CS auditing

The certificate request and issuance activity at the center of this attack is only useful to defenders if it is being recorded, and AD CS certificate services auditing is not enabled by default. With it on, the same events power detection and investigation across Microsoft Defender, and Kerberos authentication telemetry requires no additional configuration.

Organizations that have Microsoft Defender for Identity sensors installed on their AD CS servers and have completed the required sensor configuration can typically skip this step, as the necessary Certificate Services auditing settings are already enabled as part of the deployment prerequisites.

Enabling AD CS auditing takes two settings:

Turn on the Certification Services audit subcategory. Under Advanced Audit Policy, Object Access, enable success and failure for Certification Services. Set it through Group Policy, or with auditpol:

auditpol /set /subcategory:"Certification Services" /success:enable /failure:enable

Set the Certification Authority audit filter. In the Certification Authority console this is the Auditing tab; it can also be set with certutil, followed by a service restart:

certutil -setreg CA\AuditFilter 127 Restart-Service CertSvc -Force

With both in place, the Certification Authority records Security log events for certificate lifecycle operations, including event 4886 when a certificate request is received and event 4887 when a request is approved and a certificate is issued. Each event captures the requester, the template used, and the request disposition. For Certighost, this is the record that makes the abuse visible: a certificate issued for a Domain Controller identity, requested through a machine template by a low-privileged principal, is an issuance pattern that should never occur normally, and these events let defenders detect it, investigate it, and correlate it with the PKINIT authentication and DCSync activity that follow.

For complete guidance, see Configure Windows event auditing — Microsoft Defender for Identity.

4. Watch for alerts

Attempts to exploit this vulnerability are detected by Microsoft Defender for Identity with the alert :

"Potential Certighost (CVE-2026-54121) AD CS abuse."

The alert fires on the malicious certificate requests crafted to exploit this flaw, the anomalous issuance pattern at the heart of the technique, so you do not need to author a custom rule to catch the core activity. Ensure Defender for Identity is deployed on your domain controllers and AD CS servers and treat this alert as high priority.

Example of Potential Certighost (CVE-2026-54121) AD CS abuse alert within Microsoft Defender

Because the exploitation chain touches several stages of an identity attack, you may also see supporting alerts that commonly appear alongside this activity, though on their own they do not confirm a Certighost attempt:

Security principal reconnaissance (LDAP)
Suspicious Active Directory Certificate Services abuse tool activity
Suspected suspicious Kerberos ticket request
DCSync attack (replication of directory services)

Learn more

To stay on top of the latest Defender for Identity capabilities, follow our What's New documentation page.

MDTI convergence in Microsoft Sentinel and Defender XDR is complete

AmelieDarchicourt — Wed, 29 Jul 2026 16:00:00 GMT

Beginning August 1, the final phase of Microsoft Defender Threat Intelligence (MDTI) convergence will be generally available in the Defender portal, giving customers real-time Microsoft threat intelligence across detection, investigation, response, hunting, and automation at no additional cost. Announced last year, this unified SecOps experience reduces fragmented context and tool handoffs, creating a clearer path from threat signal to informed action.

Latest features converging

Entity enrichments: all the intel, right where you need it

Defender entity pages surface threat intelligence enrichments in the Threat Intelligence Insights tab for IP addresses, domains, URLs, and files. This unified view combines reputation data and scores, attributed reports, infrastructure relationships, services, certificates, DNS and WHOIS records, trackers, cookies, and sandbox analysis, helping analysts assess risk and investigate incidents without switching tabs. For more information, see View threat intelligence in entity pages.

Screenshot of the Threat Intelligence Insights tab under Threat Analytics in the Defender portal showing reputation risk.

Screenshot of the Threat Intelligence Insights tab under Threat Analytics in the Defender portal showing WHOIS records.

MDTI Sentinel data connectors and APIs

Microsoft Threat Intelligence data that previously required the Premium MDTI connector is now available through the free Microsoft Threat Intelligence connector in Sentinel, enabling free and premium indicator feeds through one setup. MDTI APIs are also available by default to Microsoft Defender XDR and Microsoft Sentinel customers, without a separate MDTI license SKU, so teams can enrich investigations through Sentinel or external SIEM, SOAR, and automation tools.

As a reminder, the API surface remains unchanged, and no customer migration is required. Customers do not need to perform endpoint mapping, code changes, tooling changes, or cutover activities.

Features previously released

Threat Intelligence Library

Microsoft’s threat actor profiles, intelligence reports, OSINT articles, MSTIC and MTP research, and indicators of compromise (IoCs) are now available through Threat Analytics in the Defender portal, at no additional cost beyond the existing license.

Screenshot of the Threat Analytics dashbaord in the Defender portal.

Threat Analytics Enhancements

Reports now bring together embedded IoCs, MITRE ATT&CK mappings, targeted industries, actor origins, and automatic incident correlation, so defenders can move from reading intelligence to applying it in investigations.

Screenshot of the Threat Analytics page in the Defender portal showing actor profile overview.

Case Linking

Security teams can link investigation cases directly to relevant IoCs, making it easier to document findings, collaborate across response workflows, and show how intelligence informed action.

Reference the table below to see the full list of features available with the MDTI convergence into Microsoft Defender XDR and Sentinel.

Chart showing full list of MDTI capabilities converged into Defender XDR and Sentinel

Actions for existing MDTI customers

Starting August 1, the standalone MDTI pages (Intel Profiles, Intel Explorer & Intel Projects) will be retired. All MDTI capabilities will be accessible via the Threat Analytics tab in the Defender portal instead of the Threat Intelligence tab. No migration action is needed. Customers will now access the MDTI value via the Threat Analytics tab in the Defender portal instead of the Threat Intelligence tab. Explore our documentation for more details and reach out to your account team or partner if you need have questions or need assistance on how to reduce your current license and transition to this new unified threat intelligence experience in Defender XDR or Sentinel at no additional cost.

Get started

To access threat intelligence in the Microsoft Defender portal:

Go to the Microsoft Defender portal and sign in.
Use the Threat intelligence navigation menu to access Intelligence explorer and Intel profiles.
Investigate entities enriched with threat intelligence by selecting IP addresses, domains, URLs, or files from incidents, alerts, or search results.

Graph API Endpoint for the Vulnerability Profile

scottholland — Tue, 28 Jul 2026 12:02:06 GMT

I can use this endpoint to get threat reports via the graph api

GET

https://graph.microsoft.com/beta/security/threatIntelligence/article

but threat Analytics reports that come in from defender that are category: vulnerability, aren't in there However they are written up in an article style. What endpoint do I need to hit to get these types of reports.

Microsoft Defender now integrates with Dragos, Forescout, & Armis for OT Security

Caroline_Lee — Tue, 14 Jul 2026 13:46:58 GMT

Co-author(s): Amit Cohen and Hadar Shindler

Operational technology (OT) environments are unlike anything else in cybersecurity. The systems that run our factories, power grids, water treatment plants, pipelines, and transportation networks weren’t built with modern threats in mind — and they can’t simply be patched, rebooted, or scanned the way IT systems can. A misstep doesn’t just create an alert backlog; it can stop a production line, disrupt critical services, or put physical safety at risk.

To support customers in bringing their OT security solutions into their Security Operation (SOC) platform, we’re excited to announce an expansion of the Microsoft ecosystem with new OT security integrations from Dragos, Forescout, and Armis from ServiceNow. This gives customers greater flexibility to use the OT security solutions that best fit their environments.

Expanding OT coverage in Defender with new partner integrations

We’ve built new connectors for Dragos, Forescout and Armis that are now ready for customers to start using.

Dragos

"Strong OT defense starts with knowing what is running in your operational environment, the vulnerabilities those assets carry, the threats targeting your systems, and the data to determine root cause. That kind of intelligence comes from years of operating inside OT environments and tracking the groups behind those threats. As OT threats continue to grow and AI accelerates how quickly adversaries can approach the OT boundary, integrating Dragos into Microsoft Defender strengthens how organizations see, understand, and defend their OT environments."

-Robert M. Lee, CEO and Co-Founder, Dragos, Inc.

Forescout

"Our integration with Microsoft Defender represents a significant step forward in helping organizations defend their most critical operations against today's rapidly evolving cyber threats. By combining Forescout's industry-leading visibility and protection for IoT, OT, and network-connected assets with Microsoft's leadership in endpoint, identity, cloud, and security operations, we're delivering a more unified approach to cyber defense. Together, we're enabling healthcare providers, government agencies, critical infrastructure operators, and enterprises comprehensive visibility across IT and OT environments while empowering security teams to detect, investigate, and respond to threats faster and with greater confidence."

-Robert McNutt, Chief Strategy Officer, Forescout

Armis

“Fragmented security is no longer an option as threats to critical infrastructure evolve at machine speed. By deepening our integration with Microsoft, we are unifying visibility and context in complex OT and IoT environments. Integrating Armis Centrix™ with Microsoft Defender equips security teams with real-time, actionable insights to identify and mitigate risks across their entire operational footprint.”

-Nadir Izrael, Group Vice President, Armis from ServiceNow

Bringing OT and IT Security Together

With these new integrations, signals, asset inventory and vulnerabilities from Dragos, Forescout, and Armis from ServiceNow flow directly into Microsoft Defender — giving security operations teams a single, unified view across IT, OT, and IoT.

What this means for customers:

Unified visibility across IT and OT. OT assets and vulnerabilities surface alongside IT signals in Defender, so the SOC can see and reason about them in one place.
Cross-domain correlation. Identity, endpoint, cloud, and OT signals are correlated automatically.
Streamlined investigation and response. Analysts can pivot from an OT detection to related IT activity (and back) without switching tools or losing context.
Specialized depth, unified breadth. Customers keep the deep OT expertise of their chosen partner platform and gain the enterprise-wide coverage of Defender.

Let’s take a look at some of new the user experience updates that showcase these integrations.

Figure 1. Discovered devices by OT partner in device inventory

The Device Inventory now will show OT devices discovered through a new partner integration (see Figure 1). Industrial assets like substation relays and switches from vendors are automatically surfaced with rich context, criticality, vendor, model, firmware, and discovery source alongside built-in recommendations to classify critical assets and protect unmanaged OT devices. The result: unified visibility across IT and OT from a single view, so security teams can find, prioritize, and protect previously unseen devices faster.

Figure 2. Vulnerabilities and exposure across OT devices

The Vulnerabilities view now includes a dedicated OT Partner CVEs tab, surfacing thousands of vulnerabilities on operational technology devices discovered through partner integrations. Every CVE is enriched with severity, CVSS score, age, active threats, and exposed device count, and the list is sorted by exposure so the most widespread, highest-impact risks rise to the top. Most importantly, security teams can now see OT vulnerabilities alongside IT in a single, prioritized view, making it faster to focus remediation where it matters most.

Figure 3. Discovered devices exposed by OT integration

Selecting a CVE opens a detail panel with a dedicated Exposed devices discovered by OT partner tab, listing every affected device along with its OS platform and last seen date. For CVE-2024-7264, that means a clear view of all 75 exposed devices in one place, from OT controllers to sales workstations. The benefit is that security teams can move from a single vulnerability straight to the exact devices at risk, making it easy to scope impact and drive targeted remediation without leaving the view.

Figure 4. Discovered vulnerabilities by OT integration

Drilling into a specific device, like the Substation-North-HMI2 shown here, reveals a dedicated Discovered vulnerabilities by OT partner tab alongside the standard device views such as incidents, timeline, and security recommendations. It lists every vulnerability found on that device by the OT partner, complete with severity, CVSS score, publication and detection dates, and active threats. The benefit is a complete, device-level picture of OT risk right where analysts investigate, so they can see exactly what a single asset is exposed to and prioritize remediation without switching tools or context.

Built for customer choice and flexibility

We’re excited to expand our integration ecosystem, giving customers the flexibility to work with the OT solutions they already trust. These integrations help bring specialized OT context into broader security workflows, enabling SOC teams, risk managers, and security leaders to collaborate more effectively while using the tools that best fit their environment.

Get started

The Dragos, Forescout, and Armis integrations are available in public preview starting today. Customers can enable them through the Defender portal and begin ingesting OT signals from their partner platform of choice.

Ask Microsoft Anything: Attack Disruption with Microsoft Defender on July 14

TrevorRusher — Tue, 07 Jul 2026 18:55:19 GMT

Hey Defender enthusiasts! Just wanted to remind you all that we are holding an AMA next week at 9AM PST on July 14 with the Attack Disruption team. Come learn about Attack Disruption—Microsoft Defender’s built‑in, AI-powered capability that stops in‑progress attacks at machine speed by analyzing attacker intent, identifying compromised assets, and containing threats before they spread. Bring your questions and hear directly from product experts on real‑world scenarios and best practices.

Hope to see you there!

Event Link: Ask Microsoft Anything: Microsoft Defender Attack Disruption | Microsoft Community Hub

DefenderXDR "Preparing new space for data and connecting them" is stuck , and never finished !

PanosGR191 — Tue, 07 Jul 2026 18:08:06 GMT

Hello everyone,
I am delivering SC-200 courses and on the lab environment of Skillable (or even free-tiers) when you have to "initiate" the data space for DefenderXDR, the process seems to be stuck .... never finished and we are "locked" in the page of a ...coffee cup and the phrase
"Hang on. We are preparing new spaces for your data and connecting them. "

does anyone else have same problem ?
Any resolution , (I have already open a support ticket to Skillable support, but I haven't got resolution for over 1+day , and cannot open or continue the lab (for connecting or onboarding Microsoft Defender for Endpoint ) which is frustrating for the participants-students

Thanks
Panos

Looking for a simple deployment guide

MeatBear11 — Tue, 07 Jul 2026 16:17:36 GMT

MS Learn is a great starting point, but it just doesn't seem to cover the steps needed to get up and running safely.

I have concerns about adding or setting something that suddenly creates a vulnerability or exposure. Where is the installation guide that installs and configures the solution then tells you, "You are now protected". Do I really want to set my own policies? Why aren't the default set of rules good enough, safe enough. I can't have a solution that is so complicated I need to hire a team to manage it 24 hours a day. I am okay investigating an alert and helping a user solve a pop-up question. Why is every major corporation around the world required to re-invent the same or similar policies the company next door is creating to make this tool work?

I want to onboard all of our Intune devices and monitor anything that CAN'T be stopped by default security measures. Just the fact that Sentinel appears to be changing as an embedded tool within Defender gives me hope that this will be getting closer to a more manageable tool. But that still seems a way off.

I am ready to do the reading and research to get this set up but I am hoping for a guide that is specific enough to achieve a final result.

Thank for understanding my challenges here.

Feature Request: Manual Invocation Mode for Embedded Security Copilot Experiences to reduce cost !

PanosGR191 — Sun, 05 Jul 2026 16:32:54 GMT

Hello, I see that Copilot for Security in XDR dashboards , if used in embedded mode (I mean whenever you are opening a case to investigate) you get AUTOMATICALLY a summary of the incident , and you are consuming SCU costs.

I want a way either globally as a tenant option, or through a pwsh to be able to DISABLE this, or be able to PRESS the AI button AND THEN generate the AI reply (and consume SCU credits ..)

Current behavior:

Open Incident --> Copilot automatically generates Incident Summary --> SCUs ARE consumed

Desired behavior:

Open Incident --> No AI execution --> Click "Generate Summary" MANUALLY --> SCUs consumed

I am not talking about RBAC controls to assign WHO of my admins can use Security Copilot, I have set that, BUT I want my admin to decide IF they want AI to help them (and consume - pay for that SCU credits-costs) OR NOT !!

At the moment I havent found any solution, except to educate my admin to press CANCEL the moment he/she opens such an XDR dashboard ! :)

Does anyone knows something ?

Regards, Panos

Monthly news - July 2026

HeikeRitter — Wed, 01 Jul 2026 09:30:09 GMT

Microsoft Defender
Monthly news - July 2026 Edition

This is our monthly "What's new" blog post, summarizing product updates and various new assets we released over the past month across our Defender products. In this edition, we are looking at all the goodness from June 2026. We are now including news related to Defender for Cloud in the Defender portal. For all other Defender for Cloud news, have a look at the dedicated Defender for Cloud Monthly News here.

🚀 New Virtual Ninja Show episode:

Weekly Security News: We publish a short 1ish minute video every week with updates across our Microsoft Security stack. Subscribe to our YouTube channel, so you don't miss the next episode.

Actionable threat insights (find all of them here)

Microsoft Defender

Two Workbooks capabilities in the unified Microsoft Defender portal moved to GA:
- Advanced Hunting connector - build custom dashboards directly on top of Advanced Hunting (XDR) dat. Query XDR tables and visualize them in Workbooks for richer investigations and reports.
- Workspace filter / multi-workspace experience - scope and filter workbooks by workspace, with workspace selection integrated into the workbook itself rather than relying on the global selector.
MTO Tenant Groups let MSSPs and large enterprises organize their multitenant view in Microsoft Defender by grouping tenants logically (e.g., by region, business unit, or customer cohort). Learn more here.
Custom Detections support in Microsoft Sentinel Repositories. Custom Detections can now be managed as code in Microsoft Sentinel Repositories, the same way customers already manage analytic rules, playbooks, parsers and workbooks. Detection engineers connect a GitHub or Azure DevOps repo to their workspace; Custom Detections placed in the repo are reconciled on every commit. A standalone Bicep path via the Microsoft Security Bicep extension lets teams deploy from any CI/CD pipeline (ADO Pipelines, GitHub Actions, custom runners).
(General Availability) The following advanced hunting schema tables are now generally available:
- The CloudAuditEvents table contains information about cloud audit events for various cloud platforms protected by the organization's Defender for Cloud.
- The CloudDnsEvents table contains information about DNS activity events from cloud infrastructure environments.
- The CloudProcessEvents table contains information about process events in multicloud hosted environments.
(Public Preview) The AgentsInfo table in advanced hunting is now available in preview. The AIAgentsInfo table is transitioning to this new table, which provides a unified schema that supports agent inventory and governance for all agent types, including Copilot Studio, Microsoft Foundry, Microsoft 365 Copilot, third-party, and endpoint-discovered agents. Microsoft Agent 365 customers should use the AgentsInfo table today. The AIAgentsInfo table remains accessible until July 1, 2026. Update your queries to use AgentsInfo before this date. For more information, see Advanced hunting schema - Naming changes.
For all other Sentinel News, have a look at the "What's new in Microsoft Sentinel blog post - June edition"

Identity Security

(Public Preview) The Identity Security dashboard now includes a new Human identities card that shows your human identities by source (Entra ID, SaaS, and on-premises), giving you a single view of where your human identities live. For more information, see Identity Security dashboard.

Identity Security dashboard overview

(Public Preview) On the Coverage and maturity page, the Review and improve coverage side panel for SaaS Identities now includes an Observed column and a Show Only Observed Applications toggle. By default, the panel shows only SaaS applications detected in your environment. Turn off the toggle to see other supported SaaS applications you can onboard to expand your identity coverage. For more information, see Coverage and maturity.
New alerts were added to the Defender for Identity security alerts related to Microsoft Entra ID, Active Directory as well as other identity providers. For a full list of those new alerts, check out our documentation.
Recent ShinyHunters attacks on Salesforce show how OAuth tokens and connected apps are being weaponized to bypass MFA at scale. The upgraded Salesforce connector for Defender for Cloud Apps helps detect these attacks faster, with richer connected-app context and investigation-ready signals. Customers already using the connector are advised to enable the additional events in the Salesforce console for tighter protection, and eligible customers not yet using it are advised to connect Salesforce. Learn more.

Microsoft Defender for Endpoint / Microsoft Defender Vulnerability Management

(Public Preview) Local AI agent discovery: as part of the Defender AI agents experience, Microsoft Defender now automatically discovers supported local AI agents running on onboarded Windows & macOS devices. Discovered agents appear as assets in the AI agent inventory, exposure map, and advanced hunting, giving security teams visibility into local AI agent usage across the organization. For more information, see Discover local AI agents.
AI Assets page
(Preview) Local AI agent runtime protection on Windows endpoints is now available in public preview. Microsoft Defender inspects the agent loop (user prompts, tool calls, and tool responses) and can block risky activity before it executes, helping stop prompt injection and unsafe agent actions at the device level. Blocked and audited events appear as alerts in Microsoft Defender to support incident correlation and investigation workflows.
The new version of the Defender deployment tool for Windows streamlines onboarding and enhances security by:
- Bundling the onboarding package directly into the tool's executable.
- Generating a key during deployment package creation that is required for running the tool.
- Enabling users to configure an expiry date for the package to reduce the risk of unauthorized use.
  In addition:
- You have the option of downloading the package as either an .exe or a .zip file, whichever best suits your organization's needs.
- A new Deployment packages page in the Defender portal facilitates management of downloaded packages by providing centralized visibility into all the packages and their current status.
Now generally available: Selective Response Actions enables organizations to tailor high-impact security operations on devices during onboarding. It provides precise control over how response actions are applied on Tier-0 systems and other high-value assets, helping maintain operational stability while delivering strong protection.
Enable selective response actions
The new exposure score model in Defender Vulnerability Management is now generally available. This model improves risk prioritization and recommendation impact accuracy by incorporating exploit prediction data (EPSS) and asset context factors such as internet-facing status and criticality. More details here.
Microsoft Secure Score now includes the Reduce unnecessary inbound internet exposure on internet-facing devices recommendation, which helps identify devices that are accessible from the public internet and may represent unnecessary attack surface. This recommendation provides centralized visibility into internet-facing devices across the environment.
Many predefined SaaS application classification rules were added to the critical assets list. Have a look at our documentation for the full list. These classifications require onboarding to Microsoft Defender for Cloud Apps.

Defender of XDR - Quarantine - Lack of filter/search options

DarkingDK — Wed, 01 Jul 2026 05:55:09 GMT

Hi Microsoft,

I love what you're doing with the Defender XDR portal, but could you please show some love to the Quarantine section soon?

On a daily basis, I have to review emails caught in quarantine for false positives, and the lack of search and filtering options is appalling.

As a company based in Denmark, 99% of legitimate emails come from .dk domains. Yet there is no way to search for or filter on something this simple.

If I type .dk into the search box, I get 0 results, even though I can clearly see .dk sender addresses on the page. The filter options only allow me to enter full sender or recipient email addresses, which is of course almost useless in a quarantine-review context.

Some examples of filters that would be extremely useful:

Sender domain ends with .dk
Sender domain contains .dk
URL domain filtering
Attachment name filtering
Saved filter views
More flexible search across message properties

The Quarantine experience could be made dramatically better with relatively little effort.

So please, pretty please, give the Quarantine portal some attention. It's often the part of Defender that security teams interact with every single day.

Microsoft Defender Incident – Handling incident severity change

gokhantatar — Thu, 25 Jun 2026 20:27:49 GMT

There's no dedicated history/audit endpoint for field-level transitions (like "this incident went from Low → High at timestamp X") in the /security/incidents Graph API — the incident object only exposes the current severity plus a lastUpdateDateTime, not a change log. So this isn't something you're missing; it genuinely doesn't exist as a queryable history today.

Also worth knowing before you build around it: Graph change notifications (webhooks) are not documented as supported for /security/incidents — subscription/webhook support is only documented for the legacy /security/alerts resource, and that resource is deprecated with removal expected around April 2026. So polling is currently the only supported pattern for incidents specifically, not a limitation of your approach — there's no webhook alternative to fall back to yet.

Given that, the fix is in your polling strategy, not in finding a hidden feature: instead of filtering once at creation time and then ignoring the incident, poll using $filter=lastUpdateDateTime gt {last_poll_timestamp}. Since lastUpdateDateTime bumps on any property change — including a severity escalation — this catches incidents that started as Low/Informational and later got escalated, without re-fetching everything.

A pattern that works well in practice:

GET /security/incidents?$filter=lastUpdateDateTime gt {last_poll_time}&$orderby=lastUpdateDateTime asc

Then in your own store, diff the incoming severity against what you last recorded for that id to detect the transition yourself — you're effectively reconstructing the history client-side since the API won't give it to you natively. Store (incidentId, severity, lastUpdateDateTime) on each poll and compare.

One gotcha: this still won't tell you the exact moment the severity changed if multiple fields changed between polls — only that it changed sometime between your last two poll timestamps. If you need second-level precision on transition timing, you'd need to poll more frequently (your 5-minute interval is probably fine for SOC triage purposes, but not for precise SLA timestamping).

Is "Endpoint Security Policies" available to us? (error getting Intune policies)

goslackware — Thu, 25 Jun 2026 14:28:35 GMT

Question

We'd like to use Defender \ Endpoint Security Policies.

Is that possible for my tenant's environment?

Getting below error on "Defender \ Endpoint Security Policies" page

"There seems to be an issue getting your Intune policies"

Details of our environment

Purpose of defender

To protect our server fleet that's running outside of Azure

Tenant

GCC - Moderate Scoped

Region

Commercial Azure East US 2

Subscription

Microsoft Defender for Servers Plan 1

(No other subscription, etc.)

Defender Client OS

Windows 2016, 2019, 2022

RHEL8, 9

(No desktops\laptops)

Agents installed on each Windows and Linux server

Defender is onboarded

Arc is onboarded

Configured Settings and Errors

Defender \ Settings \ Configuration management \ Enforcement scope

https://security.microsoft.com/securitysettings/endpoints/configuration_management2

Error at top of page

"Intune is not configured to allow Microsoft Defender for Endpoint to manage security configuration settings."

Use MDE to enforce security configuration settings from Intune

Set to ON

Enable configuration management

Windows Server devices

On tagged devices

Windows Server Domain Controller devices

On tagged devices

Linux devices

On tagged devices

Security settings management for Microsoft Defender for Cloud onboarded devices.

Set to ON

Manage Security settings using Configuration Manager

Set to OFF

Defender \ Settings \ Configuration management \ Intune Permissions

https://security.microsoft.com/securitysettings/endpoints/intune_permissions

Getting error

"Access needed

You don't have the right permissions in AAD to view this information (in addition to those you already have in MDE). To adjust your permissions, go to the AAD portal."

Defender \ Endpoint Security Policies

https://security.microsoft.com/policy-inventory

On main page, getting below error

There seems to be an issue getting your Intune policies

If I try to make a new policy

There seems to be an issue loading the policy authoring wizard.

Intune \ Endpoint security

https://intune.microsoft.com/#view/Microsoft_Intune_Workflows/SecurityManagementMenu

Getting Error

You don't have access

Intune roles | My permissions

https://intune.microsoft.com/#view/Microsoft_Intune_DeviceSettings/RolesLandingMenuBlade/~/myPermissions

You're an administrator with full permissions to all Microsoft Intune resources.

Intune roles | Administrator Licensing

https://intune.microsoft.com/#view/Microsoft_Intune_DeviceSettings/RolesLandingMenuBlade/~/administratorLicensing

Allow admins without an Intune license to access Intune. Their scope of access is determined by the Intune roles you've assigned them.

I've clicked the box "Allow access to unlicensed admins"

Alternatives

If Defender \ Endpoint Security Policies isn't available, as alternatives, I guess we could use

SCCM Antimalware policies to manage Windows servers

Deploying a central mdatp_managed.json to manage Linux servers

However, it would be greatly preferred to use the Defender \ Endpoint Security Policies feature for Windows and Linux

Securing the invisible workforce

Nagaraj Venkatesh — Wed, 17 Jun 2026 12:35:52 GMT

Non-human identities are now the majority of the identity estate in most enterprises. Service principals access organizational resources across SharePoint, Azure, and Microsoft 365, Service accounts run critical business processes on-premises, OAuth apps move data across SaaS boundaries, and AI agents increasingly operate autonomously at machine speed.

As NHIs have grown in number and importance, so to have the threats targeting them. Midnight Blizzard showed how damaging compromised NHI can be. Attackers moved laterally across cloud resources and accessed sensitive data without ever triggering user-centric controls like MFA. The challenge many security teams are faced with however is that they simply do not have the visibility into what NHI’s even exist within their organization. Unlike their human counterparts, NHI can vary drastically in purpose, behaviour and risk profile. The one consistency is that most organizations lack a formal process for their creation, management and governance. For instance, while these identities often carry high and standing privileges, those permissions are typically granted at creation and never revisited. They authenticate programmatically so they cannot be enrolled in, or benefit from the protections of multi-factor authentication.

As AI adoption accelerates, this issue has become even more urgent. Every AI agent needs an identity to function. That identity accesses data, invokes APIs, and takes action, autonomously, continuously, and at an unprecedented velocity. But because AI tooling has moved faster than guidance, many agents were never given identities of their own, many riding on existing Service Principles. This means that those ordinary app registrations may in fact represent autonomous agents making decisions and taking action. This new reality further compresses the window between compromise and impact and makes securing non-human identities a prerequisite for safely deploying AI at enterprise scale.

Today, I am excited to share more about the non-human identity protection available within Microsoft Defender. These capabilities bring NHIs into the same unified platform where security teams already work and protect human identities with purpose-built experiences for discovery, risk assessment, business context, governance, threat detection, and attack disruption.

The Challenge:

We hear consistently from customers that they cannot answer fundamental questions about their NHI estate:

How many non-human identities exist? Across Entra ID, Active Directory, and SaaS applications, the true count consistently exceeds expectations, often by an order of magnitude.
Which ones are still in use? NHIs accumulate over time. Decommissioning is rare and dormant identities retain active permissions indefinitely.
Which ones hold more access than they need? Permissions are granted broadly at provisioning and seldom revisited. Over-privilege is not the exception—it is the default state.
Who is responsible for them? Without established ownership, remediating a risky NHI requires significant manual effort just to identify the right person to engage.
Which ones are powering AI agents? Many agents ride on NHIs created long before the agent existed, making them indistinguishable from routine integrations.

These are the questions that drive the capabilities we are delivering.

Raising the bar for NHI protection with Defender

Microsoft Defender helps protect non-human identities through six integrated focus areas: Visibility, Risk analysis, relationships and access mapping, governance policies, AI Agent awareness and Detection and Disruption. Together, these areas help organizations discover NHI risk, understand relationships and permissions, enforce governance, identify AI-driven identity activity, and detect or disrupt threats before they escalate.

1. Visibility:

When Entra service principals, Active Directory service accounts, and SaaS-connected OAuth apps are managed in separate consoles with separate workflows, security teams cannot form a coherent picture of NHI exposure. These gaps in visibility translate directly into gaps in protection.

Defender delivers a unified identity inventory for both human and non-human identities within a single view and investigation workflow. For non-human identities, coverage includes:

Source	Coverage
Microsoft Entra ID	All service principals
Active Directory	All service accounts
SaaS Apps	All OAuth-connected apps

Unified visibility across all non-human identities in a single pane of glass

This consolidated inventory is the foundation that security insights, risk scoring, business context, governance, and threat detection all build on. Security teams work from one place, using the same investigation workflows they already use for human identities, across the entire NHI population.

2. Risk insights and analysis:

Visibility into what exists is the starting point. What security teams need next is a clear understanding of which identities carry risk, what kind of risk, and how they should prioritize. Similar to how we review risk signals for human identities, Defender continuously evaluates the NHI estate and surfaces findings across key risk pivots:

Actionable insights into your unique NHI footprint

Unused Identities

NHIs that have not authenticated over extended periods but retain active permissions. These identities serve no current business purpose while remaining fully available for misuse if compromised.

Over-Privileged Identities

NHIs whose granted permissions significantly exceed their observed usage. Defender analyses the gap between what an identity can do and what it actually does, identifying where privilege can be safely reduced without impacting operations.

High-Privileged Identities

Some NHI’s however require elevated roles or broad permissions to perform their intended use. These NHIs pose the highest lateral movement risk if compromised. For context, these privileges can sometimes exceed the access held by admins in the organization.

Identity Risk Score for NHIs

The new Identity Risk Score within Defender also extends to NHI. Ever NHI now has a dynamic risk score , informed by Microsoft’s global threat intelligence, exposure indicators, and observed activity patterns.

The score is fully explainable. For every NHI, Defender shows the specific factors that contributed—what combination of privilege, exposure, and activity drove the assessment, and why. Analysts see the reasoning directly: an identity scored high because it is unused, holds broad directory permissions, and is published by an unverified publisher. This means analysts can act on the score with confidence, without needing to conduct a separate investigation to understand what it means.

These insights allow teams to rank their entire NHI estate by risk and systematically focus investigation where it matters most.

Risk insights for NHI for effective prioritization

3. Relationship mapping:

Knowing that an NHI is risky is necessary but not sufficient for remediation. Security teams need business context: what application depends on this identity, who owns it, what resources can it access, and with what permissions.

Without this information, even a critical finding stalls. Can we disable this identity, or will it break a production workflow? Who do we contact to coordinate? What is the scope of exposure if this identity is compromised?

Defender introduces a Graph for NHIs that visually maps these relationships directly.

Graph connecting risk to business context for faster remediation

What application depends on this NHI? Understanding downstream dependencies before taking remediation action.
Who owns it? Identifying the owner for coordinated response.
What resources or crown jewels does it access, and with what permissions? Determining the sensitivity of accessed resources to assess actual severity.

With this context directly available in the investigation experience, security teams can assess risk, evaluate business impact, and coordinate remediation without switching tools or conducting manual discovery.

4. Governance policies

When we extrapolate this out to enterprise scale, with thousands to tens of thousands of NHIs, manual remediation simply cannot keep pace with the rate at which risk accumulates. Organizations need governance policies that enforce decisions automatically and consistently.

Defender enables this through governance policies. Organizations can define policies that leverage the insights Defender surfaces like unused timeframe, privilege level, risk score, over-privilege status, AI agent association and then map them to automated disablement of identities that exceed acceptable risk.

Example: An NHI that has been unused for 90+ days, holds high-privilege roles, and carries a risk score above 70 exceeds the organization’s risk tolerance → disable the identity.

Automated governance policies that turn risk insights into enforcement at scale

This shifts NHI security from periodic audit cycles to continuous posture management. The NHI estate stays within organizational risk tolerance because policy enforces the standard automatically, at the scale the environment demands.

5. AI Agent awareness

Agents built on platforms like Copilot Studio, Azure AI Foundry, and third-party frameworks require identities to authenticate, access data, and take action. In practice, many agents operate using traditional NHI that were provisioned for other workloads, making them indistinguishable from routine integrations at the identity layer.

The risk profile, however, is materially different:

Agents are autonomous. They make decisions and execute actions without human approval at each step.
Agents are high-velocity. They perform hundreds of operations per minute across multiple systems.
Agents interact with sensitive data. They access documents, query databases, read communications, and invoke APIs, often with broad permissions to support flexible workflows.

When a misconfigured identity backs an AI agent, the risk compounds significantly because the agent continues to operate autonomously, with legitimate access, at machine speed, across whatever resources it can reach.

Defender infers which NHIs are used by AI agents and surfaces this signal directly in the inventory, risk insights, and assessment. This enables security teams to prioritize investigation of agent-backed NHIs and apply differentiated governance like stricter controls, shorter review cycles, and tighter privilege boundaries for identities backing

Visibility into service principals powering AI agents and their associated risk

6. Detection and disruption

Posture and governance reduce the attack surface. But when an attacker compromises a non-human identity, detection speed and response automation determine whether the attack is contained or succeeds.

Microsoft Defender brings the same detection and disruption capabilities that protect human identities to the non-human estate.

Threat Detection for NHIs

Defender detects anomalous and malicious activity involving non-human identities using behavioral analytics and Microsoft’s global threat intelligence. Detections are purpose-built for how NHIs operate because the signals indicating compromise in a NHI is fundamentally different from those in a human account, and our detection models reflect that.

Detecting anomalous and suspicious activities on non-human identities

Every alert is enriched with full context from the identity inventory, risk insights, and graph. Analysts see not just what happened, but which identity was involved, what it can reach, who owns it, and how critical it is immediately, without manual correlation.

Disrupting Attacker Persistence

We are introducing new disruption capabilities designed to address the persistence techniques attackers use against non-human identities. These capabilities focus on the specific actions that turn a legitimate non-human Identity into an attack path, such as adding credentials for off-tenant use or modifying permissions and role assignments to expand access.

Rather than broad remediation, the approach targets the exact moves attackers use to establish and maintain control. By directly addressing actions like unauthorized credential additions and privilege expansion, these capabilities help remove attacker access while preserving legitimate application functionality.

Why This Maters

Every AI agent requires an identity. As organizations scale agent deployments, the NHI estate grows with them and inherits every existing gap: over-privilege, absent ownership, insufficient monitoring.

What has changed is speed. An AI agent with a compromised identity operates autonomously and never sleeps. The window between compromise and impact has compressed to the point where periodic manual review is no longer adequate. Automated visibility, continuous risk assessment, policy-driven governance, and real-time detection and disruption are now requirements.

The organizations investing in NHI protection today are building the security foundation their AI strategy depends on.

Getting Started

Non-human identity protection is available in Microsoft Defender today:

Visit the unified identity inventory in Defender to see all NHIs across Entra ID, Active Directory, and SaaS.
Review risk insights to identify unused, over-privileged, high-risk NHIs, and NHIs used by agents.
Explore the identity graph to understand business context, ownership, and resource access.
Configure risk-based governance policies to enforce organizational risk tolerance at scale.

These capabilities are integrated into the same platform and workflows security teams already use for human identity protection—no separate tools, no additional deployment. Learn more about the NHI protections provided by Defender within our docs here.

Microsoft 365 Developer E5 license lacking endpoints and device on defender portal

Dozie — Sat, 13 Jun 2026 13:22:02 GMT

Dear Support Team,

I am a microsoft certified trainer (MCT). I currently have a Microsoft 365 Developer E5 license assigned to my tenant. However, I have noticed that my Microsoft Defender portal (security.microsoft.com) is missing several critical features. For example, I cannot see the Endpoints or Devices menus, which is preventing me from implementing and testing Microsoft Defender for Endpoint.

Additionally, my Azure tenant and Microsoft 365 tenant are separate. This has created challenges when configuring security services such as Microsoft Sentinel (SIEM), as certain prerequisites and integrations require configuration through the Microsoft Defender portal. Due to the missing Defender features, I am unable to complete the necessary setup.

I would appreciate your assistance in understanding:

Why the Endpoints and Devices sections are unavailable in my Defender portal despite having a Microsoft 365 Developer E5 license.
Whether additional licensing, onboarding steps, or tenant configurations are required to enable Microsoft Defender for Endpoint features.
How best to integrate or align my separate Azure and Microsoft 365 tenants to support services such as Microsoft Sentinel and Defender XDR.

These issues are significantly impacting my ability to evaluate and implement Microsoft's security solutions. I would appreciate any guidance or recommendations to resolve them.

Thank you for your assistance.

Kind regards,
[Your Name]

Campaign-Centric Hunting with Microsoft Defender XDR and Microsoft Sentinel

klianos — Thu, 11 Jun 2026 12:34:22 GMT

Phishing investigations usually start with one suspicious email.

A user reports a message.
An alert is generated.
An analyst opens the email details, checks the sender, reviews the URL, and tries to understand whether the message is malicious.

That is a normal starting point. However, in a real SOC investigation, one email is rarely the full story.

Attackers usually operate in campaigns. They reuse sender infrastructure, similar subjects, URLs, payloads, templates, and delivery techniques. A single email may be only one part of a wider phishing or malware campaign targeting multiple users.

This is why campaign-centric hunting is important.

I wrote this article from the perspective of a SOC analyst who often needs to move quickly from a single suspicious email to the full campaign impact. The goal is simple: use Microsoft Defender XDR and Microsoft Sentinel together to understand who was targeted, what was delivered, who clicked, and what should be prioritized first.

Why Campaign-Centric Hunting

When investigating a phishing or malware email, analysts usually need to answer practical questions:

How many users received messages from the same campaign?
Were the messages blocked, junked, delivered, or remediated?
Did any user click the URL?
Did anyone click through a Safe Links warning?
Were any priority or high-risk users affected?
Was the email removed after delivery?
Are there related Defender XDR or Sentinel incidents?

If we only investigate one message, we may miss the bigger picture.

Campaign-centric hunting helps the SOC move from this question:

Is this email malicious?

To this question:

What is the full impact of this campaign?

That shift is important because the response priority should be based on campaign impact, not only on a single alert.

What Campaign Views Provides

Campaign Views in Microsoft Defender for Office 365 help analysts investigate coordinated email attacks such as phishing and malware campaigns.

From Campaign Views, analysts can review campaign-level information such as:

Campaign name
Campaign type
Campaign subtype
Targeted users
Inboxed messages
Clicked users
Visited links
Sender domains
Sender IPs
Payload URLs
Delivery actions
Campaign timeline
Campaign flow

This is useful during triage because it quickly shows whether an email is part of a wider attack.

For example, one reported phishing message may look small at first. But if Campaign Views shows that the same campaign targeted 50 users, delivered messages to 15 inboxes, and had 2 users click the URL, the investigation becomes much more urgent.

Where CampaignInfo Fits

The CampaignInfo table gives analysts a KQL-based way to query campaign-related data.

Some useful fields are:

Field	Purpose
CampaignId	Unique identifier for the campaign
CampaignName	Name of the campaign
CampaignType	Campaign category, such as Phish or Malware
CampaignSubtype	Additional context, such as brand being phished or malware family
NetworkMessageId	Unique identifier for the email message
RecipientEmailAddress	Recipient affected by the campaign
Timestamp	Time when the event was recorded

For correlation, the most important field is usually:

NetworkMessageId

This field can help connect campaign data with other Defender XDR email tables, including:

EmailEvents
UrlClickEvents
EmailPostDeliveryEvents
EmailAttachmentInfo
EmailUrlInfo

This makes CampaignInfo a useful pivot table for campaign-level hunting.

Important note: CampaignInfo is currently documented as Preview. Before using these queries in production analytics rules, validate the table availability, schema, and results in your own tenant.

Practical Scenario

An analyst receives a phishing alert in Microsoft Defender XDR. The alert is related to a user who received a suspicious email with a credential-harvesting URL.

The analyst opens Campaign Views and sees that the message belongs to a wider phishing campaign.

At that point, the investigation should not stop with the original user.

The analyst should now ask:

Who else received this campaign?
How many messages were delivered?
Which users clicked?
Did any users click through the Safe Links warning?
Were the messages removed after delivery?
Are there related incidents in Microsoft Sentinel?

The investigation flow could look like this:

Start from Campaign Views in Microsoft Defender XDR.
Identify the campaign details.
Use CampaignInfo to list affected users and messages.
Join with EmailEvents to validate delivery status.
Join with UrlClickEvents to identify user interaction.
Join with EmailPostDeliveryEvents to confirm remediation.
Review related Microsoft XDR incidents in Microsoft Sentinel.
Prioritize response based on campaign impact.

Query 1: List Recent Campaigns

The first query gives a simple overview of recent campaigns.

CampaignInfo
| where Timestamp > ago(14d)
| summarize
    FirstSeen = min(Timestamp),
    LastSeen = max(Timestamp),
    AffectedUsers = dcount(RecipientEmailAddress),
    Messages = dcount(NetworkMessageId)
    by CampaignId, CampaignName, CampaignType, CampaignSubtype
| order by LastSeen desc

This helps analysts quickly identify campaigns that affected the organization during the selected period.

Useful questions to ask from this output:

Which campaigns are most recent?
Which campaigns affected the most users?
Are the campaigns phishing, malware, or spam?
Is there a specific brand or malware family in the subtype?
Are similar campaigns appearing repeatedly?

Query 2: Understand Delivery Impact

After identifying campaigns, the next step is to understand delivery impact.

A campaign that was fully blocked is different from a campaign that reached user inboxes.

let Campaigns =
CampaignInfo
| where Timestamp > ago(14d)
| project
    CampaignId,
    CampaignName,
    CampaignType,
    CampaignSubtype,
    NetworkMessageId,
    RecipientEmailAddress;
Campaigns
| join kind=leftouter (
    EmailEvents
    | where Timestamp > ago(14d)
    | project
        NetworkMessageId,
        RecipientEmailAddress,
        Subject,
        SenderFromAddress,
        SenderFromDomain,
        SenderIPv4,
        DeliveryAction,
        DeliveryLocation,
        ThreatTypes,
        DetectionMethods,
        Timestamp
) on NetworkMessageId, RecipientEmailAddress
| summarize
    Messages = dcount(NetworkMessageId),
    AffectedUsers = dcount(RecipientEmailAddress),
    Subjects = make_set(Subject, 5),
    SenderDomains = make_set(SenderFromDomain, 10),
    SenderIPs = make_set(SenderIPv4, 10)
    by CampaignId, CampaignName, CampaignType, CampaignSubtype, DeliveryAction, DeliveryLocation
| order by AffectedUsers desc, Messages desc

This query helps separate campaigns that were blocked from campaigns that actually reached users.

From a SOC perspective, delivered messages deserve closer attention, especially if they reached the inbox.

Query 3: Identify Users Who Clicked Campaign URLs

Delivery is important, but clicks usually increase the priority of the incident.

This query joins campaign data with UrlClickEvents.

let Campaigns =
CampaignInfo
| where Timestamp > ago(14d)
| project
    CampaignId,
    CampaignName,
    CampaignType,
    CampaignSubtype,
    NetworkMessageId,
    RecipientEmailAddress;
Campaigns
| join kind=inner (
    UrlClickEvents
    | where Timestamp > ago(14d)
    | project
        NetworkMessageId,
        AccountUpn,
        Url,
        ActionType,
        IsClickedThrough,
        ThreatTypes,
        DetectionMethods,
        IPAddress,
        Workload,
        ClickTime = Timestamp
) on NetworkMessageId
| summarize
    FirstClick = min(ClickTime),
    LastClick = max(ClickTime),
    ClickEvents = count(),
    ClickedUsers = dcount(AccountUpn),
    ClickThroughUsers = dcountif(AccountUpn, IsClickedThrough == true),
    ClickedUrls = make_set(Url, 10),
    SourceIPs = make_set(IPAddress, 10)
    by CampaignId, CampaignName, CampaignType, CampaignSubtype
| order by ClickThroughUsers desc, ClickedUsers desc, LastClick desc

This query helps identify campaigns where users interacted with the payload.

If a user clicked a phishing URL, the next step should usually include identity-focused investigation, such as reviewing sign-in activity, MFA status, session activity, and possible risky sign-ins.

Query 4: Focus on Click-Through Events

Safe Links may block access to a malicious site. In some cases, however, a user may continue through a warning page.

Those cases should be reviewed carefully.

let Campaigns =
CampaignInfo
| where Timestamp > ago(30d)
| project
    CampaignId,
    CampaignName,
    CampaignType,
    CampaignSubtype,
    NetworkMessageId,
    RecipientEmailAddress;
Campaigns
| join kind=inner (
    UrlClickEvents
    | where Timestamp > ago(30d)
    | where IsClickedThrough == true
    | project
        NetworkMessageId,
        AccountUpn,
        Url,
        ActionType,
        ThreatTypes,
        IPAddress,
        ClickTime = Timestamp
) on NetworkMessageId
| project
    ClickTime,
    CampaignId,
    CampaignName,
    CampaignType,
    CampaignSubtype,
    AccountUpn,
    RecipientEmailAddress,
    Url,
    ActionType,
    ThreatTypes,
    IPAddress
| order by ClickTime desc

This is one of the most useful views during incident response.

A click-through event does not automatically mean compromise, but it is a strong reason to investigate the user account further.

Query 5: Confirm Post-Delivery Remediation

A malicious message may be delivered first and removed later by ZAP, AIR, or manual remediation.

This query joins CampaignInfo with EmailPostDeliveryEvents.

let Campaigns =
CampaignInfo
| where Timestamp > ago(30d)
| project
    CampaignId,
    CampaignName,
    CampaignType,
    CampaignSubtype,
    NetworkMessageId,
    RecipientEmailAddress;
Campaigns
| join kind=leftouter (
    EmailPostDeliveryEvents
    | where Timestamp > ago(30d)
    | project
        NetworkMessageId,
        RecipientEmailAddress,
        RemediationTime = Timestamp,
        Action,
        ActionType,
        ActionTrigger,
        ActionResult,
        DeliveryLocation,
        SourceLocation
) on NetworkMessageId, RecipientEmailAddress
| summarize
    RemediatedMessages = dcountif(NetworkMessageId, isnotempty(ActionType)),
    RemediationTypes = make_set(ActionType, 10),
    RemediationResults = make_set(ActionResult, 10),
    LastRemediation = max(RemediationTime)
    by CampaignId, CampaignName, CampaignType, CampaignSubtype
| order by LastRemediation desc

This helps answer a very important question:

Were the delivered malicious messages actually removed?

This is useful for both SOC triage and reporting because it shows not only detection, but also response.

Query 6: Campaign Blast Radius Summary

The following query combines campaign, delivery, click, and remediation data into one campaign-level view.

let TimeRange = 30d;
let Campaigns =
CampaignInfo
| where Timestamp > ago(TimeRange)
| project
    CampaignId,
    CampaignName,
    CampaignType,
    CampaignSubtype,
    NetworkMessageId,
    RecipientEmailAddress;
let Delivery =
EmailEvents
| where Timestamp > ago(TimeRange)
| summarize
    DeliveryActions = make_set(DeliveryAction, 10),
    DeliveryLocations = make_set(DeliveryLocation, 10),
    DeliveredMessages = dcountif(NetworkMessageId, DeliveryAction =~ "Delivered"),
    JunkedMessages = dcountif(NetworkMessageId, DeliveryAction =~ "Junked"),
    BlockedMessages = dcountif(NetworkMessageId, DeliveryAction =~ "Blocked"),
    Subjects = make_set(Subject, 5),
    SenderDomains = make_set(SenderFromDomain, 10)
    by NetworkMessageId, RecipientEmailAddress;
let Clicks =
UrlClickEvents
| where Timestamp > ago(TimeRange)
| summarize
    ClickEvents = count(),
    ClickThroughEvents = countif(IsClickedThrough == true),
    FirstClick = min(Timestamp),
    LastClick = max(Timestamp),
    ClickedUrls = make_set(Url, 10)
    by NetworkMessageId;
let Remediation =
EmailPostDeliveryEvents
| where Timestamp > ago(TimeRange)
| summarize
    RemediationActions = make_set(ActionType, 10),
    LastRemediation = max(Timestamp)
    by NetworkMessageId, RecipientEmailAddress;
Campaigns
| join kind=leftouter Delivery on NetworkMessageId, RecipientEmailAddress
| join kind=leftouter Clicks on NetworkMessageId
| join kind=leftouter Remediation on NetworkMessageId, RecipientEmailAddress
| summarize
    AffectedUsers = dcount(RecipientEmailAddress),
    Messages = dcount(NetworkMessageId),
    DeliveredMessages = sum(DeliveredMessages),
    JunkedMessages = sum(JunkedMessages),
    BlockedMessages = sum(BlockedMessages),
    TotalClickEvents = sum(ClickEvents),
    ClickThroughEvents = sum(ClickThroughEvents),
    Subjects = make_set(Subjects, 10),
    SenderDomains = make_set(SenderDomains, 10),
    ClickedUrls = make_set(ClickedUrls, 10),
    RemediationActions = make_set(RemediationActions, 10),
    LastClick = max(LastClick),
    LastRemediation = max(LastRemediation)
    by CampaignId, CampaignName, CampaignType, CampaignSubtype
| extend SuggestedPriority =
    case(
        ClickThroughEvents > 0, "High",
        TotalClickEvents > 0, "Medium",
        DeliveredMessages > 0, "Medium",
        "Low"
    )
| order by SuggestedPriority asc, AffectedUsers desc, Messages desc

This type of query can be useful during hunting sessions, incident review, and campaign reporting.

The goal is not only to collect more data. The goal is to help the analyst decide what needs attention first.

Correlating Campaign Activity with Microsoft Sentinel

When Microsoft Defender XDR is connected to Microsoft Sentinel, incidents and alerts can be synchronized into the Sentinel incident queue.

This allows the SOC to correlate campaign-related email activity with other security signals, such as:

Suspicious sign-ins
Identity alerts
Endpoint alerts
Cloud app activity
OAuth consent activity
Data exfiltration attempts
Related Microsoft XDR incidents

For example, if a user clicked a phishing URL, the SOC can then review whether the same user had suspicious sign-in activity shortly after the click.

The following query is a simple starting point for reviewing Microsoft XDR incidents in Microsoft Sentinel.

SecurityIncident
| where TimeGenerated > ago(30d)
| where ProviderName == "Microsoft XDR"
| where Title has_any ("phish", "phishing", "email", "malware", "campaign")
| summarize
    Incidents = count(),
    HighSeverity = countif(Severity == "High"),
    MediumSeverity = countif(Severity == "Medium"),
    Closed = countif(Status == "Closed"),
    Active = countif(Status == "Active")
    by bin(TimeGenerated, 1d)
| order by TimeGenerated desc

This query does not replace campaign hunting. It simply helps analysts understand how email-related activity is represented in the Sentinel incident queue.

Suggested SOC Workflow

A practical campaign-centric workflow could look like this:

Step 1: Start from Campaign Views

Review campaigns with delivered messages, clicked users, visited links, or high user impact.

Step 2: Pivot to KQL

Use CampaignInfo to list campaign-related messages and affected recipients.

Step 3: Validate Delivery

Join with EmailEvents to confirm whether messages were blocked, junked, delivered, or replaced.

Step 4: Review User Interaction

Join with UrlClickEvents to identify users who clicked URLs or clicked through Safe Links warnings.

Step 5: Confirm Remediation

Join with EmailPostDeliveryEvents to confirm whether delivered messages were removed after delivery.

Step 6: Correlate in Sentinel

Review related Microsoft XDR incidents and correlate with identity, endpoint, and cloud activity.

Step 7: Decide Response

Depending on the impact, the SOC may decide to:

Escalate the incident
Notify affected users
Review user sign-ins
Revoke user sessions
Reset passwords
Block sender domains or URLs
Submit false negatives
Create a watchlist for related indicators
Tune analytics rules or response processes

Suggested Priority Logic

Not every campaign needs the same level of response.

A simple triage model could be:

Condition	Suggested priority
Campaign blocked before delivery	Low
Campaign delivered to junk	Low to Medium
Campaign delivered to inbox	Medium
Campaign delivered to multiple inboxes	Medium to High
User clicked URL	High
User clicked through warning	High
Priority account clicked	High
Click followed by suspicious sign-in	Critical

This model should be adapted to each organization’s risk profile and response process.

Limitations and Things to Validate

Before using this approach in production, validate the following:

Defender for Office 365 Plan 2 availability
Campaign Views permissions
CampaignInfo table availability
Defender XDR connector configuration
Advanced hunting event streaming
Field names in your environment
Retention period
Data latency
Join behavior using NetworkMessageId
Whether click events can be joined to email metadata in all cases

One important limitation is that some URL click events may not join cleanly with email metadata. For example, clicks from Drafts or Sent Items may not have the same message metadata available for correlation.

Also, because CampaignInfo is currently documented as Preview, I would avoid depending on it alone for critical production automation without testing and validation.

Pending Approval/Provisioning for Microsoft Defender XDR Lab/Trial Environment

TechDefender — Wed, 10 Jun 2026 14:43:13 GMT

Hello Microsoft Community Team,

On June 26, 2026, our organization applied for a Microsoft 365 Developer Environment / Free Trial to support evaluation of the Microsoft Defender XDR Lab environment.

To date, the environment has not been provisioned, and we have not received any status updates or confirmation.

Impact:

Current Status: We are currently utilizing our production environment to test project capabilities, which poses risks and limitations.
Future Intent: Our organization plans to transition to a full, paid Business/Enterprise purchase immediately upon proving the platform’s benefits.

Urgency: This delay is stalling our evaluation phase. We urgently need this environment onboarded and activated so we can proceed with deployment tests and subsequent procurement.

Request: Please review the status of our registration and expedite the onboarding/provisioning of this developer environment.

Thank you for your prompt assistance.

Operational Notes on Microsoft Security Copilot Agents in Defender XDR and Microsoft Entra ID

klianos — Fri, 05 Jun 2026 09:31:28 GMT

Microsoft Security Copilot is now becoming more visible inside day-to-day security operations, especially through embedded experiences and agent-based workflows across Microsoft Defender XDR, Microsoft Entra ID, Microsoft Intune, and Microsoft Purview.

Instead of looking at Security Copilot only as a standalone prompt interface, SOC and identity teams should also understand how Security Copilot agents are deployed, how they consume Security Compute Units, how they appear in operational workflows, and where activity can be monitored.

This post summarizes practical observations from a security operations perspective, with a focus on Microsoft Defender XDR, Microsoft Entra ID, usage monitoring, and KQL-based activity review.

Licensing & Capacity Units

Requirements

Requires eligible Microsoft security licensing, typically:
- Microsoft 365 E5
- Microsoft 365 E7

Security Compute Units (SCUs)

Security Copilot capacity is measured using Security Compute Units (SCUs).
SCUs are billed based on provisioned capacity.
Indicative pricing:
- $4 per Provisionied SCU/hour
- $6 per Overage SCU/hour
Billing is calculated hourly, based on the amount of SCUs provisioned.

Included Capacity

Organizations with:
- 1,000 Microsoft 365 E5 licenses
Receive:
- 400 included SCUs
Included SCUs are shared across the tenant within a common capacity pool.

Scaling

SCU capacity can be scaled dynamically based on operational requirements and workload demand.

Data Retention

Security Copilot session and interaction data without active SCU-backed retention is typically retained for:
- 90 days

Security Copilot Agents - Microsoft Defender

This section outlines the Microsoft Security Copilot agents currently available in the Microsoft Defender portal.

NameKey characteristics Security Alert Triage Agent (Preview)

Manual setup from Defender portal
Automatically creates Unified RBAC custom role
Runs automatically when a user reports a suspicious email or when a new supported alert is generated, supported alert sources: MDI, MDC, MDO
If an alert tuning rule is enabled, it will be automatically disabled when the agent is deployed.
Creates and connects with agentic user account: Phishing Triage Agent (Security Copilot)
Automatic alert assignment to SecurityCopilotAgentUser-db16fec3-f1fb-4632-843e-46d07408c584@<tenant-domain>Alert was assigned to Phishing Triage Agent (Security Copilot).
Adds Tag Agent to the created Incidents

Threat Hunting Agent

Manual setup from Defender portal
Automatically creates Unified RBAC custom role
This agent runs manually. There isn't an automatic trigger.
Creates and connects with agentic user account: Threat Hunting Agent (Security Copilot)
Analyst Questions in natural language
Generates and executed KQL queries in Advanced hunting
Provides charts, dynamic follow-up questions and remediation actions recommendations
No activity is identified from agent's identity during agent execution

Threat Intelligence Briefing Agent

Manual setup from Defender portal
Provides automated TI briefing summary
Configured from https://security.microsoft.com/securitysettings/defender/agent_configuration-threatintelligencebriefingagent

Security Analyst Agent

Manual setup from Defender portal

Dynamic Threat Detection Agent (Preview)

Automatically enabled
always-on, runs continuously in the background
Correlates: Alerts, Security events, Behavioral anomalies, TI signals
Generates Alerts with Detection Source: Security Copilot
The Alerts can be correlated with existing Multi-Stage Incidents
No agentic user account identity is used by this agent
Available free of charge during public preview, will begin consuming Security Compute Units (SCUs) once generally available (GA)

Incidents handled by Security Alert Triage Agent:

Alerts created by Dynamic Threat Detection Agent:

Execution of Threat Hunting Agent:

View agents in use: https://security.microsoft.com/security-copilot/agents

View Unified RBAC custom roles: https://security.microsoft.com/mtp_roles

View Security Copilot user identities in Microsoft Entra ID:

Notes:

CloudAppEvents activity logs only from the following agents:

Phishing Triage Agent
Conditional Access Optimization Agent

Security Copilot Agents - Microsoft Entra ID

Conditional Access Optimization Agent

Usage Monitoring

Sign-in to Security Copilot portal using Global Admin account and navigate to the following location: https://securitycopilot.microsoft.com/usage-monitoring

Reference: https://learn.microsoft.com/en-us/copilot/security/manage-usage

Logging Activity

Copilot Agents Management:

CloudAppEvents

| where ActionType contains "CopilotAgent"

| extend AgentName = RawEventData.AgentName

| extend Workload = RawEventData.Workload

| extend ResultStatus = RawEventData.ResultStatus

| project TimeGenerated, ActionType, ResultStatus, AgentName, Application, Workload

All Copilot Workload data:

CloudAppEvents

| extend Workload = RawEventData.Workload

| where Workload == "Copilot"

| summarize EventCount = count() by ActionType, AccountDisplayName

Prompted to sign in to Microsoft Defender Platform on W11/W2025 using Entra

chrisnelmes — Thu, 04 Jun 2026 12:40:24 GMT

Hi Microsoft Defender XDR community,

Since around May 18th, our users on devices that are onboarded to Microsoft Defender for Endpoint are being prompted to sign-in to the following application using Entra on login to Windows.

Application

Microsoft Defender Platform

Application ID

cab96880-db5b-4e15-90a7-f3f1d62ffe39

Is anyone aware of a change that requires user sign-in to Entra as a requirement for Microsoft Defender for Endpoint? I have tried raising a support topic on this topic.

Regards

Chris

The next frontier in endpoint security: Securing local AI agents with Microsoft Defender

Eitan_Shteinberg — Tue, 30 Jun 2026 03:19:36 GMT

AI agents are now doing real work on the endpoint — reading files, running commands, browsing the web, and acting on behalf of the users they run under. That same power is also what makes them dangerous: agents act on whatever content they take in, and much of it comes from outside the user's control — a web page, a repository, a command's output. A single malicious instruction hidden in that content can turn an agent against the very environment it's trusted to work in. With access to source code, secrets, and the corporate resources, its identity can reach — from cloud infrastructure to SharePoint, email, and internal apps — a compromised agent becomes a path to everything that identity is trusted with.

Yet most security teams can't see this activity at all. Local AI agents run as ordinary processes, with little of the visibility or context SOC teams need to understand — let alone investigate — what an agent actually did.

That’s why today, we're extending Microsoft Defender to secure AI agents running locally on devices. Security teams now have the visibility, context, and control needed to manage this new frontier of endpoint risk without slowing down the developers driving innovation forward. This includes:

Discover 20+ types of local AI agents running on managed Windows and macOS devices
Block malicious AI agent activity on the device in real time
Assess local agent exposure across identities and reachable resources
Investigate local AI agent activity in Advanced Hunting

In preview, Defender now discovers these agents across the endpoint — AI coding agents, AI assistants, local AI runtimes, agentic IDE extensions, and Model Context Protocol (MCP) servers — and adds runtime protection for popular coding agents, with coverage expanding over time. Just as important, it brings them into the same security platform teams already use for endpoints, identities, email, and cloud, so local agents are no longer running unseen alongside the tools security teams already protect, but part of one coordinated defense.

Watch this episode of the Ninja Show to see how Microsoft Defender brings visibility, context, and control to local AI agents, helping security teams securely adopt AI and stay ahead of emerging threats.

Discover local AI agents on managed devices

Security Operation Center (SOC) teams can now identify AI agents running locally as first-class assets, not just operating system (OS) processes. In the Defender portal, security teams can view a dedicated inventory of AI agents across their environment, spanning categories such as:

Coding CLIs and terminal agents: GitHub Copilot CLI, Codex CLI, Claude Code CLI, Gemini CLI, Antigravity CLI, OpenCode
Agentic IDEs and VS Code extensions: Cursor, Windsurf, Antigravity, Claude Code, Codex, Cline, Gemini, GitHub Copilot, Roo Code
Desktop AI assistants: ChatGPT Desktop, Claude Desktop, Codex Desktop, Poe Desktop, Antigravity Desktop, GitHub Copilot App
Local AI runtimes and autonomous platforms: OpenClaw, Nanobot, ZeroClaw, Ollama Desktop

Each agent is surfaced as a security asset, with runtime context including user identity, device and process relationships, trust indicators, and integrity level. Security teams can also see configuration signals, such as “auto-approve” settings and connected services via MCP servers. Defender discovers more than 20 supported local AI agents across Windows and macOS, with coverage continuing to expand.

Figure 1: The AI Assets (preview) inventory and an agent detail record in the Microsoft Defender portal.

Block malicious AI agent activity in real time

Discovery is the starting point. Once SOC teams know which agents are present, they need confidence that malicious behavior will be stopped to reduce impact to their organization’s environment.

For popular coding agents, Defender now provides runtime protection that helps block malicious behavior inline and in real time. This capability starts with Claude Code and GitHub Copilot CLI, with OpenClaw and OpenAI Codex coming soon. When Defender identifies that an agent activity is malicious, it can automatically block it. As with other threats, the user can be notified, and the activity is logged in the protection history.

The SOC analyst receives a detailed alert with agent and session context for investigation, including details on the detected threat. At the same time, the user sees a notification on the device that the activity was blocked.

Figure 2: Runtime protection blocking malicious instructions in a post-tool response

Figure 3: The matching Windows Security notification, blocking the detected threatFigure 4: The corresponding security alert in the Defender portal, with the process tree and session context for investigation

Assess local agent exposure

Knowing an agent exists is only half the picture. The next step is mapping the potential blast radius: the resources the agent touches, the identities it can use, and the assets exposed to its next moves. That’s why every agent discovered is automatically mapped to the device it runs on, the identity associated with that device, the MCP servers it’s connected to, and the cloud resources the identity can reach. The exposure graph turns "this agent exists" into “this agent can do these things” by providing an understanding of the agent’s connectivity across your environment.

As an example, in the map below, the SOC analyst can see that a ChatGPT Desktop agent is tied to a single AWS account, and from that identity its reach extends to S3 buckets, an AWS KMS key, EC2 instances, and an AWS Bedrock agent. The agent has no cloud permissions of its own, but it inherits the account's — so if it were compromised or misused, that reach becomes a path to encrypted data and key material. This view gives security teams a clear picture of the agent's blast radius, so they can decide how to contain it before it's abused.

Figure 5: Exposure map of a local AI agent, showing its identity and the resources that identity can reach.

Investigate local AI agent activity in Advanced Hunting

Beyond the inventory and exposure views, security teams often need to hunt across the environment — to ask which agents are behaving unusually, and what else they touch. Every AI agent discovery event, MCP server connection, and configuration signal is queryable in Advanced Hunting, alongside the endpoint, identity, email, and cloud security telemetry your team already uses every day.

This capability unlocks two use cases that security teams have been asking for:

Correlate agent activity with process, file, network, identity, and cloud telemetry to see the full picture of what the agent did

Hunt for risky configurations – for example, agents running in auto-approve mode under an identity with privileged access to production, source code, or CI/CD systems

Security teams can turn any of these queries into a custom detection rule — for instance, raising an alert whenever a newly discovered agent appears with a risky configuration on a device tied to a privileged identity.

Figure 6: A KQL query in Advanced Hunting tracing which critical resources a local AI agent can reach.

Securing the next frontier of endpoint activity

The risk that opened this post — an agent acting on a malicious instruction and reaching everything its identity can touch — is exactly what this protection is built to contain.

By bringing local AI agents into the same platform teams already use for endpoints, identities, and cloud, Defender turns that blind spot into something security teams can see, investigate, and stop — without getting in the developer's way.

Developers keep the AI tools accelerating their work. Defenders get the visibility and real-time protection to stay ahead of attackers as they turn to this new surface. That balance — speed for builders, control for defenders — is what securing the AI era actually requires.

Learn more

Organize your multitenant view with Tenant Groups in Microsoft Defender

Simaya_Ouli — Wed, 27 May 2026 16:00:00 GMT

Managing security across many tenants shouldn’t mean drowning in a single, flat list. We’re excited to share a new capability, now in public preview in the Microsoft Defender multitenant (MTO) portal: Tenant Groups—a flexible way to organize the tenants you manage and switch your view between them with a single click.

If you’re a managed security service provider (MSSP), a cloud service provider (CSP), or a security team operating across multiple Entra ID tenants, this one’s for you.

What’s new

Tenant Groups let you create logical groupings of tenants (by customer segment, geography, criticality, onboarding stage—whatever fits how you work) and seamlessly switch the Defender MTO view to show data from only the tenants in that group.

NOTICE: The feature previously called Tenant groups—used for content distribution—has been renamed to Deployment profiles. The name “Tenant Groups” now refers to this new grouping experience.

Why it matters

Focus, faster – Investigate incidents, hunt threats, and review posture against just the tenants you care about right now—without noise from the rest.
Operational clarity – Group tenants the way your team actually works (e.g., Tier 1 customers, EMEA, Pilot rollout).
Permissions-aware – Even if a Tenant Group contains more tenants, you’ll only see the ones where you have B2B/GDAP (granular delegated admin privileges) access. Your existing access controls stay in charge.

Permissions you’ll need

To work with Tenant Groups, your account needs one of the following:

Entra ID roles

Security Administrator
Security Operator
Global Administrator

Product-specific (MDE, MDI, etc.) role-based access control (RBAC)

Global Administrator
Security Administrator
Plus, any custom RBAC roles required to see data across products

Unified RBAC (URBAC)

Security/read—to view Tenant Groups
Security/manage—to create Tenant Groups

Remember: A Tenant Group can include tenants you don’t have access to. You’ll only ever see the ones your permissions allow.

Getting started

1. Open Tenant Groups

Sign in to the Microsoft Defender portal with administrative credentials, then navigate to Multitenant Management > Tenant Groups.

You’ll find a built-in group called My private group that contains all the tenants from your previous setup. You can add or remove tenants from it, but it can’t be deleted.

2. Create a Tenant Group

Select + Create tenant group.
Give it a descriptive name (e.g., Healthcare customers, EMEA Tier 1).
Optionally, add a description so teammates know the group’s intent.
Select the tenants you want to include.

That’s it—your group is ready.

3. Switch between Tenant Groups

In the top-left corner of the portal, select Open multitenant management.
Choose the group you just created.

Navigate around the Defender MTO portal—incidents, alerts, devices, hunting—and you’ll see only data from the tenants in that group. Switch groups anytime to refocus.

Live change detection: If a teammate edits a Tenant Group (adds or removes tenants) while you’re viewing it, the portal surfaces a notification so you know the underlying scope has changed. No stale views, no surprises.

4. Edit a Tenant Group

Go back to Multitenant Management > Tenant Groups.
Select the group and choose Edit.
Add or remove tenants as your environment evolves, then re-test your views.

Tips for getting the most out of Tenant Groups

Start with how your team triages – Name groups after the workflows you actually run (On-call queue, Customer A—production).
Keep groups small and purposeful – Overlapping, focused groups beat one giant catch-all.
Pair with Deployment profiles – Use Tenant Groups for viewing, and Deployment profiles for distributing content—two clean, complementary concepts.
Audit access regularly – Because group membership is independent of B2B/GDAP access, periodic reviews keep expectations aligned.

We want your feedback

Tenant Groups are designed around real multitenant operations work—and we’d love to hear how you’re using them. Try it out in your environment, share what’s working (and what isn’t), and let us know what you’d like to see next.