An operator buys a valid CI pipeline token, pushes an image the cluster deploys, and reads production data. Which step escalated privilege?
answer
- ask who granted each right
- hunt for the exploit and find none
- the estate performs most of the work
- same sequence as Tuesday's deployment
- cost was one credential, bought not earned
basics
~20 sNone of them. The token was entitled to push, the cluster was configured to pull and run whatever it finds, and the workload identity already held the database rights. The operator's only cost was acquiring one credential.
solid answer
~50 sWalk the hops and ask, at each one, who granted the right. The build token may push to the registry because the platform team granted that. The cluster pulls and runs the referenced image because the deployment was configured to. The running workload reads the customer database because its identity was granted that access on purpose. Every hop is an ordinary, fully authorised action, so there is no escalation anywhere in the chain — and the chain still ends in production. The operator bought a credential out of band instead of earning one, and the estate performed the rest of the work as designed. MITRE ATT&CK files this as T1078, Valid Accounts, and lists that technique under Initial Access, Persistence, Privilege Escalation and Defense Evasion at once, which is the framework conceding that account use is not a lesser act. Note also that this exact sequence is the platform team's Tuesday deployment.
code
text · 9 lineshop 1 push image identity: ci-build-runner right granted: write to registry
hop 2 deploy identity: cluster node right granted: pull image, run container
hop 3 read customers identity: workload service acct right granted: SELECT on prod database
...
enforced privilege boundary crossed at any hop : none
exploit used : none
patch that would have prevented it : none
ATT&CK: T1078 Valid Accounts - listed under Initial Access, Persistence,
Privilege Escalation and Defense Evasiongo deeper
Recognise that a build pipeline holds real power: something entitled to publish what production runs is a production-grade credential regardless of what it is called.
Be able to walk the three hops and name the granted right at each one, then state that no rights were elevated anywhere in the chain.
Show production judgment by answering 'none' and immediately refusing the comfort in it, and by naming the two preconditions the route actually depends on: a reusable credential and an over-broad entitlement.
Own the strategic point — routes with no defect in them do not age out with a patch cycle, so an estate that only funds vulnerability work never touches this class at all.
## Read the chain hop by hop The trap in this scenario is the instinct to hunt for the exploit. There is none, and looking for one is the wrong reflex. The right reflex is to ask, at each hop, *who granted this right, and to whom*. **Hop one — push.** The build identity is entitled to write images to the registry. That entitlement is not an accident; a pipeline that cannot publish artefacts is useless. The operator did nothing to obtain the right, only something to obtain a credential that carries it. **Hop two — deploy.** The cluster pulls the referenced image and runs it. This is the deployment's entire purpose. No decision is made about *what* the image contains, because the design placed that decision upstream, in the pipeline the operator now holds. **Hop three — read.** The container runs under a workload identity that was granted access to the production database because the application needs it. The operator's code inherits that access simply by executing inside the workload, with no further authentication step of its own. At no point does an identity acquire rights it did not have. The operator moved *between* identities, each already entitled, and the direction of those moves is not up. ## What the operator actually paid for One credential. That is the whole bill. Compare it with what the operator did *not* have to buy: - No vulnerability research and no exploit, reliable or otherwise. - No race against patching, because there is nothing unpatched in the path. - No custom tooling, because the estate's own delivery mechanism performs every remaining step. - No persistence work in the classical sense, because the route stays open as long as the entitlement does. This is why routes made of granted rights are attractive quite independently of stealth: they are *cheap and reliable*. An exploit chain has a shelf life measured against a vendor's release cycle. An entitlement chain has a shelf life measured against an organisation's willingness to revisit who may deploy what, which is usually much longer. ## The contrast case that makes the point A competent platform engineer, on an ordinary Tuesday, performs this same sequence in this same order: builds, pushes, lets the cluster deploy, and the workload reads the database. The action sequence is not merely similar, it is the same. Nothing intrinsic to the operations separates the intrusion from the deployment. What differs is one fact that lives entirely outside the sequence: whether the party holding the credential was authorised to hold it. That is a statement about custody, not about behaviour, and the whole reason this route is chosen is that it pushes the distinguishing fact out of the actions and into a place the actions never touch. ## Where the framework lands ATT&CK's **T1078, Valid Accounts** covers exactly this. It is worth knowing that ATT&CK lists that single technique under **four** tactics — Initial Access, Persistence, Privilege Escalation and Defense Evasion — because candidates often assume account use is a footnote next to the "real" escalation techniques. The taxonomy says otherwise: using a valid account *is* the escalation, *is* the persistence, and *is* the evasion, all at once. ## The answer the interviewer is testing for The question asks which step escalated privilege, and the correct answer is a confident **none** followed immediately by a refusal to let that stand as reassurance. Say the two things together: 1. There is no escalation in this chain, and looking for one will waste the review. 2. The chain reached production anyway, so "no escalation" tells you about the mechanism and nothing about the outcome. A candidate who says only the first sounds precise and is dangerous. A candidate who says only the second sounds alarmed and imprecise. Both sentences together are the answer. ## What genuinely bounds a route like this The move rests on two preconditions that are not on any host: a **reusable** credential exists for the build identity, and the identities in the chain are entitled to more than the specific job requires. Those are the properties that would have to change, and they live with whoever owns the pipeline and the workload's access — which is also why this kind of route survives estates that have hardened every operating system in them.
- Your platform team says that sequence is identical to their normal deployment. Are they right?Yes, and that is the finding rather than a rebuttal. The operations carry no distinguishing property; the only difference is whether the party holding the credential was authorised to hold it. An operator choosing this route is buying precisely that property — every step looks like the work the estate exists to do.
- How does this route behave on a fully patched estate?Identically. There is no defect in the path, so patch level is irrelevant to every hop. That is worth saying out loud, because 'we are fully patched' is the most common response to this scenario and it addresses a dependency the route never had.
- What did the operator have to supply that the estate did not?One credential and an image to push. Everything else — the registry write, the pull, the container start, the database access — was supplied by rights somebody granted deliberately. The intrusion's entire cost sits in obtaining custody of a secret that already existed.
saying these in an interview costs you the question
- Insists an exploit must exist somewhere in the chain
- Calls the image push an escalation because production was reached
- Answers 'none' and stops, treating that as reassurance
- Claims admin-tier separation or patching would have stopped it
- Assumes the workload authenticated separately to the database