ACSC Logo
© GEMXIT
GEMXIT Logo
Agent Foskett Investigation • Azure Key Vault • Microsoft Entra ID • Workload Identities • AzureDiagnostics • KQL

The Azure Key Vault Secret Was Read by an Identity Nobody Recognised

The Key Vault operation was successful.

A production secret had been read.

The timestamp was outside the normal deployment window.
The source did not match the application team’s expected activity.

Then the SOC looked at the identity.

It wasn’t a username anybody recognised.
It was an object ID.

Agent Foskett had one question.

Who — or what — had just read the secret?

Discuss cloud securityBack to investigations
Agent Foskett investigating an unfamiliar identity reading an Azure Key Vault secret
The Secret Read Was Only the First Clue

Azure resource logs can show that a secret was accessed. The investigation begins when the identity in that event has to be resolved back to a user, application, managed identity or service principal.

✓ Establish the Key Vault operation
✓ Resolve the unfamiliar identity
✓ Hunt for related activity

The alert was about a secret read

The SOC was reviewing activity against a production Azure Key Vault when a successful secret-read operation appeared outside the expected application window. The operation itself was legitimate functionality. The context was not yet explained.
Production vaultThe resource contained secrets used by a business application.
Successful accessThe request was not merely attempted; the Key Vault operation completed successfully.
Unknown identityThe caller information did not immediately map to a person or workload the team recognised.

Start with the Key Vault evidence

If Key Vault diagnostic logging is being sent to Log Analytics, begin with the resource telemetry and isolate secret operations around the suspicious time. Depending on the diagnostic configuration and table mode, the exact schema can differ, so confirm the fields available in your workspace.
key-vault-secret-operations.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
AzureDiagnostics
| where TimeGenerated > ago(7d)
| where ResourceProvider == "MICROSOFT.KEYVAULT"
| where OperationName has "Secret"
| project TimeGenerated,
          Resource,
          OperationName,
          ResultType,
          CallerIPAddress,
          identity_claim_oid_g,
          identity_claim_appid_g,
          CorrelationId
| order by TimeGenerated asc

The identity was an object ID

Cloud resource logs often identify callers with GUIDs rather than friendly names. That is not a dead end. Preserve the object ID, application ID, source address and correlation information, then resolve the identity in Microsoft Entra ID or the appropriate identity inventory.
Object IDThe caller object identifier becomes a pivot into Microsoft Entra.
Application IDIf present, the application identifier can help distinguish workload authentication from a normal user sign-in.
Source addressThe caller IP provides another pivot for comparing expected application infrastructure with the observed access.

Was it a service principal?

If the caller resolves to an application or service principal, investigate the workload identity rather than forcing the event into a user-account story. Microsoft Entra service principal sign-in telemetry can help establish when and from where the application identity authenticated.
service-principal-signins.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
AADServicePrincipalSignInLogs
| where TimeGenerated > ago(7d)
| where ServicePrincipalId ==
    "00000000-0000-0000-0000-000000000000"
| project TimeGenerated,
          ServicePrincipalName,
          AppId,
          IPAddress,
          ResourceDisplayName,
          ResultType,
          CorrelationId
| order by TimeGenerated asc

Or was it a user identity?

If the object ID resolves to a user, pivot into SigninLogs and compare authentication context with the Key Vault event. The goal is to determine whether the user was expected to access the vault, whether the source and device were normal and whether the authentication timeline supports the resource access.
user-signin-context.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
let User = "alex@contoso.com";
SigninLogs
| where TimeGenerated > ago(7d)
| where UserPrincipalName =~ User
| project TimeGenerated,
          AppDisplayName,
          ResourceDisplayName,
          IPAddress,
          ResultType,
          ConditionalAccessStatus,
          DeviceDetail
| order by TimeGenerated asc

Check how the identity gained access

Resolving the caller answers who or what performed the operation. It does not yet explain why that identity could read the secret. Review the vault’s current access model — Azure RBAC or legacy access policies — and investigate relevant administrative changes around the incident window.
key-vault-access-changes.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
AzureActivity
| where TimeGenerated > ago(30d)
| where ResourceProviderValue =~
    "MICROSOFT.AUTHORIZATION"
| where OperationNameValue has_any
    ("roleAssignments/write",
     "roleAssignments/delete")
| project TimeGenerated,
          Caller,
          CallerIpAddress,
          OperationNameValue,
          ActivityStatusValue,
          Properties
| order by TimeGenerated asc

Build the access timeline

Put the identity and resource events together. A newly created workload identity, a recent role assignment and a secret read minutes later tell a very different story from a long-standing managed identity reading the same secret during a normal deployment.
Identity historyDetermine whether the caller is established, newly created or recently modified.
Permission historyLook for role or access-policy changes that altered what the identity could do.
Resource activityPlace the successful secret operation after the authentication and permission events that made it possible.

