Validating Lateral Access Without Remote Execution

This playbook checks whether a named assessment identity can reach and access one approved resource. It separates network reachability, authentication, and authorization. It does not run a remote process, create a service or task, copy a tool to another host, or collect user data.

1. Record the exact test tuple

Write down the source host and identity, destination host, protocol, port or share, test marker, test window, and owner contact. Confirm all are in scope. If any value is unknown or mismatched, stop before connecting.

2. Check service reachability

On Windows, test a single approved port:

Test-NetConnection 'APP-SRV-02.northwind.example' -Port 445 -InformationLevel Detailed

Example output:

ComputerName     : APP-SRV-02.northwind.example
RemotePort       : 445
TcpTestSucceeded : True

A successful TCP connection only means that a listener answered. It does not show that the test identity authenticated or is authorized to use the service.

3. Confirm the current Beacon context, if applicable

If the assessment has an explicitly authorized Beacon, collect only its current identity and working directory before a permitted access check:

beacon> getuid
beacon> pwd

Example output:

Current identity: NORTHWIND\analyst01
Working directory: C:\Windows\System32

If the host or identity differs from the operation record, stop. Do not switch tokens or borrow another user’s session to make the check succeed.

4. Test only a designated read-only marker

With the resource owner present or available, access one named marker file in an approved read-only share:

dir \\FILE-SRV-03\AssessmentReadOnly\validation-marker.txt

Example result:

 Directory of \\FILE-SRV-03\AssessmentReadOnly

09/25/2026  01:18 PM             64 validation-marker.txt
               1 File(s)             64 bytes

Do not open the file or list the rest of the share. Record whether the marker’s metadata was accessible, the identity used, and the matching destination log entry. If the share is unavailable, do not search for alternate shares or files.

5. Distinguish the three outcomes

Check	What it establishes	What it does not establish
TCP connection	A service answered from this route	Successful authentication or access rights
Authentication log	The named identity authenticated to the service	Permission to perform an action
Marker access	The identity could read the approved marker	Administrative rights or access to other data

6. Review higher-impact methods without executing them

WinRM, SMB service creation, PsExec-style remote service execution, scheduled-task execution, and trusted binary proxy execution can change a remote host or execute code. Inventory whether the pathway is enabled through configuration, access-control, and audit evidence. If a live test is required, obtain a separate approval specifying one disposable target, benign action, expected logs, stop condition, and rollback. Do not use a privileged user’s identity as the validation target.

7. Close the test

Correlate source and destination timestamps, note clock offsets, preserve the minimum required events, and confirm that no test file or connection remains. Record the result as reachable, authenticated, authorized, blocked, or not tested; do not collapse these states into a claim of host compromise.