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

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

← Home

Week 43 · 26 min read

October 19 – October 26, 2026

Act by

  • Within 30 days of the banner — Defender for Identity is rolling out automatic sensor v3.x activation and automatic Windows auditing configuration to existing customers, and the default flips on by itself. Eligible organisations that are licensed for Defender for Identity and have an active workspace see a banner on the Sensor management tab of the On-premises settings page for 30 days. After that notice period, Automatic sensor v3.x activation and Automatic Windows auditing configuration are enabled by default through a very gradual rollout, including settings currently set to Off. If you deliberately turned those off, that decision expires unless somebody selects Opt out in the banner while it is still showing. Either outcome can be the right one — automatic auditing configuration is how the newer detections get the events they need, and v3.x is where the alert investment is going — but it should be a decision rather than a surprise, and the people who watch that settings page are not always the people who made the original call. Go to Advanced features from the banner to enable the settings yourself, or Opt out to prevent automatic enablement. (Microsoft Defender for Identity what's new)

What changed

The week's headline is a nation-state campaign that ran at machine speed, published by Microsoft Security Research and Microsoft Threat Intelligence on 21 October. Storm-0940, a China-state aligned actor active since 2021, has been using ARTEX — an open-source, multi-agent penetration testing framework written in Go that can drive any AI model through reconnaissance to exfiltration with little human interaction — since as early as September 2026. Microsoft assesses Storm-0940 was responsible for compromising ConnectWise's multi-tenant Cloud Backup application, the subject of ConnectWise's own advisory on 16 October. Having taken control of identities for several ConnectWise cloud applications, the actor's agents authenticated into downstream customer tenants on the trusted app access and attempted sign-ins to more than 2,250 tenants; the infographic reports over 200 sign-ins in under four minutes using four application credentials, and privileged access to cloud infrastructure in some cases within three hours of initial targeting. OAuth application abuse was already in this actor's toolkit, so read the novelty correctly: ARTEX did not invent a technique, it removed the human bottleneck from one. In some environments the agents went past authentication into Microsoft Graph and directory operations — reconnaissance, adding application credentials for persistence, and changes to identities, groups and privileged roles, with one ConnectWise management application self-assigning Global Administrator. Credential access included bulk Key Vault secret reads. There is also a separate, cleanly documented password-spray campaign to check your own logs against: from 10 to 14 October, 144.172.64.99 hit 327 accounts across eight organisations with more than 151,000 failed logons, peaking around 2,900 per minute on 11 October, nearly 98 percent of it lockouts, with no successful authentication observed. The investigation guidance is specific and worth following literally: keep affected ConnectWise connections disabled until ConnectWise publishes restoration instructions, do not delete the enterprise applications as a first move because that destroys the evidence, inventory the four listed application IDs and record each tenant's local service principal object ID searching by application ID rather than display name, review every tenant where the apps were ever installed, and preserve Entra sign-in and audit records, Purview Audit, SIEM and Graph telemetry before changing anything. Review activity from at least 15 October and push service principal sign-in review back to 1 October where you can, treating successful and failed sign-ins as separate questions and not limiting yourself to the published IPs. Detection coverage spans Defender XDR alerts naming the compromised ConnectWise application and the Global Administrator self-assignment, Defender for Cloud Apps alerts on app role assignment and post-grant mailbox access, a Key Vault anomaly alert in Defender for Cloud, and Sentinel hunting queries over SigninLogs and MicrosoftGraphActivityLogs. Microsoft states plainly that this did not stem from a compromise of or vulnerability in Microsoft's own systems, products or services. (Microsoft Security Blog)

Two days later Microsoft published an analysis of the LiteLLM 1.107.0 supply chain compromise, and the mechanism is the part to internalise because it defeats the mental model most people use for a malicious package. The compromised release went to PyPI and official container images on 21 October. It did not need to be imported: the wheel dropped cook.pth, cook.py and sitecustomize.py into the environment's library directory, so Python ran the payload at interpreter startup, for anything, mapped to ATT&CK T1546.018. The one line in cook.pth imports cook, which decodes an embedded collector Microsoft calls PRIVCOLLECT and runs it in a daemon thread; a second path in sitecustomize.py reads a GitHub-hosted domain.txt as a pointer to an attacker server and fetches code from /codepy with no signature verification, though that file was empty at analysis time and no second stage was confirmed. According to LiteLLM's maintainers, stolen developer GitHub credentials redirected the release workflow to a lookalike repository, Berri-AI/litellm instead of BerriAI/litellm, and a second developer's credential passed a production approval step. The collector targeted developer and AI tool configs including GitHub Copilot, VS Code and MCP integrations, git and package-manager credentials, dotenv files, AWS, Azure CLI and Google Cloud configs and caches, Kubernetes service account files, Docker configs, cloud instance metadata, Chromium and Firefox credential data and history, shell and database client histories, SSH, GPG, TLS and Vault keys, readable process environments via procfs on Linux, and selected fields from two LiteLLM proxy database tables. Exfiltration was AES-256-CBC with a per-run key wrapped by an embedded 4,096-bit RSA public key, tarred and POSTed to a LiteLLM lookalike domain. Three operational points matter more than the IOC list. The startup files live outside the litellm directory, so deleting the application folder leaves the malicious components behind — rebuild from verified artefacts and confirm the files are gone. Do not run Python or pip inside a suspect environment to check whether the package is there; Microsoft observed a Windows case where a routine pip install of an unrelated dependency activated the collector. And the blast radius is every credential the compromised identity could reach, rotated from a clean machine with sessions revoked, because rotation alone may not invalidate existing tokens — on gateway hosts that includes stored provider credentials and DATABASE_URL. Detections were in place from 22 October across Defender Antivirus, Defender for Endpoint, Defender for Cloud and a threat analytics report, with the exposure tracked as TVM-2026-0003 in Defender Vulnerability Management, and Microsoft published advanced hunting queries for the collector domain, the startup-file hashes, the inline database collection commands and the OpenSSL staging activity. Treat those queries as leads rather than verdicts. (Microsoft Security Blog)

Two critical PHP remote code execution vulnerabilities, collectively PHP2Shell, were disclosed on 22 October, and Azure Network Security published upgrade guidance alongside Azure WAF mitigations the same day. CVE-2026-109618 is RCE via out-of-memory corruption and CVE-2026-109619 is RCE via stale global state; both are network exploitable without privileges or user interaction with high impact across confidentiality, integrity and availability. The underlying flaw is in how PHP handles memory when a request terminates abnormally, such as on memory exhaustion or a fatal error. Fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35, Microsoft worked the coordinated response alongside the PHP Foundation, Wiz and others, and the post is unusually blunt that upgrading is the only full remediation and the WAF work is temporary cover. The mitigation has two halves. Request-side custom rules reduce exposure to selected exploitation patterns and may produce false positives depending on your traffic. Response-side mitigation is the more interesting half, because request signals alone are not reliable here: for Azure Front Door, managed rule 99006001 in the MS-ThreatIntel-Response-CVEs group was rolling out with completion expected by 28 October, it is disabled by default so you have to enable it, it supports DRS 2.0, 2.1 and 2.2, and rather than blocking it strips the malicious elements from the response — which also means it takes effect only when the rule action is set to Block on anomaly and it generates no WAF log entries or hit counts, so do not expect to see it working. Application Gateway v2 has no managed rule yet and the interim mitigation is a header rewrite rule that matches Set-Cookie against a published PHPSESSID regular expression and deletes the matching header; validate it on a non-production gateway first, and note the reader comment on that post describing an evaluation loop that returned empty responses until the match pattern in the action was widened. Application Gateway for Containers gets custom rules only, since it does not support regex rewrites on HTTP responses. Rebuild and redeploy container images that carry their own PHP runtime, because patching the host does not patch PHP inside an image. (Azure Network Security Blog)

A day later the same team covered CVE-2026-111497, a buffer overflow in the Brotli decoder affecting Google Brotli 1.0.3 through 1.2.0. A remote unauthenticated attacker sends a crafted Brotli-compressed stream to corrupt decoder memory, with outcomes ranging from memory disclosure and denial of service to possible arbitrary code execution, and anything that decompresses untrusted Brotli data is in scope — Node.js and Python applications that bundle the decoder, and services that accept request bodies with Content-Encoding: br. Patched Brotli is 1.0.10, 1.1.1 or 1.2.1; for Node.js it is 22.23.4, 24.22.1 or 26.12.1. The genuinely good news is that if you run Azure WAF with DRS 2.2 on Application Gateway or Azure Front Door Premium you are already protected against the analysed requests, because DRS 2.2 adds Content-Encoding to the restricted-header list checked by rule 920450, which is on by default at Paranoia Level 1 and carries a critical anomaly score, so one match blocks in Prevention mode. That is a concrete argument for the ruleset upgrade you have been deferring: DRS 2.1, CRS 3.2 and earlier do not restrict that header. For policies still on an older ruleset, where 920450 is disabled or overridden, or on Azure Front Door Standard where only custom rules are available, the post gives ready-made custom rules for both services that block requests whose Content-Encoding includes br — set them to log only first if you are not certain your application never receives Brotli-compressed bodies. Request size limits are offered as a second layer rather than a mitigation, since the analysed proof-of-concept payloads run about 23 MB each and smaller ones are plausible. The limitation to carry into your own threat model is stated explicitly: Azure WAF inspects inbound requests only, so an application that fetches and decompresses Brotli-encoded responses from an external server is not protected by any of this and has to be patched. (Azure Network Security Blog)

Microsoft Entra ID Protection has a new user risk detection called Suspicious credential addition, added to the risk detections reference on 21 October. It identifies when a new authentication method is added to an account under suspicious circumstances, which might indicate that an attacker has accessed the account and registered a new credential. It is calculated in real time, requires Microsoft Entra ID P2, and surfaces in Graph as riskEventType suspiciousCredentialAddition. Real-time matters here more than usual, because credential registration is the step that converts a stolen password or session into durable access, and an offline detection that arrives after the attacker has their own MFA method is a post-mortem rather than a control. Two things to do with it: confirm your risk-based Conditional Access policies will actually act on a user-risk elevation rather than only reporting it, and check that the detection is wired into whatever your identity team triages, since it joins a user-risk table that most teams configured once and have not revisited. (What are risk detections?)

Defender for Identity's October batch grew after the alert drop this issue's predecessor covered, with the what's new page redated 20 October, and the additions are pointed at exactly the behaviour the ARTEX campaign and the new Entra detection describe. On the Entra side there are now alerts for malicious registration of a device with strong MFA, malicious registration of an attacker controlled MFA device, suspicious registration of a new Authenticator MFA method, suspicious registration of a new Email MFA method, suspicious registration of a new Phone MFA method, and a newly created user performing an organization branding change. Read that cluster as a single theme rather than six alerts: MFA registration is now instrumented as an attack step, which is the gap that made account takeover survivable through a password reset. The branding-change alert is the odd one out and the one to brief your service desk on, because sign-in page branding is how a convincing in-tenant phishing surface gets built. On the Active Directory side, a new alert covers potential Certighost (CVE-2026-54121) AD CS abuse, which joins the ESC1, ESC8 and ESC11 template and issuance alerts already in this batch and pairs with the Defender detection guidance Microsoft published for that CVE in July. Separately, sensor v3.x activation without Defender for Endpoint reached general availability for eligible domain controllers, AD FS, AD CS and Microsoft Entra Connect servers running Windows Server 2019 or later; it supports only new v3.x deployments on eligible servers with no existing sensor, and v2.x migration by that route is not available yet. That removes the deployment argument that has stalled identity-server coverage in estates where Defender for Endpoint on a domain controller was a political rather than a technical problem. (Microsoft Defender for Identity what's new)

