Microsoft Defender XDR topics

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.

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

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

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.

Identity Attack Graph in Microsoft Sentinel

klianos — Wed, 06 May 2026 11:47:45 GMT

Identity is now one of the most important attack surfaces in cloud security. In many real-world incidents, attackers do not rely only on malware or network movement. Instead, they abuse identities, permissions, role assignments, group memberships, service principals, and misconfigured access paths to move from an initial compromise to high-value resources.

This is why the new Identity Attack Graph in Microsoft Sentinel is an important capability. It helps security teams visualize how identities are connected to Azure resources and how an attacker could potentially move from one identity to another resource through permissions and relationships.

What is the Identity Attack Graph?

The Identity Attack Graph in Microsoft Sentinel provides a visual way to understand how identities, permissions, groups, and Azure resources are connected.

Instead of manually checking multiple portals, logs, and role assignments, the graph helps analysts understand relationships such as:

Which identities have access to specific Azure resources
Which users or service principals are over-privileged
Which groups provide indirect access to sensitive resources
Which identities may have a path to critical assets
What the potential blast radius of a compromised identity could be
How attackers could move laterally through identity and permission relationships

This is especially useful because identity risk is often not obvious when looking at a single user, group, or role assignment in isolation. The real risk usually appears when these relationships are connected together.

A user may not directly have access to a sensitive resource, but the user may be a member of a group that has access to another resource, which then has permissions that create a path toward a high-value asset.

The Identity Attack Graph helps expose these hidden relationships.

Why this matters

In many Azure environments, permissions grow over time. Users change roles, groups are reused, emergency access is granted, service principals are created, and temporary permissions are not always removed.

As a result, organizations often end up with:

Too many privileged identities
Unused or stale permissions
Service principals with excessive access
Guest users with unnecessary permissions
Groups that provide indirect access to sensitive resources
Subscription-level roles that are broader than required
Lack of visibility into who can reach critical assets

Traditional investigation usually requires analysts to move between several places, including Microsoft Entra ID, Azure RBAC, Azure Activity logs, Sentinel queries, Defender XDR, and Azure Resource Graph.

The Identity Attack Graph reduces this complexity by presenting identity relationships as a connected graph.

This makes it easier to answer practical security questions such as:

“What can this identity access?”
“What happens if this user is compromised?”
“Which identities have a path to critical resources?”
“Which access path should we remediate first?”
“Which permissions create the highest risk?”
“Why does this identity have access to this asset?”

Key use cases

The feature can support several important identity security and cloud security scenarios.

1. Attack path discovery

Security teams can use the graph to identify how an attacker could move from a compromised identity to a sensitive Azure resource.

This is useful during both proactive assessments and active incident response.

For example, if a user account is suspected to be compromised, the graph can help identify which resources may be reachable through that identity’s direct or indirect permissions.

2. Blast-radius analysis

When an identity is compromised, one of the first questions is:

What could the attacker access with this identity?

The Identity Attack Graph can help analysts understand the potential impact of a compromised user, group, service principal, or managed identity.

This can help with containment, prioritization, and communication with stakeholders.

3. Over-privileged identity detection

The graph can help identify identities that have more permissions than they need.

Include:

Users with Owner or Contributor access at subscription level
Service principals with broad permissions
Guest users with privileged access
Groups that grant access to sensitive resources
Identities that have access to multiple critical assets

This is useful for enforcing least privilege and reducing identity attack surface.

4. Privileged access review

IAM and cloud security teams can use the graph to support access reviews.

Instead of only reviewing a list of role assignments, teams can understand the real impact of those permissions.

This helps answer:

Is this role assignment still required?
Does this group create unnecessary risk?
Does this identity have access to critical resources?
Is this access direct or inherited?
Is this path expected or suspicious?

5. Incident response and threat hunting

For SOC teams, the graph can support investigations involving:

Suspicious sign-ins
Compromised users
Privilege escalation
Suspicious role assignments
Lateral movement
Service principal abuse
Unusual access to sensitive resources

The graph does not replace logs or hunting queries, but it gives analysts a faster way to understand relationships and prioritize what to investigate next.

Important prerequisites and setup notes

During my evaluation, there were a few important setup requirements that should be clearly highlighted.

Microsoft Sentinel permissions

The environment must already be onboarded to Microsoft Sentinel, and the user testing or configuring the feature must have the appropriate Microsoft Sentinel permissions.

