Turning access into position¶

Access permits network interaction, capability performs meaningful action, and position largely determines operational value. Converting access into a new position spends a finding, introducing specific prerequisites, credential expiration limits, and detection costs.

Exploitation chains distinct technical actions. Reading a local configuration file may recover plaintext credentials, which can enable further authentication or privilege escalation. Access to process memory may then reveal cached credentials, session material, or Kerberos tickets, depending on the operating environment. These chains require active execution, separating them from structural dependencies that exist regardless of adversary activity.

Valid credentials and hijacked live sessions may provide execution authority without requiring local host ownership. Leveraging trust relationships involves authenticating through federation, single sign-on, or Active Directory delegations rather than bypassing authentication mechanisms.

Privilege escalation exploits misconfigured file permissions or unquoted service paths on a single host, a policy an identity is permitted to rewrite in a cloud account, or a capability left in a container. Developing custom capabilities may involve overflowing buffers, reversing compiled binaries, or exploiting weaknesses in cryptographic implementations to bypass specific technical controls. Evading detection often depends on matching operational execution to the local baseline environment. Persistence holds a way back for when existing paths are revoked.

Re-map reachability from the new position, ask again what is there, or read what the move cost in What changed, and what it cost.