Microsoft Sentinel topics

Windows Forwarded Events connector with Windows Security Events NRT rules

enescalban — Sun, 26 Jul 2026 00:07:11 GMT

Hello,

We are testing Microsoft Sentinel using the official Windows Forwarded Events connector.

Environment

- Windows Server WEC

- Windows Event Forwarding

- Azure Arc

- Azure Monitor Agent

- Windows Forwarded Events connector

Everything works correctly.

Forwarded security events are successfully ingested into the WindowsEvent table.

For example:

- Event ID 1102

- Event ID 4732

However, the built-in Windows Security Events NRT Analytics Rules (Content Hub version 1.0.1) query only the SecurityEvent table.

Example:

NRT Security Event log cleared

SecurityEvent

| where EventID == 1102

As a result, forwarded events received through the Windows Forwarded Events connector never trigger these NRT rules.

Question:

Is this expected behavior?

Should Windows Forwarded Events customers use a different set of analytics rules (ASIM or other templates), or should these built-in NRT rules also support WindowsEvent?

Thank you.

Hunting AI Agent Configuration Drift with Microsoft Sentinel

Marcel_Graewer — Mon, 20 Jul 2026 12:28:46 GMT

Four KQL patterns for detecting instruction changes, new MCP servers, ownership changes, and organization-wide sharing

I recently authored and contributed four new Microsoft Sentinel hunting queries for detecting security-relevant configuration drift in AI agents. They have been reviewed, approved, and merged into Microsoft's public Azure-Sentinel repository.

I built the queries around four changes that can materially affect an agent's behavior, access, or exposure: instructions being modified, MCP servers being connected, owners being added, and sharing being expanded to the entire organization. Each modification may be legitimate, but each deserves enough context for a security team to verify that it was expected and authorized.

For a security operations team, the difficult question is often not what does this agent look like now? It is what changed since the last known state?

Microsoft Sentinel's AgentsInfo table provides inventory-style snapshots of AI agents and their associated configuration. That makes it useful for more than posture reporting. By comparing a recent snapshot with an earlier baseline, we can hunt for configuration drift that deserves investigation.

This post walks through four practical hunting scenarios:

Instructions changed on a previously published agent
A newly observed MCP server on an existing agent
An owner added to an MCP-enabled agent
Sharing expanded from a restricted scope to the entire organization

The complete hunting queries are available in Microsoft's public Azure-Sentinel repository. The focus here is the detection design behind them, the KQL patterns they share, and the investigation questions they help answer.

What I contributed

I wrote the four standalone hunting queries discussed in this article and submitted them to Azure/Azure-Sentinel in pull request #14702:

AI Agents - Instructions changed on previously published agent
AI Agents - Newly observed MCP server on existing agent
AI Agents - Owner added to MCP-enabled agent
AI Agents - Sharing expanded to organization-wide

The contribution went through several rounds of technical review. Across six commits, I aligned the queries with the unified AgentsInfo schema, added schema-tolerant IdentityInfo enrichment, improved entity mappings, bounded the identity lookback, expanded all owner values, and kept the ATT&CK mappings limited to scenarios where a precise technique could be defended. Repository collaborator v-atulyadav approved the final revision, and the four queries were merged into master on July 20, 2026.

This article explains the detection logic and engineering decisions behind that contribution rather than simply reproducing the final YAML files.

Why current-state queries are not enough

A current-state query can answer questions such as:

Which agents are published?
Which agents have MCP servers configured?
Which agents are shared with the organization?
Who owns a particular agent?

Those are important posture questions, but they do not tell us whether the state is new. An agent with an MCP server might have been reviewed and approved months ago. The same MCP server appearing for the first time today is a different security signal.

Configuration-drift hunting adds the missing time dimension. Instead of treating a risky-looking property as an event, it compares two states of the same agent and reports only meaningful transitions.

The common detection pattern

I used the same basic time model across all four hunts:

let lookback = 14d; let recent = 2d;

The latest snapshot observed during the last two days becomes the current state. The latest snapshot from the preceding portion of the 14-day lookback becomes the baseline.

Conceptually, the comparison looks like this:

let CurrentState = AgentsInfo | where Timestamp > ago(recent) | summarize arg_max(Timestamp, *) by AgentId | where LifecycleStatus != "Deleted"; let BaselineState = AgentsInfo | where Timestamp between (ago(lookback) .. ago(recent)) | where LifecycleStatus != "Deleted" | summarize arg_max(Timestamp, *) by AgentId; CurrentState | join kind=inner BaselineState on AgentId

Several details matter here:

arg_max(Timestamp, *) by AgentId selects the latest available state for each agent in the relevant time range.
The inner join restricts results to agents that exist in both periods. A newly created agent is therefore not automatically treated as configuration drift on an existing agent.
Deleted lifecycle snapshots are excluded so that a deletion record does not become the effective baseline or current configuration.
The two-day current window is operationally significant. To retain coverage, these hunts should run within two days of a change.

The 14-day and two-day values are practical defaults, not universal constants. Environments with different ingestion cadence or retention requirements can adjust them, but the current and baseline windows must remain non-overlapping.

Scenario 1: Instructions changed on a published agent

An agent's instructions define its default behavior, persona, and operating boundaries. Changing them can be part of normal development, but it can also weaken restrictions, redirect the agent's behavior, or modify how it uses connected capabilities.

The first hunt compares the current and previous instruction values only when the agent was published in both snapshots:

CurrentState | join kind=inner BaselineState on AgentId | where CurrentInstructions != PreviousInstructions | extend PreviousInstructionsHash = hash_sha256(PreviousInstructions), CurrentInstructionsHash = hash_sha256(CurrentInstructions), InstructionsLengthDelta = strlen(CurrentInstructions) - strlen(PreviousInstructions)

I deliberately chose to expose hashes and a length delta rather than returning both instruction bodies in plaintext. This confirms that a change occurred without unnecessarily spreading potentially sensitive prompts through query results, exports, or screenshots.

Useful investigation questions include:

Was the change associated with an approved development or release process?
Did the agent remain published while the instructions changed?
Were guardrails, declared tools, permissions, or sharing settings modified around the same time?
Do audit records identify an expected actor and change path?

The query maps well to an integrity-focused investigation. Its MITRE ATT&CK mapping is T1565.001 (Stored Data Manipulation), but the result is still a hunting lead rather than proof of malicious manipulation.

View the complete instruction-change query

Scenario 2: A newly observed MCP server

Model Context Protocol servers can extend an agent with external tools, data sources, or actions. From a defender's perspective, the important transition is not simply that an MCP server exists. It is that a server name appears in the current configuration but was absent from the baseline.

The query expands the dynamic McpServers array and builds a set of server names for each agent:

let CurrentMcp = CurrentRaw | mv-expand Mcp = McpServers | extend McpName = tostring(Mcp.name) | where isnotempty(McpName) | summarize CurrentMcpServers = make_set(McpName) by AgentI

It performs the same normalization for the baseline, then calculates the difference:

| extend AddedMcpServers = set_difference(CurrentMcpServers, BaselineMcpServers) | where array_length(AddedMcpServers) > 0

Using set_difference() avoids raising a result merely because the order of array elements changed. The hunt reports only MCP server names present in the current set and absent from the previous set.

An analyst should validate more than the displayed name:

Is the MCP integration part of the approved inventory?
What endpoint, authentication method, and permissions are associated with it?
Which tools or data can the server expose to the agent?
Was the integration introduced through an expected deployment path?
Did ownership, instructions, or sharing change in the same period?

I did not assign an ATT&CK technique to this query. Adding an MCP server does not, by itself, prove command execution, persistence, or a specific attacker behavior. Avoiding an overly broad mapping keeps the signal honest.

View the complete MCP-server query

Scenario 3: An owner added to an MCP-enabled agent

Ownership is a control-plane relationship. A newly added owner may be able to modify an agent's configuration, instructions, integrations, or publication state. The risk becomes more interesting when the agent already has MCP servers configured.

