↑↓ move ↵ open esc close Searches the full text of every issue.

SOC Weekly Brief The week in the Microsoft security stack, distilled

← Home

Week 41 · 17 min read

October 5 – October 12, 2026

Act by

  • 15 Oct 2026 — the SaaS accounts integration between Microsoft Defender for Cloud Apps and Identity inventory stops being opt-in and switches to automatic enablement. Eligible tenants need to do nothing, which is exactly why this is worth reading before the date rather than after: SaaS account data starts flowing into the Identity inventory on its own, and anyone who deliberately left the integration off should decide now whether that decision still stands. The one carve-out is tenants that use the User group admin or App/instance admin roles, which are not in scope for automatic enablement. If you do want it, the useful consequence is that SaaS accounts from connected app connectors show up alongside Active Directory and Entra ID identities in the same inventory, so an investigation that starts on a person no longer stops at the directory boundary. (Microsoft Defender for Cloud Apps release notes)

  • 9 Oct 2027 — the Azure Key Vault Secrets Provider Extension for Azure Arc-enabled Kubernetes clusters retires, announced on 9 October. A year is plenty of time, but the migration target is a different extension rather than a version bump, so this is a change to plan rather than a patch to apply: move to the Azure Key Vault Secret Store extension before the retirement date. The reason to put it on the board now is inventory. Arc-enabled clusters tend to be the ones nobody in the SOC has a complete list of, and a secrets provider that silently stops reconciling is the kind of failure that shows up as an application outage first and a security finding much later. (Azure updates)

What changed

The most consequential thing Microsoft published this week is a warning about your own patch queue. The 6 October post from Microsoft's Deputy CISO for Europe and its Partner Director of Product Security says plainly that AI-assisted vulnerability discovery is already changing the shape of Patch Tuesday for on-premises software, and that September 2026 set a record with close to 1,000 vulnerabilities. Their expectation is that high volumes continue, and the recommendations follow from that. Resource on-premises patching for a sustained increase, not a one-off spike. Rethink patch timing for the systems you have traditionally held back for low-disruption windows, because the gap between a patch shipping and exploitation attempts is narrowing: the post suggests deploying to domain controllers and edge devices within 24 hours rather than waiting for the next maintenance window. Lean harder on defence in depth and continuous monitoring of critical controls, on the explicit grounds that not every vulnerability will be patched in time. Two product notes travel with it. MDASH, the harness layer Microsoft wraps around frontier models to control how they access code and validate what comes back, is now available to customers, and the advice is to start scanning and remediating your own code rather than waiting for model access, budgeting for both tokens and the people who triage what comes out. And Microsoft Baseline Security Mode is recommended for all CISOs as the way to implement and monitor secure configurations at scale, with scenario analyses to assess a control before rollout, the ability to turn controls on and off, and exception handling; it is available to existing customers under current licences, and new tenants will get BSM controls by default over time. The post also sets out where Microsoft draws the Secure by Design line, meaning controls customers cannot opt out of such as mandatory MFA for Azure administrators and Conditional Access enforcement for Windows Hello for Business and macOS platform SSO registration, versus Secure by Default protections that are on but can be turned off, such as Azure Backup soft delete. (Microsoft Security Blog)

The numbers behind that warning landed a day later, on 7 October, in the first substantial results post from Microsoft's FORGE Lab, and it is worth reading precisely because it makes the scale concrete. Between May and September 2026, agentic scanning work produced 140 Windows CVEs, and the monthly curve is the part to look at: 16 in May, 10 in June, 27 in July, 35 in August and 52 in September. On open source there were 155 internally validated reports across 23 projects including the Linux kernel, with 93 reports across 14 projects or project families carrying documented maintainer acknowledgement at the time of writing, and one Linux report became the first Akrites submission to reach a merged kernel patch. In the Linux kernel study, MDASH surfaced thousands of suspicious locations and validation agents produced supporting evidence for 627 findings, with crash proof-of-concept generation averaging 3.61 US dollars and 21.5 minutes per confirmed case. Publicly disclosed examples include CVE-2026-9545 and CVE-2026-13608 in curl, CVE-2026-56848 in Node.js and CVE-2026-64563 in the Linux kernel. The three lessons are aimed at people building this kind of pipeline rather than at a SOC, but the second and third translate directly: spend reasoning to close a specific evidence gap rather than minimising tokens, and treat validation and remediation as part of the discovery loop instead of downstream cleanup. The framing to take away is the one the author leads with, which is that finding vulnerabilities is no longer the bottleneck — validating and fixing them is. (Microsoft Security Blog)

