Leaked Secret Validation Detection: GetCallerIdentity

Before an attacker abuses a leaked key, they almost always check that it works, and that check is often the first and best chance you get to notice. Validation calls are cheap identity lookups such as AWS GetCallerIdentity, Slack auth.test or a GitHub request for the authenticated user. They are made at scale by automated tooling within minutes of a leak, they need no special permissions, and they look harmless in isolation. This guide covers how validation works, which calls show up in which provider logs, how to tell attacker validation from your own tools, and what to do in the minutes after a key is tested. It is written for detection engineers, cloud security teams and NHI owners. For the case studies behind leaked secrets, see Leaked secret breaches.

Key takeaways

Validation is the hinge between leak and abuse. The first call from a new source is usually a who-am-I lookup, followed within minutes by discovery calls; detecting that first call shortens your response window from days to minutes.
You cannot block it with policy on AWS. AWS states that GetCallerIdentity needs no permissions and still succeeds when an explicit deny is attached, so a quarantine policy does not stop a key from being validated.
Not every validation reaches your logs. Some checks run from the attacker's own account or hit endpoints the provider does not audit, so pair log detection with canary credentials and leak alerts.
Context beats the event name. The same call is made by your SDKs and scanners every day; the signal is a new source address, a new user agent, a dormant key or a who-am-I call followed by enumeration.
Treat a validated key as compromised. A confirmed attacker validation means the key is live in someone else's hands: deactivate, rotate and scope the blast radius, then investigate.

What attacker validation looks like

Secret scanners used by defenders and attackers alike confirm a candidate credential by calling the issuing provider's API. TruffleHog's documentation describes three result states, verified, unverified and unknown, and gives its AWS detector as an example: it calls GetCallerIdentity to check whether an AWS credential is active. The tool reports over 700 detectors that support active verification, and its analyze feature goes further for around 20 common credential types, sending several requests to work out what the secret can access. The same capability that helps a security team triage findings tells an attacker which of thousands of harvested strings are worth using.

Live incidents show the pattern:

In the TruffleNet campaign, Fortinet recorded more than 800 attacker hosts built around TruffleHog. They called GetCallerIdentity to confirm stolen AWS keys, and a second component called GetSendQuota to see how much email a key could send through Amazon SES before abuse began.
In the 230 million AWS cloud environments campaign, keys taken from exposed .env files were first used for GetCallerIdentity, then ListUsers and ListBuckets, then SES probing, before the attacker created an administrator role.

Across providers the sequence is consistent: an identity check, then a capability check aimed at what the attacker can monetise (email sending, compute, AI model access, repository contents), then enumeration and privilege escalation. The first two steps are the detection opportunity this guide focuses on.

Validation calls by provider and where they are logged

The table lists common validation calls and what the provider's own documentation says about logging. Where documentation does not confirm that a call is audited, plan as though it is not.

Provider	Typical validation call	What the provider documents	Where to look
AWS	STS `GetCallerIdentity`; capability checks such as SES `GetSendQuota`	No permissions required; succeeds even with an explicit deny. CloudTrail logs all authenticated requests to IAM and STS. Global endpoint calls are logged in US East (N. Virginia), regional endpoint calls in their own Region	CloudTrail `eventSource` `sts.amazonaws.com`, `eventName` `GetCallerIdentity`, with `userIdentity.accessKeyId`, `sourceIPAddress`, `userAgent`; check all Regions, not only your home Region
AWS (no trace)	STS `GetAccessKeyInfo`	Returns the account ID for any access key ID and does not indicate whether the key is active	Called with the attacker's own credentials, so expect nothing in your account; it reveals which account a key belongs to without touching it
Microsoft Entra ID	Client credentials token request with an app secret or certificate	Service principal sign-in logs record sign-ins that use an app's own credential, grouped by service principal, status, IP address and resource	Entra sign-in logs, service principal sign-ins view; failed sign-ins show tested but wrong or expired secrets
Google Cloud	Any API call with a token minted from a service account key	Audit logs of the called service include `protoPayload.authenticationInfo.serviceAccountKeyName`, naming the key used (not logged by App Engine and Compute Engine)	Cloud Audit Logs filtered on `serviceAccountKeyName` for keys that should be idle or only used from known workloads
GitHub	A request for the authenticated user or token scopes	Enterprise audit log events carry `hashed_token` (SHA-256, Base64), `programmatic_access_type` and `token_scopes`. Streaming of API request events must be enabled and is limited to security-relevant endpoints	Audit log search by `hashed_token`; do not assume simple read calls are streamed
Slack	`auth.test`	Checks authentication and returns team and user (and `bot_id` for bot tokens); no scopes required	Treat as unlogged for detection purposes and rely on token leak alerts and canaries