The hunt first limits the current state to MCP-enabled agents:

| where array_length(coalesce(McpServers, dynamic([]))) > 0 | project AgentId, Timestamp, Name, Platform, CreatedDateTime, CurrentOwners = coalesce(Owners, dynamic([])), McpServers

It then compares the owner arrays as sets:

| extend AddedOwners = set_difference(CurrentOwners, PreviousOwners) | where array_length(AddedOwners) > 0 | mv-expand AddedOwnerId = AddedOwners to typeof(string)

Expanding AddedOwners produces one row per newly observed owner. This is more useful than returning one opaque dynamic array because every added identity can be enriched, mapped, and investigated independently.

I kept the raw object identifier in the result even when identity enrichment fails:

| extend AddedOwnerUpn = AccountUpn, UnresolvedAddedOwnerId = iff(isempty(AccountUpn), AddedOwnerId, "")

That fallback matters. A missing UPN should not hide the underlying ownership change.

Investigation should establish:

Is the added owner an expected person, service identity, or administrative group?
Does the identity's role and business function justify control of this agent?
Was the owner added before other configuration changes?
Does the identity appear in related sign-in, audit, or privileged-access activity?
Should ownership be removed while the change is reviewed?

This query maps to T1098 (Account Manipulation) under Persistence and Privilege Escalation. As with the instruction-change hunt, the mapping frames an investigation hypothesis; it does not label every ownership change as malicious.

View the complete owner-change query

Scenario 4: Sharing expanded to the entire organization

An agent can move from a limited audience to organization-wide availability without changing its underlying tools or instructions. That transition can materially increase exposure, especially when the agent has MCP integrations or declared tools.

The hunt treats "*" in SharedWith as the organization-wide state. The current snapshot must contain it, while the baseline must not:

// Current state | where set_has_element(coalesce(SharedWith, dynamic([])), "*") // Baseline state | where not(set_has_element(coalesce(SharedWith, dynamic([])), "*"))

The result also counts MCP servers and declared tools:

| extend McpServerCount = array_length(coalesce(McpServers, dynamic([]))), DeclaredToolCount = array_length(coalesce(DeclaredTools, dynamic([]))) | extend HasElevatedCapabilities = McpServerCount > 0 or DeclaredToolCount > 0 | sort by HasElevatedCapabilities desc, Timestamp desc

I use HasElevatedCapabilities as a prioritization field, not a verdict. It brings agents with connected capabilities to the top of the result set so analysts can review the potentially larger blast radius first.

Questions for triage include:

Was organization-wide publication explicitly approved?
Is the agent intended for every user, or was a group-based scope expected?
What data sources, tools, and MCP servers can organization-wide users reach through it?
Do the instructions contain assumptions that were safe only for a restricted audience?
Were access reviews or user-acceptance tests completed before the expansion?

No ATT&CK mapping is assigned because a broader sharing scope is a security-relevant exposure change, but not a sufficiently precise adversary technique on its own.

View the complete sharing-scope query

Resolving owners without making the hunt schema-fragile

The Owners field contains identifiers. Human-readable identity context makes results easier to triage, and entity mappings make those identities more useful in Sentinel investigations.

I built a small, materialized IdentityInfo lookup that is shared by the four hunts:

let IdentityIdtoUPN = materialize( IdentityInfo | extend ResolvedAccountUpn = tostring( column_ifexists("AccountUpn", column_ifexists("AccountUPN", ""))), IdentityTimestamp = todatetime( column_ifexists("Timestamp", column_ifexists("TimeGenerated", datetime(null)))) | where IdentityTimestamp >= ago(lookback) | where isnotempty(AccountObjectId) and isnotempty(ResolvedAccountUpn) | summarize arg_max(IdentityTimestamp, ResolvedAccountUpn) by AccountObjectId | project AccountObjectId = tostring(AccountObjectId), AccountUpn = ResolvedAccountUpn);

There are three design choices worth noting:

column_ifexists() accommodates observed IdentityInfo naming variants without maintaining separate query versions.
The lookup is bounded by the same lookback period instead of scanning unbounded identity history.
arg_max() keeps the latest usable identity record for each object ID.

After enrichment, the queries map the account using the UPN components and the Entra object ID:

entityMappings: - entityType: Account fieldMappings: - identifier: Name columnName: OwnerAccountName - identifier: UPNSuffix columnName: OwnerAccountUPNSuffix - identifier: AadUserId columnName: OwnerId

The strong AadUserId identifier remains valuable even when display information changes. Microsoft Sentinel can use mapped entities in bookmarks and investigation experiences, so mapping the changed owner is more than cosmetic enrichment.

Turning a result into an investigation

These queries intentionally stop at the configuration transition. AgentsInfo tells us that two snapshots differ; it does not necessarily tell us who performed the change, through which interface, or whether the action was authorized.

A practical investigation workflow is:

Confirm that the two snapshots represent the expected agent and time period.
Review the exact changed property and the agent's current capabilities.
Identify the owner or newly added owner through IdentityInfo and Entra ID context.
Correlate the transition with the relevant audit source for actor attribution.
Check for related changes to permissions, tools, data sources, publication state, and sharing.
Validate the change against an approved request, release, or ownership process.
Restrict, unpublish, or revert the agent if the exposure cannot be justified.

Expected changes can still be useful findings. Repeated legitimate results may reveal that a deployment process lacks a stable change window, that ownership is managed through noisy automation, or that the hunt's timing needs to be aligned with release activity.

Tuning the hunts for your environment

Before operational use, consider the following adjustments:

Run cadence: Execute within the two-day current window. A daily cadence provides overlap without blending current and baseline periods.
Lookback: Increase the 14-day lookback only if snapshot history and query cost support it. A longer lookback does not compensate for missing the current window.
Known change windows: Add watchlists or environment-specific suppression logic for well-controlled automated deployments, while retaining enough context to audit the change.
Agent scope: Filter by platform, business unit, agent naming convention, or owner if different teams require separate triage queues.
Risk prioritization: Raise agents with sensitive declared data sources, powerful tools, privileged owners, or broad availability to the top of the result set.
Audit correlation: Keep attribution logic separate unless the audit source and join keys are stable in your environment. This makes the configuration-drift hunt reusable while allowing each organization to attach its own control-plane evidence.

Test with representative snapshots before treating any hunt as an operational control. In particular, validate array shapes for Owners, McpServers, and SharedWith, confirm the identity fields present in your workspace, and exercise both changed and unchanged states.

Using the queries

The four YAML definitions have been merged into the Hunting Queries/AI Agents folder of Microsoft's Azure-Sentinel repository. Each file contains the complete KQL, description, entity mappings, and ATT&CK mappings where a precise technique applies.

The broader pattern is reusable beyond these four scenarios: select a stable current snapshot, select a non-overlapping baseline, normalize dynamic properties into comparable sets, calculate the transition, and enrich only after the drift has been identified. That keeps the core detection explainable and gives the analyst the before-and-after context needed for a defensible investigation.

References

I authored the four hunting queries discussed in this article and contributed them to Microsoft's Azure-Sentinel repository as PR #14702. The complete implementations and review history are publicly available through the links above.

Sentinel - Defender XDR KQL Queries Library

GokselATAKAN — Sun, 19 Jul 2026 11:33:56 GMT

Hello all,

I’ve been building something over the past few weeks that I think the security community might find useful.

GoXDR is a searchable KQL query library for Microsoft Sentinel and Defender XDR. The name comes from a nickname my colleagues gave me (GoX) combined with XDR. I also picked up goxdr.fyi as a short and easy to remember domain for it.

You can check it out here: https://goxdr.fyi

The idea came from my own day to day work as someone working in IAM and SOC operations. I constantly find myself writing and refining KQL queries for threat hunting, detection engineering and incident investigation. Over time I realized I had a growing collection of queries that I kept going back to and I thought why not make these available to others?

It currently has 117 queries covering identity security, BEC/AiTM detection, NTLM and LDAP attack hunting, OAuth governance, AI/Copilot security, Sentinel alert trending, SOC performance metrics and more.

Some of these queries are ones I wrote from scratch based on real scenarios I encountered in production environments. Others are community queries I tested and validated in my own setup. Only the ones I found genuinely useful and that actually worked against real data made it in.

Each query comes with a description explaining what it detects and why it matters, along with severity levels, platform tags (Sentinel, XDR or both) and a copy button so you can paste it directly into Advanced Hunting or use it as the basis for an Analytics Rule.

The site is open source, hosted on GitHub Pages and licensed under CC BY 4.0. No sign-up, no paywall, no tracking. The source is available.

I’ll keep adding queries as new scenarios come up. If there’s enough interest I’m also considering adding Cortex XQL queries for Palo Alto environments.

Suggestions, feedback or ideas for new detections are always welcome. Feel free to reach out.

Thanks

Sentinel - Defender for Cloud P2 Benefit

DaithiG — Mon, 06 Jul 2026 09:11:03 GMT

Hi all,

To receive the the benefit of the Sentinel / Defender for Cloud P2 500mb benefit is the following correct:

Enabled Defender for Cloud P2 on the server or via Azure Arc (these are mainly on-prem servers.

Create a DCR rule to collect events and send to our Sentinel Workspace.

Enable Defender on the Sentinel workspace (not subscription)

Defender for Servers is far more work than it should be!

Reminder: Next Tuesday 6/23 at 9AM PST we will be hosting an 'Ask Microsoft Anything' session on Tech Community for the Sentinel SIEM Migration Experience!

Trevor_Rusher — Thu, 18 Jun 2026 22:25:31 GMT

Join us for a live demo and AMA on the Microsoft Sentinel SIEM migration experience. We’ll show how the experience helps teams move from legacy SIEMs like Splunk and QRadar into Microsoft Sentinel with a more guided, lower-friction path. We’ll cover what it does today, how it works, and the questions customers ask most, then open it up for live Q&A.

Link here: Ask Microsoft Anything: The Microsoft Sentinel SIEM Migration Experience

Hope to see you there!

Reset Data Lake?

DaithiG — Fri, 12 Jun 2026 09:54:30 GMT

Hi,

Is the only want to reset or change the Data Lake to contact Microsoft Support. We've a ticket open for a few days now. The Data Lake was setup as in a test subscription and we really need to delete it/reset it and start again under a proper production subscription.

Thanls

Detecting AI agents and non-human identities in Microsoft Sentinel: the classic-agent blind spot

Marcel_Graewer — Tue, 09 Jun 2026 13:57:23 GMT

Build 2026 made the direction official. The industry is moving from the app era into the agent era, and Microsoft spent a real share of the keynote on securing agents across their lifecycle, from discovering what is exploitable to governing what is running in production. On the identity side the centerpiece is Microsoft Entra Agent ID, now generally available, which gives AI agents first-class identities and extends Conditional Access, Identity Protection, and full audit logging to them.

That is good news for agents you build the new way. It is not the whole picture, and the gap is where most SOCs will get hurt first.

Modern agents are covered. Classic agents are not.

Entra Agent ID draws a hard line between two kinds of agent.

Modern agents are created through the Agent ID platform, each backed by an agent identity blueprint. They carry a proper Agent ID, a full audit trail, and the complete set of governance capabilities, including Identity Protection for Agents, which establishes a baseline for an agent's normal activity and flags anomalies automatically.

Classic agents are everything that came before, or that gets built outside the platform: AI agents implemented as ordinary service principals or app registrations, for example Copilot Studio agents created before Agent ID was enabled, or any home-grown automation calling Graph with client credentials. In the Entra agent registry they appear with "Has Agent ID: No," and that flag matters, because the Agent ID protections apply to identities that actually hold an Agent ID. Classic agents sit outside Identity Protection for Agents and Conditional Access for Agents.

Here is the uncomfortable part. The non-human identities you already run, the service principals behind your pipelines, your integrations, your scripts, your pre-platform Copilot Studio bots, are almost all classic agents. They tend to outnumber your human accounts, they have no MFA in any meaningful sense, and a credential added to one does not show up in the Azure portal. The new platform protections do not reach them. Until you migrate them, the only place you get detection coverage on that population is your SIEM.

So this is the job Sentinel does that Agent ID does not: detect risky behavior on the classic, service-principal-backed agents that the platform cannot yet protect.

The telemetry you have, and the one switch people forget

Three tables carry most of the signal.

AADServicePrincipalSignInLogs records service principal authentications, the client-credentials sign-ins your agents and automation use. No user, no MFA, just an app proving it holds a secret or certificate.

AADManagedIdentitySignInLogs does the same for managed identities.

AuditLogs records directory changes, including the one that matters most for persistence: a new credential added to an application or service principal.

One practical warning before any of this works. Service principal and managed identity sign-in logs are not streamed by default. You have to enable those categories explicitly in the Entra diagnostic settings feeding your workspace. Plenty of teams write the detection, never check, and never notice the table is empty. Verify that first.

Detection 1: a new credential on a service principal or app

Adding a secret or certificate to an existing service principal is one of the cleanest persistence techniques in a Microsoft cloud. The attacker compromises a privileged user or app, drops a fresh credential on a service principal that already holds useful Graph permissions, and now has access that survives password resets and session revocation. It maps to MITRE T1098.001, Account Manipulation: Additional Cloud Credentials. For a classic agent it is especially nasty, because there is no Identity Protection baseline watching it.

// Detection 1: new secret or certificate added to an application or service principal // MITRE T1098.001 - Account Manipulation: Additional Cloud Credentials AuditLogs | where OperationName has_any ("Add service principal", "Certificates and secrets management") | where Result =~ "success" | extend Initiator = coalesce( tostring(InitiatedBy.user.userPrincipalName), tostring(InitiatedBy.app.displayName)) | extend InitiatorIp = tostring(InitiatedBy.user.ipAddress) | mv-apply Target = TargetResources on ( where Target.type =~ "Application" | extend TargetName = tostring(Target.displayName), TargetId = tostring(Target.id), KeyChanges = Target.modifiedProperties ) | mv-apply Prop = KeyChanges on ( where tostring(Prop.displayName) =~ "KeyDescription" | extend NewKeys = parse_json(tostring(Prop.newValue)), OldKeys = parse_json(tostring(Prop.oldValue)) ) | extend AddedKeys = set_difference(NewKeys, OldKeys) | where array_length(AddedKeys) > 0 | project TimeGenerated, Initiator, InitiatorIp, TargetName, TargetId, AddedKeys | order by TimeGenerated desc

The operation filter catches the three shapes this event takes in the log: "Add service principal," "Add service principal credentials," and "Update application - Certificates and secrets management." The modifiedProperties parsing isolates the KeyDescription change, and set_difference confirms a key was actually added rather than removed, so rotating out an old credential does not, on its own, fire the rule.

False positives come from legitimate rotation and from automation that provisions app credentials (CI/CD, infrastructure as code). The initiator is the discriminant. A credential added by your deployment pipeline's service account at the usual time is routine. The same change initiated by an interactive admin out of hours, or by an account that never normally touches app credentials, is what you want to surface. Allow-list the expected initiators, not the targets.

Detection 2: a classic agent signing in from a first-seen IP

A service principal that has only ever authenticated from your Azure regions and suddenly signs in from somewhere new is a strong signal that its credential has been lifted and is being used elsewhere. Service principals have stable, boring network behavior, which makes a first-seen IP a far cleaner indicator for them than it is for roaming human users. This is the behavioral baseline Identity Protection gives you for free on modern agents, rebuilt in KQL for the classic ones it ignores. MITRE T1078.004, Valid Accounts: Cloud Accounts.

// Detection 2: classic-agent service principal signing in from a previously unseen IP // MITRE T1078.004 - Valid Accounts: Cloud Accounts let baseline = 14d; let detection = 1d; let KnownIPs = AADServicePrincipalSignInLogs | where TimeGenerated between (ago(baseline + detection) .. ago(detection)) | where tostring(ResultType) == "0" | summarize KnownIPSet = make_set(IPAddress) by AppId; AADServicePrincipalSignInLogs | where TimeGenerated > ago(detection) | where tostring(ResultType) == "0" | lookup kind=leftouter KnownIPs on AppId | where set_has_element(KnownIPSet, IPAddress) == false | summarize FirstSeen = min(TimeGenerated), Resources = make_set(ResourceDisplayName, 10) by ServicePrincipalName, AppId, IPAddress | order by FirstSeen desc

The query builds a per-application baseline of source IPs over the previous two weeks, then flags any successful sign-in today from an address outside that set. Two tuning notes. Brand-new service principals have no baseline, so they surface on first use. That is usually worth seeing once, but you can exclude AppIds younger than the baseline window if it gets noisy. And if your agents egress through shifting cloud IP ranges, widen the comparison from an exact IP to the autonomous system number or a known-range allow-list, otherwise you will chase your own infrastructure.

This complements Agent ID, it does not replace it!

The endgame is not to run these rules forever. It is to shrink the population they apply to. Inventory your tenant for agents marked "Has Agent ID: No," prioritize the ones holding sensitive Graph permissions, and migrate them onto the Agent ID platform, where Identity Protection and Conditional Access take over the baselining you are doing here by hand. Microsoft has signaled a migration path from classic to modern agents. Treat these two detections as the coverage you need in the meantime, and as a permanent safety net for anything that never makes the move.

If you do one thing this week: enable the service principal sign-in log category, deploy detection 1, and pull a list of every service principal that had a credential added in the last 90 days. That list alone tends to be more interesting than people expect.

Cheers, Marcel

MSSP migration to Unified portal: how are you sequencing your customer portfolio?

AnthonyPorter — Mon, 08 Jun 2026 01:13:15 GMT

Following the automation and SOAR discussion, I wanted to open a conversation specifically focused on the MSSP and multi-tenant side of the migration, because this is where the coordination challenges are an order of magnitude higher than the technical ones.

A few things I am working through before writing this up as Part 5 of the migration series.

On Workspace Manager: Microsoft's own documentation now points you away from Workspace Manager at the point of onboarding to the Defender portal, directing you to Microsoft Defender multitenant management instead. For MSSPs who built their operating model around Workspace Manager, this is a significant structural change. For those implementing now, the recommendation is to go straight to the multitenant portal. I am interested in what the transition has looked like in practice for teams who were mid-flight on Workspace Manager when this became clear.

On access delegation: one of the more honest framings I want to include in the article is around the GDAP plus Unified RBAC gap. A Microsoft employee confirmed in the RSAC 2026 thread that Unified RBAC support for GDAP in the Defender portal is on the roadmap with no firm date. MSSPs choosing between Entra B2B and the governance relationships model today are making an architectural call that is difficult to reverse. I want to present this accurately, and real experience from practitioners will sharpen that framing.

On the connector deployment constraint: you cannot deploy connectors from a managed workspace configured with Azure Lighthouse alone, you also need GDAP. This makes a layered delegation architecture, Lighthouse plus GDAP plus B2B or governance relationships, necessary rather than optional. I am curious whether MSSPs are already running this layered model or whether most are still trying to make Lighthouse work as a single mechanism.

On migration sequencing: the question I want to ask specifically is how teams are structuring their customer portfolio migration. Are you running waves based on customer complexity, based on contract renewal timing, based on customer risk appetite, or some other factor? And when something goes wrong in one tenant's migration, how are you containing the impact on the rest of the programme?

Sharing the full article once it is written. Happy to discuss anything above in more detail in the thread.

SentinelHealth: Scheduled Rule Retry Logging Does Not Match Docs

SomeZnimav — Wed, 03 Jun 2026 09:41:53 GMT

## Objective

I am working on a health checks architecture for Microsoft Sentinel analytic rules. The goal is to build a set of monitoring queries/approaches that cover rule execution failures, configuration issues (entity mapping, partial success), rule audit tracking, and auto-disabled rule detection.

## My Current Approach

So far I have built monitoring for the following areas using the SentinelHealth and SentinelAudit tables:

- Scheduled rule window failures (retry exhaustion)

- NRT rule execution delays (cumulative delay over 25 minutes)

- Partial success and configuration issues (entity mapping drops, alert size limits, semantic errors) with transient error codes filtered out

- Auto-disabled rules detection

- Rule disable/delete audit tracking via SentinelAudit + AzActivity

## The Issue: Scheduled Rule Retry Logging

The documentation at https://learn.microsoft.com/en-us/azure/sentinel/monitor-analytics-rule-integrity#scheduled-rules states that when a scheduled rule fails, it is retried 5 more times on the same window (6 total attempts). It also provides this query to detect completely skipped windows:

```kql

_SentinelHealth()

| where SentinelResourceType == @"Analytics Rule"

| where SentinelResourceKind == "Scheduled"

| where Status != "Success"

| extend startTime = tostring(ExtendedProperties["QueryStartTimeUTC"])

| summarize failuresByStartTime = count() by startTime, SentinelResourceId

| where failuresByStartTime == 6

| summarize count() by SentinelResourceId

```

This query assumes that each retry attempt is logged as a separate event in SentinelHealth, all sharing the same QueryStartTimeUTC. You would then count 6 failure records per startTime to identify a fully skipped window.

However, in practice I am seeing different behavior. I ran a diagnostic query with a 90-day lookback (480 non-success events total, 73 unique rules). Every single event had a count of 1 per unique (SentinelResourceName, startTime) combination. No grouping of retries was observed at all.

I then found an actual failed-window event that confirms this. Here is the record:

- Rule: Port scan detected (ASIM Network Session schema)

- Status: Failure

- Description: "Rule's scheduled run at 06/01/2026 10:43:55 failed after numerous attempts. It will be re-executed over the next scheduled time."

- Issue Code: SemanticErrorInQuery

- Only 1 SentinelHealth record exists for this failed window

The Description field says "failed after numerous attempts" which indicates the retries happened internally, but only one consolidated Failure event was written to SentinelHealth after all retries were exhausted. The individual retry attempts do not appear as separate records.

This means the failuresByStartTime == 6 query from the documentation would never match this pattern, because there is only 1 record per failed window, not 6.

## Why This Matters

Yes, completely skipped windows are rare. In my 90-day dataset most failures were permanent types (SemanticErrorInQuery, QueryGeneralError) that would not benefit from retries anyway. But they still happen, and if a tenant experiences a transient issue that causes a higher rate of failed windows, the documented query would silently return nothing.

For my health checks I have rewritten the detection to simply look for Status == "Failure" with Description containing "failed after numerous attempts" which matches the actual consolidated event Sentinel writes.

## Questions

Is the documented failuresByStartTime == 6 query still accurate? Or has the retry logging behavior changed to write a single consolidated event per failed window?
Are there specific failure types or conditions where individual retries are logged as separate events? Perhaps transient failures behave differently from permanent ones in this regard?
For anyone else building health monitoring on SentinelHealth - am I missing any important use cases beyond what I described above?

Any clarification would be appreciated.

Sentinel SOAR migration to Unified portal: what broke? anyone evaluated the AI playbook generator?

AnthonyPorter — Thu, 14 May 2026 23:42:29 GMT

I want to open a conversation specifically focused on the automation and SOAR side of the migration, because this is the area where problems most commonly surface after onboarding rather than during it.

A quick orientation: the Unified portal introduces a specific constraint that catches teams by surprise. Alert-triggered automation for alerts created by Microsoft Defender XDR is not available in the Defender portal. The main use case for alert-triggered automation in this context is responding to alerts from analytics rules where incident creation is disabled. If you had alert-triggered playbooks firing on Defender XDR signals, those need to be re-evaluated against the incident trigger model. This is documented by Microsoft, but it is easy to miss in the volume of migration guidance.

The automation failure mode I have seen most consistently: automation rules built around incident title conditions. The Defender XDR correlation engine assigns its own incident names, so any condition keyed to "if incident title contains X" stops matching without throwing an error. The rule is still active, the automation is still enabled, and everything looks fine until someone notices a class of enrichment or response has gone quiet. Microsoft's recommendation is to use Analytic rule name as the condition instead.

There is also a firm near-term deadline separate from the March 2027 portal retirement: queries and automation need to be updated by July 1, 2026 for standardised account entity naming. The Name field will consistently hold only the UPN prefix from that date. Any automation comparing AccountName against a full UPN will break.

A few specific questions for practitioners:

When you onboarded or reviewed your automation post-onboarding, what broke silently versus what produced a visible error? Silent failures are the dangerous ones and sharing specific patterns would be genuinely useful for the community.
Has anyone evaluated the new AI playbook generator in the Defender portal? It requires Security Copilot with SCUs available and generates Python-based automation coauthored with Cline in an embedded VS Code environment. Interested in real-world comparisons against existing Logic Apps workflows for the same use case.
For those who have migrated alert-triggered playbooks to automation rule invocation: did you find edge cases in the migration, particularly around playbooks used by multiple analytics rules simultaneously?

Writing this up as Part 4 of the migration series. Sharing the article link once it is live for anyone who wants the full detail.

XdrLogRaider Defender XDR portal telemetry

alkefallonitis — Fri, 08 May 2026 08:45:47 GMT

A Microsoft Sentinel custom data connector that ingests Microsoft Defender XDR portal-only telemetry — configuration, compliance, drift, exposure, governance — that public Microsoft APIs (Graph Security, Microsoft 365 Defender, MDE) don't expose.

https://github.com/akefallonitis/xdrlograider— Defender XDR portal telemetry

Happy Hunting 🥳 🎉

Sentinel Foundry - MCP Server (Preview) (Github Community Release)

veesamprabhukiran — Tue, 05 May 2026 18:05:13 GMT

I’ve been cooking something that a lot of people in SOC have been struggling with — especially on the engineering side of Microsoft Sentinel. Thanks to the Microsoft Security team for shaping the capabilities of Sentinel even better with Sentinel Data Lake & Modern SecOps.

Today’s the day I can finally share it.

Note: This is not an official Microsoft product, but it is designed to make the Sentinel Build even better (complement) with much more intelligence.

🚀 Sentinel Foundry is now in public preview with 43 tools. (Sentinel Foundry - MCP Server)
It’s an MCP server built to act like the brain of a strong Sentinel engineer — helping make building, improving, and operating Sentinel far more practical, faster, and honestly more enjoyable.

For a lot of teams, the challenge is not understanding what Sentinel can do. The hard part is the engineering work around it:
-> Deciding what data should actually be ingested
-> Building a clean, scalable Sentinel foundation
-> Writing useful detections instead of noisy ones
-> Balancing security value with cost
-> Turning ideas into deployable engineering outputs

That is exactly why I built Sentinel Foundry to help communities grow stronger.

It helps with the real engineering tasks behind Sentinel — from architecture thinking to detection design, deployment planning, ingestion strategy, automation ideas, and many of the workflows outlined in the GitHub project.

How does it work?

Here’s one of the flagship prompts I ran with it:

“Give me a complete security posture report for our workspace. Score each pillar and tell me what to prioritise.”

And within seconds, it produced a structured engineering blueprint that would normally take a lot longer to pull together manually.

You can see the example prompts here in what it can do: https://github.com/prabhukiranveesam/Sentinel-Foundry#what-can-it-do

I want building Sentinel to feel less like repetitive engineering overhead — and more like real security engineering that is fast, creative, and enjoyable.

If you work with Sentinel as a SOC L2 analyst, engineer, detection engineer, consultant, or architect, I’d genuinely love for you to try it and tell me what you think.

🔗 Public Preview: https://github.com/prabhukiranveesam/Sentinel-Foundry

This is just the start of an AI era — and I’m excited to keep shaping it with more powerful features over the coming days.

This is very easy to set up and will be available to all of you at no cost during this month as part of the public preview, and your feedback is extremely valuable to shape this as a powerful solution.

Sentinel RBAC in the Unified portal: who has activated Unified RBAC, and how did it go?

AnthonyPorter — Tue, 21 Apr 2026 06:04:28 GMT

Following the RSAC 2026 announcements last month, I have been working through the full permission picture for the Unified portal and wanted to open a discussion here given how much has shifted in a short period.

A quick framing of where things stand. The baseline is still that Azure RBAC carries across for Sentinel SIEM access when you onboard, no changes required. But there are now two significant additions in public preview: Unified RBAC for Sentinel SIEM itself (extending the Defender Unified RBAC model to cover Sentinel directly), and a new Defender-native GDAP model for non-CSP organisations managing delegated access across tenants.

The GDAP piece in particular is worth discussing carefully, because I want to be precise about what has and has not changed. The existing limitation from Microsoft's onboarding documentation, that GDAP with Azure Lighthouse is not supported for Sentinel data in the Defender portal, has not changed. What is new is a separate, Defender-portal-native GDAP mechanism announced at RSAC, which is a different thing. These are not the same capability. If you were using Entra B2B as the interim path based on earlier guidance, that guidance was correct and that path remains the generally available option today.

A few things I would genuinely like to hear from practitioners:

For those who have activated Unified RBAC for a Sentinel workspace in the Defender portal: what did the migration from Azure RBAC roles look like in practice? Did the import function bring roles across cleanly, or did you find gaps particularly around custom roles?
For environments using Playbook Operator, Automation Contributor, or Workbook Contributor role assignments: how are you handling the fact those three roles are not yet in Unified RBAC and still require Azure portal management? Is the dual-management posture creating operational friction?
For MSSPs evaluating the new Defender-native GDAP model against their existing Entra B2B setup: what factors are driving the decision either way at your scale?

Writing this up as Part 3 of the migration series and the community experience here is directly useful for making sure the practitioner angle is grounded.

Stuck looking up a watchlist value

MrD — Wed, 01 Apr 2026 14:25:42 GMT

Hiya,

I get stuck working with watchlists sometimes.

In this example, I'm wanting to focus on account activity from a list of UPNs.

If I split the elements up, I get the individual results, but can't seem to pull it all together.

=====================================================

In its entirety, the query returns zero results:

let ServiceAccounts=(_GetWatchlist('ServiceAccounts_Monitoring'))| project SearchKey;

let OpName = dynamic(['Reset password (self-service)','Reset User Password','Change user password','User reset password','User started password reset','Enable Account','Change password (self-service)','Update PasswordProfile','Self-service password reset flow activity progress']);

AuditLogs

| where OperationName has_any (OpName)

| extend upn = TargetResources.[0].userPrincipalName

| where upn in (ServiceAccounts) //<=This is where I think I'm wrong

| project upn

=====================================================

This line on its own, returns the user on the list:

let ServiceAccounts=(_GetWatchlist('ServiceAccounts_Monitoring'))| project SearchKey;

=====================================================

This section on its own, returns all the activity

AuditLogs

| where OperationName has_any (OpName)

| extend upn = TargetResources.[0].userPrincipalName

| where upn contains "username" //This is the name on the watchlistlist - so I know the activity exists)

====================================================

I'm doing something wrong when I'm trying to use the watchlist cache (I think)

Any help\guidance or wisdom would be greatly appreciated!

Many thanks

Security Copilot Integration with Microsoft Sentinel - Why Automation matters now

Marcel_Graewer — Tue, 31 Mar 2026 13:09:01 GMT

Security Operations Centers face a relentless challenge - the volume of security alerts far exceeds the capacity of human analysts. On average, a mid-sized SOC receives thousands of alerts per day, and analysts spend up to 80% of their time on initial triage. That means determining whether an alert is a true positive, understanding its scope, and deciding on next steps. With Microsoft Security Copilot now deeply integrated into Microsoft Sentinel, there is finally a practical path to automating the most time-consuming parts of this workflow.

So I decided to walk you through how to combine Security Copilot with Sentinel to build an automated incident triage pipeline - complete with KQL queries, automation rule patterns, and practical scenarios drawn from common enterprise deployments.

Traditional triage workflows rely on analysts manually reviewing each incident - reading alert details, correlating entities across data sources, checking threat intelligence, and making a severity assessment. This is slow, inconsistent, and does not scale.

Security Copilot changes this equation by providing:

Natural language incident summarization - turning complex, multi-alert incidents into analyst-readable narratives
Automated entity enrichment - pulling threat intelligence, user risk scores, and device compliance state without manual lookups
Guided response recommendations - suggesting containment and remediation steps based on the incident type and organizational context

The key insight is that Copilot does not replace analysts - it handles the repetitive first-pass triage so analysts can focus on decision-making and complex investigations.

Architecture - How the Pieces Fit Together

The automated triage pipeline consists of four layers:

Detection Layer - Sentinel analytics rules generate incidents from log data
Enrichment Layer - Automation rules trigger Logic Apps that call Security Copilot
Triage Layer - Copilot analyzes the incident, enriches entities, and produces a triage summary
Routing Layer - Based on Copilot's assessment, incidents are routed, re-prioritized, or auto-closed

(Forgive my AI-painted illustration here, but I find it a nice way to display dependencies.)

+-----------------------------------------------------------+ | Microsoft Sentinel | | | | Analytics Rules --> Incidents --> Automation Rules | | | | | v | | Logic App / Playbook | | | | | v | | Security Copilot API | | +-----------------+ | | | Summarize | | | | Enrich Entities | | | | Assess Risk | | | | Recommend Action| | | +--------+--------+ | | | | | v | | +-----------------------------+ | | | Update Incident | | | | - Add triage summary tag | | | | - Adjust severity | | | | - Assign to analyst/team | | | | - Auto-close false positive| | | +-----------------------------+ | +-----------------------------------------------------------+

Step 1 - Identify High-Volume Triage Candidates

Not every incident type benefits equally from automated triage. Start with alert types that are high in volume but often turn out to be false positives or low severity. Use this KQL query to identify your top candidates:

SecurityIncident | where TimeGenerated > ago(30d) | summarize TotalIncidents = count(), AutoClosed = countif(Classification == "FalsePositive" or Classification == "BenignPositive"), AvgTimeToTriageMinutes = avg(datetime_diff('minute', FirstActivityTime, CreatedTime)) by Title | extend FalsePositiveRate = round(AutoClosed * 100.0 / TotalIncidents, 1) | where TotalIncidents > 10 | order by TotalIncidents desc | take 20

This query surfaces the incident types where automation will deliver the highest ROI. Based on publicly available data and community reports, the following categories consistently appear at the top:

Impossible travel alerts (high volume, around 60% false positive rate)
Suspicious sign-in activity from unfamiliar locations
Mass file download and share events
Mailbox forwarding rule creation

Step 2 - Build the Copilot-Powered Triage Playbook

Create a Logic App playbook that triggers on incident creation and leverages the Security Copilot connector. The core flow looks like this:

Trigger: Microsoft Sentinel Incident - When an incident is created

Action 1 - Get incident entities:

let incidentEntities = SecurityIncident | where IncidentNumber == <IncidentNumber> | mv-expand AlertIds | join kind=inner (SecurityAlert | extend AlertId = SystemAlertId) on $left.AlertIds == $right.AlertId | mv-expand Entities | extend EntityData = parse_json(Entities) | project EntityType = tostring(EntityData.Type), EntityValue = coalesce( tostring(EntityData.HostName), tostring(EntityData.Address), tostring(EntityData.Name), tostring(EntityData.DnsDomain) ); incidentEntities

Note: The <IncidentNumber> placeholder above is a Logic App dynamic content variable. When building your playbook, select the incident number from the trigger output rather than hardcoding a value.

Action 2 - Copilot prompt session:

Send a structured prompt to Security Copilot that requests:

Analyze this Microsoft Sentinel incident and provide a triage assessment: Incident Title: {IncidentTitle} Severity: {Severity} Description: {Description} Entities involved: {EntityList} Alert count: {AlertCount} Please provide: 1. A concise summary of what happened (2-3 sentences) 2. Entity risk assessment for each IP, user, and host 3. Whether this appears to be a true positive, benign positive, or false positive 4. Recommended next steps 5. Suggested severity adjustment (if any)

Action 3 - Parse and route:

Use the Copilot response to update the incident. The Logic App parses the structured output and:

Adds the triage summary as an incident comment
Tags the incident with copilot-triaged
Adjusts severity if Copilot recommends it
Routes to the appropriate analyst tier based on the assessment

Step 3 - Enrich with Contextual KQL Lookups

Security Copilot's assessment improves dramatically when you feed it contextual data. Before sending the prompt, enrich the incident with organization-specific signals:

// Check if the user has a history of similar alerts (repeat offender vs. first time) let userAlertHistory = SecurityAlert | where TimeGenerated > ago(90d) | mv-expand Entities | extend EntityData = parse_json(Entities) | where EntityData.Type == "account" | where tostring(EntityData.Name) == "<UserPrincipalName>" | summarize PriorAlertCount = count(), DistinctAlertTypes = dcount(AlertName), LastAlertTime = max(TimeGenerated) | extend IsRepeatOffender = PriorAlertCount > 5; userAlertHistory

// Check user risk level from Entra ID Protection AADUserRiskEvents | where TimeGenerated > ago(7d) | where UserPrincipalName == "<UserPrincipalName>" | summarize arg_max(TimeGenerated, RiskLevel), RecentRiskEvents = count() | project RiskLevel, RecentRiskEvents

Including this context in the Copilot prompt transforms generic assessments into organization-aware triage decisions. A "suspicious sign-in" for a user who travels internationally every week is very different from the same alert for a user who has never left their home country.

Step 4 - Implement Feedback Loops

Automated triage is only as good as its accuracy over time. Build a feedback mechanism by tracking Copilot's assessments against analyst final classifications:

SecurityIncident | where Tags has "copilot-triaged" | where TimeGenerated > ago(30d) | where Classification != "" | mv-expand Comments | extend CopilotAssessment = extract("Assessment: (True Positive|False Positive|Benign Positive)", 1, tostring(Comments)) | where isnotempty(CopilotAssessment) | summarize Total = dcount(IncidentNumber), Correct = dcountif(IncidentNumber, (CopilotAssessment == "False Positive" and Classification == "FalsePositive") or (CopilotAssessment == "True Positive" and Classification == "TruePositive") or (CopilotAssessment == "Benign Positive" and Classification == "BenignPositive") ) by bin(TimeGenerated, 7d) | extend AccuracyPercent = round(Correct * 100.0 / Total, 1) | order by TimeGenerated asc

For this query to work reliably, the automation playbook must write the assessment in a consistent format within the incident comments. Use a structured prefix such as Assessment: True Positive so the regex extraction remains stable.

According to Microsoft's published benchmarks and community feedback, Copilot-assisted triage typically achieves 85-92% agreement with senior analyst classifications after prompt tuning - significantly reducing the manual triage burden.

A Note on Licensing and Compute Units

Security Copilot is licensed through Security Compute Units (SCUs), which are provisioned in Azure. Each prompt session consumes SCUs based on the complexity of the request. For automated triage at scale, plan your SCU capacity carefully - high-volume playbooks can accumulate significant usage. Start with a conservative allocation, monitor consumption through the Security Copilot usage dashboard, and scale up as you validate ROI. Microsoft provides detailed guidance on SCU sizing in the official Security Copilot documentation.

Example Scenario - Impossible Travel at Scale

Consider a typical enterprise that generates over 200 impossible travel alerts per week. The SOC team spends roughly 15 hours weekly just triaging these. Here is how automated triage addresses this:

Detection - Sentinel's built-in impossible travel analytics rule flags the incidents
Enrichment - The playbook pulls each user's typical travel patterns from sign-in logs over the past 90 days, VPN usage, and whether the "impossible" location matches any known corporate office or VPN egress point
Copilot Analysis - Security Copilot receives the enriched context and classifies each incident
Expected Result - Based on common deployment patterns, around 70-75% of impossible travel incidents are auto-closed as benign (VPN, known travel patterns), roughly 20% are downgraded to informational with a triage note, and only about 5% are escalated to analysts as genuine suspicious activity

This type of automation can reclaim over 10 hours per week - time that analysts can redirect to proactive threat hunting.

Getting Started - Practical Recommendations

For teams ready to implement automated triage with Security Copilot and Sentinel, here is a recommended approach:

Start small. Pick one high-volume, high-false-positive incident type. Do not try to automate everything at once.
Run in shadow mode first. Have the playbook add triage comments but do not auto-close or re-route. Let analysts compare Copilot's assessment with their own for two to four weeks.
Tune your prompts. Generic prompts produce generic results. Include organization-specific context - naming conventions, known infrastructure, typical user behavior patterns.
Monitor accuracy continuously. Use the feedback loop KQL above. If accuracy drops below 80%, pause automation and investigate.
Maintain human oversight. Even at 90%+ accuracy, keep a human review step for high-severity incidents. Automation handles volume - analysts handle judgment.

The combination of Security Copilot and Microsoft Sentinel represents a genuine step forward for SOC efficiency. By automating the initial triage pass - summarizing incidents, enriching entities, and providing classification recommendations - analysts are freed to focus on what humans do best: making nuanced security decisions under uncertainty.

Feel free to like or/and connect :)

