October 26 – November 2, 2026

Act by

• 3 Nov 2026 — the Microsoft Entra memberOf rule operator retires, and Microsoft published a final reminder on 28 October for anyone who has not acted. After that date, dynamic membership groups, dynamic administrative units and entitlement management auto-assignment policies that still use the operator stop updating and stay frozen in their last known state. The consequence is not an error message, which is why this one slips: stale group membership silently becomes stale Teams and SharePoint access, outdated Conditional Access targeting, wrong group-based licensing and incorrect access package assignments, all of which look like working configuration. If you have not already replaced those rules, the realistic move in the time left is to inventory every use of the operator and accept that affected groups freeze rather than break. Microsoft's reason for pulling the preview is worth knowing when you argue for the migration work internally — it observed that a single memberOf rule can affect dynamic membership processing across an entire tenant. (Configure dynamic membership groups with the memberOf operator)

What changed

The week's most immediate item is a supply chain compromise aimed squarely at the machines your engineers use, and Microsoft Threat Intelligence published the analysis on 30 October. On 29 October, Cursor reported that a tampered copy of the Claude Code extension, anthropic.claude-code versions 2.1.313 and 2.1.312, was served from the Cursor extension marketplace from roughly 2:27 AM to 1:35 PM Pacific. Microsoft confirmed the malicious packages were never published or distributed from the Visual Studio Marketplace or from the npm package @anthropic-ai/claude-code, neither of which was affected, and Anthropic confirmed to Microsoft that its systems were not compromised and that it did not develop the package; all evidence suggests the incident is limited to the Cursor marketplace. The mechanism is the part to internalise. Injected JavaScript runs when the extension module loads, before the extension's expected code, and it uses Node.js APIs to collect host details, write files and run operating system commands. It checks the user's authorized_keys file for the comment svc-telemetry and, if absent, appends an embedded Ed25519 public key — which authorises whoever holds the matching private key, subject to the local SSH server configuration. It then decodes a separate private key to a hidden temporary file named .stk_ followed by ten hexadecimal characters derived from the hostname and home directory, and uses it to authenticate an outbound connection to the remote account tunnel with the arguments -N -R '*:0:localhost:22', asking the server to allocate a listening port and forward connections back to port 22 on the victim's loopback interface. Host key checking is disabled, known_hosts is bypassed, and the retry loop prefers autossh on Unix-like systems and a hidden PowerShell loop on Windows, waiting sixty seconds between attempts. Reconnaissance covers hostname, username, operating system, architecture, home and working directories and the global Git email, plus up to forty environment variable names matching terms such as KEY, TOKEN, SECRET, PASS, AWS or GCP — names, not values, which reveals the shape of the host's secrets without proving theft. Three operational points matter more than the indicator list. Persistence is written outside the extension directory, so removing or updating the extension does not remove it: on macOS a user LaunchAgent at ~/Library/LaunchAgents/com.apple.sysmond.plist with ~/.config/.smt and ~/.config/.smtk, on Linux a user crontab @reboot entry referencing ~/.config/.smt, and on Windows a SysMon scheduled task, a Startup folder sysmon.cmd fallback and %USERPROFILE%.config\smt.cmd and smtk. Those names resemble legitimate monitoring components, so inspect each startup object's configured action before deleting anything. And a running SSH process is not proof the attacker got in — Cursor reports that errors and administrator permission requirements blocked SSH access on most macOS and Windows hosts, but the loader could still plant its key, establish persistence and report host details, so treat key presence and tunnel failure as two separate findings. Preserve the package, modified SSH authorization files, generated keys and scripts and startup configuration before cleanup, and rotate credentials and revoke sessions from a known-clean device where telemetry indicates credential access. Microsoft published advanced hunting queries for the reported address 134.209.82.225, the artefact filenames and SHA-256 hash, the Windows scheduled task creation and the macOS plist modification, plus a threat analytics Activity Profile. The durable control is the one Cursor documents in its hardening guidance and most organisations have never configured: restrict extensions to approved publishers and set an extension installation cooldown so a freshly published version cannot install on the day it appears. (Microsoft Security Blog)

The same day Microsoft published two human-operated intrusions that share an initial access pattern and diverge at the certificate layer, and it is the best end-to-end AD CS investigation write-up Microsoft has produced. Both began with Teams messages and calls impersonating IT or help desk personnel, using organisation-themed onmicrosoft.com tenant names and support-oriented display names, and persuading a user to open Quick Assist and hand over the connection code. Immediately after the user granted control, the attacker dropped an archive in Downloads, created a KB-prefixed staging directory under the user profile, extracted the archive there and launched the payload with a portable Python, Bun or Java runtime — one variant used a renamed executable that still carried Bun version metadata. The actionable pattern is not a filename but a sequence: a portable runtime launched from a newly created user-writable directory after an unexpected remote support session, followed by discovery commands and connections to identity infrastructure over LDAPS and SMB. In the first case the attacker found a certificate template vulnerable to ESC1, where a requester can supply identity information in the request and obtain an authentication certificate for a privileged account, and took certificates for three highly privileged accounts. Defender attack disruption contained the compromised user and those three identities, restricting remote logons and SMB access and disconnecting sessions — except for one privileged account that had been excluded from automated response. About ninety minutes later a larger phishing wave targeting sixteen users compromised a second workstation and produced certificates for eight more privileged accounts, and disruption blocked more than a thousand subsequent SMB file-access attempts. Within seconds of obtaining one certificate the attacker performed DCSync against a domain controller while containment was taking effect. The excluded account, however, remained usable, and the attacker rode it to a file server and ran a renamed copy of Rclone as SearchApp.exe, recursively copying share data to an external SFTP destination with twenty concurrent transfers, selecting files up to three years old and excluding executable, database, virtual-disk, media, temporary and log types. The second case had no ESC1 path available, so the attacker used PetitPotam over EFSRPC to coerce the domain controller into authenticating to an attacker-controlled system with its machine account, relayed that NTLM authentication to AD CS Web Enrollment without knowing the password, requested a certificate on the Domain Controller template, and used it for Kerberos PKINIT to obtain a ticket-granting ticket for the domain controller. Defender raised ESC8-related alerts, the customer isolated the workstation, and no further progression followed. Two sentences from this post belong in your incident runbook verbatim. Resetting a password or reimaging the first workstation does not revoke an issued certificate or invalidate Kerberos tickets that were already issued, so certificate revocation and ticket review are separate containment actions from identity containment. And containment exclusions are incident decisions: if an account or device cannot be automatically contained, assign a compensating manual action and verify it completed, because the gap in case one was not a detection failure. The hardening list is the familiar one and is now backed by two documented intrusions — KB5005413, HTTPS with Extended Protection for Authentication on enrollment web endpoints, NTLM disabled on enrollment services where feasible, authentication-capable templates reviewed for requester-supplied subject information and broad enrollment rights, unneeded Web Enrollment endpoints removed, Defender for Identity AD CS posture assessments used to find ESC1 template exposure and insecure ESC8 endpoints, and the Certification Services audit subcategory enabled for success and failure so the CA can tell you what was issued. (Microsoft Security Blog)

