Microsoft is auto-closing your alerts.
Built-in tuning went live Feb 5. Plus: Azure's worst outage in months.
As of Thursday, Microsoft is auto-suppressing your MDO alerts in Defender XDR. If you didn’t opt out before February 5, built-in tuning rules are already active in your environment. Microsoft chose which alerts to close, not you. Meanwhile, a single config change to a storage account cascaded into the biggest Azure outage in months, taking down VMs, pipelines, Managed Identity, and yes, the Defender XDR portal itself.
Every Monday from Adversary Lab: Azure security news for practitioners. No fluff, just the updates to stay ahead.
In This Issue
Microsoft started auto-closing your MDO alerts on Thursday. The opt-out window is already gone.
If your CI/CD pipelines or AKS nodes broke Sunday night, here’s the full cascade
Your AV exclusions might silently stop applying if you use MDE Security Settings Management
A new identity hunting table just went GA, and it’s not the one you think
Punycode phishing detection queries you can deploy to Sentinel today
Early signal: lake-only ingestion for hunting tables could cut your Sentinel costs
🔥 Azure Managed Identity Outage: February 2–3, 2026
A single config change cascaded through half of Azure’s infrastructure Sunday night. Here’s the chain of events, and why your security team should care about the blast radius.
How it started:
At 19:46 UTC on February 2, a configuration change to Microsoft-managed storage accounts blocked public access to VM extension packages. VM Agent couldn’t retrieve the artifacts it needed, and VM provisioning, scaling, and extension installations started failing across Azure.
That was bad enough. But the fix made it worse.
The mitigation effort overloaded the Managed Identity platform in East US and West US starting around 00:10 UTC on February 3. Once token acquisition broke, everything downstream broke with it:
Storage config change → VM extension failures → Managed Identity platform collapse → token acquisition failures across:
Azure Synapse
Azure Databricks
Stream Analytics
AKS (again, from a different angle)
Copilot Studio
Container Apps
AI Video Indexer
Azure DevOps and GitHub Actions (all regions, all runner types)
GitHub features: Copilot Coding Agent, Code Review, CodeQL, Dependabot, Enterprise Importer, Pages
Arc-enabled servers, PostgreSQL
Full mitigation came at 06:05 UTC on February 3. Roughly 10 hours from start to finish.
The part Microsoft won’t highlight: The Defender XDR portal went down too. DownDetector showed a spike at 4:04 PM ET on February 2. Your security team lost portal access during an active infrastructure incident, exactly when you need visibility the most.
What Microsoft is doing about it: A preliminary PIR is published. They’re rolling out a cache refresh concurrency optimization (estimated completion this month), and a final PIR is expected within 14 days.
The bigger takeaway: Managed Identity is a single point of failure for a staggering number of Azure services. One overloaded token endpoint created a blast radius spanning compute, data, DevOps, security, and AI services simultaneously. Worth stress-testing that dependency in your resilience plans.
Sources: Azure Status History | Tracking IDs: FNJ8-VQZ (VMs), M5B-9RZ (Managed Identity)
Defender XDR Built-In Alert Tuning Rules: Live February 5
Microsoft Defender XDR | February 5 | GA (MDO rules) / Preview (framework)
Your MDO alert volume probably dropped this week. Not because it was quiet. Because Microsoft started deciding which alerts you see.
Built-in alert tuning rules went live in Defender XDR on February 5 (MC1222979), auto-suppressing informational and low-severity MDO alerts. The opt-out window ran January 25 through February 5, so unless you caught the MC post and acted, these are already running in your environment.
What’s being suppressed: Between 12 and 18 rules (the MC post and SOC Automators blog disagree on the count), all targeting informational and low-severity MDO alerts. The full list from MC1222979 includes:
User-reported spam/junk/malware/phish notifications
Quarantine release requests
Tenant Allow/Block List expiration and removal alerts
ZAP alerts: emails removed after delivery due to malicious files, URLs, or campaigns
Admin submission results and admin-triggered investigation alerts
That last group matters more than the first. ZAP removals and admin investigation alerts are operationally significant. If your SOC tracks post-delivery remediation, verify those specific rules aren’t suppressing alerts you actually triage.
How it works: Suppressed alerts don’t just vanish. AIR still runs in the background, and if an investigation turns up something suspicious, the alert reopens as “New” and lands back in your queue. There’s a safety net. It’s just Microsoft’s safety net, running Microsoft’s logic.
Scope and limitations: Only MDO at launch. Defender for Endpoint, Defender for Identity, Cloud Apps, Entra ID Protection alerts are unaffected. Your existing custom suppression rules still work independently alongside these. And these are Microsoft’s opinionated defaults, not a replacement for tuning that reflects your environment.
The honest take: For SOCs drowning in low-severity MDO noise, this helps. User-reported spam flooding your queue is exactly the kind of alert that should be auto-triaged. But there’s a real difference between “we chose to suppress these” and “Microsoft chose to suppress these for us.” Mature SOCs will want to review every rule individually before accepting the defaults.
What’s next: Microsoft confirmed plans to expand built-in tuning to other Defender XDR workloads. They’ve committed to advance notification and another opt-out window before new rule sets activate. More are coming.
Requirements: Defender for Office 365 Plan 1 or Plan 2, Security Administrator role
Check your settings: Settings → Microsoft Defender XDR → Alert tuning (or directly: https://security.microsoft.com/securitysettings/defender/alert_suppression). Review every built-in rule. Disable anything you want to keep seeing. You can still opt out rule-by-rule even though the bulk window has closed. Running multi-tenant? The MTO portal supports pushing these settings across all managed tenants.
Sources: MC1222979 | Microsoft Learn: Alert investigation | Microsoft Learn: Alert policies
MDE Antivirus Exclusion Storage Change (MC1227621)
Microsoft Defender for Endpoint | February 2026 | Change
Microsoft is changing how Defender Antivirus exclusions are stored when you manage them through the Defender portal instead of Intune. Worth paying attention to, even though the details are thin.
MC1227621 announced the change for devices using MDE Security Settings Management, the scenario where devices are managed directly through the Defender portal via the MDE-Management tag without full Intune enrollment.
Here’s what we know and what we don’t:
We can confirm the MC post exists and references exclusion storage changes for MDE-managed devices. The current behavior stores and delivers exclusions through the MDE client channel, and MDE Security Settings Management is the delivery mechanism in scope.
What we can’t confirm yet: the exact nature of the storage change, the rollout timeline, or whether existing exclusion policies will migrate automatically or need to be recreated. Full MC post details aren’t publicly indexed, and detailed documentation hasn’t landed.
Why this matters anyway: AV exclusion management is already one of the most confusing areas in the Microsoft security stack. GPO, Intune, MDE SSM, local policies, each with different scoping, different merge behavior, different failure modes. Another variable in an already fragile chain. The risk: exclusions silently stop applying, and you don’t notice until something breaks in production or a false positive blocks a critical process.
Keep an eye on this one. Watch MC1227621 in your Message Center. After rollout, verify your exclusion policies are still applying to MDE-managed devices at Endpoints → Configuration management → Endpoint security policies.
Sources: MC1227621 (Message Center) | Microsoft Learn: MDE Security Settings Management
IdentityAccountInfo Table Now GA in Advanced Hunting
Microsoft Defender XDR | February 2026 | GA
There’s a new identity table in advanced hunting, and it’s not the IdentityInfo table you already know.
IdentityAccountInfo just went generally available. It’s focused on account-level metadata from Microsoft Entra ID with identity ownership mapping, basically the layer that links accounts to the identities that own them. Shared accounts, service accounts, mapping activity back to a specific person: that’s where this table earns its keep.
Important distinctions: IdentityInfo isn’t going anywhere. The two tables serve different purposes: IdentityInfo covers user accounts across services, while IdentityAccountInfo is specifically account metadata with ownership links. IdentityAccountInfo requires Defender for Identity deployed in your Defender XDR environment, and won’t include on-prem AD data unless you have MDI sensors on your domain controllers.
Where this gets interesting: Join IdentityAccountInfo with IdentityLogonEvents or IdentityDirectoryEvents. The ownership mapping lets you correlate account-level activity with the identity behind it, which is exactly what you need when investigating compromised accounts or tracking lateral movement across multiple accounts.
Also shipping this month (identity-related): BehaviorInfo and BehaviorEntities tables now include additional UEBA data columns (Preview). A new UEBA behaviors layer transforms raw logs into behavioral insights in near-real time (Preview). Microsoft Entra Agent IDs are now supported for dedicated agent identities (Preview). Identity hunting in Defender XDR is getting a lot of attention right now.
Requirements: Microsoft Defender for Identity deployed in Defender XDR
Try it out: Open advanced hunting in the Defender portal and explore the IdentityAccountInfo schema. Start with a simple query to see what data populates, then build joins with your existing identity hunting workflows.
Sources: Microsoft Learn: IdentityAccountInfo | Defender XDR What’s New | Tech Community: Monthly News February 2026
Punycode Lookalike Domain Hunting Queries: New in Sentinel
Microsoft Sentinel | February 2026 | Community Contribution
New hunting queries just dropped in the Azure-Sentinel GitHub repo for detecting phishing via punycode lookalike domains. Actually useful ones.
The queries target Defender for Office 365 and Microsoft Teams data, hunting for emails and messages containing domains that use punycode characters to mimic legitimate ones. An attacker registers a domain using Cyrillic “а” (visually identical to Latin “a”) or similar homoglyphs, creating domains that pass visual inspection. Your users won’t spot the difference. These queries will.
Worth knowing: These are hunting queries, not prevention rules. They won’t block punycode domains at the gateway. Safe Links and your anti-phishing policies still handle that. Coverage is punycode specifically, not all homoglyph variants.
Why this is worth your time: Import them into your Sentinel workspace, run against the last 30 days of data, and see if anyone in your environment has been targeted. Hits? Convert to a scheduled analytic rule or NRT detection. No hits? You’ve still got a query ready for the next campaign.
Grab them here: Azure-Sentinel GitHub repo, under Hunting Queries → Email and Collaboration Queries → Phish. Review the logic, adapt the domain lists for your environment, and deploy.
👀 On Our Radar: DCR Support and Lake-Only Ingestion for Hunting Tables
We’re flagging this as an early signal, not a confirmed announcement.
A commit in the MicrosoftDocs/defender-docs GitHub repo this week updated the advanced hunting schema tables documentation with references to Data Collection Rules (DCR) support and a “lake-only” ingestion option. Substantial change: 66 lines added, 65 removed across the schema reference, suggesting updates across multiple hunting tables.
If this is what it looks like, it’s significant. DCR support would let you route hunting data to a Log Analytics workspace with more flexibility in how data flows. Lake-only ingestion would let you ingest data into the Sentinel data lake tier without paying full analytics-tier costs, a potential game-changer for teams that want long-term retention of Defender XDR data without the analytics-tier bill.
What we can’t confirm: No corresponding MC post, no public docs page, no announcement beyond the GitHub commit. Could be documentation prep for an upcoming announcement, or it could be landing quietly.
No action required yet. We’ll cover this in detail when documentation confirms. But if long-term retention costs for Defender XDR hunting data are on your radar, watch this space.
📋 What You Should Actually Do This Week
⚠️ HIGH PRIORITY (This Week):
Review built-in alert tuning rules. They went live Feb 5. Head to Settings → Microsoft Defender XDR → Alert tuning and verify nothing you care about is being auto-suppressed. You can still disable individual rules even though the bulk opt-out window has closed. Five-minute check with real consequences if you skip it.
Verify AV exclusions if using MDE Security Settings Management. MC1227621 announced changes to exclusion storage for MDE-managed devices. Confirm your exclusion policies are still applying correctly at Endpoints → Configuration management → Endpoint security policies.
📋 MEDIUM PRIORITY (Before Month-End):
Explore the IdentityAccountInfo table. Now GA in advanced hunting. Open the schema in the Defender portal, test a join with IdentityLogonEvents, and see identity ownership mapping in action.
Import punycode hunting queries from the Sentinel GitHub repo. Deploy to your workspace, run against the last 30 days. Hits warrant conversion to a scheduled analytic rule.
📎 LOW PRIORITY (Nice to Have):
Watch for DCR/lake-only ingestion documentation. Nothing to act on yet, but monitor the Defender XDR What’s New page. Could be a meaningful cost optimization if it confirms.
Looking Ahead
February 11. Patch Tuesday. Expect the usual CVE dump. We’ll cover security-relevant patches next week.
March 31, 2027. Microsoft Sentinel in the Azure portal retirement date (updated from July 2026). Start planning your move to the Defender portal if you haven’t already.
July 14, 2026. InfoPath 2013 / Forms Services end of life
💡 Get Hired as a Detection Engineer.
Picture the interview. They ask what you’ve built.
You pull up 11 detections you wrote yourself. APT29 service principal abuse. Scattered Spider privilege escalation. Silk Typhoon pulling secrets from Key Vault. You walk them through the logic, the telemetry, the edge cases you accounted for.
That’s not a candidate. That’s a hire.
New playbooks and content drop every month. Your portfolio keeps growing and you stay ahead.
$150/month. Founding member pricing. Locks in forever.
📚 About Adversary Lab
Azure security news for practitioners. No fluff, just the updates to stay ahead.
📤 Worth sharing? Forward it.
Charles Garrett | LinkedIn | theadversarylab.com
This is really good man