Webinar Cancellation

emilyfalla — Mon, 30 Mar 2026 21:40:40 GMT

Hi everyone!

The webinar originally scheduled for April 14th on "Using distributed content to manage your multi-tenant SecOps" has unfortunately been cancelled for now. We apologize for the inconvenience and hope to reschedule it in the future.

Please find other available webinars at: http://aka.ms/securitycommunity

All the best,

The Microsoft Security Community Team

Your Sentinel AMA Logs & Queries Are Public by Default — AMPLS Architectures to Fix That

veesamprabhukiran — Wed, 25 Mar 2026 23:19:39 GMT

When you deploy Microsoft Sentinel, security log ingestion travels over public Azure Data Collection Endpoints by default. The connection is encrypted, and the data arrives correctly — but the endpoint is publicly reachable, and so is the workspace itself, queryable from any browser on any network.

For many organisations, that trade-off is fine. For others — regulated industries, healthcare, financial services, critical infrastructure — it is the exact problem they need to solve.

Azure Monitor Private Link Scope (AMPLS) is how you solve it.

What AMPLS Actually Does

AMPLS is a single Azure resource that wraps your monitoring pipeline and controls two settings:

Where logs are allowed to go (ingestion mode: Open or PrivateOnly)
Where analysts are allowed to query from (query mode: Open or PrivateOnly)