Sentinel shipped the ASIM EmailEvent schema on 7 October, and if you have ever written the same email detection twice for two different mail products, this is the one to look at. EmailEvent is a normalised structure for email delivery and inspection events covering sender, source and recipient information, subject, size, direction and delivery location, URLs and attachments, SPF, DKIM and DMARC results, delivery actions such as delivered, blocked, quarantined or deleted, and threat, risk, confidence, tactic, technique and remediation detail. The point is the separation it creates: a connector collects the source event, a parser or data collection rule maps native fields into EmailEvent, and your queries address the normalised field names, so when another source gains an EmailEvent parser your existing source-independent detections work against it without being rewritten. The release includes the schema definition at version 1.0.0, the source-independent parser framework, a filtering parser, deployment templates and validation support in the Azure-Sentinel repository, so partners and community contributors can write source-specific parsers. Microsoft is explicit that this does not replace the rich native data a mail security product produces — it adds a consistent security layer on top of it. Worth pairing with the ASIM parser deployment guidance before you start rewriting anything. (Microsoft Sentinel Blog)

The new Defender server security experience went to public preview on 6 October, and it closes the split-brain problem between endpoint and cloud server data. In the Defender portal you get a server asset page that combines cloud and endpoint details from Defender for Endpoint and Defender for Servers in one view, with servers investigable across alerts, incidents and the attack graph, a Go hunt pivot into related events, and access managed through role-based access control, server device groups and cloud scopes. On the Azure side, turning off the Defender for Servers plan for a subscription now automatically offboards those servers from Defender for Endpoint, which removes a tedious and error-prone manual step at decommissioning time. If your analysts currently answer the question of what a server is and whether it matters by holding two browser tabs open, this is the preview to enable in a test subscription. (Microsoft Defender for Cloud release notes)