Was it one secret or a pattern?

One suspicious operation should trigger scoping. Search the same caller object, application ID or source address across the vault telemetry to determine whether other secrets, keys or vaults were accessed during the same period.
scope-key-vault-activity.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 CallerObjectId =
    "00000000-0000-0000-0000-000000000000";
AzureDiagnostics
| where TimeGenerated > ago(7d)
| where ResourceProvider == "MICROSOFT.KEYVAULT"
| where identity_claim_oid_g == CallerObjectId
| summarize Operations=count(),
            FirstSeen=min(TimeGenerated),
            LastSeen=max(TimeGenerated)
    by Resource, OperationName, ResultType
| order by LastSeen desc

What happened after the secret was read?

A successful secret read establishes access to a protected value; it does not by itself establish how that value was subsequently used. Hunt for related authentication, workload and resource activity that could be connected by identity, time, application or source context.
Follow the identitySearch for subsequent sign-ins or resource access performed by the same caller.
Follow the applicationDetermine whether the secret belongs to a workload whose behaviour changed after the read.
Follow the timelineUse temporal correlation to identify activity that deserves deeper validation without claiming causation from timing alone.

What the evidence can and cannot prove

A successful Key Vault secret-read event can prove that an authorised request retrieved a secret through the service. It does not automatically prove the caller was malicious, that the secret was exfiltrated beyond Azure or that it was later used. Those conclusions require additional identity, resource and application evidence.
ProvenThe Key Vault telemetry can establish the operation, time, result and recorded caller context.
ResolvableThe caller identifiers can often be mapped back to a Microsoft Entra user, service principal or workload identity.
Do not overclaimA secret read is not by itself proof of theft, exfiltration or malicious use.

Agent Foskett's investigation mindset

Cloud logs frequently begin with identifiers rather than friendly names. Do not dismiss an unfamiliar GUID as meaningless. Treat it as a pivot that connects the resource operation to the identity plane.
Resolve the callerTurn object IDs and application IDs into an identity the investigation can understand.
Explain the permissionDetermine why that identity was authorised to read the secret at that moment.
Scope the impactSearch for other Key Vault operations and related activity before deciding the event was isolated.

Investigation findings

The suspicious event began as a successful secret read by an unfamiliar object ID. By resolving the caller into Microsoft Entra, reviewing workload or user sign-ins, checking access changes and scoping Key Vault activity, the SOC turned an anonymous GUID into a complete identity-and-resource timeline. The important question was not simply whether the secret had been read. It was whether the identity, permission and timing made that read expected.
The GUID became an identityThe caller identifier provided the bridge from Azure resource telemetry into Microsoft Entra.
The permission needed explanationThe investigation established why the identity could perform the operation rather than treating successful access as automatically legitimate.
The scope extended beyond one eventOther vault operations and related identity activity were reviewed before the incident was closed.

Related Agent Foskett investigations

Continue with Azure, service-principal and cloud identity investigations.
The New Service Principal Had No OwnerInvestigate an unfamiliar non-human identity and reconstruct its creation, permissions and activity.The Service Principal Had Global AdministratorFollow excessive application privilege through Microsoft Entra evidence.Agent Foskett AcademyBuild practical Microsoft security investigation and KQL skills.
The log showed a GUID. The investigation had to find the identity behind it.
In cloud investigations, unfamiliar identifiers are often the beginning of the evidence trail.
Continue the Investigation

Final thought

Azure Key Vault is designed to let authorised identities retrieve protected secrets when applications and people need them. That means a successful read is not suspicious simply because it succeeded. Context makes the difference. Resolve the caller, understand the permission, compare the timing with expected workload behaviour and then follow the activity. The secret read tells you what happened. The identity tells you whether it makes sense.
Who read it?Resolve the caller object and application identifiers.
Why could they read it?Review the vault access model and recent permission changes.
What happened next?Scope related vault and identity activity before deciding the incident is understood.
Develop IT. Protect IT.
GEMXIT PTY LTD | GEMXIT UK LTD
Talk to GEMXIT
ACSC Logo

GEMXIT PTY LTD  |  GEMXIT UK LTD  |  © GEMXIT

The Azure Key Vault Secret Was Read by an Identity Nobody Recognised

This Agent Foskett investigation explores Azure Key Vault secret access, AzureDiagnostics, Microsoft Entra service principals, workload identities, Azure RBAC, SigninLogs and KQL.

Azure Key Vault Security Investigation

The investigation starts with a successful secret-read operation and follows the caller object ID into Microsoft Entra to determine whether the access came from an expected user, service principal or workload identity.

Cloud Identity, Key Vault And KQL

By correlating Azure resource telemetry, Microsoft Entra authentication and access-control changes, defenders can explain who accessed a protected secret, why the identity was authorised and whether the surrounding activity was expected.