The gap rows matter. A Slack token or an AI provider API key can be validated with little or nothing for you to see. For those, prevention (short lifetimes, IP restrictions where the provider offers them) and canary credentials do more than log rules. See the Honeytokens and Canary Credentials Guide.

Telling attacker validation from normal use

SDKs, CLIs, infrastructure-as-code tools and your own secret scanners call identity endpoints constantly. Raw alerts on GetCallerIdentity will drown a SOC. Score the context instead.

Signal	Why it matters	Suggested weight
First-seen source IP or ASN for this key	Leaked keys are tested from infrastructure the key has never used, often hosting providers, VPNs or Tor	High
Dormant key becomes active	A key with no use for 30 or more days that suddenly makes a who-am-I call has very likely leaked	High
Validation followed by enumeration within minutes	Identity check, then `ListUsers`, `ListBuckets`, `GetSendQuota`, model or repository listing, is the attacker sequence	Critical when combined
Unfamiliar user agent	A scanner or scripting library user agent on a key used only by one application	Medium (user agents are easily changed)
Calls from a human-style client on a workload key	A workload key used from a CLI on a residential or VPN address	Medium
Failed authentication bursts	Repeated failures with expired or rotated secrets show someone holds an old copy	Medium
Key recently reported in a leak alert	Provider or scanner notification of public exposure	Critical

Build an allowlist of expected callers per key: the workload's egress addresses, the CI runner ranges and your own scanner. Your scanners should validate from a fixed, documented address range with a distinctive user agent so they never look like an attacker. For broader behavioural baselines, see the NHI Behavioural Baselining Guide; for location-based rules on AWS keys specifically, see How to detect AWS access key use from unusual locations.

Detection rules to build

New-source validation: an identity call (GetCallerIdentity, an Entra client credentials sign-in, a GitHub token event) from a source IP or ASN not seen for that credential in the last 90 days. Alert at medium; raise to high for keys with write or IAM rights.
Validation then capability check: the same key makes an identity call and, within 15 minutes, a capability or enumeration call such as GetSendQuota, ListVerifiedEmailAddresses, ListUsers, ListBuckets or GetAccountAuthorizationDetails. Alert at high.
Dormant credential wake-up: any successful authentication by a key whose last use was more than 30 days ago. Alert at high; these keys should usually be deleted anyway.
Multi-region or global endpoint anomaly: an AWS key that normally calls regional STS endpoints suddenly appearing via the global endpoint, or STS events in Regions you do not use. CloudTrail records endpointType and awsServingRegion under additionalEventData.RequestDetails.
Old secret still being tried: repeated failed sign-ins for an Entra service principal or failed calls with a rotated key. This shows a copy is held outside your control even though it no longer works.
Canary trip: any use at all of a planted credential. This is the one rule with no false positives.

The 15-minute and 30-day windows are starting points; tune them to how often your keys are genuinely used. Keep at least 90 days of identity logs so first-seen rules have a baseline.

Responding to a validation alert

Speed matters more than certainty here. In the cases above, the gap from validation to abuse was minutes.

Confirm the credential and owner. Map the key ID, service principal or token hash to its owner and workload from your NHI inventory.
Contain without waiting for root cause. Deactivate or disable the key, or revoke the token. On AWS remember that an attached deny does not stop GetCallerIdentity, but it does stop the follow-on calls; deactivation stops both.
Issue a replacement. Rotate to a new secret or, better, move the workload to a short-lived credential (role, workload identity federation, managed identity) so there is nothing long-lived to leak again.
Scope what happened. Pull every event for the credential from the first new-source call onwards: discovery, data access, new identities, new keys, policy changes.
Find the leak. Search code, CI logs, container images, chat and ticketing for the secret; the validation tells you it leaked, not where.
Record and tune. Record time from leak to validation and validation to containment, and tune rules from the result.

The Leaked Credential Response Playbook covers the full procedure, and provider-specific steps for GitHub are in How to revoke a leaked GitHub personal access token and check what it touched.

Decision guidance

