Home› Blog› Azure Weekly Intelligence #7 - 21-25 September 202…
Azure Weekly Intelligence Azure

Azure Weekly Intelligence #7 — 21–25 September 2026

A quiet week for announcements and a loud one for incident reports. Ten Azure updates, four of them retirements with dates attached — and two Microsoft security write-ups that read like field evidence for arguments this series has been making all month.

Verified against current vendor documentation on 26 September 2026. Pricing, limits and API behaviour were checked against the official docs on that date. Cloud services change fast — if you are reading this much later, treat the specifics as a starting point and re-check the linked sources.
Azure Weekly Intelligence · #7 · 21–25 September 2026

The week in one paragraph

Ten announcements on the Azure Updates feed across five working days, and four of them were retirements — PowerShell 7.4, .NET 8 and .NET 9, Node.js 22, and Azure Communication Services standalone. Two Container Apps features reached general availability, AKS picked up a preview compute option, and the rest was steady. The genuinely important reading was published by the Microsoft Security team rather than the product groups: two incident write-ups, one on compromised service principals and one on device code phishing, both of which describe attacks that the controls covered in this series' last ten posts are specifically for.

Two incident reports that read like footnotes to this series

Normally the security section of a roundup is advisories and CVEs. This week it is the lead, because both write-ups describe attacks on the exact mechanisms recently covered here — and both are more specific about consequences than any documentation page is willing to be.

Storm-3168: a secret in a GitHub issue, and eight hours later the storage accounts are gone

Microsoft tracks this as Storm-3168, and its designation is worth quoting because of what it claims: JADEPUFFER, the first documented agentic ransomware operation, discovered by Sysdig in July 2026.

The initial access is the part to sit with. Its client ID, client secret, and tenant ID had previously been exposed in plaintext in a public GitHub issue by an employee of the impacted organization. Not a breach, not a zero-day — a service principal's three-part credential pasted into a public issue, presumably while asking for help.

What followed is a timeline worth reading as a clock:

PhaseWhat happened
Reconnaissance, ~15.5 hours One service principal enumerated Azure Virtual Machines, subscriptions, resource groups and resources … with 300+ successful read operations
Second pass, 90 minutes later A second principal enumerated virtual machines and resource groups across two subscriptions in five seconds
Destruction, 7 minutes 100+ storage account deletion attempts; most Azure Storage accounts targeted by the threat actor were successfully deleted
Credential collection, 30 minutes later 30+ successful ListKeys requests, asking ARM to return each storage account's access keys

Five seconds to enumerate two subscriptions. Seven minutes to attempt a hundred deletions. That is the "agentic" part, and it is the operationally important one: the window between detection and irreversible damage is now shorter than a human response loop.

The authorisation detail is the one that should change a review. Nothing was escalated: the operations followed the identity's existing Azure role assignments. A group-granted Storage Account Contributor role authorized the destructive storage operations. Direct Contributor access authorized the three application-resource deletions. The blast radius was exactly what someone had already granted, sitting unexercised until it wasn't.

And the actor went for the recovery path too — multiple unsuccessful deletion attempts were also made against Azure Site Recovery locks and Azure Backup protection locks protecting storage accounts. The locks held. That is the single most encouraging sentence in the report, and it is an argument for the management-lock material from earlier in this series being more than hygiene.

The mitigation Microsoft leads with is the one people find hardest to believe: treat credentials that have been publicly exposed as compromised, even if the original location has subsequently been edited or deleted. Removing the content does not invalidate the credential. Editing the GitHub issue does nothing. Rotation is the only action that means anything.

What this series said about exactly this

Post #37 covered workload identity federation, whose entire pitch is that no application secret or certificate has to be stored or rotated — a credential that does not exist cannot be pasted into a GitHub issue. Post #42 noted that calls made by service principals aren't blocked by Conditional Access policies scoped to users, so a tenant-wide block policy would not have touched this actor. And the standing advice from #35 onward: if your organization uses service accounts in scripts or code, replace them with managed identities.

None of that is hindsight. It is the documented reason those features exist, and this is what the failure mode looks like when they are not used.

EvilTokens: 12,000 inboxes, and the flow is working as designed

The second report covers device code phishing, and the scale is the headline: following its emergence in February 2026, the campaign compromised more than 12,000 inboxes in over 10,000 organizations worldwide, concentrated in the United States, Canada, the United Kingdom, Australia, India, and France.

The mechanism deserves care, because nothing is broken. The OAuth device authorization grant exists for devices with no keyboard — you get a code, type it somewhere else, and the first device receives a token. Device code phishing occurs when threat actors insert themselves into this process. Instead of a legitimate device requesting access, the threat actor initiates the flow and provides the user with a code through a phishing lure.

The attacker's page interacts with the Microsoft identity provider in real time to generate a live device code, shows it to the victim, and sends them to the genuine microsoft.com/devicelogin. Meanwhile, every three to five seconds … the script pings the threat actor's /state endpoint waiting for the token to arrive. The victim signs in at a real Microsoft page, completes real MFA, and hands a token to a session they never saw.