Microsoft Defender got a new Threat Intelligence experience on 22 October, and the sentence to notice is that it replaces the previous Threat Analytics and Intel Management pages rather than sitting beside them. There are two surfaces. Threat Intelligence Overview is a personalised dashboard that puts your industry, your regions and your own environment at the centre, highlighting relevant threats, their impact and your exposure, so the starting question becomes what matters to us right now rather than what is loud globally. Threat Intelligence Explorer is the investigation surface: free-text search across indicators, threat actors, campaigns, attack patterns, tools, vulnerabilities and reports, drawing on Microsoft research articles and indicators, connected third-party feeds and intelligence your own team has curated, with filters by type, industry, geography and source and relationships you can follow from a threat to the evidence. From an indicator you continue into the relevant Defender entity page, and you can tag records in your Threat Intelligence Platform so the research compounds instead of evaporating when the analyst closes the tab. Microsoft says the Microsoft reports you rely on remain available in full detail and existing intelligence carries over, building on the completed convergence of Defender Threat Intelligence into Sentinel and Defender XDR. Access needs an eligible Defender licence. The practical work is unglamorous: anything in your runbooks, training material or saved links that points at Threat Analytics or Intel Management needs repointing, and whoever owns your threat intel curation should set the industry and region scope deliberately rather than inheriting a default. (Microsoft Defender XDR Blog)

