ACSC Logo
© GEMXIT
GEMXIT Logo
Agent Foskett Case File • Microsoft Azure • Managed Identities • Key Vault • AzureActivity • KQL

Key Vault Was Still Trusting an Identity — The VM Was Already Gone

The virtual machine had been deleted.

Its workload was supposed to be gone with it.

But while reviewing Key Vault access, Agent Foskett found an identity that appeared to belong to the old system.

The compute resource was gone.
The identity trail was not.

Was this simply historical telemetry?
A surviving user-assigned managed identity?
Or an authorization path nobody had cleaned up?

Discuss Microsoft SecurityBack to investigations
Agent Foskett investigating Azure Key Vault access involving a managed identity after a virtual machine was deleted
The Resource Was Gone. The Authorization Story Needed Rebuilding.

System-assigned and user-assigned managed identities have different lifecycles. Before calling an identity orphaned, Agent Foskett had to establish exactly which type existed and what Azure still knew about it.

✓ Identify the principal
✓ Reconstruct the deleted resource
✓ Verify the remaining authorization path

The first assumption could have ruined the investigation

A system-assigned managed identity is tied to the lifecycle of its Azure resource. Delete the resource and that identity is deleted with it.

A user-assigned managed identity is different. It exists as its own Azure resource and can survive after a VM using it has been removed.

So Agent Foskett did not begin by calling the identity orphaned.

He began by identifying exactly what kind of principal the evidence referred to.

Start with the Key Vault access evidence

Where Key Vault diagnostic logs were being sent to Log Analytics using resource-specific tables, Agent Foskett searched AZKVAuditLogs for recent data-plane operations and preserved the caller identity context available in the records.
key-vault-access.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
AZKVAuditLogs
| where TimeGenerated > ago(30d)
| where OperationName has_any
    ("SecretGet", "KeyGet", "CertificateGet")
| project TimeGenerated,
          OperationName,
          ResultType,
          CallerIpAddress,
          Identity,
          ResourceId,
          CorrelationId
| order by TimeGenerated desc

A principal ID is more useful than a friendly name

Names can be reused. Resources can be renamed. Old documentation can be wrong.

Agent Foskett preserved the immutable identity identifiers present in the telemetry and compared them with the managed identities and service principals that still existed in the tenant.

The investigation followed the principal — not the label someone remembered.

Was the identity still present?

If the principal belonged to a surviving user-assigned managed identity, Azure Resource Graph could help locate that identity resource and show its current Azure resource context.
managed-identity-resource-graph.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
Resources
| where type =~
    "microsoft.managedidentity/userassignedidentities"
| extend PrincipalId =
    tostring(properties.principalId),
         ClientId =
    tostring(properties.clientId)
| project name,
          resourceGroup,
          subscriptionId,
          PrincipalId,
          ClientId,
          id

Not finding a user-assigned identity changed the hypothesis

If the principal no longer mapped to a current user-assigned managed identity, Agent Foskett did not immediately conclude that a deleted system-assigned identity was somehow still authenticating.

Instead he checked the timestamp of the Key Vault event, the deletion timeline and whether the telemetry was historical.

An old access event can survive longer than the resource that generated it.

When was the VM actually deleted?

The Azure Activity Log records control-plane operations. Agent Foskett searched AzureActivity for deletion activity involving the known VM resource ID or name.
vm-deletion-timeline.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
let VmName = "prod-app-vm01";
AzureActivity
| where TimeGenerated > ago(90d)
| where ResourceProviderValue =~
    "MICROSOFT.COMPUTE"
| where Resource has VmName
| where OperationNameValue has
    "virtualMachines/delete"
| project TimeGenerated,
          Caller,
          CallerIpAddress,
          ResourceGroup,
          ResourceId,
          ActivityStatusValue,
          CorrelationId
| order by TimeGenerated asc

The timestamps separated history from impossible behaviour

If Key Vault access occurred before the VM deletion, the event could simply describe legitimate historical activity by the old workload.

If access occurred after deletion, Agent Foskett had a different problem to solve.

For a system-assigned identity, post-deletion authentication using that deleted identity would conflict with its expected lifecycle and demand careful validation of the principal mapping and timestamps.

For a user-assigned identity, continued authentication could be entirely possible because the identity may have survived and been attached or used elsewhere.

The identity type determines what “after deletion” actually means.

Was the surviving identity attached somewhere else?

A user-assigned managed identity can be associated with more than one Azure resource. Agent Foskett searched current Azure resources for references to the identity's resource ID.
identity-attachments-resource-graph.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
let IdentityName = "uami-prod-app";
Resources
| where isnotempty(identity)
| where tostring(identity) has IdentityName
| project name,
          type,
          resourceGroup,
          subscriptionId,
          identity,
          id
| order by type asc

Then inspect what still authorised the principal

Key Vault authorization can be implemented using Azure RBAC or the older vault access-policy model, depending on the vault configuration.

Agent Foskett therefore checked the vault's authorization model before deciding where to look for the surviving permission.

Do not hunt an RBAC assignment when the vault is using access policies — and do not assume an access policy exists when RBAC is enabled.

Check Azure RBAC assignments for the principal

