Distinguishing interaction from capability¶

Access permits authentication or basic interaction with a target system. Capability enables performing meaningful operational actions using that access. The space between interaction and capability contains key tradecraft, and conflating the two causes reporting to overstate real operational impact.

Illustrating the operational gap¶

Four scenarios demonstrate the distinction between access and capability:

Authenticating to a web application provides access. Placing a file that executes code represents capability, requiring a specific technical mechanism to bridge the gap: an upload handler trusting user filenames, a template engine evaluating rendered inputs, or an unsafe deserialisation routine.

Performing an authenticated directory query offers basic access across an enterprise network. Requesting a Kerberos service ticket for offline cracking represents capability, where the progression relies on service account configuration rather than the querying account’s privileges.

Reading telemetry from an industrial controller provides basic network access, frequently permitted across entire segments by unauthenticated protocols. Downloading or modifying control logic represents capability, requiring specialised engineering tools and an operational window where physical panel mode changes avoid raising suspicion.

Allowing a cloud instance to reach its metadata service provides localised access. Assuming the IAM role issued by that metadata service represents capability, requiring a server-side request forgery flaw in a hosted application to expose those temporary credentials.

Converting findings into operational movement¶

Converting access into capability requires expending a technical finding. Each conversion represents an observed relationship, evaluated for risk, and actively leveraged. A long list of network access yields nothing without underlying technical findings. An environment featuring widespread access may offer minimal operational progression, while a tightly restricted network can collapse following a single misconfiguration.

Expiration and operational lifespans¶

Capabilities inherit explicit limitations from their supporting findings, as outlined in what the unlock actually is, which specifies the subject, target object, and required conditions.

Capabilities expire across varying timeframes based on their underlying mechanisms. Access tokens often expire within an hour. Interactive user sessions end upon logoff or host reboot. Kerberos ticket-granting tickets run for ten hours, with renewal windows extending up to a week. Passwords persist until password policies mandate updates, which can take ninety days or remain indefinite. Digital certificates frequently outlive the personnel who issued them. Relying on a capability beyond its valid lifespan grounds operational planning on expired assumptions.

Progression relies on a collection of scoped, expiring capabilities, each backed by an identified technical conversion mechanism.