Cross-tenant delegated administration in Microsoft Defender went generally available on 20 October, and it is now built on the same governance relationship model as Microsoft Entra Tenant Governance, with delegated access extended to Microsoft Sentinel resources and granular permissions through Defender unified RBAC. The shape is a directional relationship between a governing tenant, where an MSSP or central security team manages its analysts and security groups, and a governed tenant, which grants the access. Selected groups from the governing tenant appear in the governed tenant as remote tenant groups, and the governed tenant assigns the roles and resource scopes while the governing tenant keeps managing membership. Establishing it is a three-step consent-based handshake: the governed tenant enables governance invitations in Defender and invites the governing tenant, the governing tenant sends a relationship request carrying an access template of security groups and Entra role assignments, and the governed tenant approves and then configures the Defender and Sentinel roles and scopes. The security argument is the one worth making internally, because this is usually filed as an MSSP feature and it is not only that. Analysts use home-tenant accounts, so you stop minting local administrator or B2B guest identities in every tenant you operate — and a standing guest admin account in a customer or subsidiary tenant is precisely the kind of object nobody inventories and nobody removes. For Defender you can assign supported unified RBAC roles including custom ones to remote tenant groups; for Sentinel you can use Defender unified RBAC or Azure RBAC. If you run a multi-tenant estate across business units, regions or subsidiaries rather than as a service provider, this is the model to migrate toward. (Microsoft Sentinel Blog)