The documented role requirement includes Microsoft Sentinel Contributor.

However, in my experience, this is not always enough for the full onboarding and validation experience.

Subscription-level Owner permission

One important prerequisite that should be clearly mentioned is that Owner permissions at the Azure subscription level may be required.

This is especially important during onboarding and activation, because the graph depends on access to Azure resource and permission relationships.

If the user does not have sufficient subscription-level permissions, some setup steps or visibility into resources and relationships may not work as expected.

Recommended permission note:

In addition to Microsoft Sentinel permissions, ensure that the user configuring the preview has Owner permissions at the subscription level for the subscriptions that should be represented in the graph.

This should be made very clear in the onboarding documentation to avoid confusion during deployment.

Required data connector: Azure Resource Graph

Another very important setup step is the Azure Resource Graph data connector.

The Azure Resource Graph connector must be:

Installed manually

Activated manually

Connected to the relevant Sentinel workspace

This is a key point. The connector is not automatically enabled just because the Identity Attack Graph feature is available.

Without this connector, Sentinel may not have the required Azure resource relationship data needed to build a useful graph.

Why Azure Resource Graph is important

Azure Resource Graph provides visibility across Azure resources, subscriptions, and relationships. For an identity attack graph, this data is essential.

The graph needs to understand not only identities, but also the resources those identities can reach.

This may include:

Subscriptions
Resource groups
Storage accounts
Key Vaults
Virtual machines
Managed identities
Role assignments
Resource relationships
Resource hierarchy
Critical assets

Without Azure Resource Graph data, the attack graph may not provide the full picture of how identities connect to Azure resources.

For this reason, I believe the onboarding instructions should explicitly state:

The Azure Resource Graph data connector must be manually installed and activated before using the Identity Attack Graph.

Recommended onboarding checklist

Before using the Identity Attack Graph, I would recommend validating the following:

Requirement

Recommendation

Microsoft Sentinel workspace

Ensure the workspace is active and accessible

Sentinel role

Microsoft Sentinel Contributor or equivalent access

Subscription permissions

Owner permissions at subscription level

Azure Resource Graph connector

Manually install and activate the connector

Azure RBAC visibility

Ensure access to relevant role assignments

Microsoft Entra ID visibility

Ensure identity and group data is available

Resource visibility

Validate that relevant subscriptions and resources are visible

Data freshness

Allow enough time for data collection and graph population

This checklist can help avoid issues where the feature appears available but does not show the expected relationships.

How the Identity Attack Graph improves investigation

Before using a graph-based approach, an analyst often needs to manually collect and correlate data from multiple sources.

A typical investigation may include:

Checking the user in Microsoft Entra ID
Reviewing group memberships
Reviewing Azure RBAC assignments
Checking subscription-level access
Looking at resource-level permissions
Reviewing PIM activations
Searching Sentinel logs
Running KQL queries
Checking Azure Activity logs
Validating access with cloud or IAM teams

This process can be time-consuming.

The Identity Attack Graph helps reduce this effort by showing relationships visually. This allows the analyst to understand the possible path faster and decide where to focus.

For example, instead of manually asking:

“Does this user have access to this resource through any group, role, or inherited permission?”

The graph can help show the relationship directly.

This is valuable because many risky permissions are indirect. The user may not have direct access, but may inherit access through a group, role assignment, nested relationship, or service principal path.

Where validation is still needed

Although the graph provides strong visibility, I would still validate findings before taking remediation action.

This is especially important because removing access can affect business operations or production systems.

I would still validate with:

Microsoft Sentinel KQL queries
Microsoft Entra sign-in logs
Microsoft Entra audit logs
Azure Activity logs
Azure RBAC role assignments
PIM activation history
Defender XDR signals
Defender for Cloud recommendations
Azure Resource Graph queries
IAM team input
Cloud platform team input
Application owner confirmation

The graph is very useful for discovery and prioritization, but final remediation decisions should still be validated.

GQL and graph-based investigation

One of the interesting aspects of this feature is the use of graph-based thinking.

Security teams are already familiar with query languages such as KQL for log analytics. However, graph investigation is different.

KQL is excellent for searching and analyzing events over time, such as sign-ins, alerts, audit logs, and activity logs.

Graph Query Language, or GQL, is designed for querying connected data. Instead of only asking what happened at a specific time, graph queries help answer how entities are connected.

