Executive summary
Microsoft reported on 5 November 2026 that threat actors were using agentic offensive tools to find secrets in public GitHub repositories and then act on them. The exposed material included application credentials and keys for cloud and AI services. In one observed case, an agent moved from searching for client secrets to taking data from Azure Key Vault in five minutes. That is one observed progression, not a representative compromise time for all exposed secrets. Microsoft's investigation
The underlying failure is familiar: a usable credential becomes public while its identity retains access. Automation reduces the manual work between discovery and abuse. TIR assessment — likely (B2): an exposed application secret should trigger investigation of the application's permissions and activity, alongside revocation or rotation. Deleting the file or commit does not establish that the credential was never copied or used.
What the report actually links
Microsoft places the observed public-repository searching as early as August 2026. It separately describes follow-on application-credential abuse beginning as early as 28 October. Some cases involved a vendor-owned multitenant application's credential being compromised at its source and then used against downstream tenants. The report also covers activity associated with other addresses and cloud reconnaissance. Those observations are not proof that every exposed secret or affected tenant followed one identical chain. Microsoft
A service principal is the identity an application uses to act within its authorised scope. Microsoft observed successful service-principal sign-ins across multiple application identities and tenants, followed by cloud discovery and attempts to retrieve sensitive resources. The available permissions determine what a stolen credential can reach; possession of one application secret does not automatically confer control of every resource in an organisation.
The report describes access to storage-account keys, application settings and other credential-bearing resources. In some environments, compromised applications accessed documents, mailbox content or Azure Key Vault secrets. It also reports use of virtual-machine command functionality. These are observations across cases. They should guide scoping without being represented as actions completed in every victim. Microsoft
Why removing the disclosure is insufficient
Microsoft explicitly distinguishes removing a secret from source code from making that secret unusable. An attacker can retain authentication material after the public copy disappears. Recovery therefore has two related tasks: remove the disclosure path and invalidate the exposed authentication material. The report recommends reviewing affected applications for credentials added by the attacker, rather than rotating only the original secret and assuming access has ended. Microsoft
There is a further timing limit. Microsoft notes that tokens already issued can remain valid until expiry. Removing an application credential is not an assurance of immediate termination of every existing token. Incident responders need to understand which identity was used, its grants, the relevant token behaviour and any additional credentials created during the intrusion. A successful rotation is one recovery event, not the complete incident timeline.
Investigation priorities
The following sequence is TIR's defensive interpretation of Microsoft's observations:
- Identify the exposed credential and the application or service identity it belongs to. Establish the earliest public exposure the available evidence supports, while recognising that search history and retention can leave gaps.
- Preserve the relevant identity, application and resource logs before making changes that could obscure the sequence. Check both successful and failed access: a failure followed by success can be more informative than either event alone.
- Revoke or rotate exposed authentication material and inspect credentials, certificates and federated access on the affected application. If necessary, disable the service principal while the incident is scoped.
- Determine what the identity could read and what it actually accessed. Rotate further secrets exposed through those resources, with scope based on the investigation rather than a blanket claim that every secret was stolen.
- For a vendor-owned application, coordinate the investigation across the application owner and affected customers. A customer's local controls may not fix the compromised credential at the vendor.
This sequence does not replace product-specific containment guidance. Microsoft's workload-identity Conditional Access recommendation has particular coverage and licensing limits: the report says it covers single-tenant applications registered in the tenant and requires the relevant premium workload-identity licence. It should not be presented as a universal fix for compromised multitenant vendor applications. Microsoft
Detection opportunities
Useful records include service-principal and non-interactive sign-ins, application and directory audit events, Azure Activity, and relevant Key Vault, storage, development-platform and Microsoft 365 audit data. Their availability depends on configuration and retention. Absence of an event in an unconfigured or expired log does not establish absence of access.
Illustrative leads include one source authenticating to several application identities, a short sequence of token requests across different services, and credential reads followed by access to additional identities or resources. These behaviours need comparison with deployment pipelines and legitimate administration. Microsoft also provides specific addresses, but warns that one is a Tor exit node that can carry unrelated activity. Matching a shared address is an investigation lead, not sufficient actor attribution. Microsoft
Reducing repeat exposure
Microsoft recommends secret scanning, protection against committing supported secrets and moving away from long-lived secrets where suitable managed identities are available. Scanning should consider exposure outside repositories the organisation directly owns. These measures reduce disclosure risk; they do not retrospectively prove that an already leaked credential was unused.
The current evidence supports a faster credential-abuse workflow, not a claim that AI created a new authentication vulnerability. It also does not establish a general five-minute response deadline. The durable priorities are smaller application permissions, fewer reusable secrets, usable audit records and recovery that addresses both the original disclosure and subsequent identity changes.
