analyst already has a shell on lab-linux, and CORP.LOCAL\svcuser already signs in to LAB-WIN01. Neither foothold is an administrative result. The assessment question is whether a local configuration error lets either account cross the local privilege boundary to root or SYSTEM, and whether we can prove that risk without executing an exploit. A permitted command in sudoers, a writable service path, or a stored credential can be sufficient evidence when the account, configuration, and prerequisite all align.
All work in this course stays inside the fixed offline Ubuntu 22.04 and Windows Server 2022 labs that we own or are explicitly authorized to assess. The method produces defensible findings, not payloads, exploitation chains, or evasion steps. On Ubuntu, a sudo request and its outcome may leave authorization evidence in /var/log/auth.log and the system journal, while Windows privilege activity must be tied to the relevant Security log or service evidence.
The fixed lab makes the privilege boundary and its evidence stores visible:
This diagram shows why enumeration begins on the host. The relevant configuration and the evidence of its use usually sit on opposite sides of the same privilege boundary, so a finding needs both rather than an isolated suspicious setting.
Because a visible boundary does not establish a path across it, every enumeration pass produces four connected outputs. A hypothesis list is a ranked set of possible vector classes, such as delegated Linux commands, scheduled tasks, weak Windows service configuration, or credentials exposed to a non-administrative account. A hypothesis is not a finding. It becomes one only when the host configuration satisfies the vector’s prerequisites.
For example, analyst seeing an executable with elevated permission does not prove elevation. We must establish who owns the file, whether analyst can influence it, what privileged component executes it, and whether the execution context actually reaches root. The Windows equivalent is not merely noticing a service. We need the service account, binary path, access control, and the permissions held by CORP.LOCAL\svcuser.
The same evidence answers a defender’s question. On Ubuntu, accepted and rejected sudo activity can identify the invoking account, target user, working directory, and command; policy files such as /etc/sudoers and /etc/sudoers.d/ explain why the action was permitted. A defender can compare those records with the intended delegation rule and alert on unusual privileged commands or unexpected changes to policy files.
The assessment outputs distinguish a plausible route from a reportable privilege-escalation condition: