Step 127. The Post-Exploitation Checklist — The Beginning After the Shell

Level 2 — Introduction to Security and Attack Skill Basics | Difficulty ★★★☆☆ | Estimated time: 2 hours 30 minutes

Prerequisites: manual recon from Step 125 and linPEAS from Step 126. This is a concept chapter — new command practice is minimal; weaving the commands you already know into "a list" is the main event.

• What you need: your wiki (the personal documentation you made in Step 89), and your recon memos from Steps 125–126. Today’s artifact is not code but one document.
• ⚠️ All exercises in this chapter are for your own lab and legal platforms only. Applying them to unauthorized systems is a crime.

The moment you get a shell is not the end but the beginning — by now this phrase should sound familiar. But unless you decide in advance exactly what "the beginning" is, you will inevitably miss something important in the field. A nervous person’s memory is not to be trusted, and a penetration session can drop at any time. That’s why professionals build checklists and run them mechanically. Today is the day you complete your own post-exploitation checklist v1 — a living document that will keep growing through every future penetration exercise, all the way to Step 272.

1. Learning Objectives

By the end of this chapter, you will be able to:

• Classify and state the items of information to collect right after acquiring a shell
• Organize the commands corresponding to each item in checklist form
• Interpret the meaning of "empty results" and "unviewable results"
• Flip an attacker’s collection list into a defender’s audit list
• Begin the playbook habit of running a checklist and updating it

2. Background Knowledge — Today’s Tools and Concepts

Today’s Tools at a Glance

2-1. Why a Checklist — The Pilot’s Lesson

Airline pilots fly thousands of hours and still read the checklist at every takeoff and landing. "Don’t trust memory; trust the list" — in the professional world, a checklist is part of skill. Penetration testing is the same. In the excited state right after getting a shell, if you leave "what was I supposed to do first" to memory, you miss the information obtainable only in that session (running processes, current network connections) — and then the session drops. The opportunity comes once; the list is forever.

In real work, the destination of everything you collect is fixed — the report (Step 128). Every line you gather now becomes material for the "evidence" section later. A report without collection becomes fiction.

2-2. Five Categories of Collection Items

Here’s what post-exploitation collection looks like divided into five baskets. These are commands you met one by one in Steps 125–126 — today we weave them into a single-page list.

① System identity — what is this machine: uname -a (kernel), /etc/os-release (OS), hostname, uptime. As you saw in Step 125, the kernel version is the key for exploit searches.

② Accounts and privileges — who am I and who’s here: id, /etc/passwd (login-capable accounts), sudo -l, who·w (people active now), last (recent login records).

③ Network — what is this machine connected to: ip a (addresses), ss -tlnp or netstat -antp (open ears), arp -a (neighboring machines). As you saw in Step 126, internal-only ports show up here. And "is this machine talking to other machines right now" is the thread of pivoting (using it as a base to go deeper inside).

④ Stored secrets — keys left inside files: ~/.bash_history (previous command history), passwords in config files (grep -r "password" /etc), exploring home folders, SSH keys (~/.ssh/). People leave secrets in files for convenience, and that is the attacker’s treasure chest.

⑤ Threads of escalation — all of Steps 125–126: the SUID list, cron, writable files, linPEAS candidates. You’ve already learned them, so they only need to be attached to the checklist like links.

2-3. Persistence and Traces — Know Them, But Don’t Use Them Lightly

Two more concepts attach to the checklist.

Persistence — the collective name for techniques that leave a backdoor so you can get back in even if the session drops (adding accounts, planting a reverse connection in cron, etc.). In professional penetration tests, these are used only when permitted by contract, and must be removed after the test ends. At your introductory stage, it’s enough to know — through a defender’s eyes — that "attackers leave backdoors in places like these." That’s how you know where to audit.

Traces — the commands you type remain in logs and history. On the attack side, it’s knowing "traces remain"; on the defense side, it becomes knowing "where to find traces." It’s an extension of the sense with which you read an empty .bash_history in Step 126 as "a clue to trace-management habits." Trace-erasure techniques themselves are not covered in this introductory course — erase your lab’s logs and your learning material disappears.

2-4. Reading It Flipped as a Defender