Change those two settings and you fundamentally change the security posture — not as a policy recommendation, but as a hard platform enforcement. Set ingestion to PrivateOnly and the public endpoint stops working. It does not fall back gracefully. It returns an error. That is the point.

It is not a firewall rule someone can bypass or a policy someone can override. Control is baked in at the infrastructure level.

Three Patterns — One Spectrum

There is no universally correct answer. The right architecture depends on your organisation's risk appetite, existing network infrastructure, and how much operational complexity your team can realistically manage. These three patterns cover the full range:

Architecture 1 — Open / Public (Basic)
No AMPLS. Logs travel to public Data Collection Endpoints over the internet. The workspace is open to queries from anywhere. This is the default — operational in minutes with zero network setup.
Cloud service connectors (Microsoft 365, Defender, third-party) work immediately because they are server-side/API/Graph pulls and are unaffected by AMPLS. Azure Monitor Agents and Azure Arc agents handle ingestion from cloud or on-prem machines via public network.

Simplicity: 9/10 | Security: 6/10
Good for: Dev environments, teams getting started, low-sensitivity workloads

Architecture 2 — Hybrid: Private Ingestion, Open Queries (Recommended for most)
AMPLS is in place. Ingestion is locked to PrivateOnly — logs from virtual machines travel through a Private Endpoint inside your own network, never touching a public route. On-premises or hybrid machines connect through Azure Arc over VPN or a dedicated circuit and feed into the same private pipeline.
Query access stays open, so analysts can work from anywhere without needing a VPN/Jumpbox to reach the Sentinel portal — the investigation workflow stays flexible, but the log ingestion path is fully ring-fenced. You can also split ingestion mode per DCE if you need some sources public and some private.
This is the architecture most organisations land on as their steady state.