Unified Data Management for Microsoft Sentinel entered public preview on 20 October, in the new Data and connectors experience under Setup and configuration in the Defender portal. It pulls connectors, tables and ingestion health into three tabs. Overview gives a workspace-level view of daily ingestion split by Analytics tier and Data Lake tier, connectors needing attention with error type, failure count and last successful ingestion, tables with unexpected volume spikes or drops, top ingesting tables by daily volume, and ingestion latency by table. Connectors puts unified data connectors and Sentinel classic connectors side by side with status, provider, content source and available updates, filterable by provider, data type and status. Tables brings Sentinel and Defender XDR tables together with last data received, average daily ingestion volume, estimated daily ingestion cost, volume anomaly, tier and retention settings in the grid, and a details panel per table covering metadata, schema with column names, data types and descriptions, the Filter, Split and Scope Tag transformations applied, and retention. Two of those deserve a detection engineer's attention rather than a platform owner's. A table that has gone stale is a detection that has silently stopped firing, and this is the first place that condition is visible as a column instead of as an incident nobody raised. And reading a table's schema without writing a schema-discovery query first is a small thing that removes a genuine friction point from building transformations and hunting queries. Prerequisites are Sentinel onboarded to the Defender portal, unified RBAC enabled, the Data (manage) permission in the Data Operations permission group, and workspace permissions equivalent to Log Analytics Contributor including writing workspace and table settings. Commercial cloud only for now. (Microsoft Sentinel Blog)