In identity security, this is very powerful because the risk often exists in the relationship between objects.

Graph entities include:

Users
Groups
Service principals
Managed identities
Roles
Subscriptions
Resource groups
Azure resources
Permissions
Sessions
Attack paths

Graph relationships include:

User is member of group
Group has role assignment
Identity has access to resource
Service principal owns application
Managed identity can access Key Vault
User can escalate privilege
Identity can reach critical asset

This allows analysts to ask more relationship-focused questions, such as:

Which identities can reach this resource?
What is the shortest path from this user to a critical asset?
Which groups create privileged access?
Which service principals have paths to sensitive resources?
Which identities have indirect access through nested relationships?
Which attack paths include subscription Owner or Contributor permissions?

KQL vs GQL: why both are useful

KQL and GQL serve different but complementary purposes.

Area

KQL

GQL / Graph Querying

Main purpose

Analyze logs and events

Analyze relationships and paths

Best for

Time-based investigation

Connected identity/resource investigation

question

“Did this user sign in from a risky location?”

“What resources can this user reach?”

Data model

Tables

Nodes and edges

Common use

Detection, hunting, analytics

Attack path discovery, relationship mapping

Strength

Event correlation

Path discovery

In practice, security teams need both.

KQL can identify a suspicious sign-in.
The Identity Attack Graph can show what the compromised identity could access.
KQL can then be used again to validate whether the attacker interacted with those resources.

This creates a strong workflow between event-based detection and relationship-based investigation.

Graph investigation scenarios

The following are conceptual are the types of graph questions that would be useful in identity attack path analysis.

Find paths from a user to critical resources

A useful graph query would help answer:

Show me all paths from this user to critical Azure resources.

This could help determine whether a compromised identity has a direct or indirect route to sensitive assets.

Find identities with paths to Key Vaults

Key Vaults often contain secrets, certificates, and keys.

A graph query could help identify:

Which users, groups, service principals, or managed identities have a path to Key Vault resources?

This would be useful for prioritizing access review and remediation.

Find subscription-level privileged identities

Subscription-level roles are high-impact because they can provide broad access.

A graph query could help find:

Which identities have Owner or Contributor access at subscription level?

This is especially important because subscription-level permissions can create wide attack paths.

Find indirect access through groups

Many access paths are created through group membership.

A graph query could help answer:

Which users have access to this resource through group membership?

This can help IAM teams clean up excessive or unnecessary group-based access.

Find service principals with broad access

Service principals are often used for automation and applications, but they can become high-risk if over-privileged.

A useful query would identify:

Which service principals have broad access to subscriptions or critical resources?

This is important because service principal compromise can lead to significant impact.

How GQL can improve analyst workflows

Adding strong GQL support to the graph explorer would make the feature more powerful for advanced users.

You could use graph queries to:

Search for specific paths
Filter by identity type
Filter by role
Filter by resource type
Find shortest paths
Find high-risk paths
Exclude known approved paths
Focus on critical assets
Query only privileged relationships
Identify unexpected permission chains

This would help both SOC analysts and cloud security engineers move from visual exploration to repeatable analysis.

A SOC analyst may want a quick visual graph during an incident, while a cloud security engineer

Scope filter (preview) has stopped working in Edge/Chrome

Pal Espen Bru — Wed, 06 May 2026 08:05:00 GMT

We have noticed that the Scope filter (preview) under Exposure Management -> Vulnerability Management has stopped working across all our desktops on the latest versions of Edge and Chrome. We see it across the board so guess it should be replicatable by you too.

Not critical enough that it warrants our time spent on an incident since it'll likely get reported anyhow, but putting it out here in case it's picked up by the Product Owners or Dev teams.

Microsoft Defender Incident – Handling incident severity change.

esanya2280 — Mon, 04 May 2026 12:06:36 GMT

I am polling incidents via Microsoft Graph API every 5 minutes, initially filtering out Low/Informational incidents.

Later, some low severity incidents are updated to High/Medium severity.

Is there any built-in mechanism in Defender for tracking severity transitions?

Fishing linking passwords and data

79470Valen — Thu, 02 Apr 2026 15:06:48 GMT

activar control de seguridad mejorada antivirus maleware and fishing data

Why there is no Signature status for the new process in the DeviceProcessEvent table?