Every collection item in this chapter flips into an audit item. If an attacker looks at login-capable accounts in /etc/passwd, the defender audits "do only the accounts that truly need shells have them?" If an attacker looks for writable cron scripts, the defender runs the same command in advance and fixes them. One checklist, two professions — like all knowledge in this course.

3. Follow Along

Today’s "follow along" is the process of actually building the checklist document. We use the measured outputs from Steps 125–126 as material.

3-1. Building the Document Skeleton

Create post-ex.md in your wiki and write the five baskets’ skeleton.

# My Post-Exploitation Checklist v1 (2026-09-09)

### ① System identity
- [ ] uname -a        → kernel version (for exploit searches)
- [ ] cat /etc/os-release
- [ ] hostname && uptime

### ② Accounts and privileges
- [ ] id
- [ ] cat /etc/passwd → mark accounts with shells
- [ ] sudo -l
- [ ] who && w && last | head

### ③ Network
- [ ] ip a
- [ ] ss -tlnp  (netstat -antp if unavailable)
- [ ] arp -a

### ④ Stored secrets
- [ ] cat ~/.bash_history
- [ ] cat /home/*/.bash_history 2>/dev/null
- [ ] grep -r "password" /etc 2>/dev/null | head
- [ ] ls -la ~/.ssh/

### ⑤ Threads of escalation (link to Steps 125–126 recon table)
- [ ] find / -perm /4000 -type f 2>/dev/null
- [ ] cat /etc/crontab && crontab -l
- [ ] find / -writable -type f 2>/dev/null | head
- [ ] Re-review linPEAS red/yellow results

How to read it: notice that next to each item, "why it’s collected" is written. Commands without a reason get forgotten; commands with a reason remain.

3-2. Verifying by Actually Running It

A checklist doesn’t end at being written — you must actually run one full round before the gaps become visible. Run the list above from top to bottom on your Linux. Since these are commands you already measured in Steps 125–126, you’ll be able to predict the outputs.

Scenes you’ll meet while running it (reproduced from the 2026-09-09 WSL measurement):

$ crontab -l
no crontab for root

$ cat /root/.bash_history
cat: /root/.bash_history: No such file or directory

$ netstat -antp
bash: netstat: command not found

How to read it: three kinds of "empty results." No personal cron, no history file, no command at all. A beginner thinks "I failed" here; a professional writes an interpretation in the checklist’s comment area — "this environment has no netstat → use ss," "no history → the user manages traces, or it’s a fresh environment." Every time it runs, a checklist fattens with comments like these.

3-3. Also Write the List of "What You Can’t See"

From a low-privilege shell, there are things you simply can’t see. In Step 125’s measurement, /etc/shadow was Permission denied as www-data. Add lines like these to your checklist:

### ⑥ Re-check after escalation (not possible at low privilege)
- [ ] cat /etc/shadow        → capture password hashes after escalation
- [ ] Process names in netstat -antp → some are visible only to root

Why: enumeration doesn’t end in one pass. There’s a separate before-escalation list and after-escalation list. When privilege changes, the visible world changes, so the moment you gain root you run this section of the checklist again.

3-4. The Star System — Marking What Proved Useful

Every time you use the checklist in real labs (MS2, Bandit, Natas), attach a star (★) to the commands that gave a real harvest that day. A few months later, the distribution of stars becomes your own "core command ranking." A book or someone else’s list is only a starting point — the list with stars on it is yours.

3-5. Making a Defensive Copy

Copy the document into post-ex-defense.md and turn each item into a question.

# Audit Checklist (Defensive)
- [ ] Do only the accounts that truly need them have login shells? (the shell column of /etc/passwd)
- [ ] Are there any strange guests in the SUID list? (baseline comparison)
- [ ] Are write permissions closed on scripts cron executes?
- [ ] Are there passwords embedded in config files?
- [ ] Are per-account history and logs being recorded normally?

How to read it: same commands, different questions. The attacker’s "find things to use" list becomes the defender’s "find things to fix" list. The Step 128 report’s "remediation" section comes straight out of this defensive list.

4. Missions & Exercises

Mission — Completing Post-Exploitation Checklist v1 and Its First Round

1. Complete your own post-ex.md based on the skeleton in 3-1 — add, delete, and rearrange items freely
2. Run every item one full round on your Linux, and next to each item write a summary of the actual result and an interpretation
3. Create a "re-check after escalation" section with at least 3 entries
4. Make a defensive copy with at least 5 questions placed
5. Actually use this checklist in your next lab exercise (the MS2 report work in Step 128, etc.), and update at least one spot after using it — a list that isn’t used isn’t a list

Exercises

Exercise 1. Give two reasons why you should rely on a "checklist" rather than "memory" right after acquiring a shell.

Exercise 2. When crontab -l outputs no crontab for root, state the information readable from this result and how to keep it in the checklist.

Exercise 3. Explain the reason for separating a "before-escalation checklist" and an "after-escalation checklist," using the /etc/shadow example.

Exercise 4. Explain the principle by which an attack collection list flips into a defense audit list, picking the SUID item and writing both sentences.

### ② Accounts and privileges  (execution memo example)
- [x] id → uid=0(root). The experiment environment starts as root, so escalation-verification practice happens in the lab ★
- [x] cat /etc/passwd → bash-shell accounts: root only. On a server, user accounts would appear here
- [x] sudo -l → (ALL : ALL) ALL. On a low account, look for NOPASSWD lines first

### ⑥ Re-check after escalation
- [ ] cat /etc/shadow → capture hashes (john material from Step 123)
- [ ] ls -la /root/ → only root enters root's home
- [ ] Full process command lines → some ps aux columns are root-only

6. Common Pitfalls & Fixes

Wall 1. I made the checklist but never run it

Symptom: the document is beautifully complete, but there’s no trace of using it in a real lab.

Cause: you mistook "making it" for the goal. A checklist’s completion is updating after use.

Fix: at your next lab exercise, open the document beside you and proceed crossing off (checking) one line at a time. And when it ends, fix at least one spot without fail — reorder something, or add a comment. A checklist that isn’t updated is decoration.

Wall 2. I copied someone’s giant list verbatim

Symptom: you imported a hundreds-item list from the internet wholesale and now it’s unusable.

Cause: a command whose "why" you don’t know can’t be executed. Not the list’s size but your depth of understanding is skill.

Fix: start with this chapter’s twenty-odd items. A list of 20 that you’ve run yourself and starred is stronger than a copied list of 200. Just add new commands one line at a time, with their "why," as you learn them — this document grows until Step 272.

Wall 3. A command like netstat is missing and I’m flustered

Symptom (measured form): bash: netstat: command not found.

Cause: installed tools differ by system. An old system may lack new commands; a new system may lack old ones.

Fix: don’t panic — write the substitute command side by side in your checklist, like ss -tlnp (netstat -antp if unavailable). The fact that "the command is missing" is itself information about that system, and you can move to the next item.

Wall 4. I collected but didn’t save, so nothing remains after the session ends

Symptom: you worked hard, but closing the terminal left no evidence.

Cause: you don’t yet have the habit of leaving outputs as files.

Fix: make Step 126’s tee your default — for important commands, command | tee -a evidence.txt. In penetration testing, a finding not saved is a finding that never happened. The report (Step 128) is written from these files.

Wall 5. Curiosity drives me to test persistence/traces items outside my lab

Symptom: you get curious — "does a backdoor really work?"

Cause: curiosity is a good thing, but the direction is dangerous.

Fix: remember the boundary — at the introductory stage, the rule for persistence techniques is in your own lab, at concept-confirmation level, removed immediately when done. And recording them in your defensive copy as "places where attackers plant backdoors" is the correct destination of that curiosity. Know, but don’t use lightly — that is this course’s ethics.

7. Summary

Today’s Concepts

Today’s Commands

An Instinct More Important Than Commands

Today you learned not a single new command, yet perhaps you just passed the most practical chapter. Skill comes not from the number of commands you know but from a system that doesn’t omit. What rescues an excited person in front of a shell is not memory but a list, and that list fattens with stars and comments every time it’s used, becoming your own weapon. And the defensive copy that flips that weapon — a list that locks the doors while following the attacker’s footprints — these two volumes will grow together with every exercise ahead of you. Trust the list; but growing the list is your execution alone.

Once every box is checked, Step 127 is complete.