Microsoft Threat Intelligence published its assessment of AI adoption across North Korean threat actors on 29 October, and it is useful less as threat news than as a calibration exercise. The headline assessment is that overall adoption is high, graded across four stages: Jade Sleet, Coral Sleet and Jasper Sleet have operationalised AI across their entire operations; Diamond Sleet, Onyx Sleet, Pearl Sleet and Sapphire Sleet are accelerating; Emerald Sleet is expanding; and no North Korean actor is assessed at the emerging stage. The concrete examples are the part worth repeating to anyone who still treats AI-enabled tradecraft as hypothetical. Between 8 and 12 June 2026 Jade Sleet ran job-themed targeting against cybersecurity, AI, blockchain and recruitment organisations while standing up three separate front companies in a single week. Microsoft identified more than a hundred PDF lure files attributed to Onyx Sleet created in August and September 2026, with metadata showing dozens generated at a time within minutes. Coral Sleet has run a workflow to trojanize private GitHub repositories since April 2026, and Sapphire Sleet's malware in the August 2026 Rust compromise was a marked improvement on its earlier work, using dynamic .NET compilation post-exploitation for defence evasion. Jasper Sleet uses AI-assisted resume workflows and tooling to keep multiple fraudulent remote-worker personas consistent. Since late October 2026, Onyx Sleet and Pearl Sleet have been running the open-source agentic penetration testing framework ARTEX in operations — the same framework behind the Storm-0940 ConnectWise campaign, now in a second nation-state's hands within weeks. Microsoft's measured conclusion is the one to carry into planning: AI is a force multiplier on existing workflows rather than a change in motivation, and these operations remain human-directed rather than autonomous. For defenders the practical consequence is that the detection surface has not changed, but the volume and polish on the social engineering side have, which makes high-volume lure regeneration a detection-maintenance problem rather than a one-off indicator exercise. (Microsoft Security Blog)

Discovery of local AI agents and their configured MCP servers reached general availability on Windows and macOS on 29 October, with coverage expanded from the twenty-plus agent types announced at Build 2026 to more than fifty supported agents and MCP servers. On eligible onboarded devices, Defender discovers supported agents by observing their activity and shows them under Assets, associating each agent with the device and user account where it runs and recording agent name, version, vendor, related process and discovery history. The named examples cover the ground most estates actually have: CLI agents including Claude Code, Codex CLI, Gemini CLI and GitHub Copilot CLI; desktop applications including ChatGPT Desktop, Claude Desktop, Microsoft Copilot and Ollama Desktop; agentic IDEs including Cursor, Devin Desktop, Kiro IDE and Antigravity IDE; VS Code extensions; and Claw-based agents such as OpenClaw, Clawpilot and QClaw. The more valuable half is the MCP context — Defender surfaces local and remote MCP server configurations associated with discovered agents, including server name, type, endpoint or the command used to start a local server, which answers what tools and services an agent can actually reach rather than merely which agent is installed. Agents and their MCP context appear in the exposure graph as a blast radius alongside devices and identities, are queryable in advanced hunting, and carry risk indicators and recommendations. Runtime protection remains in preview and only on Windows: agent-native event inspection through vendor event interfaces inspects user prompts, tool requests before execution and tool responses after, and network inspection covers supported agents without such an interface by inspecting agent-to-model flows. When Defender detects prompt injection it raises a suspicious AI prompt injection alert with agent and session context, and the policy setting takes Default, which disables protection, Audit, which detects and reports while allowing the action, or Block, which stops the action and notifies the user. Microsoft's own recommendation is a limited group in Audit for one to two weeks before moving to Block, and deployment is now possible from either the Defender portal or, in public preview, a native Intune endpoint security policy. Both discovery and runtime protection require Defender for Endpoint P2 or higher. Read this against the Cursor extension item above: discovery would have told you which workstations had the agent and which MCP servers it was wired into, which is the inventory question that incident started with. (Microsoft Defender XDR Blog)

Conditional Access policy plans arrived in public preview, documented on 26 October and carried here because no prior issue covered them. A plan groups related rules under shared assignments and conditions: plan details with a name, description, optional tags and owners recorded for accountability rather than permissions; shared conditions covering identities, resources, user actions, authentication context, risk levels, device platforms, network locations and client app types; and rules that each add their own scenario-specific conditions and grant or session controls, with at least one rule required. The security argument is the second of Microsoft's four stated benefits, and it is the one that should decide whether you pilot this. Emergency access accounts, trusted service accounts and privileged workstations appear in exclusion lists across many policies, a missed exclusion is a common cause of unintended lockout, and plan-level exclusions apply to every rule automatically and cannot be removed by an individual rule. That turns a convention your team has to remember into a control the platform enforces. The other benefits are reducing duplicated targeting across per-platform policies, scaling the hundreds of network-scoped rules a Global Secure Access deployment tends to need, and applying one shared condition such as high agent risk across separate rules for agent users and autonomous agents. Templates exist, including plans that secure agent activity, and template-generated rules are created with State set to Off deliberately; the documented path is Off, then Report-only to validate in sign-in logs, then On. Two mechanics to note before you build: you need the Conditional Access Administrator role, and the All resources assignment is available only at the rule level, not in shared conditions. (What are Microsoft Entra Conditional Access policy plans?)

