Skip to content

Lesson 9.2 · Collection, credentials, and impact· 3 min read

Privilege escalation and lateral movement boundaries

Distinguish a change in permissions from a change in execution location and explain the evidence required for each.

Platform:
Cross-platform
Language:
Concepts
Difficulty:
Intermediate

What you will learn

Distinguish a change in permissions from a change in execution location and explain the evidence required for each.

Before you begin: Credential access and capability boundaries; security context.

Two axes of change

A program can act in a different security context without moving to another host, or act on another host without acquiring a more privileged context. Keep those dimensions separate. This prevents a source study from interpreting every authentication event as privilege escalation or every network connection as lateral movement.

MITRE's Lateral Movement overview describes activity used to move through an environment. Here, the focus is the distinction between location and authority. The lesson contains no exploit, credential-use procedure, remote-execution command, or host-discovery routine.

Record before and after

Before:
  execution location: example host A
  effective context: example user U
  permitted operation: unknown

After:
  execution location: example host B
  effective context: example user U
  permitted operation: unknown

These invented observations describe a location change only if execution on B has actually been established. The repeated username is not proof of identical permissions, and the different hostname is not proof of elevated permissions. The missing operation and policy context remain unknown.

Requests, authority, and results

An implementation may request an operation through an existing authenticated channel. A successful authentication result is different from permission to perform that operation. Permission is also different from successful completion. Trace which result the caller checks and what it does when later stages fail.

For privilege-related claims, identify the initial effective context, the operation being attempted, and the context associated with the outcome. Starting with elevated rights should not be described as having gained them during execution. A change in a displayed account label likewise does not fully describe the effective authority of a process.

Exploitation is not implied by an outcome

Even if a study confirms execution with greater authority, the mechanism still needs evidence. Existing permissions, administrative action, configuration, and exploitation are different explanations. Do not select one merely because it would fit the narrative. A source repository may contain several paths while the observed artifact uses only one.

The earlier component-map lesson applies here: establish who initiates the action, which boundary evaluates it, and where the resulting behavior occurs. Include failure states, because an attempted transition can leave artifacts without reaching the intended result.

Exercise

A trace shows a successful login to B and a rejected request to start a component there. What can be said about lateral execution and privilege escalation? How would the answer change if execution were confirmed but the initial context were unknown?

Check your understanding

The first trace confirms authentication and rejection, not successful execution or privilege gain. Confirmed execution would establish a narrower location claim, but an unknown initial context still prevents a reliable before-and-after privilege comparison.

Discussion

Related snippets

Explain credential-related capabilities by separating access, representation, use, and outcome, without confusing discovery with privilege gain.
Explain ransomware-related implementation boundaries and distinguish changed data, encryption claims, recoverability, and confirmed impact.
Distinguish a library dependency, an API call, and a successful privileged operation when reading an implementation.