Defender for Identity made sensor v3.x activation without Defender for Endpoint generally available on 6 October, for eligible domain controllers running Windows Server 2019 or later. This matters mainly for organisations where domain controllers sit outside the Defender for Endpoint rollout for policy or change-control reasons, because until now the v3.x sensor path ran through an MDE onboarding you may not have been able to get approved. Read the scope narrowly before planning work against it: the activation method supports only new sensor v3.x deployments on eligible domain controllers that do not already have a Defender for Identity sensor, and migration from sensor v2.x is not supported through it. So this is a route for new coverage, not a way to move an existing v2.x estate. (Microsoft Defender for Identity what's new)

Purview gained a DLP policy on 8 October that keeps Microsoft 365 Copilot from grounding its answers in external email, and it is the cleanest mitigation for cross-prompt injection through the mailbox that Microsoft has shipped so far. The mechanism is narrow by design. You create a DLP policy on the Microsoft 365 Copilot and Copilot Chat location with the condition Email is received from set to External users and the action set to prevent Copilot from processing content; Copilot then checks sender metadata against the tenant's accepted domains and excludes external mail from grounding data entirely. The body of the message is never inspected, which is both the limitation and the reason the control is cheap to run. Everything else stays as it was: users read, reply to and manage external mail exactly as before, mail flow, delivery and retention are untouched, and other grounding sources including internal email, Office documents and web results continue to work. The scenario Microsoft uses to justify it is the one to brief your users on — a vendor-looking message carrying hidden instructions to an AI assistant, which gets picked up when someone later asks Copilot to summarise their inbox. Deploy it in simulation mode first and work out where external mail is genuinely load-bearing in a business workflow before you enforce, because this is a control you apply where the risk is rather than everywhere. (Microsoft Security Blog on Microsoft Community Hub)

A companion Purview DLP control published the same day handles the other direction: stopping sensitive data in a user's prompt from reaching external web search. The gap it fills is real, because the existing controls are binary. The Allow web search in Copilot policy in Cloud Policy service and the per-user Web content toggle are on or off and know nothing about what is in the prompt, so an organisation with web search enabled for good reasons has no way to handle the user who types a credit card, passport or social security number into a question about compliance requirements. The DLP policy evaluates each prompt in real time against Microsoft-provided or custom sensitive information types and, when it matches, prevents Copilot from using external web search as a grounding source for that prompt only — the prompt itself is not blocked, Copilot still answers from permitted internal sources, the user is told why, and the next prompt without sensitive data searches normally. Microsoft's argument for deploying it even where web search is already disabled is worth taking seriously: configurations change, new users land in groups with different settings, and a control that is data-aware rather than mode-aware keeps working through all of that. For context on what actually leaves the tenant today, the post also spells out that Copilot sends generated queries of a few words rather than the whole prompt, excludes entire Microsoft 365 files, and strips user and tenant identifiers before queries reach Bing. (Microsoft Security Blog on Microsoft Community Hub)

Microsoft Security Research used 8 October to make the case that post-quantum planning cannot stop at encryption, and the practical hook is a pilot you can actually join. The PQC TLS Pilot Program launched on 27 August 2026 and lets certificate authorities in good standing with the Microsoft Trusted Root Program evaluate post-quantum TLS roots and certificate issuance using ML-DSA-87; the August Trusted Root Program release added seven pilot roots from ComSign, DigiCert, HARICA, IdenTrust Services, Sectigo, Shanghai Electronic Certification Authority and SSL.com, and rolling admissions run through the end of 2026. The constraints are stated bluntly — pilot certificates are not publicly trusted, must not be used for production trust scenarios or public-facing websites, and ML-DSA support is limited and still evolving. On the client side, ML-DSA certificates can be evaluated in non-production scenarios on supported Windows 11 systems starting with the 28 July 2026 updates, KB5101681 for 26H1 and KB5101684 for 25H2, and can be used with Schannel in supported scenarios. There is no enforcement date and no deadline here, which is the point: the recommended work is inventory of everything that depends on certificates for authentication, trust or lifecycle management, a map of public and private PKI trust relationships, roadmap questions to your CA, PKI, HSM and platform vendors, and a non-production environment to test interoperability and the performance cost of larger certificate chains. Prioritise the long-lived systems with slow upgrade cycles, which in most estates means embedded devices, appliances and OT. (Microsoft Security Blog)

Azure Web Application Firewall exceptions reached general availability on 8 October for both Application Gateway and Azure Front Door, which gives you a middle option that has been missing from WAF tuning. Until now, handling a false positive meant either an exclusion, which skips inspection of one element of a request such as a noisy cookie or header while the rest is still inspected, or a custom rule with an Allow action, which bypasses the Default Rule Set, Core Rule Set and Bot Protection ruleset completely for matching traffic. Exceptions sit between them: they bypass inspection only for specific rules, rule groups or an entire managed ruleset, matched on request URI, remote IP address or request header name and value using equals, starts with, ends with, contains or IP match. The example to hold onto is a single DRS rule blocking valid mobile app requests, where an exception for that one rule leaves every other DRS rule, Bot Protection and DDoS protection running. Check the prerequisites and limits before promising anything: exceptions need the next-generation WAF engine and managed ruleset version DRS 2.1 or later, each WAF policy supports up to 60 exceptions with 60 in total across all policies on a given Front Door, and a single exception holds up to 600 IP addresses, 10 URIs or 10 request headers. The guidance is the usual and still correct advice to prefer a per-rule exception over a whole-ruleset one, exempt sources rather than paths, and review them on a schedule, because an exception added for a one-time load test is still there a year later. (Azure updates)

Carried over from 5 October, because no prior issue picked them up, two Defender for Cloud items went generally available. The first is a scope change that will move numbers on your dashboard: Kubernetes security posture management misconfiguration recommendations now align to Kubernetes workload controllers rather than individual running container instances, so they appear at the deployment or top-level controller scope such as Deployment or StatefulSet. Expect changes to affected recommendations and to their Secure Score impact, and expect to explain the shift to whoever reports on container posture monthly. The second is more immediately useful on shift: on-demand malware scanning in Defender for Storage now supports targeted scanning, so instead of scanning a whole storage account you can scope a scan to a single blob or file, a specific container or file share, or everything matching a path prefix, using filters in the REST API request body. With no filters the scan still covers the entire account. For the common incident case of one suspect upload in a large account, that is the difference between a scan you can run during triage and one you schedule for overnight. (Microsoft Defender for Cloud release notes)

Also from 5 October and also uncovered until now: Defender for Office 365 extended user reporting in Microsoft Teams to cover meetings. Users can report a scheduled or Meet now Teams meeting, or an individual meeting participant, as a security concern during or after the meeting, and can also report a participant who was incorrectly flagged as suspicious as not a security concern. Where the report goes depends on your Teams user reported settings, with reported meeting and participant metadata sent to the designated reporting mailbox, to Microsoft, or both. The reason to care is queue shape rather than capability — if you have been running Teams-based social engineering response off screenshots forwarded to a shared mailbox, there is now a first-party path, and someone needs to decide who triages it before the first report arrives. (Microsoft Defender for Office 365 what's new)

KQL to try

Published on 8 October and almost embarrassingly short for how useful it is, this one answers a question every SOC running Defender for Office 365 should be able to answer this month: how much prompt-injection email is being caught, and is any of it still landing in mailboxes rather than quarantine. It filters EmailEvents on the Prompt injection detection method over 30 days and summarises message counts by DeliveryAction and DeliveryLocation in daily bins, which gives you both a volume trend and an immediate read on whether anything is being delivered. Given the two Purview grounding controls elsewhere in this issue, run it before you write the business case for either. (Uncover every prompt-injection detection and its disposition — Michalis Michalos)

// Prompt-injection detections over the last 30 days, by disposition
let lookback = 30d;
EmailEvents
| where Timestamp > ago(lookback)
| where DetectionMethods has "Prompt injection"
| summarize Messages = count() by DeliveryAction, DeliveryLocation, bin(Timestamp, 1d)
| sort by Timestamp desc

From the same author on the same day, a heuristic hunt for the shape of a URL an AI assistant would be instructed to call. It joins delivered messages to their URLs through EmailUrlInfo on NetworkMessageId and flags long base64-looking values in data, q, payload or d query parameters, or collector-style paths such as /collect, /exfil and /log. Two caveats the author states and you should respect: the exact DetectionMethods string varies by tenant and changes over time, so confirm the literal in your own EmailEvents before building an alert on it, and the regex is a starting heuristic that needs tuning against your own legitimate URL patterns before the false positive rate is tolerable. Treat it as a hunt, not a detection, until you have done that work. (Delivered mail carrying exfiltration-style URLs — Michalis Michalos)

let lookback = 30d;
EmailEvents
| where Timestamp > ago(lookback)
| where DeliveryAction == "Delivered"
| join kind=inner (
    EmailUrlInfo
    | where Timestamp > ago(lookback)
) on NetworkMessageId
| where Url matches regex @"(?i)([?&](data|q|payload|d)=[A-Za-z0-9+/]{24,}={0,2}|/(collect|exfil|log)\b)"
| project Timestamp, SenderFromAddress, RecipientEmailAddress, Subject, Url, DeliveryLocation
| sort by Timestamp desc

Worth knowing

A retirement announced on 6 October that will reach anyone running encrypted-in-use data in Azure SQL Database: Always Encrypted with Intel SGX enclaves retires on 31 October 2027 as support for SGX-enabled DC-series hardware is phased out, and the transition path is Virtualization-Based Security enclaves, which are hardware-independent. The practical reading is that the capability survives and the hardware dependency does not, so the work is a migration plan rather than a redesign — but it is a plan that has to clear a database change window, and those are booked a long way out. (Azure updates)

Merill Fernando published an Entra Chat write-up on 9 October with two Global Secure Access product managers, and the headline recommendation is specific enough to act on this quarter: if you hold Entra ID P1 and have not deployed the GSA client, start with compliant network. The argument is that a Conditional Access policy blocking access from anywhere outside the All Compliant Network locations named location means a stolen refresh token or primary refresh token fails when replayed from the attacker's machine — the token is not bound, but its use is confined to your network, which for most token-theft scenarios amounts to the same thing. Deployment advice is to target all users and all resources, start in report-only, pilot small, and exclude break-glass accounts, with the last of those presented as the lockout risk people actually hit. Two further points are worth noting for detection work. GSA restores original source IPs to Entra, which makes sign-in logs accurate again and lets location-based risk detections and IP-based Conditional Access work as intended. And traffic routed through GSA becomes continuous access evaluation aware, including for private apps, so a session can be cut within minutes of an identity risk signal or a device being marked non-compliant in Intune or a third-party MDM. (Entra.News)