Choose Your Own Telephony Provider for SMS and voice authentication is now documented as available, with the provider list updated on 30 October — the milestone a September issue of this brief flagged as due at the end of October. Microsoft Entra still manages the authentication experience including one-time passcode generation and validation; the request goes to a CYOT integration running as an Azure Function in your own subscription, which hands off to your telecom provider for delivery. Soprano is listed with per-user and per-transaction offers, and Telesign and Infobip each have an offer, all through Microsoft Security Store. Your organisation owns the Azure resources and the provider account, which means you own the availability of your own MFA delivery path — a guided deployment sets up the integration, but the Azure Function and provider account are yours to run and monitor. Microsoft's framing is unusually direct and should shape how you use this: it recommends phishing-resistant methods such as passkeys instead of SMS or voice, and says to use a telephony provider only for user populations with a business, regulatory or technical requirement for telephony-based authentication. Treat CYOT as the exception path for a scoped population rather than a way to keep the status quo, because the retirement dates behind it have not moved — Microsoft-provided SMS and voice retires on 1 February 2027 for everyone except Global Administrators and external users, with internal guest users explicitly in that February group, and on 1 July 2027 for the remainder. (Choose your own telephony provider for SMS and voice authentication)

Cloud firewall for Global Secure Access clients entered public preview, documented on 27 October, extending Allow and Block rules on outbound internet traffic by destination, port and protocol from remote networks to traffic coming from the Global Secure Access client itself. The design detail that will cause the first round of confused tickets is spelled out at the top of the page: traffic acquisition and firewall enforcement are separate layers, and creating a firewall rule does not configure the Internet Access profile to acquire that traffic. The Default Acquire policy picks up TCP on ports 80 and 443 only, so anything else — other TCP ports, any UDP — needs acquisition configured before a rule can act on it, and acquisition rules do not override traffic bypass exclusions. One more precedence rule is worth writing down before you design policy: traffic routed through Private Access takes precedence over Internet Access and is not evaluated by Internet Access cloud firewall rules at all. You need the Global Secure Access Administrator role to build the policy and the Conditional Access Administrator role to assign the security profile, which is a sensible split and also a reason to check who in your organisation holds both. (Configure cloud firewall for Global Secure Access clients (preview))

Defender for Cloud moved posture policies and recommendation exemptions into the Microsoft Defender portal in public preview on 28 October, for Azure environments. The release note covers three capabilities: visibility into posture through evaluations of Azure resources against the Defender for Cloud baseline policy, the ability to create and manage your own posture policies so evaluations match business, compliance and operational requirements, and centralised exemption management with lifecycle tracking. The third is the one that changes behaviour on shift. Exemptions are how accepted risk gets recorded, and in most estates they are created once, justified in a ticket nobody reopens, and then quietly outlive the reason for them; lifecycle tracking in the portal that also owns your recommendations is the first version of this that an analyst might actually review. Read it alongside the cloud security plan management preview from 20 October, which this brief covered last week: plan configuration, posture policy and exemptions are all migrating into the Defender portal, so if your posture governance assumes the Azure portal is authoritative, that assumption now has two expiry dates rather than one. (Microsoft Defender for Cloud release notes)