rstanile — Thu, 12 Mar 2026 09:22:30 GMT

According to the schema, there is only field for checking the initiating (parent) process digital signature, named InitiatingProcessSignatureStatus. So we have information if the process that initiated the execution is signed. However, in many security use-cases it is important to know if the spawned (child) process is digitally signed.

Let's assume that Winword.exe (signed) executed unsigned binary - this is definitely different situation than Winword.exe executing some signed binary (although both may be suspicious, or legitimate).

I feel that some valuable information is not provided, and I'd like to know the reason. Is it related to the logging performance? Or some memory structures, that are present only for the already existing process?

Issues blocking DeepSeek

KevinJohnson1 — Thu, 26 Feb 2026 02:45:18 GMT

Hi all,

I am investigating DeepSeek usage in our Microsoft security environment and have found inconsistent behaviour between Defender for Cloud Apps, Defender for Endpoint, and IOC controls. I am hoping to understand if others have seen the same.

Environment

Full Microsoft security and management suite

What we are seeing

Defender for Cloud Apps

DeepSeek is classified as an Unsanctioned app

Cloud Discovery shows ongoing traffic and active usage

Multiple successful sessions and data activity visible

Defender for Endpoint Indicators

DeepSeek domains and URIs have been added as Indicators with Block action

Indicators show as successfully applied

Advanced Hunting and Device Timeline

Multiple executable processes are initiating connections to DeepSeek domains

Examples include Edge, Chrome, and other executables making outbound HTTPS connections

Connection status is a mix of Successful and Unsuccessful

No block events recorded

Settings

Network Protection enabled in block mode

Web Content Filtering enabled

SmartScreen enabled

File Hash Computation enabled

Network Protection Reputation mode set to 1

Has anyone else had similar issues when trying to block DeepSeek or other apps via Microsoft security suite?

I am currently working with Microsoft support on this but wanted to ask here as well.

Observed Automation Discrepancies

Aar123 — Mon, 09 Feb 2026 08:54:18 GMT

Hi Team ... I want to know the logic behind the Defender XDR Automation Engine . How it works ?

I have observed Defender XDR Automation Engine Behavior contrary to expectations of identical incident and automation handling in both environments, discrepancies were observed. Specifically, incidents with high-severity alerts were automatically closed by Defender XDR's automation engine before reaching their SOC for review, raising concerns among clients and colleagues. Automation rules are clearly logged in the activity log, whereas actions performed by Microsoft Defender XDR are less transparent .

A high-severity alert related to a phishing incident was closed by Defender XDR's automation, resulting in the associated incident being closed and removed from SOC review. Wherein the automation was not triggered by our own rules, but by Microsoft's Defender XDR, and sought clarification on the underlying logic.

Invalidating kerberos tickets via XDR?

JoelNyRe — Mon, 26 Jan 2026 19:40:38 GMT

Since we have alerts every now and then, regarding suspected Pass the Ticket-incidents, I want to know if there's a way to make a user's kerberos ticket invalid? Like we have the "Revoke Session" in Entra ID, is there anything similar that we can do in XDR?

Where can I get the latest info on Advanced Hunting Table Retirement

david_n_o — Tue, 20 Jan 2026 11:35:09 GMT

First question - where can I find the latest info on the deprecation of advanced hunting tables?

Background - I was developing some detections and as I was trying to decide on which table I should use I opened up the docs containing the schema for the `EntraIdSignInEvents` table (https://learn.microsoft.com/en-us/defender-xdr/advanced-hunting-entraidsigninevents-table) and was met by two ambiguous banners stating:

"On December 9, 2025, the EntraIdSignInEvents table will replace AADSignInEventsBeta. This change will be made to remove the latter's preview status and to align it with the existing product branding. Both tables will coexist until AADSignInEventsBeta is deprecated after the said date.

To ensure a smooth transition, make sure that you update your queries that use the AADSignInEventsBeta table to use EntraIdSignInEvents before the previously mentioned date. Your custom detections will be updated automatically and won't require any changes."

"Some information relates to prereleased product that may be substantially modified before it's commercially released. Microsoft makes no warranties, express or implied, with respect to the information provided here.

Customers need to have a Microsoft Entra ID P2 license to collect and view activities for this table."

This made me very confused as I still have data from AADSignInEventsBeta on my tenant from today. I'm not sure what this means and I'm hoping to get some clear info on table retirement.