Linux Host Post Exploitation

Linux host post-exploitation

Use this skill to turn a Linux foothold into an evidence-backed host model. Enumerate with a question, validate one privilege edge at a time, preserve credential provenance, and pair every state change with rollback evidence.

When to use

Use this skill after obtaining an approved Linux shell when the task involves:

• host identity, users, groups, namespaces, mounts, services, routes, packages, or security controls;
• sudoers, SUID/SGID, file capabilities, systemd, cron, polkit, PAM/NSS, loader paths, or privileged sockets;
• secret discovery in process state, service configuration, SSH/GPG agents, cloud CLIs, Kubernetes files, CI runners, databases, or backups;
• local privilege escalation validation, including container and user-namespace boundary checks;
• SSH, Kerberos, NFS, database, orchestration, cloud-token, tunnel, or route-based lateral pivots;
• persistence assessment, artifact inventory, audit/EDR visibility, and verified cleanup.

Do not use it for initial-access delivery. Route a kernel vulnerability to linux-kernel-exploitation, an eBPF-specific path to ebpf-offensive, and a container-runtime root cause to the dedicated container owner when present.

Completion standard

A completed case records initial and final identity, builds a privilege graph with evidenced edges, classifies secrets without uncontrolled disclosure, validates only selected paths with negative controls, records telemetry, and proves rollback. A command dump with no boundary model or provenance is not completion.

Core workflow

1. Start an action and artifact ledger

Before broad enumeration, record:

• engagement/case ID and approved host identity;
• UTC time plus local timezone and measured clock offset;
• access method, current shell, parent process, TTY, and network source;
• current UID/GID/groups, capabilities, namespace IDs, SELinux/AppArmor context, and container evidence;
• allowed identities, networks, credential classes, persistence tests, and cleanup requirements;
• commands or APIs that are prohibited because they disrupt service, retrieve cloud tokens, or modify controls.

Store the authoritative ledger off-host when possible. If a local working directory is required, use restrictive permissions, list it in the cleanup manifest immediately, and never write secret values to it.

Each action record should contain:

UTC | operator | current identity | command/API | purpose | expected signal
exit/status | files/processes/network touched | evidence location | rollback status

Hash collected artifacts on acquisition. Record owner, mode, ACL, inode, mount, timestamps, and collection method without changing content merely to inspect it.

2. Establish identity and host truth

Use quiet local sources first:

id -a
umask
printf 'shell=%s tty=%s\n' "$SHELL" "$(tty 2>/dev/null)"
uname -a
cat /etc/os-release
cat /proc/self/status
readlink /proc/self/ns/*
findmnt -rn -o TARGET,SOURCE,FSTYPE,OPTIONS
cat /proc/1/cgroup
systemd-detect-virt --vm --container 2>/dev/null

When available, capture capsh --print, lsns -p $$, getenforce, aa-status, sestatus, systemctl --version, package-manager identity, secure-boot/lockdown state, and kernel command line. Preserve permission failures; they describe the current boundary.

Do not infer the host from the prompt or hostname. Correlate machine ID, boot ID, primary addresses, default routes, cloud/provider evidence, and approved asset inventory. Treat cloned machine IDs and container hostnames as non-unique.

State the current boundary in one sentence:

identity and namespace -> candidate broker/resource -> stronger identity or broader host/network scope

3. Build a privilege graph, not a checklist

Represent nodes as identities, services, namespaces, files, sockets, devices, credentials, and remote principals. An edge records:

• source identity and required groups/capabilities;
• exact executable, config, file, socket, API, or scheduler;
• interpreter and environment behavior;
• target identity and namespace;
• preconditions and race/lifetime assumptions;
• evidence, negative control, side effects, and rollback.

Inventory candidate edge families:

Collect only metadata needed to rank candidates. Restrict recursive searches to intended local mounts; skip procfs, sysfs, devfs, network filesystems, snapshots, and large application trees unless the hypothesis requires them.

Useful candidate commands include:

sudo -n -l
find /usr /bin /sbin /opt -xdev -type f -perm /6000 -printf '%m %u %g %p\n' 2>/dev/null
getcap -r /usr /bin /sbin /opt 2>/dev/null
systemctl list-unit-files --state=enabled --no-pager
systemctl list-timers --all --no-pager
ss -lxnp 2>/dev/null

Do not execute a candidate during inventory. First read its exact unit/config, resolve symlinks with namei -l, inspect ACLs with getfacl, verify package ownership and hashes, and trace how stronger code reaches attacker-controlled state.

4. Rank and validate one edge at a time

Score each edge on:

• stronger identity or boundary reached;
• control over executable, arguments, environment, config, input, or IPC method;
• trigger availability and whether it is automatic;
• reliability and concurrency;
• service impact and rollback quality;
• audit, process, file, and network visibility;
• dependence on an unverified version-specific bug.

For the selected edge, capture a clean baseline. Create a benign marker whose content, path, owner, and lifetime are explicit. Use a negative control that preserves the expected security check, then the minimal positive test. Verify stronger identity using id, /proc/self/status, namespace links, and a harmless operation the original identity cannot perform.

Do not use interactive sudo merely to test policy; sudo -n prevents an unexpected password prompt or timestamp refresh. Record whether a sudo timestamp already existed and whether the test changed it.

If an edge needs a public vulnerability, pin package/build/config and reproduce the root cause in a disposable analog before target validation. Route kernel memory-safety work to linux-kernel-exploitation and generic exploit construction to exploit-dev.

5. Handle capabilities and namespaces correctly

Linux capabilities are per-thread and split into permitted, effective, inheritable, ambient, and bounding sets. File capabilities interact with UID transitions, no_new_privs, securebits, user namespaces, and mount options. Capture all sets before and after an edge.

For namespace context, compare the current process with PID 1 and the approved host boundary:

for n in cgroup ipc mnt net pid time user uts; do
  printf '%-8s self=%s init=%s\n' "$n" \
    "$(readlink /proc/self/ns/$n 2>/dev/null)" \
    "$(readlink /proc/1/ns/$n 2>/dev/null)"
done
cat /proc/self/uid_map 2>/dev/null
cat /proc/self/gid_map 2>/dev/null

UID 0 in a user namespace does not prove host root. A container runtime socket may represent host-level control, rootless-user control, or a remote daemon; identify the peer process, socket owner/ACL, daemon mode, API endpoint, and mounted host resources before assigning impact.

Map seccomp, AppArmor/SELinux, Landlock when observable, cgroups, mount propagation, read-only mounts, device policy, and no_new_privs. A stronger UID may still remain inside the same constrained boundary.

6. Discover secrets by provenance and scope

Start with likely locators, metadata, and process ownership; do not dump every readable file. Classify each candidate:

Potential sources include shell history, environment, process arguments, /proc, service configs, deployment manifests, backups, cloud CLI stores, kubeconfigs, credential helpers, keyrings, and application databases. Access to /proc/PID/environ, memory, agent sockets, or keyrings is itself a security-relevant action; log it and minimize reads.

For each secret, prefer fingerprint, hash, metadata query, or low-impact identity call over printing the value. Keep raw values only in the approved secret store. Never copy them into terminal transcripts, chat, screenshots, case markdown, or command history.

Cloud metadata endpoints are not generic enumeration targets. First establish provider and instance context, then record the exact endpoint, token flow, role, and audit effect. Do not probe every provider address or retrieve role credentials merely to see whether they exist.

7. Validate a credential without expanding scope

Before use, record the approved destination, protocol, principal, expected role, expiry, and one low-impact identity operation. Use host-key validation and a dedicated known-hosts record for SSH. Do not disable TLS or SSH verification to make a credential work.

A valid authentication is not proof of useful authorization. Capture the remote identity and the smallest authorization query, then update the privilege graph. Do not enumerate unrelated projects, shares, clusters, databases, or hosts.

For agents, test a signature or key listing without exporting private material. For Kerberos, preserve cache provenance and ticket flags. For cloud and Kubernetes tokens, avoid refresh unless explicitly needed; refreshing changes lifetime and often creates a new audit event.

8. Model lateral movement as bounded edges

For every pivot record:

source host/identity -> credential or trust -> protocol/route -> destination
remote identity -> allowed operation -> stronger boundary -> expiration/revocation

Candidate channels include SSH certificates/agents, Kerberos keytabs/caches, NFS, database credentials, orchestration APIs, configuration management, CI runners, cloud roles, and existing tunnels. Identify routing and DNS from current state before adding a tunnel or route.

If a tunnel is required, define bind address, destination allowlist, protocol, lifetime, keepalive, authentication, process owner, logs, and teardown. Bind to loopback unless exposure is intentional. Confirm the listener and route are gone at cleanup.

9. Assess persistence with paired rollback

Persistence testing is a configuration transaction, not a list of startup tricks. For each approved mechanism capture:

• authoritative owner and parser;
• trigger and resulting identity;
• original bytes, metadata, labels, ACLs, links, enablement, and package ownership;
• atomic application method and service impact;
• expected audit/process/file evidence;
• exact rollback and post-rollback verification.

Relevant families include system and user systemd units/timers, cron/anacron, shell/profile hooks, SSH authorized_keys or certificates, PAM, loader configuration, package hooks, containers, desktop autostart, and service-specific plugins.

Prefer a benign marker and one trigger. Do not install multiple mechanisms to prove the same boundary. Do not change authentication, logging, EDR, firewall, or update controls as a side effect.

For systemd, retain unit plus drop-ins, FragmentPath, DropInPaths, enablement symlinks, effective properties, service user, sandbox settings, and reload/start events. Removing a unit file without disabling links, reloading the manager, and stopping owned processes is incomplete cleanup.

10. Measure visibility while operating

Inventory active telemetry without disabling it:

• auditd rules/status and relevant audit records;
• journald persistence, forwarding, namespaces, and rate limits;
• auth, sudo, SSH, cron, systemd, package, and kernel logs;
• process accounting and shell/session recording;
• eBPF/Falco/Tetragon-style sensors and their loaded programs;
• EDR agent processes, services, kernel modules, sockets, and health state;
• network DNS/proxy/firewall/flow visibility.

Establish a clean baseline and one known positive control when the test plan includes detection validation. Missing local logs do not prove missing remote ingestion. Record sensor health, clock alignment, event delay, field schema, and collection boundaries.

Correlate each validated edge with process ancestry, effective IDs/capabilities, file changes, service events, network connections, and remote authentication. Route deep detection work to threat-hunting; route BPF sensor mechanics to ebpf-offensive.

11. Clean up and prove final state

Maintain the cleanup manifest from the first write or process creation. It includes files, directories, links, xattrs, ACLs, labels, units, timers, cron entries, keys, credentials, agents, processes, sockets, routes, tunnels, namespaces, containers, mounts, package state, and temporary logs.

Rollback in dependency order:

1. stop tasking, tunnels, listeners, and recurring triggers;
2. terminate owned children and verify no orphan remains;
3. disable and remove persistence, then reload the owning manager;
4. restore original bytes and metadata atomically where possible;
5. remove test credentials/keys and revoke remote artifacts when created;
6. remove local work files after evidence transfer and hash verification;
7. repeat targeted enumeration and compare against baseline;
8. record residual state that cannot safely be reversed.

Do not falsify timestamps or delete platform audit records. Cleanup means removal of operator-created state and restoration of modified configuration, not destruction of evidence.

Key structures & interfaces

• /proc/PID/status, attr, ns, cgroup, fd, maps, cmdline, and environ: identity, confinement, process, and secret provenance.
• UID/GID plus capability sets, securebits, no_new_privs, and user-namespace ID maps: actual privilege state.
• sudoers grammar, aliases, Runas_Spec, tags, command digests, environment policy, and timestamp records: delegated execution contract.
• ELF mode bits, file capabilities, interpreter, PT_INTERP, RPATH/RUNPATH, and secure-exec behavior: executable privilege transitions.
• systemd units, drop-ins, generators, timers, D-Bus methods, enablement links, and manager reload state: service authority.
• cron/anacron/system crontab/user spools: parser, owner, environment, and trigger.
• polkit actions/rules plus D-Bus service policy: desktop/service authorization boundary.
• PAM stacks, NSS databases/modules, dynamic-loader config, and package hooks: identity and privileged load paths.
• UNIX-domain sockets, SO_PEERCRED, filesystem ACLs, abstract namespace, and protocol authorization: local broker boundary.
• mount, user, PID, network, IPC, cgroup, time, and UTS namespaces plus cgroups and LSM labels: container/host boundary.
• SSH agents/certificates, Kerberos caches/keytabs, cloud tokens, kubeconfigs, and service credentials: lateral identity objects.

Tooling

Automated enumeration scripts are collectors, not conclusions. Pin their version, inspect what they execute, constrain output, and map every finding back to a manually evidenced edge.

Evidence outputs

host.md             asset identity, OS/kernel, clock, controls, namespaces, mounts
ledger.jsonl        ordered actions, identity, purpose, effects, evidence, rollback
privilege-graph.csv source, edge, target, preconditions, proof, control, status
secrets.csv         locator/fingerprint, provenance, scope, expiry, storage, disposition
telemetry.md        sensors, health, events, delays, positive/negative controls
cleanup.csv         created/modified state, original evidence, rollback, final proof
artifacts/          approved metadata, configs, logs, hashes, screenshots, captures

Never put raw secret values in these files. Reference the approved secret-store record instead.

Pitfalls & OPSEC

• Do not run noisy recursive searches across network mounts, procfs, sysfs, backups, or application data without a specific hypothesis.
• Do not execute SUID, sudo, service, cron, polkit, or socket candidates during inventory.
• Do not assume UID 0 means host root; prove namespaces, capabilities, mounts, cgroups, LSM, and daemon boundary.
• Do not print secrets to stdout or copy them into shell history, transcripts, process arguments, or markdown.
• Do not disable host-key or TLS verification to validate a credential.
• Do not probe every cloud metadata service; establish provider context and retrieval impact first.
• Do not refresh short-lived credentials unless the operation requires it and the new lifetime is tracked.
• Do not use fixed sleeps for service, scheduler, or race validation; await the exact event with a bounded timeout.
• Do not let an enumeration script silently install packages, change limits, mount filesystems, or upload findings.
• Record command history behavior, TTY/session recording, auditd, journald forwarding, eBPF sensors, and remote ingestion.
• Do not erase audit records or falsify timestamps during cleanup.
• If rollback cannot restore a security-sensitive file, service, namespace, route, or credential, stop changing state and record the residual precisely.

Routing

• Route a Linux kernel bug, allocator primitive, page-table UAF, credential overwrite, or kernel ROP chain to batch-B sibling linux-kernel-exploitation.
• Route verifier/JIT bugs, BPF hooks, maps, links, or BPF sensor mechanics to batch-B sibling ebpf-offensive.
• Route custom beacon runtime, task protocol, module ABI, transport failover, or update behavior to batch-B sibling c2-implant-engineering.
• Route BOF/COFF module development to batch-A sibling bof-coff-development.
• Route Windows RPC, COM/DCOM, NDR, or ALPC service boundaries to batch-A sibling windows-rpc-com-attack.
• Route Windows telemetry-provider and ETW/WPP/TraceLogging work to batch-A sibling windows-telemetry-etw.
• Route Hyper-V guest/root partitions, VMBus, hypercalls, or HCS/worker boundaries to batch-A sibling hyper-v-offensive.
• Route cloud/Kubernetes authorization to cloud-k8s, Windows-domain pivots to offensive-active-directory, generic exploit construction to exploit-dev, and detection correlation to threat-hunting.
• Route a container runtime implementation flaw to container-runtime-exploitation when that catalog target is available; until then keep the boundary evidence with exploit-dev and cloud-k8s rather than improvising host impact.

Final gate

• Initial identity, host, clock, controls, namespaces, mounts, and access path are recorded.
• Privilege graph identifies source, mechanism, stronger target, evidence, and rollback for each tested edge.
• Selected escalation has a negative control and proves the resulting identity and boundary.
• Secret records contain provenance, scope, expiry, and disposition but no raw values.
• Lateral and persistence tests remain within named destinations and use paired rollback.
• Telemetry evidence distinguishes local visibility, sensor health, and remote ingestion.
• Final targeted enumeration and cleanup manifest prove operator-created state is gone.