Defender for Office 365's what's new page, redated 28 October, adds a new advanced hunting table that lands at an opportune moment. CallActivityEvents contains details about activities performed during Microsoft Teams calls and meetings, populated by records from Defender for Office 365, and the schema is built for exactly the investigation the AD CS post above describes. Alongside call and activity identifiers it carries the activity type and detail, the activity initiator's UPN and display name, whether the action was performed on the initiator or another participant, the call scheduling type of Adhoc, Scheduled or Recurring, the join URL, the call type, and — most usefully for impersonation work — the initiator's account type, with possible values Entra, consumer, Azure Communication Services, Public Switched Telephone Network and Unauthenticated, plus membership type, originating tenant display name and region, and the client platform name and category. An unauthenticated or consumer-account initiator in a call with an employee, from a tenant nobody recognises, is now a queryable condition rather than something you reconstruct from a user's recollection. The same page adds the ability for users to report scheduled or Meet now Teams meetings, or individual meeting participants, as a security concern during or after the meeting, and to report a participant flagged as suspicious as not a security concern; where reported metadata goes depends on your Teams user reported settings. If your help desk impersonation playbook currently relies on a user screenshotting a chat, both of these are worth wiring in this month. (What's new in Microsoft Defender for Office 365)

A small correction to last week's Defender for Identity news, added to the what's new page as redated 28 October: activating the sensor v3.x on servers without a Defender for Endpoint deployment is temporarily not supported in government cloud environments. That is the deployment route that reached general availability for eligible domain controllers, AD FS, AD CS and Entra Connect servers on Windows Server 2019 or later, and it was the item that removed the political obstacle to identity-server coverage in estates where Defender for Endpoint on a domain controller was never going to be agreed. If you run GCC High, DoD or another sovereign environment and that GA was the trigger for a planned rollout, the plan needs a hold rather than a rewrite — the limitation is documented as temporary, and nothing changes for new v3.x deployments in commercial clouds or for existing sensors. (What's new in Microsoft Defender for Identity)

Microsoft announced on 28 October that the Sentinel connector ecosystem now exceeds 500 connectors for bringing Microsoft and third-party data into security operations, positioned as the data foundation for the Integrated Security Operations Center experience in Defender. The announcement itself is a number rather than a feature, but two things in it are actionable. If an integration with an independent software vendor does not exist, or a published one is broken, Microsoft has a dedicated team and an intake form for working with the ISV to build or fix it — which is a better escalation path than the custom ingestion pipeline most teams build after concluding a connector will never arrive. And on the other side, software vendors can use the Codeless Connector Framework and the Sentinel connector builder agent to turn API documentation into a working connector, which is the lever to pull when the vendor is willing but says it lacks the engineering time. Worth a note on your data coverage review rather than a project in itself. (Microsoft Sentinel Blog)

KQL to try

Published on 1 November and about as timely as a query gets, this is the follow-up question to the PHP2Shell advisories from last week: not which hosts are vulnerable, but which ones accepted a connection from the addresses reported as exploiting it. It declares five indicator IP addresses, reads DeviceNetworkEvents over the last thirty days, filters to ActionType InboundConnectionAccepted, and matches RemoteIP against the list. Two notes before you run it. InboundConnectionAccepted is the point of the query — an accepted inbound connection from one of these addresses on an internet-facing PHP host is an investigation, not a tuning exercise — and the thirty-day lookback deliberately reaches back before the disclosure, because the interesting answer is whether anything connected before you patched. (Successful php2Shell Indicator Scan — Steven Lim)

let IOC = dynamic([
"2.59.133.151",
"185.65.134.250",
"185.184.222.160",
"206.245.153.56",
"23.234.81.67"
]);
DeviceNetworkEvents
| where Timestamp > ago(30d)
| where ActionType == "InboundConnectionAccepted"
| where RemoteIP has_any(IOC)

From 31 October, an audit query for an action that almost nobody watches and that quietly ends endpoint telemetry for a device. It reads CloudAppEvents over thirty days for the DownloadOnboardingPkg and DownloadOffboardingPkg operations, matching either ActionType or the raw event data, then normalises the operation to Onboarding or Offboarding, pulls the deployment method and operating system family out of RawEventData, and projects the account display name and object ID, the IP address and the raw event. The author is careful about what it proves and so should you be: it detects download events only, and does not establish that a package was run or that a device was offboarded. The reason to schedule it anyway is that running an offboarding package stops a device sending new detection, vulnerability and security data to Defender for Endpoint — which makes an unexpected offboarding package download a credible defence evasion lead and an expected one a change request you can tie it to. (MDE Onboarding and Offboarding Package Downloads — Alex Verboon)

let Lookback = 30d;
let PackageOperations = dynamic([
    "DownloadOnboardingPkg",
    "DownloadOffboardingPkg"
]);
CloudAppEvents
| where Timestamp > ago(Lookback)
| where ActionType in (PackageOperations)
    or RawEventData has_any (PackageOperations)
| extend Info = parse_json(RawEventData)
| extend
    Operation = case(
        ActionType == "DownloadOnboardingPkg", "Onboarding",
        ActionType == "DownloadOffboardingPkg", "Offboarding",
        tostring(RawEventData) contains "DownloadOnboardingPkg", "Onboarding",
        tostring(RawEventData) contains "DownloadOffboardingPkg", "Offboarding",
        "Unknown"
    ),
    DeploymentMethod = tostring(Info.DeploymentMethod),
    OsFamily = tostring(Info.OsFamily)
| project
    Timestamp,
    Operation,
    AccountDisplayName,
    AccountObjectId,
    IPAddress,
    DeploymentMethod,
    OsFamily,
    ActionType,
    RawEventData
| order by Timestamp desc

Worth knowing

Microsoft published a CISO-perspective piece on 28 October to close Cybersecurity Awareness Month, and the one number in it is the one to quote in a planning meeting: active agents in the Microsoft 365 ecosystem grew fifteen-fold year over year, and eighteen-fold in large enterprises. The argument is that the people building with AI inside your organisation increasingly have not written code in years, which is not a criticism so much as a description of who now creates things that can reach company data and act on it. The guidance for builders is short enough to put in an internal wiki — give agents their own governed identities rather than personal or shared credentials so you can tell which agent did what and switch it off, protect the data before you connect it, and have the identity and data conversation with your security team before you build rather than after. For security leaders the framing is two jobs: put guardrails up so people can build without unmanaged risk, starting with deep observability of which agents exist, who owns them, what they can reach and when their behaviour changes; and defend differently, which it argues is less about faster tools than about integrating signals across identity, endpoints, applications and cloud with threat intelligence so an attack that shows up in pieces can be understood as one thing. (Microsoft Security Blog)

On 29 October the Entra team pointed at new Secure Future Initiative guidance for securing identity ahead of AI adoption, and the sequencing is the useful part rather than the principles, which will be familiar. Do three things in order: move users and administrators to phishing-resistant multifactor authentication, protecting privileged accounts first by requiring MFA for every administrator and moving them to device-bound passkeys or FIDO2 keys before planning a workforce rollout; eliminate standing privileges by running Privileged Identity Management discovery and converting static role assignments to eligible, time-bound activations that require justification and MFA, with guest access governed through expiring access packages; and then apply policy coverage across every identity and resource, applying Conditional Access broadly, blocking legacy authentication, requiring device compliance, and enabling ID Protection to enforce MFA at medium risk and credential reset at high risk. The closing instruction is the one with a SOC dependency — maintain continuous coverage by exporting logs to Sentinel or Azure Monitor, alerting on privileged role activations and running recurring access reviews. The argument for doing this now rather than after the agent work is that agent identities inherit whatever least privilege and policy coverage you already have, so a weak baseline gets copied rather than fixed. (Microsoft Entra Blog)

Two days earlier, on 27 October, the Entra team made the companion argument about where identity controls stop. The premise is that a successful sign-in is not the end of the access decision: sessions can be hijacked, device posture can degrade mid-session, and traffic to non-federated SaaS and AI services often bypasses identity controls entirely because those policies were never designed to see it. The proposed architecture is Conditional Access as a single engine evaluating identity alongside device compliance, location and trusted network; Global Secure Access, through Internet Access and Private Access, as the enforcement point that applies those controls to internet destinations and SaaS apps including unfederated ones; and continuous access evaluation so a session can be revoked the moment a user is disabled or risk rises rather than at the next token refresh. The practical starting point the post offers is a good one for a quiet week: review where your current access policies end, add device compliance and location conditions where they are missing, extend them to internet and private app traffic, and turn on continuous access evaluation. (Microsoft Entra Blog)