Defender for Cloud announced the Defender Workload Unit on 20 October, a new billing model and product experience that converts workload-specific usage into one common billing unit at one global per-unit price, calculated hourly and billed monthly. Servers, databases, storage, containers, posture management, APIs, AI services, app services, Key Vault and Azure Resource Manager all still convert behind the scenes; what changes is that you see one unit, estimate it with a signed-in cost estimator that shows the pricing formula, size the environment with a read-only discovery script that keeps your data in your environment, and track spend on a Defender portal dashboard with detail in Azure Cost Management. Several measurement changes come with it rather than after it, and these are the ones to model: containers move from vCore-based to per-node pricing, the multiple instance-per-hour database plans consolidate into a single Defender for Databases plan, and the several API plans consolidate into one at a reduced price. The new container and API models are available only through the DWU experience in the Defender portal, not through the existing pay-as-you-go experience in Azure, so this is a migration decision rather than a billing cosmetic. Initial support is focused on Azure with broader multicloud and hybrid support planned, and Security Copilot is explicitly not covered. Eligible subscriptions new to Cloud Security can start a 30-day full-platform trial in the Defender portal, one per subscription, after which billing begins unless all cloud security plans are disabled before it expires — put that expiry in a calendar rather than trusting it to memory. (Microsoft Defender for Cloud Blog)

The portal half of that same change landed as two Defender for Cloud release notes dated 20 October. Cloud security plan management is moving to public preview in the Microsoft Defender portal for Azure commercial environments, letting you connect Azure subscriptions and management groups to cloud security in the Defender portal, enable and manage plans globally or for selected management groups and subscriptions, estimate and track cost including under the DWU model, and start the trial when enabling plans. Read the consequence carefully before anyone starts clicking: when plan management moves to the Defender portal, plan configuration is managed there and becomes view-only in the Azure portal, and migrated subscriptions use DWU-based billing. If your plan enablement is driven by Azure Policy, infrastructure as code or a change process that assumes the Azure portal is authoritative, that assumption now has an expiry date. Alongside it, the new Defender server security experience from 6 October expanded to cover onboarding: automatic onboarding of supported Azure virtual machines and Azure Arc-enabled servers through Defender for Servers, a choice of manual deployment methods for Windows and Linux, connecting on-premises servers through Azure Arc or Direct onboarding, and verifying onboarding with the available offboarding methods documented. Servers already running Defender for Endpoint need no reinstallation or migration to keep their protection. (Microsoft Defender for Cloud release notes)

