Module 11: Situational Awareness and Host Operations

← Return to the Red Team Course #

Situational awareness is a current, evidence-backed picture of the host and security context where an assessment action would run. It starts with identity and scope, then adds the process, network, and service facts needed for the next decision. Collecting every available field is less useful than answering the right questions accurately.

Allow about 18 minutes, plus time to create the host-state record. Commands below inspect local state and do not require credential extraction.

What You Will Learn #

• Identify the host, account, process, and network context separately.
• Explain why an interface address does not establish a usable route.
• Apply read-only Windows or Linux checks in a training environment.
• Analyze changes between two host snapshots.
• Create a handover record with freshness and collection limits.

Establish Identity Before Interpretation #

A hostname or IP address is one part of an identity check. Match it against the approved inventory and available asset identifiers. DHCP changes, aliases, cloned lab systems, and virtual interfaces make a single label insufficient in some environments.

The account context is a separate fact. A visible desktop user, a remote session’s user, and a service account need not be the same principal. Reuse the SID and token distinctions from Module 4 before interpreting access results.

Freshness belongs beside each observation. A process list gathered before a service restart does not describe the replacement process. Record the collection window and repeat only the checks invalidated by a relevant state change.

Build a Minimal Snapshot #

Choose fields by purpose. Before a local configuration check, you need the current account and target object’s context. Before interpreting an outbound connection, you need the source process, route, destination, and relevant time. These questions call for different snapshots.

Collection itself is activity. Native commands, scripts, and in-process extensions differ in implementation, but all require evidence appropriate to their behavior. Avoid assuming a BOF is automatically quiet or a built-in executable automatically safe for any workload.

Missing information should stay visible. Permissions, process termination, tool filtering, and collection failures all affect completeness. Record “not collected” or “access denied” when appropriate rather than replacing uncertainty with an empty field.

Inspect Windows Identity #

Start with local identity in a Windows training shell. hostname prints the computer name, whoami /user includes the current user SID, and whoami /groups shows group information for the current context. Compare the result with the approved inventory and account. Read the whoami reference .

hostname
whoami /user
whoami /groups
ipconfig /all

ipconfig /all displays detailed adapter configuration. Read the adapter names, addresses, masks, gateways, and DNS settings together. An address alone does not prove a network is reachable or in scope. Read the ipconfig reference .

Identity and network fields need separate interpretation. A domain account does not establish organizational ownership of every listed network. A successful local identity query also does not establish the account’s permissions on a remote resource.

Correlate Processes and Sockets #

Process and connection lists provide complementary observations. tasklist /v adds verbose process information, while netstat -ano displays connections and listeners numerically with associated PIDs. Read both during a short collection window. Read tasklist and netstat .

tasklist /v
netstat -ano

Flag meanings: /v requests verbose task information. For netstat, -a includes connections and listening endpoints, -n keeps numeric addresses and ports, and -o includes the owning PID. These flags inspect state rather than proving application purpose.

PID correlation has a time boundary. A process might exit between commands, and a later process might reuse its identifier. Include image path and start-time evidence where available before joining records from distant timestamps.

Use Process Explorer Carefully #

Process Explorer adds an interactive view of running processes, handles, DLLs, and mapped files. Its lower-pane modes help connect a selected process with resources it has opened. Use this to investigate a specific question rather than treating a large tree as a conclusion. Read Microsoft’s Process Explorer overview .

A useful observation includes the selected process, timestamp, relevant properties, and what the view establishes. An image with a familiar name still needs context such as path, signer information, parentage, and behavior. A signature is evidence about provenance, not a blanket approval of every action.

Pavel Yosifovich’s demonstration explains Process Explorer features in Microsoft’s Sysinternals series. Watch for the distinction between process identity and loaded resources. Then choose one view which would improve your own host-state record.

Watch on YouTube: Sysinternals: Process Explorer deep dive .

Inspect Linux Context #

Kernel and distribution identity answer different questions. uname -a reports kernel and machine information, while /etc/os-release provides distribution identification fields on systems implementing this interface. Neither replaces a package inventory or patch assessment. Read uname and os-release .

id
uname -a
cat /etc/os-release
ip address show
ip route show
ss -lnt

id reports user and group identity for the invoking context. ip address show lists address assignments, and ip route show displays routes in the default listing context. More complex policy routing requires additional interpretation beyond this initial view. Read the address and route references.

ss -lnt displays listening TCP sockets using numeric values. -l selects listeners, -n avoids service-name resolution, and -t selects TCP. Add process information only when needed and available under the current permissions. Read the ss reference .

Avoid the Two-Address Shortcut #

Multiple addresses do not automatically make a host a bridge into another network. One interface might have several addresses, a VPN might contribute a route, or a virtual interface might belong to a local container network. Identify the interface type and routing context before drawing a topology conclusion.

Forwarding is another condition. A host having interfaces on two networks does not establish forwarding between them. Routes, forwarding settings, firewall policy, and application behavior determine which communication is possible.

Authorization remains independent. Learning about another network does not make it part of the assessment. Record the relationship as an unresolved topology observation and ask the agreed owner to confirm the permitted next step.

Work a Snapshot Difference #

Illustrative scenario: at 09:00, PID 4200 runs the approved training service and listens on loopback port 8765. At 09:10, PID 4200 belongs to a different program, while the training service has PID 6100. Its replacement listener binds to all IPv4 interfaces.

Analyze the change: identify which old observations are stale and which new exposure question needs validation. Decide whether the PID reuse proves the original process changed its identity. Keep process lifetime and socket binding separate in your answer.

Expected reasoning: the 09:00 PID-to-process association is stale. The new program’s reuse of PID 4200 does not make it the same process. The binding change warrants a scoped reachability review, but it does not prove the service is reachable through every firewall or network path.

Keep Privilege Claims Precise #

Elevated privileges affect available operations but do not prove any particular credential material is present. Authentication method, logon state, operating-system protections, and configuration all matter. Microsoft’s Credential Guard documentation describes isolation of certain secrets using virtualization-based security. Read the Credential Guard overview .

Credential extraction is a separate assessment action, not a required step in a basic host snapshot. A host-awareness objective is often satisfied by identity, process, network, and service observations. Keep the collected fields tied to the actual decision.

Read-only does not mean free of effects. An expansive query still consumes resources and produces activity. Bound repeated collection by need, particularly on systems with strict availability requirements.

Create a Host-State Record #

Your deliverable is a concise snapshot for one disposable Windows or Linux system. Collect the smallest set of fields needed to explain its identity, current context, one process, and one socket. Include an explicit freshness limit or event which would invalidate the record.

Approved asset and inventory reference:
Collection start/end time:
Host and account identity:
Current process architecture and security context:
Relevant process PID, image, and start time:
Relevant adapter, route, and socket:
Command or tool version:
Raw output location:
Missing fields or access limitations:
Change which requires a refresh:
Supported next action:

Review the record by handing it to another reader. They should identify what is known, which facts are time-sensitive, and what remains untested. Avoid turning a snapshot into a permanent description of the host.

Check Your Understanding #

1. Identity: why is a hostname insufficient in some environments?
2. Processes: what makes a PID-only correlation unreliable over time?
3. Networks: why do two addresses fail to prove forwarding?
4. Linux: which source distinguishes distribution identity from kernel information?

Next Steps #

User persistence introduces changes whose trigger, identity, and removal need separate evidence. Continue to Module 12: User Persistence to examine the lifecycle of a user-context startup entry. Return to the Red Team Course hub for the full sequence.