skip to content

A stolen workload identity calls credential issuance in a loop for twenty minutes — why does the exposure outlast those minutes?

level: middleimportance: must knowfreq 55%

answer

  1. one act, many outputs
  2. the child outlives the parent
  3. validity starts at mint time
  4. twenty minutes in, eight hours out
  5. ending the session withdraws nothing minted

basics

~20 s

Each issued credential carries its own lifetime, independent of the session that requested it. Twenty minutes of issuance at a few hundred calls a minute can leave thousands of working credentials that stay valid for their full lifetime afterwards.

solid answer

~40 s

Issuance is a multiplier, not a single act of theft. The attacker does not need to keep the borrowed identity: each call mints a fresh credential against a downstream system, and that credential's validity window starts when it is minted, not when the foothold ends. At 200 calls a minute for twenty minutes that is roughly 4,000 credentials; if each is issued with an eight-hour lifetime, the estate stays reachable for about eight hours after the last mint — well after the host is rebuilt. The bounded session the attacker rode in on does expire, and expiring it stops further minting. It withdraws nothing already minted, because a credential issued to a downstream system and the caller's session at the store are separate objects with separate clocks.

go deeper

for a junior

Recall the one fact everything else hangs on: a credential's validity window starts when it is created, so it can still be working long after whoever asked for it is gone.

for a middle

Explain the mechanics: generation mints a new independent credential per call, the minted credential and the caller's session at the store are separate objects with separate clocks, and the credential usually lives in the downstream system rather than the store.

for a senior

Show the operating judgment: do the arithmetic out loud, refuse to call the incident closed at host rebuild, and produce the list of live children with their latest expiry and their target systems before declaring anything clean.

for a principal

Frame the trade-off you are buying: generation shrinks each credential's blast radius but makes volume the new risk, so the estate's safety depends on caps and issuance-volume alerting existing before the first incident, not on lifetimes alone.

## What amplification means here A store that **generates** credentials mints a new one on each request: a downstream account, role or key created at request time for one consumer. That is normally the property you want — every consumer holds its own credential, so withdrawing one touches nobody else, and nothing long-lived is sitting in a configuration file. Under a borrowed identity the same property runs in reverse. The attacker does not have to steal a credential and hold on to it. It has to be **allowed to ask** for one — and then it asks four thousand times. What it walks away with is not the identity it borrowed but the pile of credentials that identity was entitled to request. Two numbers decide how big that pile is: - **The call rate the attacker can sustain.** If nothing bounds issuance per identity, this is bounded only by the store's own capacity, which is sized for the whole fleet. - **The lifetime stamped on each minted credential.** This is the one that produces the tail, because the clock on a minted credential starts at its own mint time. Work it through with concrete numbers. One host in a fleet of edge collectors is taken over at 02:00 and rebuilt at 02:20. During those twenty minutes its workload identity calls issuance at 200 calls a minute: **4,000 credentials**. Each is issued with an **eight-hour lifetime**, and the last is minted at 02:20. The estate therefore stays reachable through roughly **10:20** — eight hours after the foothold ended, after the host was rebuilt, after the on-call handover, and quite possibly after the incident channel was closed. ## The parent and the children are different objects The single most common wrong move here is to treat ending the attacker's access as ending the incident. It is not, because two different things are in play and only one of them was ended. | Object | What it bounds | Ends when | Ending it stops | |---|---|---|---| | The borrowed identity's session at the store | that caller's own access **to the store** | its expiry, or an operator revokes it | any **further** minting | | Each minted credential | one consumer's access to **one downstream system** | its own expiry, or withdrawal at that system | that one credential | The children usually do not even live in the same system as the parent. A minted database credential is a role in the database; a minted queue credential is an account on the broker. The store holds a record that it created them. Deleting that record, or ending the session that asked for them, does not make the database or the broker stop accepting them — withdrawal is an action against the system that honours the credential. ## Short lifetimes shorten the tail; they do not remove the multiplier It is tempting to answer "we issue short-lived credentials, so this is fine". Shorter lifetimes genuinely help — they set how long the tail runs after the last mint, and cutting eight hours to fifteen minutes turns a working day of exposure into the length of a coffee break. But two things survive the change: - **The count is unchanged.** 4,000 credentials in twenty minutes is 4,000 either way, and every one of them worked at the moment it was minted. - **A short lifetime invites re-minting.** An attacker that is still inside simply asks again; short lifetimes assume the loop stops, which is exactly what is not true while the foothold is live. So lifetime is a control on the **tail**, not on the **volume**. The volume needs a different control. ## What the arithmetic tells you to control 1. **Bound the flow** — how many credentials one identity may mint per interval, derived from what that identity legitimately needs rather than from the store's spare capacity. 2. **Bound the stock** — how many of one identity's credentials may be live at once, which catches a patient attacker minting at a legal rate for hours. 3. **Record the parentage at mint time** — which identity and which session asked, so that afterwards you can list what exists rather than sweep every downstream system. 4. **Alert on issuance volume per identity**, because no single request in the loop is anomalous; the count is. ## The sentence that should sound wrong "We rebuilt the host and deleted its identity, so we are clean." Read against the table above, that statement covers the parent and says nothing about the 4,000 children. The honest version names both: *further minting is stopped; the credentials already minted are live until their expiry or until each is withdrawn at the system that accepts it, and here is the list.*

  • Does issuing shorter-lived credentials remove the amplification, or only shorten it?
    Only shorten it. Lifetime sets how long the tail runs after the last mint, so cutting eight hours to fifteen minutes is a real reduction in exposure. It does not change how many credentials were minted, every one of them worked when minted, and an attacker still inside simply asks again as each expires. Lifetime bounds the tail; a per-identity cap bounds the volume.
  • Which count actually sizes the blast radius after an incident like this?
    Not the number of issuance calls — denied ones minted nothing. The number that matters is how many credentials from that identity are still live: not yet expired and not yet withdrawn, together with the latest expiry among them and the set of downstream systems they work against. That triple tells you how wide the reach is and when it closes on its own.
  • Why does this attack care about a generated-credential estate at all, rather than one that stores static values?
    Because generation gives the attacker manufacture rather than theft. In a static estate a compromised identity reads the values it is allowed to read, and the blast radius is that set. In a generating estate the same identity produces new, independently valid credentials on demand, so the radius is bounded by how many times it can ask — which is why a per-identity cap exists at all.

A stolen badge that also works the key-cutting machine. Taking the badge back at the end of the shift does not collect the keys it cut, and each cut key opens its own door until that lock is changed.

saying these in an interview costs you the question

  • Rebuilding the compromised host ends the exposure
  • Expiring the attacker's session invalidates what it minted
  • Short-lived credentials make bulk issuance harmless
  • Only one credential is at risk, the one the identity held
  • Deleting the store's issuance records stops the credentials working