Post-Exploitation in Linux Environments

⚠️ Safety & Ethics

This chapter covers post-exploitation techniques strictly for learning, red-team labs, CTFs, and defensive testing on systems you own or are authorized to test. I will not provide instructions for attacking real targets. Use these skills to understand attacker behavior and to build defenses.

🧭 What is post-exploitation?

Post-exploitation = what you do after you obtain initial access. Goals usually include:

  • Escalating privileges (if needed)

  • Maintaining a foothold (persistence)

  • Discovering credentials and secrets (credential hunting)

  • Lateral movement to other hosts

  • Exfiltrating evidence in a lab (safe practice)

  • Cleaning up and covering tracks (responsible lab hygiene)

In production/real engagements, every action should be authorized and documented.

— Initial checklist once you have a shell (lab)

  1. Triage the environment

    • whoami, id, hostname, uname -a, pwd, ls -la

  2. Check network context

    • ip addr, ip route, ss -tulwn

  3. Check privileges

    • sudo -l, getent group sudo, grep -E "^root:" /etc/passwd

  4. Snapshot / document

    • Save outputs and timestamps for lab report; snapshot the VM before escalatory changes.

— Credential hunting (safe, defensive mindset)

Common places for credentials or tokens (lab-only exploration):

  • /etc/passwd and /etc/shadow (shadow is root-only; never exfiltrate real secrets)

  • ~/.ssh/authorized_keys and private keys in ~/.ssh/

  • Configuration files in /etc/, /opt/, application directories — e.g., config.php, application.yml

  • Backup files: *.bak, *.old, db_backup.sql

  • Environment variables: printenv or files like /proc/<pid>/environ (requires permissions)

  • Docker mounts and volumes that expose host files

Commands to search (lab-only):

				
					# backup file search in home directories
find /home -type f \( -iname "*bak" -o -iname "*backup*" -o -iname "*.old" \) 2>/dev/null

# quick grep for keywords
grep -R --line-number -i "password\|passwd\|secret\|api_key\|token" /home /etc 2>/dev/null

				
			

Defensive note: If you find credentials in a real system, report them—don’t reuse them. In labs, document and then rotate/reset where appropriate.

— Privilege escalation recap & safe approach

If you’re not root, re-check vectors covered earlier:

  • sudo misconfigurations: sudo -l

  • SUID binaries: find / -perm -4000 -type f 2>/dev/null

  • Writable config files for privileged services

  • Cron jobs calling writable scripts

  • PATH issues and binary hijacking

  • Kernel exploits (only in lab/research)

Lab practice: Enumerate, document evidence, and practice remediation (change permissions, fix sudoers, adjust cron ownership) rather than exploit on production.

— Persistence techniques (and defensive countermeasures)

Persistence means ensuring return access. In labs, practice both implementing and removing persistence to understand detection.

Common lab persistence methods (documented, safe to test on your VMs):

  • SSH keys: add a public key to ~/.ssh/authorized_keys

    • Defense: monitor authorized_keys changes, restrict SSH, use key management.

  • Systemd services / cron: add a user systemd unit or a cron job

    • Defense: audit /etc/systemd/system/ and crontab -l, restrict permissions, use file integrity monitoring.

  • Startup scripts: modify /etc/rc.local (older systems)

    • Defense: control startup scripts via package managers and integrity checks.

  • Backdoors via webapps: webshells in webroot (lab-only)

    • Defense: file integrity, WAF, strict upload handling, and monitoring.

Safe lab example — creating and removing a harmless cron job

				
					# lab: add cron for testuser (runs a harmless script)
echo "* * * * * /usr/local/bin/lab_touch.sh" > /var/spool/cron/crontabs/testuser
# cleanup
rm /var/spool/cron/crontabs/testuser

				
			

Defensive action: Monitor crontab directories and set alerts on new entries.

— Lateral movement & pivoting (lab-first)

Lateral movement = using one compromised host to reach others.

Lab techniques to practice:

  • SSH pivoting: use ssh -J or SOCKS proxy via ssh -D for proxying traffic through the host.

    • Example: ssh -D 1080 user@compromised then configure proxychains/browser to route through SOCKS.

  • Port forwarding: ssh -L / ssh -R to forward ports between hosts.

  • Proxychains / socat tunnels: forward traffic from attacker to internal-only services via compromised host.

  • Pass-the-key: use discovered SSH keys (lab-only) to access other VMs.

