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

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

← Home

Week 39 · 18 min read

September 21 – September 28, 2026

Act by

  • 14 Dec 2026 — the Machines should have a vulnerability assessment solution recommendation is deprecated in Microsoft Defender for Cloud. Note the date: the 14 September issue carried 11 Oct 2026 for this obligation, off the 10 September announcement, and the 23 September release note now puts it at 14 December. You have two months more than you thought, and the work is unchanged — anything wired into that grouped recommendation breaks quietly rather than loudly when it disappears, so find every compliance report, exemption, governance rule and workflow automation referencing it and rebuild against the individual server vulnerability assessment recommendations. (Microsoft Defender for Cloud release notes)

  • 1 Feb 2027 — Microsoft-provided SMS and voice authentication retires in Entra ID, and the timeline was split on 23 September into two populations rather than one. Most users still hit 1 February 2027; Global Administrators and external users now get until 1 July 2027. Read the exception narrowly, because internal guest users are explicitly not in the July group and stay on the February date, which is the detail most likely to bite a tenant that reads the headline and relaxes. After each date, affected users whose only MFA method is SMS or voice get a blocking passkey registration prompt at sign-in with no opt-out. The temporary opt-out via the passkeyDynamicMigration property only covers the September 2026 to February 2027 auto-enablement window, not enforcement. Run the SMS and voice usage analyzer script now to get your actual population, and if a regulated segment genuinely needs telephony, note that provider selection through Microsoft Security Store opens on 30 October 2026 with Soprano and Telesign in private preview. (Microsoft Entra ID passkeys and SMS and voice retirement)

What changed

The headline of the week, and the one to read properly rather than skim, is the Integrated Security Operations Center in Microsoft Defender, in public preview from 23 September. ISOC is not a new product — it is a licensing and packaging benefit that pushes Microsoft Sentinel SIEM capabilities into the Defender portal for eligible Microsoft Defender Suite, Microsoft 365 E5 and E7 customers who do not already have an active Sentinel workspace. Three things arrive out of the box with no configuration and no workspace: the new Cases experience, workbooks, and natural-language playbook generation, plus an enhanced automation rule. Defender log sources are covered automatically — Defender for Endpoint, Office 365, Identity, Cloud Apps and Cloud, plus Entra ID Protection logs, with Azure Activity and Office 365 Activity available through connectors — and retention starts at 30 days, going to 90 days on 15 November 2026. Anything broader needs an ISOC workspace, which requires an Azure subscription: that gates UEBA, Content hub connectors, repositories for CI/CD, threat intelligence and any non-Microsoft data. From 1 October 2026 that ingestion runs on a 2.40 US dollar per GB pay-as-you-go meter across more than 500 connectors, with regional variation. The practical read depends entirely on which side of the eligibility line you sit. If you are an E5 shop that never stood up a SIEM, you now have one, and the sensible move is to create a workspace and see what your own data looks like before Ignite. If you already run Sentinel, nothing changes and nothing is required of you — and Microsoft says explicitly not to disconnect a production Sentinel workspace to qualify for the preview, which is worth repeating to anyone who gets enthusiastic. Existing Sentinel customers who meet the licensing criteria get the choice to move from 15 November 2026. (Microsoft Defender XDR Blog)

Case Management in Microsoft Defender went to public preview the same day, and it is the part of ISOC that actually changes an analyst's hands. Incident Cases become the primary working entity for incident response, replacing the incident page as the place you live during a response: the attack story, alerts, affected assets and evidence stay where they were, and ownership, status, findings, comments, attachments and tasks join them in the same view. The configurable pieces are custom fields, custom statuses and SLA policies that track acknowledgement, escalation and resolution against attributes like status, severity and team. Case creation and updates can trigger automation and playbooks. The compatibility story is the reason this is low-risk to turn on: existing incident-based workbooks, workflows, automations, logic app playbooks and integrations keep working, existing incident APIs continue to function on top of the Case schema with new case-only properties exposed through a Case API, the incident RBAC model and scoping carry over unchanged, and each Incident Case maps one-to-one to an incident during this phase with no migration or reconfiguration. The forward-looking piece is that agentic sessions now link to Incident Cases for the Investigation Agent workflow, so from a case you can attach the agent's work and see when a session needs a human. If you have been maintaining a separate ticketing system purely because Defender incidents could not hold ownership and SLA state, this is the thing to evaluate against it. (Microsoft Defender XDR Blog)