Alert or auto-contain: auto-disable on a canary trip or on validation followed by enumeration from a new source. Alert-only for a single new-source identity call on a low-privilege key, until you trust the allowlist.
Logs or canaries: logs cover providers that audit identity calls; canaries cover the rest and the places secrets leak (repositories, CI variables, laptops). Most teams need both.
Small organisations: start with rule 3 (dormant keys), rule 6 (canaries) and the provider's own leaked-credential notifications. These need no baseline.
Large organisations: build per-credential baselines in the SIEM, join identity events to the NHI inventory for ownership, and route alerts to the owning team with automated containment for high-privilege keys.
Your own scanners: if you run validation against found secrets, do it from fixed infrastructure and record it, so your activity is excluded from detections and auditable.

Detection and measurement

Log sources to enable: CloudTrail in all Regions with management events; Entra service principal sign-in logs exported to the SIEM; Google Cloud audit logs for services your keys can reach; GitHub enterprise audit log streaming with API request events enabled; and alert feeds from your secret scanning and canary tooling.

Time from validation to containment: median minutes from the first attacker identity call to key deactivation (target under 15 minutes for high-privilege keys).
Validation coverage: percentage of credential types in your inventory whose identity calls you can see in logs.
Canary coverage: share of high-risk leak locations (public and private repositories, CI systems, container registries) seeded with canaries.
Dormant long-lived keys: count of keys unused for 90 days still active (target 0).
False positive rate: share of validation alerts traced to your own tooling, to drive allowlist fixes.

Framework mapping

Framework	Reference	How it applies
MITRE ATT&CK v20	T1552.001 Credentials In Files; T1078.004 Cloud Accounts; T1087.004 Cloud Account discovery; T1526 Cloud Service Discovery; T1580 Cloud Infrastructure Discovery; T1593.003 Code Repositories	Leak source, use of the stolen credential and the discovery calls that follow validation
NIST SP 800-53 Rev 5	IA-5 Authenticator Management; SI-4 System Monitoring; AU-6 Audit Record Review; IR-4 Incident Handling	Credential lifetime and rotation, monitoring, review and response
NIST CSF 2.0	PR.AA-01; DE.CM-03; DE.AE-02; DE.AE-03	Managing credentials, monitoring technology use, analysing and correlating events
CIS Controls v8.1	Control 5 Account Management; Control 8 Audit Log Management; Control 13 Network Monitoring and Defense	Inventory of credentials, log collection and alerting
ISO/IEC 27001:2022 Annex A	A.5.17 Authentication information; A.8.15 Logging; A.8.16 Monitoring activities	Secret handling, logging and monitoring
OWASP Non-Human Identities Top 10	NHI7 Long-Lived Secrets	Why validated keys stay useful to attackers; see the OWASP NHI Top 10 NHI7 Long-Lived Secrets Guide

Common failure patterns

Alerting on every identity call. The rule fires thousands of times a day for SDKs and is muted within a week. Alert on context, not the event name.
Logging one Region. AWS global endpoint STS calls land in US East (N. Virginia) and regional calls in their own Region; a trail scoped to one Region misses validation from elsewhere.
Trusting a deny policy to stop testing. GetCallerIdentity still answers under an explicit deny, so a quarantined key still validates; only deactivation ends it.
Leaving exposed keys active. A new key is issued while the old one stays active "for a migration", or secrets found alongside the leaked one are never rotated, and the leaked copies keep working. In the Internet Archive breach, Zendesk API tokens in leaked source code were not rotated and were used for a second breach weeks later.
Assuming no logs means no testing. Slack tokens, many SaaS keys and AI provider keys can be validated with little or no trace in your logs; without canaries and leak alerts you will not see them.
Your own scanner looks like an attacker. Validation from changing cloud addresses with a generic user agent produces the same events as an attack and trains analysts to ignore them.

Practitioner checklist

List which of your credential types produce a log event when validated, and where that event lands.
Enable CloudTrail in every Region, Entra service principal sign-in log export and GitHub API request event streaming.
Build first-seen source rules per credential with a 90-day baseline.
Correlate identity calls with discovery or capability calls within a short window and alert high.
Alert on any use of a key dormant for 30 or more days, and delete such keys.
Seed canary credentials in repositories, CI variables and container images for credential types you cannot see in logs.
Run your own secret validation from fixed, documented infrastructure with a distinctive user agent.
Automate deactivation for canary trips and validation-then-enumeration on high-privilege keys.
Move workloads with validated or leaked keys to short-lived credentials rather than a new long-lived key.

Leaked Secret Validation Detection: Catching Attackers Testing Stolen Keys Before Use