Defensive countermeasures:

  • Restrict SSH key usage, audit authorized_keys, limit accessible hosts by bastion/jump servers, centralize logging for connections (journald/SSH logs), and enforce network segmentation.

— Data collection & exfiltration (lab practice, safe handling)

In a real engagement, data collection is carefully scoped and documented. In a lab:

  • Collect evidence into an artifacts folder with timestamps.

  • Use tar and compress results for offline review: tar -czf /tmp/lab_artifacts_$(date +%F_%T).tgz /home/user/recon_out

  • Don’t exfiltrate real sensitive data; use dummy data for testing.

Defensive tip: Monitor large archive creation and outbound transfers. Use DLP and egress filtering.

— Covering tracks vs responsible cleanup

Understanding how attackers try to hide activity helps defenders. In lab, practice cleanup but also know that real IR must preserve evidence.

Common cover-up techniques (do not use on real systems):

  • Clearing Bash history: history -c

  • Truncating logs: > /var/log/auth.log

  • Modifying timestamps: touch -t (easy to detect in real forensics)

Responsible approach: In labs, practice cleanup for learning, but always snapshot pre-change and record exactly what you did. For real incidents, involve IR teams and preserve logs and evidence.

Cleanup checklist for lab:

  • Remove added SSH keys and cron entries

  • Delete user accounts you created

  • Revert file permission changes

  • Restore from snapshot if needed

— Detection & defensive controls (what defenders should monitor)

To detect post-exploitation behaviors, ensure these controls are in place:

  • Log aggregation & alerting: collect /var/log/auth.log, syslog, and SSH logs centrally.

  • File integrity monitoring: detect changes to /etc, systemd units, and webroots.

  • Process & network monitoring: watch for unusual processes, reverse connections, or long-lived suspicious sockets.

  • Sudo & command auditing: log sudo usage and review sudo -l changes.

  • Endpoint detection: EDRs that detect suspicious shell activity or unusual persistence patterns.

  • Least privilege: limit user rights to prevent easy lateral movement.

— Tools & utilities (lab-appropriate)

  • ssh, scp, rsync — transport and pivoting basics

  • socat, netcat, proxychains — tunneling and proxies

  • ps, ss, lsof — process & socket discovery

  • grep, find, awk — data hunting

  • auditd, osquery — detection & auditing agents

  • volatility / forensic tools — for deeper analysis (study only)

— Lab exercises (snapshot before starting)

  1. Credential discovery drill

    • Seed a target VM with dummy credentials in various files. Practice finding them with safe grep & find commands. Document and then rotate/delete credentials.

  2. Persistence lifecycle

    • Create a harmless persistence mechanism (user cron or systemd user service), confirm it runs across reboots, then remove it and verify logs show the change.

  3. SSH pivoting

    • Use a compromised intermediate VM to proxy curl traffic to an internal-only web server. Practice setting up ssh -D and configuring proxychains.

  4. Defensive detection

    • Enable auditd rule to watch /etc/ssh/sshd_config and authorized_keys, then attempt a change in lab and observe alerts.

  5. Responsible cleanup

    • After each exercise, revert the VM snapshot or follow the cleanup checklist and verify no artifacts remain.

🧠 How this completes the series

Post-exploitation ties together the Linux fundamentals, permissions, scripting, recon, and lab practice you’ve built through this series. The focus has been learning to think like an attacker while keeping the primary objective: defend, document, and remediate.

🎯 Coming Up Next

Part 13: How to Defend Linux Against Common Attacks — Practical hardening and detection techniques for Linux: secure SSH, lock down services, tighten file permissions, manage SUID/SGID, audit sudo, protect containers, and deploy monitoring and response tools.

💬 Got Questions?

Drop them in the comments or join our community on Discord for exclusive hacking tips and resources.


Don’t worry — mastery comes with practice.
Just open your terminal and hack your brain into CLI mode daily.

Let’s keep building. 💻⚔️

Leave a comment

Index