Simplicity: 6/10 | Security: 8/10
Good for: Organisations with mixed cloud and on-premises estates that need private ingestion without restricting analyst access

Architecture 3 — Fully Private (Maximum Control)
Infrastructure is essentially identical to Architecture 2 — AMPLS, Private Endpoints, Private DNS zones, VPN or dedicated circuit, Azure Arc for on-premises machines. The single difference: query mode is also set to PrivateOnly.
Analysts can only reach Sentinel from inside the private network. VPN or Jumpbox required to access the portal. Both the pipe that carries logs in and the channel analysts use to read them are fully contained within the defined boundary.
This is the right choice when your organisation needs to demonstrate — not just claim — that security data never moves outside a defined network perimeter.

Simplicity: 2/10 | Security: 10/10
Good for: Organisations with strict data boundary requirements (regulated industries, audit, compliance mandates)

Quick Reference — Which Pattern Fits?

Scenario	Architecture
Getting started / low-sensitivity workloads	Arch 1 — No network setup, public endpoints accepted
Private log ingestion, analysts work anywhere	Arch 2 — AMPLS PrivateOnly ingestion, query mode open
Both ingestion and queries must be fully private	Arch 3 — Same as Arch 2 + query mode set to PrivateOnly

One thing all three share: Microsoft 365, Entra ID, and Defender connectors work in every pattern — they are server-side pulls by Sentinel and are not affected by your network posture.