Sentinel's SAP BTP solution picked up one analytics rule this month, listed as the sole October item on the what's new page as redated on 21 October, and it is a better-designed rule than the usual audit-log detection. It correlates SAP Application Vulnerability Report findings with BTP audit logs to detect use of custom apps carrying open high or critical vulnerabilities, identifying interactive XSUAA logins that match a vulnerable app together with application audit events in the same subaccount, Cloud Foundry organization and space, with a default CVSS threshold of 7.0 and a 14-day finding lookback. Niche unless you run SAP BTP, but the pattern is worth borrowing: this is not a detection of attacker behaviour, it is a detection of a vulnerable thing actually being used, which is the question vulnerability management usually cannot answer and the reason unexploited findings sit open for quarters. Enable it from Content hub if BTP is in your estate, and expect the tuning conversation to be about the CVSS threshold rather than about false positives. (What's new in Microsoft Sentinel)

A small addition to the Microsoft Entra Cloud Sync prerequisites, dated 22 October, is worth a note because it lands one week after the guided Connect Sync to Cloud Sync migration went generally available. The page now carries an Active Directory site configuration section: the Entra provisioning agent uses standard domain controller discovery, so incorrect DNS configuration, subnet-to-site mappings or site configuration can cause synchronisation failures, performance problems or intermittent connectivity. The instruction is to ensure servers hosting provisioning agents sit in correctly defined Active Directory sites and to associate each server's IP subnet with the appropriate site in Active Directory Sites and Services. Mundane, and exactly the sort of thing that turns a migration into an incident a fortnight later — a provisioning agent that discovers the wrong domain controllers fails as sync latency and missing objects rather than as an error anyone escalates, and a leaver who never leaves the directory is a security problem wearing an operations costume. Check it before the migration rather than after. (Prerequisites for Microsoft Entra Cloud Sync)

KQL to try

Published on 23 October and timely in a week with two Defender for Cloud server-onboarding items in it, this is a coverage audit rather than a hunt, which makes it the kind of query that finds the gap your detections are silently missing. It reads Azure virtual machines from the Defender XDR exposure graph, filters to the subscriptions you list in the configuration block at the top, pulls out resource group, VM name, operating system platform, device group, first and last seen, and both the onboarding status and the sensor health state, then orders by VM name. Two notes before you run it: you must replace the placeholder subscription GUID with your own, and the value of the output is the rows where OnboardingStatus or SensorHealthState is not what you assumed — an unonboarded or unhealthy Azure VM is a machine your EDR telemetry does not cover, however green the subscription looks in a plan-enablement view. (Azure VM MDE Onboarding Status — Alex Verboon)

// Configuration: Azure subscriptions to include
let vSubscriptionIds = dynamic([
    "00000000-0000-0000-0000-000000000000"
]);
// Azure VM inventory from Exposure Graph
ExposureGraphNodes
| where NodeLabel =~ "microsoft.compute/virtualmachines"
| where Categories has "virtual_machine"
// Extract Azure resource information
| extend AzureResourceId = tostring(EntityIds[0].id)
| extend
    SubscriptionId = extract(@"(?i)/subscriptions/([^/]+)", 1, AzureResourceId),
    ResourceGroup = extract(@"(?i)/resourcegroups/([^/]+)", 1, AzureResourceId)
// Filter subscriptions
| where SubscriptionId in~ (vSubscriptionIds)
// Extract VM attributes
| extend
    VMName = tostring(split(AzureResourceId, "/")[-1]),
    DeviceName = tostring(NodeProperties.rawData.deviceName),
    LastSeen = todatetime(NodeProperties.rawData.lastSeen),
    OnboardingStatus = tostring(NodeProperties.rawData.onboardingStatus),
    OSPlatform = tostring(NodeProperties.rawData.osPlatformFriendlyName),
    FirstSeenByInventory = todatetime(NodeProperties.rawData.firstSeenByInventory),
    DeviceGroup = tostring(NodeProperties.rawData.machineGroup),
    SensorHealthState = tostring(NodeProperties.rawData.sensorHealthState)
// Normalize hostname (remove DNS suffix)
| extend
    DeviceHostName = tolower(tostring(split(DeviceName, ".")[0]))
// Final inventory
| project
    SubscriptionId,
    ResourceGroup,
    VMName,
    DeviceName,
    DeviceHostName,
    OSPlatform,
    OnboardingStatus,
    SensorHealthState,
    DeviceGroup,
    FirstSeenByInventory,
    LastSeen,
    AzureResourceId 
| order by VMName asc

From 22 October, a hunt for uncommon processes reaching out to the kind of infrastructure that exfiltration and out-of-band testing actually uses, which is a useful complement to a week of supply chain compromises that ended with a POST to a lookalike domain. It matches DeviceNetworkEvents RemoteUrl against a regex list covering randomised CloudFront, KeyCDN, Azure Front Door and Azure cloudapp hostnames, AWS API Gateway execute-api endpoints, generic CDN patterns, Burp Collaborator domains, and the what-is-my-IP sites that both malware and curious staff use. The prevalence logic is what makes it liveable: it aggregates by the initiating process's version metadata rather than by file hash, invokes FileProfile, then drops anything with a global prevalence above 10,000, anything above 1,000 that is validly signed and was first seen before this run, and anything above 500 matching company and original-filename allow lists you populate yourself. Set query_frequency and query_period to match how you schedule it, and fill in those two exclusion arrays on the first few runs — the design assumes you will, and the signal gets sharper as you do. (Uncommon process connection to suspicious domain — Jose Sebastián Canós)

let query_frequency = 1h;
let query_period = 14d;
let suspicious_domains = dynamic([
    @"d\d[a-z0-9]{12}\.cloudfront\.net",
    @"[\-\w]+\-[a-f0-9]{3,5}\.kxcdn\.com",
    @"[\-\w]+\-[a-z0-9]{16}\.\w\d\d\.azurefd\.net",
    @"[\-\w]+\.[a-z0-9]+\.cloudapp\.azure\.com",
    @"[a-z0-9]{10}\.execute\-api\.[a-z]{2}\-[a-z]+\-\d\.amazonaws\.com",
    @"[a-z0-9]+\.[a-z]\-cdn\.net",
    @"portswigger\.net",
    @"oastify\.com",
    @"whatismyip\.com",
    @"whatismyip\.net",
    @"whatismyipaddress\.com"
]);
let excluded_company_names = dynamic([]);
let excluded_original_names = dynamic([]);
DeviceNetworkEvents
| where Timestamp > ago(query_period)
| where RemoteUrl matches regex strcat_array(suspicious_domains, "|") // and not(InitiatingProcessAccountSid in ("S-1-5-18", "S-1-5-20"))
| where isnotempty(InitiatingProcessFileName)
| summarize
    StartTime = arg_min(Timestamp, *),
    EndTime = max(Timestamp),
    DeviceNamesSample = array_sort_asc(make_set(DeviceName, 100)),
    RemoteUrlsSample = array_sort_asc(make_set(RemoteUrl, 100))
    by InitiatingProcessVersionInfoCompanyName, InitiatingProcessVersionInfoProductName, InitiatingProcessVersionInfoOriginalFileName, InitiatingProcessVersionInfoInternalFileName, InitiatingProcessVersionInfoFileDescription
| where StartTime > ago(query_frequency)
| invoke FileProfile("InitiatingProcessSHA1", 1000)
| where not(GlobalPrevalence > 10000)
| where not(GlobalPrevalence > 1000 and GlobalFirstSeen < ago(query_frequency) and SignatureState == "SignedValid")
| where not(GlobalPrevalence > 500 and InitiatingProcessVersionInfoCompanyName in (excluded_company_names) and InitiatingProcessVersionInfoOriginalFileName in (excluded_original_names))
| project
    StartTime,
    EndTime,
    DeviceNamesSample,
    RemoteUrlsSample,
    Timestamp = StartTime,
    DeviceId,
    DeviceName,
    LocalIP,
    ActionType,
    RemoteIP,
    RemotePort,
    RemoteUrl,
    Protocol,
    InitiatingProcessAccountName,
    InitiatingProcessAccountSid,
    InitiatingProcessAccountUpn,
    InitiatingProcessAccountObjectId,
    InitiatingProcessSHA1,
    InitiatingProcessSHA256,
    InitiatingProcessMD5,
    InitiatingProcessFileName,
    InitiatingProcessFolderPath,
    InitiatingProcessCommandLine,
    InitiatingProcessCreationTime,
    IsInitiatingProcessRemoteSession,
    InitiatingProcessParentFileName,
    InitiatingProcessVersionInfoCompanyName,
    InitiatingProcessVersionInfoProductName,
    InitiatingProcessVersionInfoOriginalFileName,
    InitiatingProcessVersionInfoInternalFileName,
    InitiatingProcessVersionInfoFileDescription,
    InitiatingProcessVersionInfoProductVersion,
    GlobalPrevalence,
    GlobalFirstSeen,
    GlobalLastSeen,
    SignatureState,
    ReportId

Worth knowing

Nadim Abdo, CVP for Identity and Network Access, published the agent-security argument on 19 October, and it belongs in this issue because the ARTEX campaign above is the demonstration. The framing is that agents are insiders: not malicious by nature, but capable of mistakes, manipulable through prompt injection, compromisable, and running continuously at machine speed, which is what breaks periodic review as a control. The load-bearing principle is to separate the supply of intelligence from the authority over it — the model must not be its own security boundary, so the controls over what an agent can access, what it may do and whether it keeps running sit outside it where it cannot tamper with them. Four continuous responsibilities carry the structure: know which agents exist and who owns them, contain what each can reach before it acts, protect the data, tools and runtime in its path, and adapt as behaviour and risk change. The illustrative case is an expense-approval agent that should not inherit every permission of its sponsoring employee, and that on encountering a prompt injection should lose writes while keeping safe reads rather than being killed outright. The product names worth knowing are Entra Agent ID with new identity types covering local and previously unknown agents, Dynamic Conditional Access extending Conditional Access to agents, Dynamic Permissions scoping authority to a task and time-bounding it with verified human approval for high-impact actions, Dynamic Agent Risk scoring continuously from Sentinel, Entra, Intune, Purview, Global Secure Access and Defender signals, the Microsoft Execution Container sandbox whose enforcement boundary sits outside the agent's reach, and Agent 365 sharing a unified registry with Project Perception. One concrete number: Defender's local agent discovery is expanding by 35 agent types to 60 supported, including Claude Code, OpenAI Codex and GitHub Copilot. (Microsoft Security Blog)

Sule Tatar published an Entra access-policy design piece on 22 October that reads as the operational counterpart to the agent post, and the useful idea in it is treating policy as a design discipline rather than an accumulation of rules — a Zero Trust posture measured by how well controls adapt to how people actually work, not by how many you enabled. The specifics are familiar and worth rehearsing anyway: start from identity rather than network location, make phishing-resistant MFA the baseline instead of the aspiration, replace standing admin rights with just-in-time elevation through Privileged Identity Management, and tier your applications so business-critical systems demand strong MFA and device compliance while low-risk tools stay light, because a blanket policy strict enough for finance will be worked around everywhere else. Two points earn their place. Treat AI agents as identities rather than exceptions — scoped identity each, least privilege, same risk evaluation and revocation as people — which is the same argument from the product side. And the list of common mistakes is honest enough to be useful: reusing identical settings for cloud and on-premises apps, leaning on device trust as a substitute for user and risk signals rather than as one input, giving agents broad or shared credentials, and deploying every rule at once with no piloting or rollback. (Microsoft Entra Blog)

Jussi Metso wrote up the Defender Workload Unit change on 21 October, and it is the practical companion to the announcement above if you have to brief someone on cost. He puts the list price at 5 dollars per unit, billed monthly or prorated hourly, while deferring to the official pricing page, and he collects the measurement changes in one place: containers from vCPU to protected node, Key Vault, Storage and Resource Manager from transactional to per-resource, Azure SQL and SQL Servers on machines and open-source relational databases consolidated into one Defender for Databases plan, and Defender for APIs unified. The detail not in the Microsoft post is the one worth catching — standalone Defender for DNS is discontinued, with Defender for Servers Plan 2 customers getting its capabilities at no extra cost. His planning caveats are sensible: enable the cloud security plans in Defender before using the DWU model, expect up to 24 hours for tenant data to appear after preparing the tenant, run the Cloud Security Cost Estimator before migrating rather than after, and read the public preview limitations because behaviour can still change. (Jussi Metso)