Sentinel data lake onboarding changed on 23 September and the change is a simplification worth acting on. The separate data lake onboarding and billing setup is gone: you complete Sentinel onboarding, verify the workspace is connected to the Defender portal, and then enable the lake tier per table through Table management under Retention. From there you can mirror an Analytics tier table into the lake tier or set lake-only retention for historical data. For existing Sentinel customers who never onboarded to the data lake, total retention evolves from archive-based retention to data lake retention automatically after Sentinel onboarding — which is the sentence to reread if you have restore workflows built around archive. The operationally useful half is that interactive KQL against the data lake now runs in advanced hunting under Investigation and Response in the Defender portal, so historical data is queryable without restoring it to the Analytics tier first. Microsoft also documented the Fabric path in the same update: Azure Monitor mirroring exposes selected Sentinel tables in Microsoft Fabric with no data copy and no additional charge, federation covers sources you cannot move such as AWS S3, Google Cloud Storage, ADLS Gen2 and Azure Databricks, and Fabric Graph can model relationships across lake tier data queried with GQL, with findings published back into Sentinel through a DCR. Customers who onboarded to the data lake before 23 September can keep using the existing documentation. (Microsoft Sentinel what's new)

Security Copilot is now included with Microsoft 365 E5 and E7 at no additional cost, with Message Center post MC1478465 landing on 24 September as the phased rollout reached tenants. The capacity model is the part to write down: 400 Security Compute Units per month for every 1,000 paid user licences, capped at 10,000 SCUs per month, scaling proportionally below 1,000 licences, resetting monthly with no rollover. Provisioning is automatic with no Azure setup — a Default Security Copilot Capacity appears in the tenant, cannot be modified, is shared tenant-wide, and the cost values shown in the UI against it are informational rather than charges. What that capacity covers is all chat, promptbook and agentic scenarios across Defender, Entra, Intune, Purview and the standalone portal, plus Agent Builder and the MCP and Graph APIs for custom agents, and SCU costs for partner-built agents until further notice. What it does not cover: Sentinel data lake compute or storage, the non-agentic Data Security Investigations experience in Purview, Azure Logic Apps usage driven from Security Copilot, and partner agent licensing bought through Security Store. Two operational notes. Agents are not switched on for you — someone still has to deploy them in each experience. And if you already provisioned SCUs, do not delete that capacity. Overage will be throttled at some future date with 30 days notice, at which point pay-as-you-go runs at 6 US dollars per SCU. (Learn about Security Copilot for Microsoft 365 E5 and E7 customers)

Microsoft Threat Intelligence published a teardown of EvilTokens on 22 September, and if you brief one thing to your identity team this week, make it this. EvilTokens is a phishing-as-a-service platform that emerged in February 2026 and became one of the most widely used kits within months, sold at 1,500 US dollars up front plus 500 a month for the kit and control panel. Microsoft tracks the operator behind it as Storm-2992, and the tally is more than 12,000 inboxes across over 10,000 organisations worldwide, concentrated in wholesale distribution, construction, financial services, real estate, higher education and healthcare across the US, Canada, UK, Australia, India and France. The mechanics matter because there is nothing to patch. A lure drawn from 44 available themes lands, a script generates a live device code against the Microsoft identity provider, the victim is shown the code with a Continue with Microsoft button pointing at the genuine microsoft.com/devicelogin, and the backend then polls its own state endpoint every three to five seconds through a 15-minute window waiting for the victim to authenticate on the real Microsoft page. No credential ever touches attacker infrastructure. Within ten minutes of token theft the actors register their own device to mint a Primary Refresh Token for durable access, then run AI-assisted inbox triage to find financial, executive and administrative targets, enumerate the tenant through Microsoft Graph, and plant inbox rules for exfiltration and persistence. Redirects are hosted on Vercel, Cloudflare Workers and AWS Lambda behind fake CAPTCHA pages and compromised legitimate domains, so URL blocking will always be behind. Defender for Identity fires Anomalous OAuth device code authentication activity, Anomalous token exchange following device code authentication and Suspicious Entra device join or registration; Defender XDR adds User account compromise via OAuth device code phishing, Device registration after potential device code phishing, the two Anomalous Microsoft Graph API activity variants and Suspicious inbox rule created after potential device code phishing sign-in. Two controls do most of the work: block device code flow in Conditional Access with exceptions scoped to named Teams device resource accounts, and require phishing-resistant MFA. One containment detail that catches people out — revoking tokens typically kills refresh tokens while leaving existing access tokens live for up to an hour, so disable the account rather than assuming revocation is enough, and remove the attacker-registered device or the eviction fails. (Microsoft Security Blog)

The 25 September Storm-3168 write-up is the first detailed public view of an agentic ransomware operation working inside Azure, and it is short enough to read end to end. Microsoft links the activity to JADEPUFFER, the actor Sysdig reported in July 2026 as the first documented agentic ransomware operation. Two service principals in one tenant were compromised and the work was divided between them: one enumerated virtual machines, subscriptions, resource groups and resources for about 15 and a half hours with over 300 successful read operations, while the second did discovery, destruction and credential collection. Both used the same Storm-3168 infrastructure and network fingerprint and the user agent python-requests/2.34.2. The destruction itself lasted about seven minutes — over 100 storage account deletion attempts, most successful, plus a Key Vault, a Function App and an App Service plan from the same resource group — inside a 35-minute window holding more than 150 destructive or credential operations. Parallel Azure SQL database deletions all failed, but only because the tooling used an unsupported API version for that resource type, which is luck rather than a control. Thirty minutes after the destruction the same principal ran ListKeys against 30-plus storage accounts including Site Recovery storage, and a similarly named storage account in the deleted resource group was deliberately spared so its keys could be taken. Deletion attempts against Azure Site Recovery and Azure Backup protection locks failed. Two findings are worth carrying into your own environment. First, every operation stayed inside the identity's existing RBAC — a group-granted Storage Account Contributor role authorised the storage destruction, direct Contributor the application resources, direct SQL DB Contributor the failed database deletions — so least privilege on workload identities is the control, not detection. Second, resource locks and storage account-level deletion protection were the only things that actually stopped deletions by an identity holding broad permissions. On initial access, the principal's client ID, secret and tenant ID had been posted in plaintext in a public GitHub issue by an employee; the issue was edited to remove the secret but it stayed readable in the public edit history. Microsoft could not confirm that was the path used, and the lesson stands regardless: editing a disclosure does not rotate a credential. (Microsoft Security Blog)

A day earlier Microsoft published a profile of Storm-2570, tracked since April 2025, and the value here is a concrete detection shopping list rather than novelty. Storm-2570 is a cross-ecosystem affiliate that deploys whichever ransomware is convenient — Qilin, DragonForce, Anubis and BERT have all been observed — against healthcare, education, government, financial services, energy, retail, IT, food and agriculture, manufacturing and transport across the US, Canada, UK, Spain, Netherlands and Puerto Rico. Initial access is unconfirmed, but everything after it repeats. Remote access comes from stacked legitimate RMM tooling: MeshAgent and MeshCentral as the primary, frequently renamed with the victim organisation's name in the filename in the pattern meshagent64-organisation.exe, plus Atera, ScreenConnect, Splashtop Streamer, Remotely_Agent and NinjaRMM, with cloudflared.exe installed as a persistent service under LocalSystem and ngrok exposing RDP on 3389. Discovery uses NetScan, SoftPerfect Network Scanner Portable and Nmap. Credential access is Mimikatz, LaZagne, pypykatz and ntdsutil.exe for an IFM-style NTDS.dit extraction. Lateral movement is PsExec and PsExec64.exe, often with an @ip.txt host list, plus Impacket, NetExec and an rdp.bat that opens the 3389 firewall rule. Defender is attacked directly through registry changes to DisableAntiSpyware and DisableRealtimeMonitoring and an exclusion added for C:\PerfLogs. Exfiltration is s5cmd.exe to S3-compatible storage with an AWS credentials file, and Rclone. Three things to check off the back of this: tenant-wide tamper protection on, DisableLocalAdminMerge set so a GPO cannot add local exclusions, and an inventory of which RMM tools are legitimately in use so a renamed MeshAgent stands out. Automatic attack disruption is the control Microsoft names for catching this mid-chain. (Microsoft Security Blog)

The September roundup published 24 September carries a batch of Purview general availability items that matter more to whoever owns data security than to the shift rota, but two touch investigations directly. Purview eDiscovery now supports search, hold, review and export against user-owned SharePoint embedded containers, which is how content from Microsoft Loop, Copilot Pages, Copilot Notebooks and Outlook newsletters becomes reachable — and the practical improvement is that investigators no longer need a SharePoint administrator to hand over a container URL, with an optional HTML conversion producing something downstream legal tooling can read. Data Lifecycle Management can now archive inactive SharePoint content without archiving the whole site: archived content stays subject to retention and legal hold and stays discoverable for eDiscovery while dropping out of Microsoft 365 Copilot indexing until reactivated, which is a genuinely useful lever if Copilot is surfacing stale material. Priority Cleanup goes the other way and permanently deletes approved content such as old Teams recordings and transcripts, after which it is gone from eDiscovery, SharePoint search and Copilot alike — so treat it as irreversible and get sign-off. Auto-labeling also scaled up: policy simulations now cover up to 20 million items and 50,000 sites through adaptive scopes, administrators can edit a policy without re-running the simulation, and new audit insights report policy coverage and processing activity. (Microsoft Security Blog)

Smaller but immediately usable from the same 24 September roundup: an email detonation summary is now available for organisations running both Microsoft Defender and Security Copilot. It generates plain-language explanations of URL and file sandboxing results, which is aimed squarely at the step where an analyst has a detonation verdict in front of them and has to correlate the sandbox evidence against the rest of the signal by hand before deciding anything. There is no new licence to buy if you already hold both, and with Security Copilot now arriving inside the E5 and E7 entitlement the population that can use it just got considerably larger. Worth a look on your next phishing queue rather than a project. (Microsoft Security Blog)

KQL to try

A hunt published this week for invisible Unicode in inbound email, built on a premise that is going to age well: an email now has two audiences, the human reader and whatever agent or parser processes the text, and they do not necessarily see the same thing. Microsoft and Micro-zero-width-space-soft render identically to a person but differ to a keyword detection, a filter or an agent, which makes zero-width and bidirectional control characters a cheap obfuscation channel. The query extracts characters in the U+200B to U+200F, U+202A to U+202E, U+2060 to U+206F and U+FEFF ranges from both Subject and SenderDisplayName, adds a geolocation check across sender IPs, and scores each message out of 100 with the reasons spelled out in a RiskReasons column so triage does not start from scratch. Note the emoji check carries the heaviest weight at 40 points and marketing mail will trip it, so expect to tune that term down before you trust the ranking. (Hunting Invisible Unicode in Emails — Sergio Albea)

EmailEvents
| where Timestamp > ago(1d)
| where isnotempty(Subject)
| extend SenderIP = iff(isnotempty(SenderIPv4), SenderIPv4, SenderIPv6)
| extend Country = tostring(geo_info_from_ip_address(SenderIP).country)
| extend SubjectSuspiciousChars = extract_all(@"([\u200B-\u200F\u202A-\u202E\u2060-\u206F\uFEFF])", Subject)
| extend SenderDisplaySuspiciousChars = extract_all(@"([\u200B-\u200F\u202A-\u202E\u2060-\u206F\uFEFF])", SenderDisplayName)
| extend HasEmoji = Subject matches regex @"[\u2600-\u27BF]"
| extend SubjectUnicode = iff(array_length(SubjectSuspiciousChars) > 0, 1, 0), SenderDisplayUnicode = iff(array_length(SenderDisplaySuspiciousChars) > 0, 1, 0)
| summarize Timestamp=max(Timestamp), HasEmoji=max(toint(HasEmoji)), SubjectUnicode=max(SubjectUnicode), SenderDisplayUnicode=max(SenderDisplayUnicode), SubjectSuspiciousChars=make_set(SubjectSuspiciousChars), SenderDisplaySuspiciousChars=make_set(SenderDisplaySuspiciousChars), Countries=make_set(Country), SenderIPs=make_set(SenderIP), SenderDisplayNames=make_set(SenderDisplayName), SenderAddresses=make_set(SenderFromAddress), SenderDomains=make_set(SenderFromDomain), DeliveryLocations=make_set(LatestDeliveryLocation), ThreatTypes=make_set(ThreatTypes), ThreatNames=make_set(ThreatNames), EmailCount=count() by Subject, NetworkMessageId, RecipientEmailAddress
| extend CountryCount = array_length(Countries)
| extend MultiCountry = iff(CountryCount > 1, 1, 0)
| extend RiskScore = (HasEmoji * 40) + (SubjectUnicode * 20) + (SenderDisplayUnicode * 20) + (MultiCountry * 20)
| extend RiskReasons = strcat(iff(HasEmoji == 1, "Unicode symbol in Subject [+40]; ", ""), iff(SubjectUnicode == 1, "Hidden Unicode in Subject [+20]; ", ""), iff(SenderDisplayUnicode == 1, "Hidden Unicode in SenderDisplayName [+20]; ", ""), iff(MultiCountry == 1, strcat("Multiple Countries [+20] (", CountryCount, "); "), ""))
| where RiskScore > 0
| project Timestamp, NetworkMessageId, RecipientEmailAddress, RiskScore, RiskReasons, Subject, SubjectSuspiciousChars, SenderDisplayNames, SenderDisplaySuspiciousChars, Countries, CountryCount, SenderIPs, SenderAddresses, SenderDomains, DeliveryLocations, EmailCount, ThreatTypes, ThreatNames
| order by RiskScore desc, Timestamp desc

Also from this week, a short hunt over UrlClickEvents for Safe Links clicks inside Microsoft Teams rather than email, filtered to Phish and Malware verdicts, and it exists because UrlClickEvents records the Teams workload too and most hunting libraries only ever point it at mail. The column to sort on is IsClickedThrough: a user who saw the warning page and continued anyway is a compromise candidate, not a click statistic, so the follow-up is their subsequent sign-ins and cloud activity. Given how much of the phishing described elsewhere in this issue arrives through Teams rather than a mailbox, this is a cheap gap to close. (MDO Hunting - Teams Safe Links Click-Through — David Alonso)

UrlClickEvents
| where Timestamp > ago(7d)
| where Workload == "Microsoft Teams" or Workload has "Teams"
| where ThreatTypes has_any ("Phish", "Malware")
| project Timestamp, AccountUpn, Url, UrlChain, ThreatTypes,
        DetectionMethods, ActionType, IsClickedThrough, Workload
| order by Timestamp desc

Worth knowing

Rob Lefferts' framing post for ISOC on 23 September is the strategy document behind the week's product news, and the argument underneath the marketing is reasonable: attackers running agent frameworks mean one operator can now do what a team did, and a SOC where protection and operations are separate systems pays a tax at every handoff. The concept Microsoft is selling is the integrated protection loop, with attack disruption as the worked example — telemetry and controls close enough together that the system can act while an attack is still unfolding and use exposure insight to harden in near real time. Read it for the direction of travel rather than for anything you can configure. The honest caveat is that most of the specifics land at Ignite, 17 to 20 November 2026. (Microsoft Security Blog)

For a practitioner's view of the same announcement, Jussi Metso walked ISOC through his own tenant on 23 September and his observations are a useful counterweight. He flags the phase one eligibility rule — E5 and E7 customers without Sentinel in use — as the significant limitation, with the expectation that the preview later widens to all customers with or without Sentinel, and he is candid that the criteria are not yet clear enough to tell who actually qualifies. On the mechanics he confirms that creating a Defender workspace needs an Azure subscription and that Automation and Workbooks appear as new menu items in security.microsoft.com afterwards, and he shows the AI playbook generation opening into VS Code with Cline to produce the Python and JSON workflow. If you are deciding whether to spend an afternoon on the preview, his write-up will tell you what you actually get before you start. (Jussi Metso)