Skip to content
Start with Identity
Join free
SWI-T024 · Non-human identity

Static API key abuse

A static API key has no expiry, no built-in scope beyond what was granted at creation, and no way to tell whether the caller presenting it is the workflow it was issued to or whoever found it in a public commit.

WidespreadHard to detect
First observed: 2013ATT&CK T1078.004 ↗ATT&CK T1552.001 ↗

How it works

An API key is a static secret string that authenticates a caller, service or automation to an API. Anyone who holds the string can call the API as the identity it represents, with no login, no MFA and no expiry, until someone revokes it. It needs nothing more than a value pasted into a header, which is why it persists despite being the weakest common credential type.

The same pattern covers AWS IAM user access keys (IDs beginning AKIA, per AWS; temporary STS keys begin ASIA), personal access tokens, SaaS admin API tokens, service principal client secrets and platform admin tokens. The abuse path is consistent:

  1. The key leaks into a repository, config file, container image, CI log or ticket, or sits in a vendor's systems that are later breached.
  2. The attacker finds it, by scanning public commits or after some other foothold.
  3. The attacker tests it. One call such as AWS GetCallerIdentity or a "who am I" endpoint confirms the key works and shows what it is.
  4. The attacker enumerates and acts. With the key's standing rights they list resources, read secrets the key can reach, mint further keys for persistence, and exfiltrate or destroy data.

GitGuardian's August 2026 research on n8n shows the path end to end. Researchers found 4,576 unique n8n API tokens exposed in public GitHub commits across 1,255 hostnames. Of 896 reachable instances they tested, 321 accepted at least one leaked token, about 36 percent. With a working token, an attacker had read access to workflow definitions, stored credentials and data tables. They could also make a workflow use a stored credential against an endpoint of their choosing without ever seeing its value.

Chaining is common. At the Internet Archive, the attacker told BleepingComputer a token in an exposed GitLab config file opened the source code, which reportedly held unrotated Zendesk API tokens.

Why it works

The control assumption that fails is that possession of the key string is the same as authorization to use it. A static key is a bearer token: nothing ties it to a specific caller, network location or time window.

Second, these keys sit in the MFA blind zone. There is no interactive login for MFA, Conditional Access or session revocation to act on. In SSO-protected apps an admin API token is also a local login bypass: the identity provider never sees it, so deprovisioning the human who created it does not revoke it.

Third, keys outlive their context. Zeabur's shared-cluster admin tokens, created in January 2024, "had no expiry, had not been rotated" and sat in plaintext in a private configuration repository when an intruder used them in October 2026. When a vendor holds keys for many customers, one leak becomes a fan-out breach. CVE-2025-3928 in Commvault's web server put Metallic's Microsoft 365 app secrets for many tenants within an attacker's reach. CVE-2025-30066 turned the tj-actions GitHub Action into a pipe that printed CI secrets into public build logs.

How to detect it

  • AWS. In CloudTrail, userIdentity.type = IAMUser with a long-term accessKeyId (prefix AKIA) calling from a new sourceIPAddress or userAgent. GuardDuty findings CredentialAccess:IAMUser/CompromisedCredentials (a key Amazon threat intelligence believes is compromised), UnauthorizedAccess:IAMUser/MaliciousIPCaller, Discovery:IAMUser/AnomalousBehavior (unusual ListAccessKeys, GetRolePolicy and similar calls) and Persistence:IAMUser/AnomalousBehavior (for example an anomalous CreateAccessKey).
  • Microsoft Entra workload identities. ID Protection raises leakedCredentials for a service principal when its valid credentials turn up on GitHub, paste sites or breach data, and suspiciousSignins when a service principal signs in with an unfamiliar IP, ASN, resource, user agent or credential type. Full details need Workload Identities Premium.
  • Okta. system.api_token.create in the System Log, which records each new unscoped API token. An unexpected token is either persistence or a key someone is about to leak.
  • Source hosting. GitHub secret scanning runs automatically on public repositories and notifies partner providers, which may revoke the key. Treat a leak notice as an incident.

The limits are real. Legitimate automation is bursty, runs from shared cloud IP ranges, and changes endpoints whenever owners edit it. GuardDuty notes that for its credential-exfiltration findings, continued activity from a new source is learned as expected and stops alerting. Zeabur's intrusion ran for more than 16 hours without triggering an alert. Build a per-key baseline and assume detection will be late.

How to stop it

Ranked by effect:

  1. Replace static keys with short-lived, workload-issued credentials. Use IAM roles and STS, workload identity federation for CI and cross-cloud calls, managed identities, or certificates. Microsoft's remediation guidance for risky service principals recommends x509 certificates over secrets. A leaked value then expires quickly.
  2. Keep keys out of code, images and tickets. Inject them at runtime from a vault such as HashiCorp Vault or AWS Secrets Manager. Turn on secret scanning with push protection, using GitHub's own or a tool such as GitGuardian.
  3. Scope every key to the smallest set of actions and resources, and add network restrictions where the API supports them, so a leaked key is useless off your network.
  4. Give every key an owner and an expiry, and include API and automation tokens in the same access reviews as human accounts. See non-human identity and workload identity.
  5. Rotate completely after any exposure. That includes every downstream credential the leaked key could read, and every key a breached vendor held for you. At Cloudflare, four missed credentials were enough.

Seen in the wild

Sources

Related identity CVEs and breaches

Last reviewed By SWI Community TeamSuggest a correctionHow we research

In the Identity Breach Database

Real incidents in our sourced breach database where this technique was used.

Browse the full database

Seeing this technique used differently, or have a detection rule that works better? Email community@startwithidentity.com. See all briefs in the technique catalog, or volunteer as a CVE Analyst.
Mapped to MITRE ATT&CK where a technique ID exists. Independent, community-driven analysis, not a substitute for the ATT&CK knowledge base. See the disclaimer.