skip to content

A Kubernetes rule firing on any pods/exec audit record is tagged T1609, T1611 and T1078 — which labels survive?

level: seniorimportance: should knowfreq 48%

answer

  1. what does the record itself establish
  2. one label is a hypothesis about later
  3. one label is true of every event
  4. the API's view stops at the request
  5. split the rule rather than stack labels

basics

~20 s

Only the container administration one, T1609. The API audit record proves a command channel was opened into a container. It shows no break-out to the node, so T1611 is a hypothesis, and every exec in the estate uses an accepted credential, so T1078 is true of everything and therefore says nothing.

solid answer

~50 s

Keep the label the rule's own condition establishes and drop the ones that are hypotheses or tautologies. The audit event records a `create` on `pods/exec` for a named pod by a named identity — that is command execution through the container administration service, so `T1609` holds. `T1611` (Escape to Host) is not established anywhere in that record: the API server's view ends at the request, and proving a process left the container's namespaces needs node-level telemetry such as an `execve` audit record or a runtime sensor on the worker. `T1078` (Valid Accounts) is technically satisfied — a credential was accepted — but it is satisfied by every authenticated request in the cluster, so tagging it turns the label into noise, and the audit record's username string cannot pick a sub-technique anyway. If you want the escape hypothesis detected, that is a second rule over different telemetry, not a third label on this one.

code

json · 13 lines
json
{
  "apiVersion": "audit.k8s.io/v1",
  "kind": "Event",
  "level": "Metadata",
  "stage": "ResponseComplete",
  "verb": "create",
  "requestURI": "/api/v1/namespaces/payments/pods/checkout-7d9f/exec?command=sh&container=checkout&stdin=true&tty=true",
  "user": { "username": "[email protected]", "groups": ["platform-oncall", "system:authenticated"] },
  "objectRef": { "resource": "pods", "subresource": "exec", "namespace": "payments", "name": "checkout-7d9f" },
  "sourceIPs": ["10.4.11.9"],
  "responseStatus": { "code": 101 },
  "requestReceivedTimestamp": "2026-03-11T02:14:07.113Z"
}

go deeper

for a junior

Know that a Kubernetes API audit record describes a request to the API server, and that it cannot see what happens inside the container afterwards.

for a middle

Be ready to walk each candidate label back to a specific field in the record and say which field would have to exist for the label to hold.

for a senior

Show the two disqualifiers — a label that is a hypothesis about what comes next, and a label true of every event from the source — and argue for splitting the rule instead of stacking labels.

for a principal

Own the consequence at scale: labels are the index other teams query, so decide what a stacked label costs a detection programme and who arbitrates when authors disagree.

## What the record actually establishes A Kubernetes API audit event for a shell into a running pod is a request record: `verb: create`, `objectRef.resource: pods`, `objectRef.subresource: exec`, the namespace and pod name, the authenticated identity and its groups, the source address, and a `requestURI` whose query string carries the requested `command` and container. A `responseStatus.code` of 101 means the API server accepted the protocol upgrade and wired the stream through. That is a precise and quite narrow set of facts: **a command channel into a named container was requested through the orchestrator's API by an identity the authenticator accepted, and the API allowed it.** ## Label one: container administration command — keep it Executing commands inside a workload through the platform's own administration interface, rather than by running a process on the node, is exactly what this record shows. The rule's condition establishes it directly, so the label is honest and the rule will correctly turn up when someone searches for detections of that behaviour. ## Label two: escape to host — drop it Breaking out of a container into the node is a different behaviour, and the API audit stream has no visibility into it whatsoever. The API server's knowledge stops at the request; everything the session does afterwards happens inside the container runtime on a worker node. To claim an escape you need telemetry from the node — a syscall audit record for the execution, a runtime sensor, or evidence of a mount, capability or namespace change — and none of that appears here. Why the label gets attached anyway: an exec into a privileged pod is a plausible *precursor* to an escape, and the author wants the rule to show up in that conversation. But the label is a claim about what the rule detects, not about what might happen next. Leave it on and the first person who searches for escape detections finds a rule that cannot see one, and stops looking. ## Label three: valid accounts — drop it Every authenticated request in the cluster is made with a credential the authenticator accepted. That is what authentication means. A label that is satisfied by every event the source produces carries no information: it will not help anyone find this rule, and it will make the rule appear as a detection for a behaviour it makes no attempt to distinguish from normal operation. Separately, the record hands you a username string and group list; that is not enough to choose among the sub-techniques for account types, so even a narrower claim is unavailable. There is a version of this that would be legitimate: a *different* rule whose condition is about the identity — a service account that has never exec'd before, an exec arriving through impersonation, an identity acting outside the namespaces it normally touches. That rule's condition establishes something about credential use and can carry the label. This rule's condition does not. ## The general test for a multi-technique rule For each candidate label ask two questions. 1. **Does the rule's own condition establish this behaviour?** If it establishes something that merely often precedes it, the label is a hypothesis and belongs in the rule's description, not its labels. 2. **Would the label be true of essentially every event from this source?** If so it is a tautology and adds nothing. What is left is usually one label, occasionally two when a rule genuinely straddles — for example a condition that requires *both* an exec *and* a privileged security context is making a stronger claim than either half, and may legitimately carry more than one. ## Split rather than stack When you want the second behaviour detected, write the second rule. Two rules with one honest label each are better than one rule with three, because labels are the index other people search: a stacked label converts "find every rule for this behaviour" from a useful query into a misleading one. ## What you cannot conclude, and should say out loud The `command=sh` in the request URI names the entrypoint the session was started with. The API audit stream records nothing that was typed inside that interactive session afterwards. Anyone reasoning from this record about *what was run* is reasoning past their evidence — which is the same discipline that decides which labels the rule may carry.

  • What telemetry would let a rule honestly carry the escape-to-host label?
    Node-level evidence, not control-plane evidence: syscall auditing of executions on the worker, a container runtime sensor reporting namespace or capability changes, or host filesystem access from a process whose cgroup says it belongs to a container. The claim is about a process crossing an isolation boundary, and only telemetry on the other side of that boundary can establish it.
  • The audit record shows a 101 response. Does that prove the operator ran anything?
    No. It proves the API server accepted the protocol upgrade and connected the stream, so a session was established. What was typed into that session is not in the API audit stream at any audit level. Treat it as proof that a channel opened, and go to container or node telemetry for what travelled through it.
  • Could a rule ever justify carrying two technique labels?
    Yes, when the condition genuinely requires both behaviours. A rule that fires only when an exec targets a pod running with a privileged security context is asserting more than either half alone, and the second label is earned by the extra clause. The test is always the condition, never the plausibility of what might follow.
  • The identity in the record is a service account rather than a person. Does that change the labels?
    Not for this rule, whose condition does not look at the identity at all. It is the seed of a different rule: exec by a service account, or by any identity that has never exec'd into that namespace before, is a condition about credential use, and that rule earns the valid-accounts label this one cannot.

saying these in an interview costs you the question

  • Keeps escape-to-host because an exec could lead there
  • Claims the audit record shows what ran in the session
  • Tags valid accounts on any authenticated event
  • Stacks labels to widen search hits
  • Treats control-plane evidence as node evidence

context

resolving links…