Looting: Evidence of Impact

You have a shell. You escalated to administrator. You moved laterally to the file server. None of that, on its own, ends an argument — because a finding without demonstrated impact is easy to dismiss. The person who has to fund the fix will ask the only question that matters to a business: so what? So what if you got code execution on a server nobody important uses? So what if you have an account, if that account can't touch anything sensitive?

Looting answers that question with evidence. It is the act of going from access to proof of consequence — demonstrating, concretely, that the foothold you established leads to something the organization cares about losing: regulated customer records, source code, financial data, the credentials that unlock the rest of the estate. The word "looting" is borrowed from the attacker's playbook, but the tester's goal is inverted. A real intruder loots to profit. You loot to prove — to make the risk undeniable so it actually gets fixed.

This is the heart of the lesson, so it comes before any technique: demonstrate impact without causing harm. Your job is to prove you could reach sensitive data — not to exfiltrate the real, sensitive data itself. The moment you copy a live table of customer records out of the environment to "show" you had access, you have stopped testing and started breaching. You have created the exact loss you were hired to prevent, and you may now be holding regulated data you have no lawful basis to possess.

The proof and the harm are separable, and a professional always takes the proof without the harm. Instead of downloading a table of real customer records, you capture the smallest artifact that makes the point:

• A redacted screenshot — the query result on screen with names, numbers, and identifiers blacked out, leaving only enough structure to prove the data was reachable.
• A record count — SELECT COUNT(*) returns "1,840,221 rows" and proves the scale of exposure without revealing a single row.
• The table schema — column names like ssn, card_number, dob prove what kind of data sits there without exposing any of it.
• A single sanitized sample — one row with the sensitive fields masked, included only when a structural example genuinely strengthens the finding.

The hard rules around all of this: never remove real PII, PHI, or financial data from the client environment, and stay strictly inside the agreed scope. A reckless "loot" is not a clever flex — it can itself become a reportable breach, with the tester as the cause. When you are unsure whether an action crosses the line, the answer is to capture less, not more.

Good evidence is convincing and safe at the same time. It shows a skeptical reader that the access is real, what it reaches, and how serious that is — while never becoming a liability in your own hands. The strongest reports pair each claim of access with a specific, captured artifact. A few of the workhorses:

Notice the pattern: in every row the proof is the context — whose machine, what privilege, what kind of data, at what scale — not the raw secret itself. A redacted screenshot of a million-row table beats a stolen copy of that table on every axis that matters: it is more ethical, more defensible, and just as persuasive to the person deciding whether to fund the fix.

Evidence is only as good as its provenance. A blurry, undated screenshot with no command context is easy to argue with; a clean, reproducible record is not. Build every artifact so a defender can trust it and retrace it:

• Timestamp everything. Note when each artifact was captured. A defender will cross-reference your timeline against their logs — and the gaps where nothing was logged are themselves a finding.
• Record the exact commands. Copy the literal command you ran and its output. "I accessed the database" is a claim; the exact query and its COUNT(*) result is evidence.
• Screenshot with context. Frame the shot so the hostname, the prompt, and your identity are visible in the same image. The client should be able to reproduce the step and arrive at the same place.

Some of what you collect is itself dangerous to hold. Credential material — password hashes, API tokens, session cookies, private keys — must be handled like the live ammunition it is: stored encrypted, transmitted only over secure channels, never pasted into a chat or a ticket in the clear, and destroyed after the report is delivered and accepted. You are a temporary, accountable custodian of this material, not its owner.

Every looting step you just performed is also a checklist of controls that should have stopped it. Turning the engagement around, the defenses that blunt this stage are the ones the report should recommend:

• Data minimization. The data you cannot loot is the data that was never collected or retained. Holding less — shorter retention, fewer copies, no "just in case" dumps — shrinks the blast radius before an attacker ever arrives.
• Encryption at rest. A database or backup encrypted with keys the compromised host cannot reach yields ciphertext, not records. The reach is still a finding, but the impact is contained.
• Least-privilege access to sensitive stores. The account you landed on should not be able to read the crown-jewel database at all. When privilege is scoped tightly, a single compromise stops at a single system instead of cascading to everything.
• Data-loss prevention and monitoring. The very collection you just performed — bulk queries, large reads, files leaving a sensitive share — is exactly what DLP and egress monitoring are built to flag. If your looting ran silently, that silence is a high-value finding in its own right.

Read together, these controls describe defense in depth around the data itself: minimize what exists, encrypt what remains, restrict who can reach it, and watch for anyone who tries. A mature environment forces a tester to work hard for thin evidence — and that difficulty is precisely the result a good program is trying to produce.

By this point you have your proof. The job is not finished: you still have a foothold, planted artifacts, and changes on the client's systems that do not belong there. Next, we account for all of it and put the environment back the way we found it — the discipline of post-engagement cleanup.