Post-Exploitation Concepts

By the end of this lesson you will be able to explain what a tester does after gaining access in a lab, why the goal is to measure business impact rather than cause damage, and how to handle evidence and clean up responsibly.

Post-exploitation is everything that happens after you gain access. In the real world it is where a tester shows the client what a break-in would actually mean. This lesson stays at the level of concepts and safe lab practice. It teaches no malware, no data theft and no evasion.

The goal: measure impact, not cause harm

Gaining a shell is not the finish line. The client's real question is: "If an attacker got this far, how bad would it be?" Post-exploitation answers that, carefully and reversibly.

Think of a building safety inspector in Pune who finds an unlocked back door. They do not ransack the building. They note what the open door could reach (the store room, the cash office), photograph the lock, and write it up. A tester does the same with a compromised machine.

Four questions guide ethical post-exploitation:

1. What is this access? Which user am I, and what can that user do?
2. What can it reach? What data and systems become visible from here?
3. How much does it matter? Translate that into business impact for the report.
4. How do I leave it clean? Restore the system and remove anything you added.

Concept: situational awareness

The first safe step is to understand where you are, using harmless read-only commands. On a Linux lab target you learn your identity and surroundings:

id           # which user and groups am I?
hostname     # what is this machine called?
uname -a     # which kernel and OS version?
ip addr      # what networks can this machine see?

uid=1(daemon) gid=1(daemon) groups=1(daemon)
metasploitable
Linux metasploitable 2.6.24-16-server ... i686 GNU/Linux

This tells you a lot. If id shows a normal user, not root, you have limited access, which leads to Privilege Escalation Concepts. The old kernel version in uname is a clue about what the machine is.

Concept: enumeration from the inside

From inside a machine you can see things that were hidden from outside: other network ranges, internal services, configuration files. A tester notes what access would expose, without copying real data out. For example, discovering that a web server can reach a database server on an internal network is an important finding, because it shows how an attacker could move deeper.

This is where the business impact becomes concrete. "I got a shell" is abstract. "From this web server I could reach the internal customer database" is a sentence a manager understands and acts on.

Concept: pivoting

Pivoting means using one compromised machine to reach others that you could not reach directly. Picture a railway junction like Itarsi: you cannot travel from one branch line to another without passing through the junction. A compromised machine can be that junction into an internal network.

For a tester, pivoting demonstrates reachability. In a lab you might show that the web target can talk to a second internal VM. You record the path as a finding: "an attacker on the web server could reach the internal subnet." You only ever pivot inside your authorised scope.

Concept: persistence, and why testers are careful with it

Persistence means keeping access after a reboot, which real attackers want. For a tester it is risky and often out of scope, because it changes the system. If persistence is in scope, a professional:

• Gets explicit written permission for it.
• Records exactly what was added, where, and when.
• Removes every trace during cleanup and confirms removal.

Many engagements forbid persistence entirely. When in doubt, do not.

Evidence, not data

Post-exploitation produces evidence for the report, not a copy of the client's data. Good evidence is the minimum that proves the finding: a screenshot of a shell prompt showing id, a directory listing that proves access, a single masked record rather than a whole table. This script shows the principle by masking sensitive fields before anything is saved as proof:

def mask(value, keep=2):
    value = str(value)
    if len(value) <= keep:
        return "*" * len(value)
    return value[:keep] + "*" * (len(value) - keep)

sample_record = {"name": "Priya Sharma", "phone": "9876543210", "email": "priya@shop.example"}
proof = {field: mask(value) for field, value in sample_record.items()}
print("Original (seen on screen, NOT saved):", sample_record)
print("Saved as evidence:", proof)

Original (seen on screen, NOT saved): {'name': 'Priya Sharma', 'phone': '9876543210', 'email': 'priya@shop.example'}
Saved as evidence: {'name': 'Pr**********', 'phone': '98********', 'email': 'pr****************'}

You prove you could reach the record without storing readable personal data. This respects the client, the data subjects, and the DPDP Act.

Cleanup checklist

Leaving a system as you found it is part of professional work. A simple checklist, tracked in code, keeps you honest:

actions = [
    {"did": "opened a shell session", "needs_cleanup": True, "done": True},
    {"did": "created /tmp/test-marker", "needs_cleanup": True, "done": True},
    {"did": "read /etc/passwd (no copy kept)", "needs_cleanup": False, "done": True},
    {"did": "added a test cron job", "needs_cleanup": True, "done": False},
]

pending = [a["did"] for a in actions if a["needs_cleanup"] and not a["done"]]
print("Cleanup still needed:")
for item in pending:
    print(" -", item)
print("All clean:" , not pending)

Cleanup still needed:
 - added a test cron job
All clean: False

Until that cron job is removed and the system restored (a snapshot rollback does this cleanly), the engagement is not finished. Never hand back a system with your changes still on it.

Common mistakes

• Treating a shell as the goal. The goal is understanding and reporting the impact.
• Copying real data as "proof". Minimum, masked evidence is enough and far safer.
• Adding persistence without permission. It changes the system and is often out of scope.
• Forgetting cleanup. Restore the system and confirm every change is gone.

Key points

• Post-exploitation measures what access means for the business, reversibly and safely.
• Start with read-only situational awareness: who am I, where am I, what can I reach?
• Pivoting shows how an attacker could move deeper; stay inside your authorised scope.
• Persistence changes the system; only with explicit permission, fully recorded and removed.
• Collect minimum, masked evidence, then clean up; a snapshot rollback restores a lab target.

def evidence_ok(item):
    if item["type"] == "full_export":
        return "do not collect"
    if item.get("contains_personal_data"):
        return "mask first"
    return "collect"

for item in [
    {"type": "screenshot", "contains_personal_data": False},
    {"type": "record", "contains_personal_data": True},
    {"type": "full_export", "contains_personal_data": True},
]:
    print(item["type"], "->", evidence_ok(item))