Why MFA does not help is stated in one clause: because authentication is completed on a separate device, the session initiating the request is not strongly bound to the user's original context. Every individual step is legitimate. The binding between the person authenticating and the session receiving the token is what is missing — which is precisely the property #44 described as verifier impersonation resistance, and precisely what a passkey provides and a code does not.

The consequences escalate past the mailbox: the tokens give full access to the victim email account, and the actor can register a device to obtain a Primary Refresh Token (PRT) for long-term persistence. That is post #40's refresh-token scenario in the wild — the durable credential, not the one-hour access token, is the prize.

Microsoft's first recommendation is blunt and structural: Microsoft recommends blocking device code flow wherever possible, and where Teams hardware needs it, scope the exception to specific Teams device resource accounts. That control appeared in this series already — Restrict device code flow is a named Conditional Access policy in the phase 3 deployment table from #41a, requiring only Entra ID P1. It has been sitting in the recommended baseline the whole time.

Four retirements, and two of them land on the same day

Four of the week's ten announcements were retirements. Two share a date, which makes 10 November 2026 a day worth putting in a calendar now.

EndsWhatAnnounced
10 Nov 2026Support for .NET 8 and .NET 9 — upgrade to .NET 1023 Sep
10 Nov 2026Support for PowerShell 7.423 Sep
30 Apr 2027Support for Node.js 2222 Sep
30 Sep 2028Azure Communication Services standalone services24 Sep

The .NET one is the broad one, because .NET 8 is a long-term-support release and a great many Functions and App Service workloads are still on it. Six weeks of notice for a runtime upgrade is tight if the app has any dependency surface, and the announcement names the destination rather than leaving it open: .NET 10.

The Communication Services retirement is two years out, which reads generous until you notice it is the standalone services being retired rather than a version. That is a product-shape change, and those take longer to absorb than a runtime bump.

Container Apps shipped two GAs; AKS got another compute layer

The week's substantive product news was all in the container space, and it arrived through the Apps on Azure blog rather than the updates feed.

  • Azure Container Apps Express reached general availability (23 Sep).
  • Azure Container Apps Sandboxes reached general availability the same day — a notable pairing, and the sandbox framing is worth watching given how much of this week's AI tooling assumes untrusted code execution.
  • Flex Nodes for AKS entered public preview (22 Sep).
  • Virtual nodes on Azure Container Instances were described as a new compute layer for AKS (21 Sep).

Two new ways to attach compute to AKS announced in the same week is a lot of surface. Neither is a replacement for node pools; both are options for bursting without managing the machines. Worth reading together rather than separately if you are sizing a cluster this quarter.

The rest, briefly

  • Azure HorizonDB supports PostgreSQL 18 (preview, 25 Sep) — the newest PostgreSQL major on a managed service, unusually quickly.
  • Instant Access for VM restore points reached GA (24 Sep). Restore-time improvements rarely make headlines and always matter on the day they are needed.
  • Azure Functions support for PowerShell 7.6 went GA (21 Sep) — note the timing against the 7.4 retirement two days later.
  • Azure Sphere OS 26.09 shipped (21 Sep).
  • A guided Copilot experience for building Azure apps in VS Code entered preview (21 Sep).
  • Terraform AzureRM v5.7.0 released (24 Sep), and the AKS 2026-09-04 release notes landed on 21 Sep.

What I would act on

  1. Search your repositories and issue trackers for service principal credentials, then rotate whatever you find regardless of whether you delete it. This is the Storm-3168 lesson stated as an action: removing the content does not invalidate the credential. An edited GitHub issue is still a leaked secret.
  2. Block device code flow tenant-wide, and scope an exception to Teams device accounts if you have shared hardware. The policy already exists in Microsoft's own baseline, it needs only P1, and 12,000 inboxes across 10,000 organisations is the cost of not having it.
  3. Review what your service principals can actually delete. Storm-3168 escalated nothing — a group-granted Storage Account Contributor did the damage. Microsoft's own mitigation is to review the Azure RBAC permissions assigned to service principals and restrict their privileges to the resources and operations required.
  4. Put 10 November 2026 in the calendar with .NET 8, .NET 9 and PowerShell 7.4 against it. Two runtimes, one date, six weeks of notice.
  5. Check that your backup and recovery resources carry locks, and that someone is alerted when a lock is touched. The locks were attacked in this incident and they held. Microsoft's framing: protect backup and recovery infrastructure as part of ransomware resilience.

Complete inventory — all 15

Ten announcements from the Azure Updates feed, plus five product and release items from Microsoft's engineering blogs and release feeds, across 21–25 September 2026. Built from a fresh fetch on Saturday morning across 44 feeds.

Feed health, for the record. The audit run covered 44 sources. Five reported stale — Identity (devblog), TC Network Security, TC FastTrack, TC MySQL and TC Defender for Cloud — and none of them carried items in this window, so nothing is missing on their account. Four sources have no feed and are checked by hand: the AKS Tech Community blog, Azure VMware Solution, Microsoft Fabric, and Ignite/Build announcements. No MSRC Azure CVEs fell inside the window.

Looking for one service rather than a whole week?

Every AWS, Azure and Google Cloud announcement is browsable by service and date, each linked to the vendor’s own page — and the other weekly roundups are collected in one place.

Browse announcements →

Comments

How was your experience?
Your feedback helps improve this site.
PoorExcellent