Please feel free to reach out if you have any questions regarding the information provided.

Sentinel datalake: private link/private endpoint

munterweger — Mon, 23 Mar 2026 11:40:25 GMT

Has anyone already configured Sentinel Datalake with a private link/private endpoint setup? I can't find any instructions for this specific case.

Can I use the wizard in the Defender XDR portal, or does it require specific configuration steps?

Or does it require configuring a private link/private endpoint setup on the Datalake component after activation via the wizard?

RSAC 2026: What the Sentinel Playbook Generator actually means for SOC automation

Marcel_Graewer — Sun, 22 Mar 2026 12:22:31 GMT

RSAC 2026 brought a wave of Sentinel announcements, but the one I keep coming back to is the playbook generator. Not because it's the flashiest, but because it touches something that's been a real operational pain point for years: the gap between what SOC teams need to automate and what they can realistically build and maintain.

I want to unpack what this actually changes from an operational perspective, because I think the implications go further than "you can now vibe-code a playbook."

The problem it solves

If you've built and maintained Logic Apps playbooks in Sentinel at any scale, you know the friction. You need a connector for every integration. If there isn't one, you're writing custom HTTP actions with authentication handling, pagination, error handling - all inside a visual designer that wasn't built for complex branching logic. Debugging is painful. Version control is an afterthought. And when something breaks at 2am, the person on call needs to understand both the Logic Apps runtime AND the security workflow to fix it.

The result in most environments I've seen: teams build a handful of playbooks for the obvious use cases (isolate host, disable account, post to Teams) and then stop. The long tail of automation - the enrichment workflows, the cross-tool correlation, the conditional response chains - stays manual because building it is too expensive relative to the time saved.

What's actually different now

