One compromised identity. Source code access. Pipeline credentials. Production Kubernetes. Microsoft DART’s Storm-3068 case study published yesterday reads like a textbook on identity blast radius - and it started with a self-service password reset. That case sits alongside Microsoft hardening Entra ID against script injection in October, a destructive 18-hour service principal attack from JADEPUFFER, and a growing consensus that persistent AI coworkers need the same identity governance humans get. Today’s brief covers all four.

In the News

Microsoft Blocks Entra ID Script Injection Attacks Starting October

Microsoft announced that Entra ID will restrict external script injection in authentication flows beginning in October 2026. The hardening targets a class of attacks where malicious scripts injected into customized authentication pages could manipulate token issuance, alter redirect URIs, or intercept credentials during the authentication handshake.

The change is significant for organizations running custom Entra ID integrations - particularly those with federated authentication flows, custom branding pages, or inline JavaScript in authentication templates. Any integration relying on script-based behavior in authentication pages needs testing against the preview environment before enforcement begins.

For identity teams, this is a welcome default-secure improvement. For operations teams, it is a potential breakage point. The recommended action is to audit custom Entra ID authentication configurations now, identify any inline script dependencies, and test against the October preview. Organizations still relying on script-based customization in authentication flows should accelerate their move to phishing-resistant authentication methods (FIDO2/passkeys) that do not depend on customizable authentication pages.

What defenders should do: Audit Entra ID custom authentication configurations for inline script dependencies. Test against the October preview. Accelerate adoption of phishing-resistant authentication (FIDO2) to reduce reliance on customizable authentication flows.

Source: BleepingComputer

Storm-3068 Pivoted from Password Reset to Azure DevOps and Kubernetes

Microsoft DART published a detailed case study tracking Storm-3068 from initial access - a single compromised identity obtained through a self-service password reset - through Azure DevOps repositories, CI/CD pipelines, and into production Kubernetes clusters. The attack chain exploited no zero-days. It exploited trust.

The compromised user account had access to source code repositories. Those repositories contained pipeline configuration files with embedded service connection credentials. Those service connections had permissions to deploy into Kubernetes namespaces. Storm-3068 followed the chain systematically: identity to code, code to pipeline secrets, pipeline secrets to production infrastructure.

This is the identity blast radius problem stated plainly. A self-service password reset - a feature designed for user convenience - became the initial access vector for a path that ended in production Kubernetes. The case demonstrates why identity-to-infrastructure trust chains must be mapped, why pipeline secrets must be vaulted rather than embedded in repository configurations, and why self-service password resets should require phishing-resistant re-authentication (FIDO2), not just email verification.

What defenders should do: Map identity blast radius - what can each developer identity reach through transitive trust (repos → pipelines → infrastructure)? Vault pipeline secrets. Require FIDO2 re-authentication for self-service password resets. Deploy ITDR to detect anomalous access patterns across the identity-to-infrastructure chain.

Source: Microsoft Security Blog

Persistent AI Coworkers Need Their Own Identity Lifecycle

Token Security published analysis arguing that persistent AI coworkers - unlike ephemeral AI agents that spin up for a task and terminate - operate with standing access, persistent sessions, and broad permissions that do not expire between tasks. The security model that worked for short-lived agent sessions (scoped tokens, ephemeral credentials, session-bound permissions) breaks when the AI entity is always on.

The parallel to unmanaged service accounts is exact. A decade ago, organizations created service accounts with broad standing permissions, no owner, and no access review cycle. The same pattern is emerging with AI coworkers: persistent identities with access to internal systems, no clear ownership, and no deprovisioning process when the AI tool is retired or reconfigured.

The recommended controls are identical to NHI governance best practices: assign an owner to every AI coworker identity, scope permissions to least privilege, rotate credentials on a defined cycle, and include AI identities in access review campaigns. The operational difference is that AI coworkers may autonomously request access to new resources - making behavioral monitoring and anomaly detection essential controls that did not apply to traditional service accounts.

What defenders should do: Inventory persistent AI coworker identities. Assign human owners. Scope permissions to least privilege. Include AI identities in access review cycles. Deploy identity behavioral analytics to detect anomalous access expansion.

Source: BleepingComputer

JADEPUFFER Deleted Azure Resources Using Compromised Service Principals

JADEPUFFER (Storm-3168) compromised Azure service principals with standing contributor-level access and executed an 18-hour destructive operation in June, systematically deleting cloud resources. Microsoft describes this as an evolution in the actor’s tradecraft - shifting from data exfiltration to resource destruction for maximum operational disruption.

The attack surface was standing service principal permissions. The service principals had contributor-level access that had not been scoped to least privilege, and no anomaly detection was in place to flag bulk-deletion operations from identities that historically performed only read or deploy actions. The 18-hour window suggests the organization did not detect the activity until significant damage was done.

This case reinforces two controls: NHI permission scoping (service principals should have the minimum permissions required, not blanket contributor access) and behavioral detection on non-human identities (a service principal suddenly issuing hundreds of delete calls is a high-fidelity signal). Immutable backups are the compensating control when the attacker’s objective is destruction rather than exfiltration.

What defenders should do: Audit service principal permissions for excessive standing access. Deploy identity behavioral analytics on non-human identities. Ensure immutable backups cover cloud resource configurations (Infrastructure-as-Code state files, resource group snapshots).

Source: The Hacker News

Defender Action Items

  • Entra ID: Audit custom authentication configurations for inline script dependencies before October enforcement. Test against the preview environment now.
  • Identity blast radius: Map developer identity access chains - repos → pipeline credentials → production infrastructure. Vault pipeline secrets. Require FIDO2 re-authentication for self-service password resets.
  • NHI governance: Inventory service principals and AI coworker identities. Scope to least privilege. Assign human owners. Include in access review cycles.
  • Service principal monitoring: Deploy behavioral detection for anomalous bulk-deletion operations from non-human identities. Correlate with immutable backup status.
  • MCP SDK: If running AI agent apps using the MCP Python SDK, upgrade to 1.30.0+ immediately - prior versions exposed OAuth credentials to malicious MCP servers.

Detection Queries

Service principal deletion activity in Azure - detecting bulk resource deletion from non-human identities, which is the technique JADEPUFFER used in its 18-hour destructive operation:

1// KQL — Azure Activity Logs
2// Detects service principals issuing 10+ delete operations in a 1-hour window
3AzureActivity
4| where TimeGenerated > ago(24h)
5| where OperationNameValue has "delete"
6| where Identity has_any ("ServicePrincipal", "ManagedIdentity")
7| summarize DeleteCount = count(), ResourcesDeleted = make_set(ResourceId) by CallerIpAddress, Caller, bin(TimeGenerated, 1h)
8| where DeleteCount >= 10
9| sort by DeleteCount desc

Tune the threshold based on your environment - CI/CD pipelines that tear down test environments will generate legitimate delete operations. Correlate with the Caller field to identify which service principal is issuing the calls, and verify whether that identity has historically performed delete operations at that volume.

References

Subscribe to The Identity Brief

Get The Identity Brief in your inbox (Mon/Wed/Fri) - Human, machine, and AI identity security — NHI, ITDR, and the IAM market.