Agent Foskett Case File • Azure • Managed Identities • Microsoft Entra • KQL
The Managed Identity Had No Password — So How Was It Misused?
The automation ran every night. The identity had no password to steal, no certificate to expire, and no secret stored in a configuration file.
Then it accessed a storage account that was never part of its job.
“Agent Foskett, the identity doesn’t have a password.”
“Excellent. Does it have permissions?”
“Quite a few.”
Agent Foskett closed his notebook. “Ah. So we’ve eliminated the one thing nobody needed to steal.”
Case file: No password does not mean no risk
A fictional, evidence-led Azure investigation of workload compromise, token access, excessive role assignments and unexpected storage activity.
✓ Identify the managed identity and its hosting workload
✓ Examine role assignments and sign-in evidence
✓ Correlate resource access with actual permissions
The alert that did not fit the job
At 02:17 UTC, monitoring flagged unusual reads against a sensitive Azure Storage account. The requests were attributed to a managed identity normally used by an Azure automation workload. That workload was supposed to process nightly inventory metadata in a different resource group.
The security team asked an understandable question: if nobody knew a password, how could the identity be abused? This is a fictional investigation; names, timestamps and sample resources are illustrative. The technical distinction matters: Azure managed identities obtain Microsoft Entra access tokens through the hosting Azure resource. A compromised or misconfigured workload can sometimes request and use tokens as the identity without possessing a reusable password or secret.
The security team asked an understandable question: if nobody knew a password, how could the identity be abused? This is a fictional investigation; names, timestamps and sample resources are illustrative. The technical distinction matters: Azure managed identities obtain Microsoft Entra access tokens through the hosting Azure resource. A compromised or misconfigured workload can sometimes request and use tokens as the identity without possessing a reusable password or secret.
Expected behaviourA scheduled Azure workload reads inventory metadata from an approved storage account.
Observed anomalyThe same identity is associated with access to a sensitive storage account outside its normal scope.
Unproven hypothesisAn attacker may have obtained code execution or another token-request capability on the hosting workload.
What a managed identity actually protects
A system-assigned or user-assigned managed identity removes the need to store application credentials. Azure manages the underlying credential lifecycle and exposes a token-acquisition mechanism to authorised workloads. That substantially reduces secret-management risk.
It does not prevent misuse if an attacker controls a process that can request tokens from the resource’s identity endpoint, or if an application exposes an unsafe proxy to that capability. Nor does it restrict what a legitimately obtained token can do beyond the identity’s assigned permissions. The exact token endpoint and safeguards depend on the Azure hosting service; do not assume every service uses the same endpoint or exposure model.
It does not prevent misuse if an attacker controls a process that can request tokens from the resource’s identity endpoint, or if an application exposes an unsafe proxy to that capability. Nor does it restrict what a legitimately obtained token can do beyond the identity’s assigned permissions. The exact token endpoint and safeguards depend on the Azure hosting service; do not assume every service uses the same endpoint or exposure model.
First, establish identity and scope
Record the managed identity’s principal/object ID, client ID, resource association, tenant and subscription. For user-assigned identities, identify every Azure resource to which the identity is attached. Capture role assignments at management-group, subscription, resource-group and resource scope, including inherited permissions. Check Azure RBAC data-plane roles separately from management-plane roles, and examine any service-specific access mechanisms.
For this case, the investigation found that the automation identity had a data access role assigned at a resource-group scope broader than required. That was a plausible path to the sensitive storage account, but the role assignment alone did not establish that an attacker had acted.
For this case, the investigation found that the automation identity had a data access role assigned at a resource-group scope broader than required. That was a plausible path to the sensitive storage account, but the role assignment alone did not establish that an attacker had acted.
Investigate Azure management-plane changes
In Microsoft Sentinel or Log Analytics, the
AzureActivity table can reveal Azure Resource Manager operations when the relevant Azure Activity Logs are ingested. The query below focuses on role assignment changes. It does not prove a storage blob was read, and it will not reveal every data-plane operation.- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
// Microsoft Sentinel / Log Analytics: AzureActivity must be ingested
AzureActivity
| where TimeGenerated > ago(14d)
| where OperationNameValue has_any (
"Microsoft.Authorization/roleAssignments/write",
"Microsoft.Authorization/roleAssignments/delete")
| project TimeGenerated, OperationNameValue, ActivityStatusValue,
Caller, ResourceGroup, ResourceId, CorrelationId
| order by TimeGenerated descReview workload identity sign-in activity
Microsoft Entra workload identity sign-in records can help establish when a managed identity obtained tokens and which resources were involved. In Sentinel,
AADManagedIdentitySignInLogs is available only when the corresponding Entra diagnostic logs are configured and ingested. Field availability and completeness vary; verify the workspace schema before running the query. These sign-ins show authentication activity, not a definitive list of every data operation performed with the resulting tokens.- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
// Microsoft Sentinel / Log Analytics
// Requires ingestion of managed identity sign-in logs
AADManagedIdentitySignInLogs
| where TimeGenerated > ago(7d)
| project TimeGenerated, ServicePrincipalId, ServicePrincipalName,
ResourceDisplayName, IPAddress, ResultType, CorrelationId
| order by TimeGenerated ascPivot to the hosting resource
A managed identity is attached to a compute or Azure service context. Investigate that context: deployment changes, extensions, application code, automation runbooks, function updates, container images, exposed endpoints and permissions to invoke or modify the workload.
Look for a change shortly before the first unexpected token use. For example, an attacker who gains remote code execution in a vulnerable app might be able to request a token through that app’s managed identity. That is a possible mechanism, not something an identity sign-in log alone proves. Validate the suspected entry point using service-specific diagnostic logs, deployment history, Defender for Cloud alerts and application telemetry.
Look for a change shortly before the first unexpected token use. For example, an attacker who gains remote code execution in a vulnerable app might be able to request a token through that app’s managed identity. That is a possible mechanism, not something an identity sign-in log alone proves. Validate the suspected entry point using service-specific diagnostic logs, deployment history, Defender for Cloud alerts and application telemetry.
Check the storage data-plane evidence
If Azure Storage diagnostic logging was enabled and routed to a Log Analytics workspace, resource-specific tables such as
StorageBlobLogs can record blob operations. Schema, logging configuration and retention must be verified. This query looks for reads in a fictional sensitive storage account. A 200 response indicates a successful request at that layer, but interpretation still requires the request context, identity, object and surrounding activity.- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
// Log Analytics: Azure Storage resource-specific diagnostic logs required
let TargetAccount = "sensitivearchive";
StorageBlobLogs
| where TimeGenerated > ago(7d)
| where AccountName =~ TargetAccount
| where OperationName in ("GetBlob", "GetBlobProperties", "ListBlobs")
| project TimeGenerated, AccountName, OperationName,
AuthenticationType, RequesterObjectId, StatusCode,
Uri, CallerIpAddress, CorrelationId
| order by TimeGenerated ascCorrelate the identity with actual access
Compare the managed identity object ID with
For this fictional case, the strongest evidence was a sequence of successful storage reads attributed to the identity’s object ID during a period when the automation workload had been unexpectedly modified. Investigators still needed host and application evidence to establish who caused those requests.
RequesterObjectId in storage diagnostics where populated. Align UTC timestamps, destination resources, source IPs and correlation identifiers, while recognising that correlation IDs from different services may not match. If a field is absent, do not infer that a request was anonymous or that the identity was uninvolved.For this fictional case, the strongest evidence was a sequence of successful storage reads attributed to the identity’s object ID during a period when the automation workload had been unexpectedly modified. Investigators still needed host and application evidence to establish who caused those requests.
Was the identity overprivileged?
A key finding was that the identity’s storage permissions covered more resources than its documented task required. An identity with narrow, resource-scoped data-plane permissions would have had less opportunity to access the sensitive account, even if its hosting workload were compromised.
Review direct and inherited role assignments, group membership where relevant, user-assigned identity attachment rights and privileged permissions that could alter the environment. Remember that changing Azure RBAC assignments and revoking access tokens have different propagation and lifetime considerations; containment should not rely on a single assumed instantaneous effect.
Review direct and inherited role assignments, group membership where relevant, user-assigned identity attachment rights and privileged permissions that could alter the environment. Remember that changing Azure RBAC assignments and revoking access tokens have different propagation and lifetime considerations; containment should not rely on a single assumed instantaneous effect.
The evidence timeline
The following timeline is illustrative and designed to show how the analyst separates observations from hypotheses.
01:42 UTC — Workload changeA deployment or automation change is recorded against the hosting resource; authorisation remains under review.
02:06 UTC — Token activityManaged identity sign-in telemetry records access to an Azure resource.
02:17 UTC — Unexpected storage readsStorage diagnostic logs show reads against a resource outside the automation’s documented task.
02:24 UTC — Security alertAnomaly detection triggers an investigation of the identity and storage account.
02:43 UTC — Permissions reviewedAnalysts identify a data-plane role assignment with broader-than-needed scope.
03:10 UTC — Containment plannedThe team coordinates workload isolation, role-scope reduction and evidence preservation.
Containment without destroying the evidence
Preserve logs, deployment artefacts, workload configuration and relevant forensic material before making changes where safe. If compromise is credible, restrict the affected workload’s ability to execute or request tokens, remove unnecessary identity assignments or access, and remediate the suspected entry point. Review all resources to which a user-assigned identity is attached.
Investigate downstream access and any copied or modified data. Test containment rather than assuming that a role change immediately invalidates every already-issued token. Restore from a known-good deployment, validate least-privilege access and add alerting for unusual resource access by workload identities.
Investigate downstream access and any copied or modified data. Test containment rather than assuming that a role change immediately invalidates every already-issued token. Restore from a known-good deployment, validate least-privilege access and add alerting for unusual resource access by workload identities.
Practical defensive lessons
Managed identities are preferable to embedded secrets for many Azure workloads, but they still require ownership, least privilege and monitoring. Scope permissions to the minimum necessary resources, protect token-access pathways in the hosting service, secure deployment pipelines, audit workload changes and ingest appropriate identity and resource diagnostics.
When investigating a managed identity, ask three separate questions: who could execute the workload, what tokens could it request, and what could those tokens access? Each requires its own evidence.
When investigating a managed identity, ask three separate questions: who could execute the workload, what tokens could it request, and what could those tokens access? Each requires its own evidence.
Agent Foskett closes the case
“So the managed identity had no password?”
“Correct.”
“And that made it secure?”
Agent Foskett looked at the role assignments.
“It made one attack path harder. Unfortunately, someone left the rest of the building unlocked.”
The Logs Already Knew!
“Correct.”
“And that made it secure?”
Agent Foskett looked at the role assignments.
“It made one attack path harder. Unfortunately, someone left the rest of the building unlocked.”
The Logs Already Knew!
Related investigations
The Certificate Was Valid — But Nobody Knew Who Was Using ItExplore workload identity credentials, permissions and authentication evidence.The Teams Message Came From a Colleague — But the Link Didn't Belong ThereTrace suspicious links, trusted identities and follow-on activity.Agent Foskett Investigation LibraryBrowse more evidence-led Microsoft security case files.