For a Key Vault using Azure RBAC, Agent Foskett used Azure Resource Graph authorization resources to look for role assignments involving the principal.
principal-role-assignments-resource-graph.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
let PrincipalId =
"11111111-2222-3333-4444-555555555555";
AuthorizationResources
| where type =~
    "microsoft.authorization/roleassignments"
| where tostring(properties.principalId)
    =~ PrincipalId
| project roleAssignmentId = id,
          scope = tostring(properties.scope),
          roleDefinitionId =
              tostring(properties.roleDefinitionId),
          principalType =
              tostring(properties.principalType)

A surviving role assignment was not proof of recent use

An RBAC assignment establishes authorization — the ability for the principal to perform permitted actions at the assignment's scope.

It does not establish that the principal actually exercised that permission.

Agent Foskett kept authorization evidence and access telemetry separate.

Permission answers “could it?”
Audit evidence answers “did it?”

What if the vault used access policies?

For vaults using the access-policy authorization model, Agent Foskett reviewed the Key Vault resource configuration and compared the policy object IDs with the principal under investigation.

The important question remained the same: did an authorization path still reference an identity that no longer matched the expected workload lifecycle?

Different authorization models. Same investigative requirement: identify exactly what still trusts the principal.

Could another resource now be using the same user-assigned identity?

This was the scenario Agent Foskett could not ignore.

The VM might have been deleted correctly while the user-assigned identity remained intentionally or accidentally available to another workload.

If Key Vault access continued after the VM deletion, the investigation shifted from “ghost VM” to “where is this identity being used now?”

The deleted VM was history. The surviving identity was the live asset.

Build the managed-identity timeline

Agent Foskett organised the evidence chronologically.
Original workload existsEstablish which VM or workload originally used the managed identity.
Key Vault access observedPreserve the operation, timestamp, caller context and principal identifiers.
VM deletedUse AzureActivity to establish when the compute resource was removed and by whom.
Identity lifecycle checkedDetermine whether the identity was system-assigned or user-assigned.
Authorization inspectedCheck Azure RBAC or Key Vault access policies for surviving trust.
Current use scopedDetermine whether another Azure resource now references the surviving identity.

What Agent Foskett checked

Identity typeWas the principal system-assigned or a standalone user-assigned managed identity?
Key Vault eventDid the access occur before or after the VM deletion?
VM deletionWhen was the original resource deleted and which identity performed the control-plane operation?
Current identity resourceDoes a user-assigned managed identity with the principal still exist?
Authorization pathDoes Azure RBAC or a Key Vault access policy still grant access?
Current attachmentsIs another workload now using the surviving user-assigned identity?

What the evidence can and cannot prove

Key Vault diagnostic telemetry can establish observed vault operations when the required diagnostics were enabled and retained. AzureActivity can establish Azure control-plane events such as resource deletion. Azure Resource Graph can describe current resources and authorization objects.

None of those sources alone proves malicious intent.

And current-state queries cannot reconstruct an object that has already been deleted unless historical telemetry or another retained source preserves its details.

Separate historical access, current identity state and current authorization. Then connect them with time.

The lesson

The VM was gone.

That did not automatically mean every identity and authorization object associated with the workload had disappeared with it.

Agent Foskett identified the principal, established the managed-identity type, reconstructed the VM deletion and checked what still authorised or used the identity.

When a workload disappears, verify the identity lifecycle separately from the resource lifecycle.
Investigation principle: Never call a managed identity orphaned until you have established whether it is system-assigned or user-assigned and verified what resources and permissions still reference it.

Related investigations

Agent Foskett InvestigationsContinue through the complete collection of real-world Microsoft security investigations.KQL Threat HuntingExplore practical investigation techniques across Microsoft Defender XDR, Microsoft Sentinel and Microsoft Azure.SOC Analyst AcademyBuild practical investigation and triage skills across identity, endpoint, email and cloud security.
The VM was gone. The identity story wasn't finished.
Identify the principal. Rebuild the resource timeline. Verify what still trusts it.
Continue the Investigation

Final thought

Cloud resources can disappear in seconds.

Identity and authorization require their own investigation.

A system-assigned identity follows its resource lifecycle. A user-assigned identity does not have to.

So when old workload evidence points toward a managed identity, do not assume the identity vanished just because the VM did.

Find the principal. Establish the identity type. Reconstruct the deletion. Then determine what still trusts — and what may still be using — that identity.

The VM was gone.

The authorization path still had a story to tell.

Follow the evidence. Build the timeline.

The Logs Already Knew! 🔎
Develop IT.. Protect IT.. GEMXIT.
GEMXIT PTY LTD | GEMXIT UK LTD
Talk to GEMXIT
ACSC Logo

GEMXIT PTY LTD  |  GEMXIT UK LTD  |  © GEMXIT

Key Vault Was Still Trusting an Identity — The VM Was Already Gone

This Agent Foskett investigation examines Azure Key Vault access involving a managed identity after the workload's original virtual machine has been deleted.

Investigating Azure Managed Identity and Key Vault Access

Use Key Vault diagnostic telemetry, AzureActivity and Azure Resource Graph to identify the principal, reconstruct the VM deletion and distinguish system-assigned from user-assigned managed identity lifecycle.

Finding Surviving Azure Authorization After Workload Deletion

Investigate Azure RBAC or Key Vault access policies, determine whether a user-assigned managed identity still exists and identify current Azure resources that may still use it.