Test the next permission boundary. Determine whether the current identity can obtain higher privileges through misconfiguration or a validated vulnerability.
The house & safe / Chapter 04
Cross an inner access boundary
Test whether a guest can obtain access reserved for the keyholder, such as entry to the upstairs safe room.
Technical meaning: Demonstrate a change in effective permissions. Reaching a different host is lateral movement; it is not necessarily an increase in privilege.
Establish the current user, groups, and effective privileges.
Review delegated commands, service permissions, and identity relationships.
Prove only the approved privilege change and record cleanup.
Phase deliverable
Evidence of the original and resulting privileges, the enabling weakness, and its limits.
Document what you observed, the assumptions you tested, and what remains unverified.
Field method / Expanded guide
Work through the phase.
This guide uses a five-phase teaching model. PTES separates additional stages, and NIST uses a different lifecycle. The topics below adapt those ideas to the workflow here; they are not a claim that every framework uses these five names.
1. Define the original and desired privileges
HOUSE LENS Moving upstairs is not enough: establish whether you gained keyholder permissions you did not previously have.
Escalation is a change in effective permissions, not just a new process.
Establish the account and effective context before testing. On Windows, group membership, token privileges, and elevation state matter. On Linux, user IDs, groups, file permissions, and capabilities can each affect what an executable can do.
Record before-and-after identity evidence using the same relevant context.
Distinguish local administrator, domain-level privilege, and access to an application role.
State what resource or action the extra privilege actually enables.
2. Inspect Linux delegation and file permissions
HOUSE LENS Look for a house rule that lets a guest control something the keyholder trusts, such as a maintenance action or its inputs.
A privileged action becomes risky when a less-privileged identity can control what it executes.
Review sudo rules, SUID programs, file capabilities, service units, and privileged scheduled jobs. Investigate their arguments and dependent paths. An intentionally privileged binary is not automatically vulnerable; ownership and actual behavior determine whether a boundary can be crossed.
Check executable and parent-directory ownership as well as the file itself.
Consider configuration files, scripts, and inputs that a privileged process consumes.
Treat enumeration results as leads until you can explain a concrete permission failure.
3. Inspect Windows tokens and service dependencies
HOUSE LENS Check who can change the instructions used by a keyholder-only service, then verify whether those instructions would actually be followed.
Access to a file matters in relation to the process that trusts it.
Review the current token and selected service executable/configuration permissions. If a standard user can modify a file consumed by a privileged service, examine the execution path and trigger requirements. An ACL granting write access is evidence of permission; it does not prove that the service will execute the altered content.
Preserve service identity, executable path, relevant ACL, and any restart permission.
Use read-only inspection before planning a proof.
Explain inheritance and group membership when interpreting access-control entries.
4. Validate and document the boundary crossing
HOUSE LENS Demonstrate the extra access, identify the permission that enabled it, and restore the house after the simulation.
Show the changed privilege and the specific weakness that enabled it.
Use an agreed bounded proof and capture both contexts. A higher-privilege session alone does not explain the cause; connect it to the rule, permission, or vulnerability tested. Restore changed files and settings, then define a retest for the same path.
Do not substitute a scanner’s “likely vulnerable” result for demonstrated escalation.
If an intrusive proof is not approved, report the exposed configuration and clearly state the validation limit.
The recommended fix should address the enabling permission or component, not merely terminate the test session.
Tools / Practical reference
Commands, outputs, interpretation.
Use approved targets. These examples show representative behavior; output varies by environment. Angle-bracket values must be replaced. No command here guarantees a finding.
User analyst may run the following commands on lab-host:
(root) /usr/local/bin/backup-report
How to interpret it: An allowed command is a lead. Assess arguments, executable ownership, and dependent files before concluding that escalation is possible. A password prompt or denial is also a valid outcome.
USER INFORMATION
lab\analyst
PRIVILEGES INFORMATION
SeChangeNotifyPrivilege Enabled
[other groups and privileges depend on token]
How to interpret it: Interpret privileges with token type, group membership, and UAC context. A listed privilege is not automatically an escalation path.
How to interpret it: SUID programs are often legitimate. Check ownership and behavior; the presence of this permission bit alone is not a vulnerability. Suppressed errors mean this inventory may be incomplete.
Inspect Linux file capabilitiesCommand / authorized lab
getcap -r /usr/bin /usr/local/bin 2>/dev/null
Expected output / illustrative
/usr/bin/ping cap_net_raw=ep
[other capability-bearing files depend on the host]
Interpretation: A capability grants selected privileges to a file when executed under applicable kernel rules. Evaluate the particular capability and program behavior; cap_net_raw on ping is commonly intentional. Suppressed errors make this an incomplete inventory.
Inspect permissions on an approved service executable
Interpretation: F means full control; RX means read and execute. This illustrative ACL does not grant Users modification. Inspect actual inherited entries, group membership, and parent directories before assessing effective access.
Interpretation / Common mistakes
Interesting permission versus escalation
Interesting permission versus escalation
Reporting every SUID executable as vulnerable.
Ignoring token elevation, group membership, or inherited ACLs.
Showing a privileged session without the enabling weakness or original context.
Evidence checklist for this phase
Target and test identity
Timestamp and relevant configuration
Exact command or sanitized request
Observed output and its interpretation
Limitations, changes made, and cleanup status
Sources / Further reading
Read the underlying guidance.
Original guidance consulted for methodology and tool behavior. Commands and outputs on this page are illustrative lab examples, not output captured from these sources.
Test whether a guest can obtain access reserved for the keyholder, such as entry to the upstairs safe room. Demonstrate a change in effective permissions. Reaching a different host is lateral movement; it is not necessarily an increase in privilege.