The playbook generator produces Python. Not Logic Apps JSON, not ARM templates - actual Python code with documentation and a visual flowchart. You describe the workflow in natural language, the system proposes a plan, asks clarifying questions, and then generates the code once you approve.

The Integration Profile concept is where this gets interesting. Instead of relying on predefined connectors, you define a base URL, auth method, and credentials for any service - and the generator creates dynamic API calls against it. This means you can automate against ServiceNow, Jira, Slack, your internal CMDB, or any REST API without waiting for Microsoft or a partner to ship a connector.

The embedded VS Code experience with plan mode and act mode is a deliberate design choice. Plan mode lets you iterate on the workflow before any code is generated. Act mode produces the implementation. You can then validate against real alerts and refine through conversation or direct code edits. This is a meaningful improvement over the "deploy and pray" cycle most of us have with Logic Apps.

Where I see the real impact

For environments running Sentinel at scale, the playbook generator could unlock the automation long tail I mentioned above. The workflows that were never worth the Logic Apps development effort might now be worth a 15-minute conversation with the generator. Think: enrichment chains that pull context from three different tools before deciding on a response path, or conditional escalation workflows that factor in asset criticality, time of day, and analyst availability.

There's also an interesting angle for teams that operate across Microsoft and non-Microsoft tooling. If your SOC uses Sentinel for SIEM but has Palo Alto, CrowdStrike, or other vendors in the stack, the Integration Profile approach means you can build cross-vendor response playbooks without middleware.

The questions I'd genuinely like to hear about

A few things that aren't clear from the documentation and that I think matter for production use:

Security Copilot dependency: The prerequisites require a Security Copilot workspace with EU or US capacity. Someone in the blog comments already flagged this as a potential blocker for organizations that have Sentinel but not Security Copilot. Is this a hard requirement going forward, or will there be a path for Sentinel-only customers?
Code lifecycle management: The generated Python runs... where exactly? What's the execution runtime? How do you version control, test, and promote these playbooks across dev/staging/prod? Logic Apps had ARM templates and CI/CD patterns. What's the equivalent here?
Integration Profile security: You're storing credentials for potentially every tool in your security stack inside these profiles. What's the credential storage model? Is this backed by Key Vault? How do you rotate credentials without breaking running playbooks?
Debugging in production: When a generated playbook fails at 2am, what does the troubleshooting experience look like? Do you get structured logs, execution traces, retry telemetry? Or are you reading Python stack traces?
Coexistence with Logic Apps: Most environments won't rip and replace overnight. What's the intended coexistence model between generated Python playbooks and existing Logic Apps automation rules?

I'm genuinely optimistic about this direction. Moving from a low-code visual designer to an AI-assisted coding model with transparent, editable output feels like the right architectural bet for where SOC automation needs to go. But the operational details around lifecycle, security, and debugging will determine whether this becomes a production staple or stays a demo-only feature.

Would be interested to hear from anyone who's been in the preview - what's the reality like compared to the pitch?

Ingest Microsoft XDR Advanced Hunting Data into Microsoft Sentinel

muraly005 — Wed, 18 Mar 2026 23:38:49 GMT

I had difficulty finding a guide that can query Microsoft Defender vulnerability management Advanced Hunting tables in Microsoft Sentinel for alerting and automation. As a result, I put together this guide to demonstrate how to ingest Microsoft XDR Advanced Hunting query results into Microsoft Sentinel using Azure Logic Apps and System‑Assigned Managed Identity.

The solution allows you to:

Run Advanced Hunting queries on a schedule
Collect high‑risk vulnerability data (or other hunting results)
Send the results to a Sentinel workspace as custom logs
Create alerts and automation rules based on this data

This approach avoids credential storage and follows least privilege and managed identity best practices.

Prerequisites

Before you begin, ensure you have:

Microsoft Defender XDR access
Microsoft Sentinel deployed
Azure Logic Apps permission
Application Administrator or higher in Microsoft Entra ID
PowerShell with Az modules installed
Contributor access to the Sentinel workspace

Architecture at a Glance

Logic App (Managed Identity)

↓

Microsoft XDR Advanced Hunting API

↓

Logic App

↓

Log Analytics Data Collector API

↓

Microsoft Sentinel (Custom Log)

Step 1: Create a Logic App

In the Azure Portal, go to Logic Apps
Create a new Consumption Logic App
Choose the appropriate:

Subscription
Resource Group
Region

Step 2: Enable System‑Assigned Managed Identity

Open the Logic App
Navigate to Settings → Identity
Enable System‑assigned managed identity
Click Save
Note the Object ID

This identity will later be granted permission to run Advanced Hunting queries.

Step 3: Locate the Logic App in Entra ID

Go to Microsoft Entra ID → Enterprise Applications
Change filter to All Applications

Search for your Logic App name
Select the app to confirm it exists

Step 4: Grant Advanced Hunting Permissions (PowerShell)

Advanced Hunting permissions cannot be assigned via the portal and must be done using PowerShell.

Required Permission

AdvancedQuery.Read.All

PowerShell Script

# Your tenant ID (in the Azure portal, under Azure Active Directory > Overview). $TenantID=”Your TenantID” Connect-AzAccount -TenantId $TenantID # Get the ID of the managed identity for the app. $spID = “Your Managed Identity” # Get the service principal for Microsoft Graph by providing the AppID of WindowsDefender ATP $GraphServicePrincipal = Get-AzADServicePrincipal -Filter "AppId eq 'fc780465-2017-40d4-a0c5-307022471b92'" | Select-Object Id # Extract the Advanced query ID. $AppRole = $GraphServicePrincipal.AppRole | ` Where-Object {$_.Value -contains "AdvancedQuery.Read.All"} # If AppRoleID comes up with blank value, it can be replaced with 93489bf5-0fbc-4f2d-b901-33f2fe08ff05 # Now add the permission to the app to read the advanced queries New-AzADServicePrincipalAppRoleAssignment -ServicePrincipalId $spID -ResourceId $GraphServicePrincipal.Id -AppRoleId $AppRole.Id # Or New-AzADServicePrincipalAppRoleAssignment -ServicePrincipalId $spID -ResourceId $GraphServicePrincipal.Id -AppRoleId 93489bf5-0fbc-4f2d-b901-33f2fe08ff05

After successful execution, verify the permission under Enterprise Applications → Permissions.

Step 5: Build the Logic App Workflow

Open Logic App Designer and create the following flow:

Trigger

Recurrence (e.g., every 24 hours

Run Advanced Hunting Query

Connector: Microsoft Defender ATP
Authentication: System‑Assigned Managed Identity
Action: Run Advanced Hunting Query

Sample KQL Query (High‑Risk Vulnerabilities)

Send Data to Log Analytics (Sentinel)

On Send Data, create a new connection and provide the workspace information where the Sentinel log exists. Obtaining the Workspace Key is not straightforward, we need to retrieve using the PowerShell command.

Get-AzOperationalInsightsWorkspaceSharedKey ` -ResourceGroupName "<ResourceGroupName>" ` -Name "<WorkspaceName>"

Configuration Details

Workspace ID
Primary key
Log Type (example): XDRVulnerability_CL
Request body: Results array from Advanced Hunting

Step 6: Run the Logic app to return results

In the logic app designer select run,

If the run is successful data will be sent to sentinel workspace.

Step 7: Validate Data in Microsoft Sentinel

In Sentinel, run the query:

XDRVulnerability_CL | where TimeGenerated > ago(24h)

If data appears, ingestion is successful.

Step 8: Create Alerts & Automation Rules

Use Sentinel to:

Create analytics rules for:

CVSS > 9
Exploit available
New vulnerabilities in last 24 hours

Trigger:

Email notifications
Incident creation
SOAR playbooks

Conclusion

By combining Logic Apps, Managed Identities, Microsoft XDR, and Microsoft Sentinel, you can create a powerful, secure, and scalable pipeline for ingesting hunting intelligence and triggering proactive detections.