Chapter 5: Post-exploitation and Lateral Movement
Post-exploitation begins the moment a tester gains an initial foothold inside the target environment. Getting in
was only the first part of the engagement. The work that follows answers the questions the client actually hired
the tester to answer: how far can an attacker get from here, what can they reach, what would they steal or
break, and how would anyone know? A tester escalates privileges, establishes persistence, moves laterally,
collects evidence of impact, and then undoes every change and reports what remains. Every technique in this
chapter is described for use inside an authorized engagement, against systems the tester has written
permission to test, with cleanup and reporting as the mandatory ending. Nothing here is a license to operate
outside scope. The exam tests this domain as judgment as much as technique: knowing which method fits the
target, which one is too loud or too dangerous for a production system, and which action must be documented
rather than hidden.
Figure 21: Post-exploitation workflow from initial foothold through privilege escalation, persistence, lateral movement, collection, and
cleanup (illustrated)
1. The rules before the techniques
Post-exploitation is where an engagement can go wrong fastest, because the tester now holds real access to
real systems. Three rules govern everything that follows. First, stay inside the written scope: the systems,
accounts, and data the client authorized, nothing beyond them. A credential that opens a system outside scope
is a finding to report, not an invitation to explore. Second, prefer the least disruptive method that proves the
point. If a misconfiguration demonstrates privilege escalation, the tester does not need to run a kernel exploit to
prove it twice. Third, document every action as it happens: what was run, on which host, at what time, and what
changed. Those notes become the cleanup checklist and the report evidence.
Post-exploitation proves impact, it does not cause damage. The difference between a tester and an attacker
using the same technique is authorization, restraint, and a cleanup plan. The exam rewards answers that show
restraint: the quieter method, the reversible change, the documented action.
Communication matters as much as technique. Before escalating privileges on a production host or moving
toward a domain controller, the tester confirms with the client point of contact that the action is expected and
that monitoring teams know a test is running. Some engagements run silently to test detection; even then, the
rules of engagement define what is allowed, and the tester never improvises beyond them.
When a question describes a tester about to run an exploit against a production system, the correct answer
usually involves checking authorization, using a safer alternative, or testing in a lab first. The exam punishes
the answer that runs the most powerful exploit first.
2. Persistence mechanisms
Persistence. Any mechanism that lets access survive a reboot, a logoff, or a password change. Attackers use
persistence to keep access; testers use it to demonstrate that an attacker could, and then remove it.
Persistence is the attacker's insurance policy. A foothold that vanishes at the next reboot is a minor incident. A
foothold that returns on its own is a compromise. The exam tests which mechanisms survive what, and which
ones defenders can find.
Windows persistence
On Windows, the classic mechanisms are scheduled tasks, services, registry run keys, and startup items. A
scheduled task runs a program on a trigger, such as system startup or user logon, and it is easy to create and
easy to overlook among legitimate administrative tasks. A malicious or rogue service runs with system privileges
at boot. Registry run keys under the Run and RunOnce keys launch programs at logon, and the startup folder
does the same with a shortcut. These are all file-based: something on disk points at something on disk, which
means a defender who inventories tasks, services, and run keys can find them.
Two Windows mechanisms are harder to spot. A web shell is a small script placed on a web server that executes
commands through ordinary web requests, so the persistence lives inside an application the organization
already runs. A WMI event subscription is fileless: it binds a trigger, such as a timer or a system event, to an
action, such as running a command, with no file and no scheduled task to inspect. WMI subscriptions survive
reboots and hide from the usual task and service listings, which is exactly why they appear in exam questions
about stealthy persistence.
Web shell. A script uploaded to a web server that lets an attacker run commands through normal web
requests. The server's own legitimate function becomes the attacker's access channel.
Linux and domain persistence
On Linux, persistence lives in cron jobs, systemd service units, and SSH authorized keys. A cron entry runs a
command on a schedule, including at reboot, and a systemd unit can restart a process whenever it stops. An
SSH key added to a user's authorized_keys file grants access as that user without a password, and it survives
password changes entirely. On any domain-joined network, Group Policy logon scripts are a domain-wide
persistence path: a script assigned through policy runs on every machine in scope at logon, so one change
reaches the whole fleet.
Establishing persistence safely inside an engagement follows a fixed order:
1. Confirm the mechanism is inside the written scope and the client expects it.
2. Choose the most reversible mechanism that proves the point.
3. Record the exact change: the task name, the service name, the key path, the file location.
4. Verify the persistence works by rebooting or logging off and confirming return access in the lab or
maintenance window.
5. Schedule its removal as part of cleanup, and verify the removal afterward.
Exam questions love to ask which persistence mechanism survives a reboot. Scheduled tasks, services, WMI
subscriptions, cron jobs, systemd units, and SSH keys all do. A process running in memory does not. Fileless
does not mean invisible: WMI subscriptions can be found by enumerating event subscriptions, which is the
defender's answer.
On your own lab virtual machine, create a scheduled task that writes the current date and time to a text file
every time you log on. Log off and back on, confirm the file updated, then find the task in the task scheduler,
examine its trigger and action, and delete it. You have now practiced both halves of persistence: creating it and
finding it again. Only ever do this on machines you own.
3. Windows privilege escalation
Privilege escalation turns a low-privilege foothold into administrative control. The disciplined order is
enumeration first, misconfiguration second, exploit last. A tester who runs an exploit before checking for a
misconfigured service wastes a loud action on a problem a quiet configuration change would have solved, and
risks crashing the host for nothing.
Enumeration means learning the context: the current user and groups, the privileges held, the services running
and their configurations, the patch level, and the files and credentials lying around. From there, the
misconfigurations below are the exam's favorites.
Service misconfigurations
An unquoted service path is a path containing spaces that is not wrapped in quotes, such as a service binary at
C:\Program Files\My App\service.exe. Windows resolves such a path by trying each space-separated prefix in
order, so if an attacker can write an executable to an earlier prefix, such as C:\Program Files\My.exe, the service
runs it with the service's privileges when it restarts. Two conditions must both hold: the path must be unquoted
and contain a space, and the attacker must be able to write to one of the earlier directories.
Unquoted service path. A Windows service binary path containing spaces but not enclosed in quotation
marks, which Windows resolves by trying each prefix in turn. A writable early prefix lets an attacker plant an
executable the service will run.
Weak service permissions are a sibling flaw: a service whose configuration a low-privilege user can modify, or
whose binary a low-privilege user can replace. If the tester can change what the service runs, the next service
restart runs it as the service account, often SYSTEM. The fix is the same in both cases: quote the path, tighten
the directory and service permissions, and run services with the least privilege they need.
AlwaysInstallElevated is a pair of Windows Installer policies, one for the machine and one for the user, that
together let any user install a crafted package with elevated privileges. Both policies must be enabled for the
attack to work, which is the detail the exam tests. A tester who finds both set can demonstrate escalation with a
test package; an administrator who finds both set should turn at least one off.
Tokens, hijacking, and credentials
Token impersonation. The technique of stealing or borrowing another user's access token, usually from a
running process or service, and using it to act with that user's privileges. Tokens belonging to SYSTEM or a
domain administrator are the prize.
Token impersonation exploits the way Windows services and scheduled processes hold tokens. A process
running as SYSTEM leaves a token the attacker can steal if their own process holds the impersonation privilege,
which many service accounts do. The practical defense is least privilege: services should not run as SYSTEM
when a dedicated service account will do, and impersonation privileges should be granted narrowly.
Kernel exploits are the last resort, not the first tool. A kernel vulnerability can crash the host or corrupt data, and
on a production system that risk needs explicit client approval, a maintenance window, and ideally a tested
snapshot or backup first. The exam's judgment questions favor the tester who checks for misconfigurations first
and treats a kernel exploit as a lab-verified, client-approved escalation, never a casual opening move.
DLL hijacking abuses the order in which Windows searches for the libraries an application loads. If an application
loads a DLL by name without a full path, and an attacker can place a malicious DLL earlier in the search order,
the application loads the attacker's code with its own privileges. The classic conditions are a writable application
directory or a writable path entry, and an application that runs elevated.
Credential hunting is the quietest escalation of all, because it needs no exploit. Configuration files, deployment
scripts, registry values, and saved credentials often contain passwords in clear text or weakly protected form. A
tester who finds a service account password in a config file has escalated without touching a vulnerability. The
exam tests this as a methodology point: check files and configurations before exploits.
User Account Control bypass techniques abuse Windows components that run elevated without prompting, or
abuse auto-elevation behavior, to cross from a standard user to an administrator without a consent prompt. The
defense is the same principle as everywhere else: standard users should not be local administrators, and UAC
should be set to prompt rather than silently elevate.
Unquoted service path questions always hinge on two facts: the path has a space and is unquoted, and the
attacker can write to an early directory. If either is missing, the attack fails. AlwaysInstallElevated questions
always hinge on both policies being enabled. One policy alone is not enough.
A tester at CertCrack.com finds a service with the binary path C:\Program Files\CertCrack App\agent.exe,
unquoted, and the tester can write files to C:\Program Files but not to C:\ or to the application's own directory.
What planted file would the service execute on restart, and why?
Answer: An executable named CertCrack.exe placed in C:\Program Files, because Windows tries the prefixes in
order: C:\Program.exe first, which the tester cannot write, then C:\Program Files\CertCrack.exe, which the
tester can write, before ever reaching the full path. The space in the path and the missing quotes create the
opening; the write permission decides which prefix is usable.
4. Linux privilege escalation
Linux escalation follows the same discipline: enumerate first, then abuse misconfiguration, then consider
exploits. The enumeration targets are the kernel and distribution, the user's sudo rights, SUID binaries,
capabilities, cron jobs, writable configuration files, and network services.
SUID, sudo, and writable files
SUID. The set-user-ID permission bit, which makes a program run with the file owner's privileges, usually root,
regardless of who launches it. A SUID binary with a flaw, or a SUID binary that shells out, is a direct path to
root.
SUID binaries are the first stop because they are common and enumerable with one command. Most SUID
binaries are harmless, but a SUID text editor, file finder, or scripting interpreter can be abused to read protected
files or spawn a root shell. The defense is to audit the SUID list and remove the bit where it is not needed.
Sudo abuse is the second stop. Running sudo with the list option shows exactly what the user may run, and what
they may run as. A user allowed to run an editor, a package manager, or a file copy tool as root can usually turn
that into a full shell, and NOPASSWD entries remove even the password barrier. Wildcards in sudo rules are a
classic flaw: permission to run a command with any argument is permission to run it dangerously. The defense
is narrow sudo rules, no wildcards, and no editors or shells in the allowed list.
Writable configuration files are a quiet path: a writable password file, a writable cron file, or a writable service
definition lets the tester rewrite what root trusts or runs. Cron and PATH hijacking are the scheduled variants. A
cron job that runs a script a low-privilege user can edit will run the attacker's code as the job's owner, often root.
A cron job or script that calls a command by bare name, such as backup, resolves that name through the PATH,
so a writable early PATH directory lets the attacker plant a fake command the job will run as root.
Capabilities, network shares, and containers
Linux capability. A fine-grained privilege, such as cap_setuid or cap_dac_override, granted to a program
instead of full root access. A program with a dangerous capability can often be abused into full root anyway,
which is why capabilities must be audited like SUID binaries.
Capabilities are the modern, finer-grained version of SUID: instead of full root, a binary gets one powerful ability.
That ability is often enough. A binary with cap_setuid can change its user ID to root. A binary with
cap_dac_override can read any file. Enumerating capabilities is part of the same audit as enumerating SUID
binaries.
NFS with no_root_squash is a network path to root. Normally, NFS maps remote root to an anonymous user,
which is called root squashing. With no_root_squash, a remote root user keeps root privileges on the share, so a
tester with root on their own machine can mount the share, plant a SUID binary, and run it on the target to gain
root there. The fix is root squashing, or better, not exporting writable shares to untrusted networks at all.
The Docker socket and API are a container-escape path. A user in the docker group, or with write access to the
Docker socket, can start a container with the host filesystem mounted and read or write anything on the host,
including the root directory. The Docker API exposed on a network port without authentication is the same flaw
remotely. The defense is strict: the docker group is effectively root, so membership must be treated as
administrative, and the socket and API must never be exposed beyond trusted administrators.
A sound Linux enumeration order is:
1. Identify the user, groups, and kernel version.
2. List sudo rights and look for wildcards and dangerous commands.
3. List SUID binaries and capabilities, and check each against known abuses.
4. Inspect cron jobs, systemd units, and writable configuration files.
5. Check NFS exports, Docker access, and other network services.
6. Only then consider kernel or application exploits, in a lab first.
Sudo questions usually turn on one line of output: what the user may run, as whom, and whether a password
is required. A NOPASSWD entry for an editor or a wildcard argument is the finding. NFS questions always turn
on no_root_squash: without it, remote root is squashed and the attack fails.
A tester at CertCrack.com finds an NFS export shared with no_root_squash to the tester's lab network, and the
tester holds root on their own lab machine. What is the escalation path, in outline?
Answer: Mount the export from the lab machine as root, place a SUID binary on the share, then execute that
binary on the target host, where it runs with root privileges because the share does not squash remote root.
The key facts are no_root_squash and the tester's own root access on their own machine.
5. Lateral movement
Lateral movement is moving from one compromised host to another, using the credentials, sessions, or trust
already present. The exam distinguishes methods, which are how you move, from authentication attacks, which
are how you obtain or reuse the credentials that let you move.
Remote execution methods
The remote execution methods are the workhorses. PsExec uses SMB and a remote service to run commands on
another Windows host. WMI executes processes remotely through the management interface, often without
dropping a service binary. WinRM is PowerShell remoting over HTTP or HTTPS, the standard administrative
channel, and it looks like legitimate administration because it is. RDP gives a full interactive desktop session,
which is powerful and also the noisiest option, leaving clear logon artifacts. Remote scheduled tasks create a
task on another host to run a command at a set time, which doubles as both movement and persistence. On the
Linux side, SSH keys harvested from one host open every host that trusts the same key, and shared credentials
in network shares or scripts open whatever they were written for.
Credential and ticket attacks
Pass-the-hash. An attack that reuses a captured NTLM password hash to authenticate as a user without
knowing or cracking the plaintext password. The hash itself is the credential for NTLM authentication.
Pass-the-hash works because NTLM accepts the hash as proof. A tester who captures a hash, for example from a
local security database, can authenticate to other hosts as that user wherever the same hash is valid, which is
common when local administrator passwords are shared across machines. The defenses are unique local
administrator passwords per host, disabling NTLM where Kerberos suffices, and protecting privileged accounts
from hash exposure.
Pass-the-ticket. An attack that reuses a captured Kerberos ticket, usually a ticket-granting ticket or a service
ticket, to authenticate as the ticket's owner without knowing the password.
Pass-the-ticket is the Kerberos counterpart: tickets are time-limited credentials, so a captured ticket grants
access until it expires. Overpass-the-hash bridges the two worlds: the tester feeds a captured NTLM hash into
the Kerberos process to obtain a ticket-granting ticket, converting hash access into ticket access.
Golden ticket. A forged Kerberos ticket-granting ticket created with the krbtgt account's hash. It grants access
to any service in the domain and can be given a long lifetime, which is why krbtgt compromise is a
domain-wide emergency.
Silver ticket. A forged Kerberos service ticket created with a single service account's hash. It grants access to
that one service only, and it never contacts a domain controller, which makes it quieter and harder to detect
than a golden ticket.
Golden and silver tickets are the exam's favorite pair to confuse, and the distinction is clean: golden tickets need
the krbtgt hash, work for any service, and represent full domain compromise. Silver tickets need only one
service account's hash, work for that service alone, and avoid the domain controller entirely, so they leave fewer
traces. Both are forgery, not theft: the tester creates tickets rather than stealing them, which is why the defense
is protecting the hashes and monitoring for anomalous ticket lifetimes and properties.
Kerberoasting. An attack that requests Kerberos service tickets for accounts with service principal names,
then cracks those tickets offline to recover the service accounts' passwords.
Kerberoasting works because any authenticated user can request a service ticket, and the ticket is encrypted
with the service account's password hash. Offline cracking then runs at the attacker's speed, with no lockout
risk, which is why weak service account passwords fall quickly. The defenses are long, random service account
passwords, managed service accounts, and monitoring for unusual ticket requests.
DCSync. An attack in which a tester or attacker with directory replication rights impersonates a domain
controller and requests password hashes from a real domain controller, including the krbtgt hash.
DCSync is not a vulnerability in the usual sense: it abuses a legitimate replication feature. An account holding the
replication rights can ask a domain controller for the hashes of any account, which is exactly what a backup
domain controller does. The defense is guarding those rights fiercely, since granting them to an ordinary
account is effectively granting domain compromise, and monitoring replication requests from hosts that are not
domain controllers.
The double-hop problem
The double-hop problem appears whenever credentials must cross two boundaries: the tester authenticates to a
first host, and from there tries to reach a second resource. With NTLM, the credentials do not delegate to the
second hop, so the second connection fails or arrives anonymous. The standard answers are Kerberos
constrained delegation, CredSSP, or simply running the action directly from the intermediate host instead of
through it. Exam questions that describe a successful first connection and a failed second one are usually testing
the double-hop problem.
A lateral movement path inside an engagement follows a fixed order:
1. Validate the credential: whose account is it, what does it reach, and is using it inside scope?
2. Choose the quietest method the target supports, preferring administrative channels already in use.
3. Move, and verify access without changing anything on the target yet.
4. Record the path: source host, method, credential type, destination, and time.
5. Stop at the boundary the client set, even if the next hop looks open.
Figure 22: Lateral movement path from a compromised workstation through a file server to a domain controller, showing credentials,
methods, and trust at each hop (illustrated)
Pass-the-hash needs NTLM and a shared hash; it fails where NTLM is disabled or the account is protected.
Golden tickets need krbtgt; silver tickets need only a service account hash and never touch a domain
controller. Kerberoasting targets service account passwords, and DCSync targets replication rights. If a
question names the prerequisite, it usually names the answer.
A tester at CertCrack.com compromises a service account's hash but has no access to the krbtgt hash. The
tester wants access to one file server's file service without contacting a domain controller. Golden ticket or
silver ticket, and why?
Answer: Silver ticket. It is forged with the service account's hash, grants access to that one service, and never
contacts a domain controller. A golden ticket would require the krbtgt hash and would grant domain-wide
access, which the tester does not have and does not need.
6. Pivoting and tunneling
Pivoting. Using a compromised host as a stepping stone to reach networks and hosts that are not directly
accessible from the tester's machine.
Once a tester controls a host inside a segmented network, that host becomes a doorway. Pivoting routes the
tester's traffic through it to reach internal systems, and tunneling wraps that traffic so it passes through the
allowed channels.
Forwarding types
SSH dynamic forwarding creates a SOCKS proxy on the tester's machine: traffic sent to the proxy is forwarded
through the SSH connection to the compromised host, which then connects onward to internal targets.
Combined with a proxy-aware toolset, such as proxychains, this lets ordinary scanning and web tools work
through the pivot as if the tester were inside the network. Local port forwarding binds one port on the tester's
machine to a port on an internal target through the SSH host, which is ideal for reaching one specific service,
such as an internal web application. Reverse port forwarding runs the other way: the compromised host, which
cannot accept inbound connections because of a firewall or NAT, connects out to the tester and brings a port
back with it, so the tester can reach an otherwise unreachable service.
Double pivots chain two compromised hosts: the tester reaches the second network only through the first host,
which reaches it through the second. Each hop adds latency and fragility, and each hop must be documented,
because a chain that breaks mid-engagement strands the tester and leaves processes running on two hosts
instead of one. VPN pivoting is the heaviest option: routing through a compromised host as if it were a gateway,
or establishing a VPN tunnel from it, gives broad network access but is noisy, hard to scope, and rarely justified
when a SOCKS proxy or a single forwarded port proves the same point.
Figure 23: Pivoting chain from the tester through a DMZ host to an internal network, showing SOCKS dynamic forwarding, a local
forward, and a reverse forward (illustrated)
Reverse forwarding is the answer when the target cannot accept inbound connections, such as a host behind
NAT or a strict firewall. Local forwarding is the answer for one specific internal service. Dynamic SOCKS
forwarding is the answer for broad access to many internal targets. If the question says "the host cannot
receive inbound connections," reverse is the direction.
Between two machines you own, such as a lab virtual machine and your own workstation, set up SSH local port
forwarding to a service running on the second machine, then reach that service through localhost on the first
machine. Confirm the service responds, then close the tunnel and confirm it stops responding. You have
practiced the full pivot lifecycle: open, use, and close. Never forward ports on systems you do not own.
7. Data collection and exfiltration
Collection is gathering the evidence that demonstrates impact: configuration files, database records,
documents, credentials, or whatever the engagement's objectives define. Staging means gathering that material
to one controlled location first, rather than copying it from host to host, which limits spread and makes the final
accounting possible.
Staging, channels, and egress testing
Staging. Collecting gathered material to a single controlled location before transport, so the tester knows
exactly what was taken, from where, and where it now sits.
Exfiltration is moving staged material out, and it is the most sensitive action in the engagement. Compression
and encryption serve two purposes: they shrink the material for transport, and they protect it in transit so that
client data is not exposed if intercepted. The channels themselves are the exam's focus. DNS exfiltration
encodes data in DNS queries, which pass through most firewalls because name resolution is essential, but it is
slow and produces distinctive query patterns. ICMP exfiltration hides data in ping payloads, which works only
where ICMP is allowed out. Authorized cloud-storage channels, such as uploading to a client-approved storage
bucket, look like ordinary business traffic, which is precisely why they require explicit written authorization: a
legitimate-looking channel is still exfiltration without permission.
Egress testing is the safer sibling: instead of moving real data, the tester sends harmless canary strings or test
files through candidate channels to learn what the network allows out. The result proves the egress path exists
without putting client data at risk. Whatever the channel, the rules are fixed: take only what the objectives
require, handle staged material as confidential evidence, transport it encrypted, and delete tester-side copies
when the engagement's retention rules say so.
Exfiltration in an engagement proves a path, not a haul. The smallest sample that demonstrates the impact is
the right sample. A tester who copies an entire database when one record proves the point has failed the
judgment test, not passed it.
DNS exfiltration questions usually hinge on two facts: DNS is almost always allowed out, and encoded queries
are slow and detectable by volume and entropy. ICMP exfiltration questions hinge on ICMP being allowed out
at all. Cloud-upload questions hinge on authorization: the channel looks legitimate, so the written permission
is the control.
8. Covering tracks, and why testers document instead
What attackers hide
Attackers cover their tracks to stay hidden and to frustrate investigation. The techniques are straightforward:
clearing logs removes the record of what happened, timestomping changes file timestamps to blend malicious
files in with legitimate ones, and tampering with audit policy stops new events from being recorded at all. A
tester must understand these techniques because the exam tests recognition: a gap in logs, timestamps that do
not match the surrounding files, or an audit policy that changed mid-incident are all indicators that someone hid
activity.
Timestomping. Changing a file's timestamps, usually to match legitimate system files, so the file blends in and
its true creation or modification time is hidden.
What testers do instead
But a tester in an authorized engagement does the opposite of covering tracks. The whole point of the test is for
the client to see the attack, measure detection, and fix the gaps. Clearing logs destroys the evidence the client
needs to improve, and it can destroy evidence the client needs for legal or regulatory reasons. Tampering with
audit policy blinds the defenders the tester is supposed to be helping. The professional standard is
documentation: every action recorded in notes, every change listed for cleanup, every finding reported with its
evidence intact. If a specific technique would destroy evidence or break a detection the client wants to measure,
the tester raises it with the point of contact before acting, and skips it if approval is refused.
In an engagement, documentation replaces stealth. A tester who hides their actions has made the test
unmeasurable and the report unverifiable. The notes are the product as much as the findings.
A question that offers "clear the logs to avoid detection" as an option for a penetration tester is a trap. The
correct answer for a tester is to document the action and report it. Log clearing belongs in the attacker's
column, and recognizing it belongs in the defender's column.
9. Cleanup, restoration, retesting, and residual-risk reporting
The cleanup checklist
An engagement is not over when the testing stops. It is over when the environment is restored, the cleanup is
verified, and the client knows what risk remains. Cleanup is a checklist, not an intention, and it is worked in
order:
1. Remove every persistence mechanism created: scheduled tasks, services, run keys, startup items, web
shells, WMI subscriptions, cron jobs, systemd units, SSH keys, and logon scripts.
2. Remove every account, credential, and backdoor added during the engagement.
3. Restore every configuration changed: service permissions, audit settings, firewall rules, and files modified.
4. Remove staged and collected data from tester systems, following the engagement's retention rules, and
confirm encrypted transport copies are handled the same way.
5. Verify the removal: re-check the task list, service list, run keys, subscriptions, cron tables, and authorized
keys on each affected host.
6. Retest access: confirm the tester's credentials, keys, and persistence paths no longer work.
7. Report residual risks: vulnerabilities that could not be fixed during the engagement, risks the client
accepted, and any change that could not be fully reversed, with the reason stated plainly.
Residual risk. The risk that remains after remediation and cleanup: unpatched vulnerabilities, accepted risks,
and changes that could not be fully reversed. It is reported, not hidden, so the client can decide what to do
about it.
Retesting is what separates a cleanup claim from a cleanup fact. A tester who says access was removed but
never tries the old credential has not verified anything. The retest is usually brief: attempt the removed
persistence, attempt the old credential, confirm both fail, and record the result. Where remediation was the
client's job, such as patching a vulnerability found during the engagement, a follow-up retest after the client's fix
confirms the finding is actually closed.
The final report closes the loop the engagement opened. It states what was tested, what was found, what was
exploited and with what impact, what was cleaned up and verified, and what risk remains. Residual risk deserves
its own section, because a client who believes everything is fixed will not fund the remaining work. Honest
residual-risk reporting is what makes the next engagement, and the client's security program, better.
Cleanup verified by retest is the last finding of every engagement. An engagement that ends with access still
open has failed, no matter how good the findings were.
A tester at CertCrack.com finishes testing and removes a scheduled task, a WMI subscription, and an SSH key
created during the engagement. What two verification steps remain before the engagement can be
considered clean?
Answer: Re-check each affected host for the removed mechanisms, and retest the old access paths to confirm
they no longer work. Removal without verification is only a claim; the retest is what turns it into a fact.
Chapter check
1. A tester at CertCrack.com wants persistence on a Windows host that survives reboots but leaves no file or
scheduled task for defenders to inventory. Which mechanism fits?
A. A startup folder shortcut
B. A WMI event subscription
C. A process running in memory
D. A registry Run key pointing to a script file
2. A Windows service runs from the unquoted path C:\Program Files\CertCrack Tools\agent.exe, and a
low-privilege tester can write to C:\Program Files but not to C:\ or to the application's own directory. Which
planted file would the service execute on restart?
A. C:\Program.exe
B. C:\Program Files\CertCrack Tools\agent.exe, replaced in place
C. C:\Program Files\CertCrack Tools\CertCrack.exe
D. C:\Program Files\CertCrack.exe
3. A tester forges a Kerberos ticket that grants access to every service in the domain and sets it to last for
months. Which ticket is this, and what hash was required to create it?
A. A golden ticket, created with the krbtgt hash
B. A silver ticket, created with the krbtgt hash
C. A golden ticket, created with a service account hash
D. A silver ticket, created with a service account hash
4. An attacker with no special privileges requests Kerberos service tickets for accounts with service principal
names, then cracks the tickets offline to recover passwords. What is this attack?
A. DCSync
B. Pass-the-hash
C. Kerberoasting
D. Overpass-the-hash
5. An account with directory replication rights asks a domain controller for password hashes, including the
krbtgt hash, while pretending to be another domain controller. What is this attack?
A. DCSync
B. Kerberoasting
C. Pass-the-ticket
D. Golden ticket forgery
6. A tester with root on their own lab machine mounts an NFS export shared with no_root_squash, plants a SUID
binary on the share, and runs it on the target host. Why does this yield root on the target?
A. NFS encrypts the binary, so the target trusts it
B. The target's firewall allows NFS traffic by default
C. The share's permissions grant all users read access
D. Remote root is not squashed, so the binary runs with root privileges on the target
7. A tester authenticates to a first host, then from that host tries to reach a file share on a second host, but the
second connection arrives without credentials. What problem is this, and which approach addresses it?
A. Token impersonation, addressed by stealing a SYSTEM token
B. The double-hop problem, addressed by Kerberos delegation or running the action from the intermediate
host
C. Pass-the-hash, addressed by cracking the hash first
D. A WMI subscription failure, addressed by restarting the service
8. A penetration test at CertCrack.com is finished. The tester removed all persistence and restored all
configurations. What must happen before the engagement can be considered clean?
A. The tester clears the event logs to remove traces of the test
B. The tester keeps one backup access path in case retesting is needed
C. The tester verifies removal on each host and retests the old access paths to confirm they fail
D. The tester deletes the final report to protect sensitive findings
Answer key: 1. B - 2. D - 3. A - 4. C - 5. A - 6. D - 7. B - 8. C
Post-exploitation Toolkit: C2, Tunnels, and the Humble Netcat
Chapter 5 covered persistence, privilege escalation, and movement. The objectives name the tooling for this phase almost as a short story: a collaborative C2 to run the operation (Covenant), a tunnel to reach what the foothold can see (sshuttle), the enumeration that picks the next target (PowerView, introduced in Chapter 4), and the utility that has been on every compromised machine since before frameworks existed (Netcat).
Covenant (collaborative .NET C2). Covenant. A command-and-control platform built on .NET, operated from a browser by multiple testers at once. Its implants are called Grunts; tasking, output, and captured data are shared across the team in real time. Engagements choose it when several operators must run one Windows-focused operation together — the collaborative design is the distinction the exam tests.
sshuttle (the poor tester's VPN). sshuttle. A transparent proxy that needs nothing on the far side but an SSH server and Python: it routes the subnets you name through the SSH connection so your local tools behave as if your machine sat inside the target network. No server admin rights, no per-tool proxy configuration — the standard answer when the scenario gives you "only SSH access to a jump host."
Netcat (the TCP/IP Swiss Army knife). Netcat. The original network utility: connect, listen, transfer, relay. In post-exploitation it is the fallback that works when nothing else can be installed — a reverse shell with nc target port -e /bin/bash (or a FIFO where -e is compiled out), a file pushed through a raw connection, a manual relay chained through a dual-homed host to reach a segment with no route. It is plaintext, unauthenticated, and utterly unaudited — which is also why defenders hunt for it, and why finding it on a server is a finding in itself.
Pivoting is a routing decision. Every post-exploitation tool in this section exists to answer one question: from this host, what can I now reach? Covenant extends control, sshuttle and Netcat relays extend reach, and PowerView's enumeration decides where reach matters. Exam scenarios describe the reach problem first ("no route to the database segment," "only SSH on the jump host") and expect the tool that changes the routing — not the tool that exploits the next host, which comes after.
| Need after the foothold | Tool | Why this one |
|---|---|---|
| Team-run C2 on Windows targets | Covenant | Multi-operator, .NET Grunts, shared tasking |
| Reach a whole subnet via one SSH login | sshuttle | Transparent routing, no server admin, no per-tool config |
| A shell or relay on a bare minimal host | Netcat | Already installed, tiny, binds shells and pipes |
| Choose the next domain target | PowerView | Users, groups, shares, ACLs from a user shell |
"Only SSH" is sshuttle's ringtone. When a scenario restricts the tester to SSH credentials on a jump host and asks for subnet-wide access for local tools, the answer is sshuttle — not Proxychains (per-program, proxy-aware apps only) and not a Netcat relay (one connection at a time, by hand).
Post-exploitation Toolkit. Question. A dual-homed internal host can see both the tester's segment and a database segment the tester cannot route to. The tester chains a listener and a FIFO on that host so connections pass through. Which utility, and what is this technique called? Answer: Netcat, used as a manual relay — the simplest form of pivoting.
Want the full CompTIA PenTest+ (PT0-003) package?
This guide is free to read. Get the full PT0-003 practice exam — 750 questions plus 10 PBQs — with the complete PDF and online access.
Get PT0-003 Full Access — $10