OSCP-Style Proof for Kioptrix: The “proof.txt + IP in One Screenshot” Rule (with Examples)

Fast Answer (Snippet-Ready): In OSCP-style reporting, the cleanest proof is one screenshot that shows (1) the target IP and (2) the contents of proof.txt (or the exam flag) in the same frame. For Kioptrix, pair an IP-display command (like ip addr, ifconfig, or ipconfig depending on OS) with cat /root/proof.txt in a split terminal. This prevents the “wrong host” argument and makes your evidence instantly auditable.

1) The rule, stated plainly: proof.txt + IP, same frame

Here’s the whole game in one sentence: your proof screenshot must show the flag file content and the target IP address in the same screenshot. Not “in the same folder.” Not “in the next screenshot.” Not “I swear that was the same session.” Same frame.

This isn’t just a vibe. In OffSec’s exam guidance (for OSCP+ and similar tracks), the screenshot requirement is described plainly: show the contents of local.txt/proof.txt and the target IP address (via commands like ip addr, ifconfig, or ipconfig). That’s the spirit of the rule you’re applying to Kioptrix practice: make it impossible to argue you were on the wrong machine. If you keep a personal crib sheet, park your “proof pair” next to your OSCP exam commands so you don’t improvise under pressure.

What counts as “same screenshot” (and what doesn’t)

“Same screenshot” means the IP and the proof content are visible simultaneously. A split terminal is the easiest way.

• Counts: Left pane shows ip addr output with the target interface IP; right pane shows cat /root/proof.txt.
• Counts: One pane with the IP shown above the proof output (same scroll region, no ambiguity).
• Usually doesn’t count: Two screenshots, one for IP and one for proof, even if they’re “taken seconds apart.”
• Doesn’t count: A note file with the flag text copy/pasted (it’s easy to fabricate, and it looks like it).

I once took a flawless screenshot of a proof file… on the wrong terminal tab. It was late, my coffee was pretending to help, and the tab title said “root.” That was not a defense. It was a confession.

The tiny detail that makes it “audit-proof”: IP provenance

The IP needs to be clearly tied to the target, not your attacker box, not your VPN interface, not your NAT adapter. “Provenance” here just means: the IP is shown in a way that makes sense for the target’s network interface.

In practice, that means you should prefer output that clearly shows the target’s interface (like eth0 in a lab VM) along with the IP. If you have multiple interfaces, you need to make the reader’s brain work less, not more. If your scan notes keep drifting from one subnet to another, tighten your workflow with a fast enumeration routine you can run on any VM—consistency up front makes “proof identity” almost automatic.

2) Why this rule exists: prevent the “wrong box” nightmare

The real enemy isn’t “missing points.” It’s the creeping suspicion that your proof can’t be verified. When a grader (or a future employer skimming your portfolio) can’t tie the flag to the target, your work becomes hard to trust—even if it was technically brilliant.

The grader’s problem: evidence without context

Screenshots are quick, but they’re also fragile. A screenshot without context is basically a quote without a speaker.

• Was this proof pulled from the target or from a local file?
• Was the IP the target, the attacker, or the VPN tunnel?
• Was this captured after a pivot, through a jump box, or from a different machine entirely?

The “proof.txt + IP” rule answers all three questions in one frame. It’s not a reporting flourish. It’s an anti-argument device—especially if you’re writing up your work in a Kali pentest report template format where screenshots are meant to be skimmed fast.

Curiosity gap: When a perfect flag still gets questioned

Here’s the weird truth: the cleaner your report looks, the more it invites scrutiny if any context is missing. That’s not paranoia; it’s pattern recognition. People learn to distrust neat artifacts that don’t explain themselves.

And yes—this happens in real digital evidence work too. NIST’s writing on evidence preservation and integrity is basically a long love letter to “show your work” and keep artifacts verifiable. You don’t need courtroom-grade chain-of-custody for a lab report, but you do want the same mindset: make verification easy.

Money Block — Eligibility checklist (Yes/No): Are you ready to capture proof?

• Yes/No: Can you show the target IP from the target system (not your attacker)?
• Yes/No: Do you know the exact proof path (/root/proof.txt or exam flag equivalent)?
• Yes/No: Can you make the output readable at 100% zoom (no squinting required)?
• Yes/No: Can you reproduce the screenshot in under 60 seconds if asked?

Next step: If any answer is “No,” fix that first—then take the screenshot once, cleanly.

Short Story: The screenshot that cost me 20 minutes and a small piece of dignity
I once finished a lab box at 1:07 a.m. and felt like a hero. I grabbed the proof file, screenshotted it, and moved on—fast, confident, smug. The next day, I opened my “proof” and realized the IP I captured was my VPN interface on the attacker box. The target’s IP wasn’t visible at all. In my head, it was obvious what I meant. On paper, it looked like I copied text from anywhere.

So I had to boot the VM again, re-auth, re-escalate, and re-open the file path—an annoying redo that took about 20 minutes because I’d forgotten which of my “final” commands actually worked cleanly. That was the day I stopped treating proof like a victory lap and started treating it like a receipt. (If you’re practicing on older boxes, a simple Kioptrix Level 1 privilege escalation checklist can save you from re-learning your own steps.)

3) Set the stage: Make your terminal screenshot-friendly

You don’t need fancy tooling. You need predictable layout. Your goal is to create a screenshot that reads like a receipt: structured, legible, and boring in the best way.

Use a split view that reads like a receipt (tmux / panes / two commands)

If you can, use tmux. It’s lightweight, it works over SSH, and it’s designed for exactly this kind of “show two things at once” workflow. The tmux manual explains pane splitting directly via split-window (horizontal/vertical splits). You don’t need to memorize everything—just build a habit. If your shell is flimsy, fix the foundation first with a TTY upgrade checklist so your panes don’t collapse at the worst moment.

• Left pane: IP output (ip addr or ifconfig)
• Right pane: Proof output (cat /root/proof.txt)
• Bonus: Put your prompt and path in view (it helps the “where am I?” question)

Pattern interrupt: Let’s be honest… your terminal is too messy to grade

If your screenshot contains three half-typed commands, a failed reverse shell, and an ASCII dragon, the reader’s brain has to sort noise before it can see proof. That’s not “personality.” That’s friction.

My rule: if I can’t understand the screenshot after a 1-second glance, I assume a tired grader won’t either. And tired graders are the natural predator of unclear evidence.

Minimal settings that improve readability (font size, contrast, wrapping)

These are small changes with outsized payoff:

• Increase font size until the IP digits are unmistakable.
• Disable excessive line wrapping when possible; wrap can hide the interface/IP relationship.
• Clear the pane (Ctrl+L or clear) before running the two proof commands.

A small anecdote: I used to keep my font tiny because it looked “pro.” Then I realized “pro” is what happens when your output is readable, not when your terminal looks like a hacker movie.

4) The exact capture: One-shot commands that show IP + proof

Your capture should be reproducible. That’s the hidden win: if your screenshot workflow is repeatable, you stop wasting time re-finding the same proof.

Option A: IP command + cat proof.txt (most universal)

The boring, reliable pair:

• ip addr (or ifconfig if that’s what’s installed)
• cat /root/proof.txt (or the correct path for your lab/exam)

Put them in two panes or one after the other with both outputs visible without scrolling. If scrolling is required, you’re one accidental wheel-flick away from ambiguity.

Show me the nerdy details

Deeper technical notes, benchmarks, or methodology. If you want maximum “grader-proof” confidence, prefer ip addr because it clearly associates each IP with an interface. If the target has multiple NICs, capture the interface that matches your attack path (e.g., the subnet you scanned). Keep the prompt visible so the screenshot also implies privilege context (# vs $) without needing extra commands. When your scans start lying to you, double-check assumptions with Nmap -sV service detection false positives in mind—bad identification upstream creates messy proof downstream.

Option B: Show exploit output that includes the IP (when applicable)

Sometimes your exploit or shell output already includes the target IP (for example, a service banner or connection log). That can work—if the IP is clearly the target’s and not just your connection endpoint.

The risk: exploit output can be noisy and confusing. If the IP appears only once in a wall of text, your reader may miss it. In that case, go back to Option A. Boring wins.

Option C: Confirm identity with hostname + IP (when IPs are similar)

If you’re in a lab with multiple boxes in the same subnet (and you’re bouncing between shells), add a small identity cue:

• hostname in one pane
• ip addr + cat proof.txt visible in the other

You’re not doing this for fun. You’re doing it because humans mix up similar-looking IPs. Especially after midnight. Especially after the third “final” exploit attempt.

5) Kioptrix examples: Proof shots you can copy

Kioptrix is a classic for a reason: it’s simple enough to teach fundamentals, but messy enough to punish sloppy proof collection. Here are proof patterns you can adapt without turning your report into a novel. If you’re mapping your practice across the series, keep a simple index of Kioptrix levels so your evidence filenames stay consistent from box to box.

Example 1: Post-root proof (root flag + interface IP shown)

The “gold standard” look:

• Pane 1: ip addr showing the target interface and IP
• Pane 2: cat /root/proof.txt showing the full flag
• Visible prompt: root prompt (#) helps, but the flag + IP is still the core

A tiny lived-experience note: I used to add whoami everywhere. It’s not wrong, but it’s not required if the core requirement is already satisfied. Keep the screenshot uncluttered.

Example 2: User-level proof (low-priv flag + target IP)

If your lab uses a user-level flag (or you’re documenting progression), the same rule applies: show the target IP and the user flag together. The point is identity, not ego.

Example 3: Web foothold proof (service banner + target IP + next pivot note)

Sometimes your “proof” for a step isn’t the final flag yet—it’s the foothold that proves you’re on the right service. In your writeup, you can include a screenshot that shows:

• Target IP + service confirmation (banner/page title)
• A short caption in the report text (not in the screenshot) describing the pivot you took next

Just remember: foothold screenshots are supporting actors. Your headline proof for OSCP-style reporting is still the flag + IP screenshot. (If your foothold is web-based, keep your writeups consistent across labs—e.g., when you document a Kioptrix Level 2 command injection moment or a Kioptrix Level 4 SQLi login bypass, the same “identity + artifact” habit still applies.)

Curiosity gap: The one Kioptrix screenshot that “looks right” but isn’t

The trap screenshot is the one where you run ifconfig… and the only visible IP is your attacker’s tunnel or NAT interface (like tun0 on Kali). It looks technical. It looks “proofy.” It’s also the wrong machine.

If your screenshot could accidentally be taken from your attacker box, assume it will be interpreted that way. If your tunnel drops mid-lab, fix the plumbing first—this OpenVPN keeps disconnecting checklist is the kind of “boring stability” that keeps your evidence clean.

6) Evidence hygiene: What graders notice in 3 seconds

You can have perfect exploitation and still lose the reader if your evidence looks like a scavenger hunt. Graders notice three things fast: legibility, identity, and confidence.

Crop like a judge: keep signal, delete noise

Crop to include:

• IP output with the relevant interface
• Full proof content (no cut-off characters)
• Enough prompt/path context to show it’s terminal output (not pasted text)

Don’t crop so aggressively that the command itself disappears. I’ve made this mistake. It feels “clean” until you realize the reader can’t tell what generated the output.

Filenames that scale (machine + step + timestamp style)

A naming convention is the difference between “I’ll remember” and “I can find it in 10 seconds.” Try:

• kioptrix-root-proof-2026-01-10.png
• kioptrix-user-local-2026-01-10.png
• kioptrix-proof-ip-one-frame-2026-01-10.png

Specific number you can trust: I’ve watched people lose 10–15 minutes per box just hunting for “the right screenshot” after the fact. Naming prevents that—and a solid note-taking system for pentesting makes those filenames actually searchable when the post-lab haze hits.

Curiosity gap: Metadata, EXIF, and why “too perfect” can backfire

In real-world digital evidence, metadata and hashing matter. NIST publications on digital evidence preservation discuss practices like hashing to protect integrity. For OSCP-style lab reporting, you typically don’t need to hash screenshots—but the mindset is still useful: avoid edits that make the artifact look “manufactured.”

Light cropping is fine. Heavy annotation, stylized overlays, or “designy” callouts can make a reviewer wonder what changed. Keep it plain.

Money Block — Decision card: One screenshot vs. two screenshots

7) Common mistakes: How people fail this rule without realizing

These are the mistakes that don’t feel like mistakes. They feel like “close enough.” That’s why they keep happening.

Mistake #1: Showing your attacker IP, not the target IP

If your screenshot shows tun0 on Kali and you’re calling it “target IP,” you’ve created confusion. The target IP must be shown from the target system (or in a way that unmistakably identifies the target), not from your machine that connected to it. If you’re routing traffic through proxies, make sure you’re not adding extra ambiguity with leaks—this ProxyChains DNS leak fix is a surprisingly common “why does this look wrong?” culprit.

I’ve done this. It’s embarrassing, but it’s also common because we stare at our attacker terminal all day.

Mistake #2: Proof on one screenshot, IP on another (“trust me, same box”)

Your brain knows it’s the same box. Your report does not. A grader shouldn’t need to reconstruct your timeline like a detective.

• Two screenshots create a gap.
• Gaps invite doubt.
• Doubt creates rework.

Mistake #3: NAT confusion (Host-Only vs Bridged vs NAT) causing IP mismatch

NAT and multiple adapters are where “proof” gets slippery. You may scan one subnet, exploit through another, then capture an IP that doesn’t match what you reported earlier. The fix is simple: be consistent about which interface IP you treat as the target identity—and show that interface in the screenshot. If you’re running your lab in VirtualBox, keep a reference handy for NAT vs Host-Only vs Bridged networking so your “target identity” doesn’t drift silently.

Pattern interrupt: Here’s what no one tells you… NAT makes “proof” slippery

NAT isn’t “wrong,” but it is a context generator. If your report lists 192.168.x.x but your screenshot shows 10.0.x.x, the reviewer’s brain hits the brakes. If you must use NAT in your lab, treat proof collection like a choreography: same interface, same format, every time.

8) Don’t do this: Two “looks fine” proofs that get rejected

These are the “I didn’t know that mattered” failures. They matter because they break verification.

The blurred proof: unreadable text = unusable evidence

If the flag is even slightly unreadable at normal zoom, it’s not usable. Blur happens from small fonts, aggressive compression, or screenshots taken on a scaled display.

A practical fix: increase font size until the IP digits are obvious, then recapture. It takes 30 seconds. It saves you from arguing later.

The cropped-out context: no prompt, no path, no ownership, no confidence

Over-cropping creates a weird vibe: the output looks detached from reality. Include enough command context to prove it was generated in a shell.

The copy/paste trap: proof text in notes instead of terminal output

I know why people do this: it’s fast, and you can format it nicely. But it looks easy to fabricate. For OSCP-style reporting, terminal output is the point.

9) Who this is for / not for

For: OSCP-style lab writeups, Kioptrix walkthroughs, portfolio reports

If you’re building a clean report for practice, a course submission, or a portfolio, this rule makes you look like an operator who respects verification—not just someone who “got the shell.” If you want the structure to match the rigor, consider aligning your writeups with a professional OSCP report template (and then keep your proof screenshots consistent inside it).

Not for: unauthorized systems, “real target” activity, or anything out of scope

This is for authorized lab environments (like Kioptrix practice VMs and legitimate training platforms). If you don’t have explicit permission, don’t test it. This is one of those areas where “I was curious” is not a valid justification. If you’re building a legal practice environment from scratch, start with a safe hacking lab at home mindset and keep your proof habits clean from day one.

Ethical boundary: your proof should prove authorized work, not power

A good proof screenshot isn’t a trophy. It’s a record. Treat it like documentation that you’d be comfortable showing a mentor, a hiring manager, or your future self on a sleep-deprived day.

FAQ

11) Next step: Build your “Proof Pack” checklist (5 minutes)

The fastest way to become “grader-proof” is to stop improvising proof collection. Build a tiny kit you can run on every box, every time—especially on Kioptrix, where it’s easy to get sloppy because it feels familiar.

Create a repeatable template: split terminal + two commands + filename rule

Your template can be as simple as:

• Open split panes
• Run ip addr (or ifconfig) on the target
• Run cat /root/proof.txt
• Screenshot and name it with a consistent pattern

Add an evidence table to your report (Step → Command → Screenshot ID)

This is a quiet power move. It helps the reader, and it helps you. Here’s a simple format you can paste into your report. If you want your “Proof Pack” to plug into the rest of your documentation cleanly, align it with a Kioptrix pentest report structure so evidence is easy to audit.

Run one dry rehearsal on Kioptrix before you write the full report

A rehearsal sounds silly until you realize it saves you from rework. Set a timer for 3 minutes and practice collecting your one-frame proof cleanly. If you can’t do it in three minutes today, you definitely won’t do it cleanly at 2:00 a.m.

Money Block — Mini calculator: How many “proof shots” do you need?

Conclusion: one screenshot, zero doubt

Remember the open loop from the beginning—how a “perfect flag” still gets questioned? This is why: proof without identity is just a screenshot of text. The “proof.txt + IP in one frame” rule closes that gap. It turns your work into something other people can verify quickly, even when they’re tired, skeptical, or skimming.

If you do only one thing after reading this, do this: build your Proof Pack and run one rehearsal on Kioptrix today. You’ll save yourself real time later—often 10–20 minutes per box—because you won’t be rebuilding “lost proof” at the worst moment.

Money Block — Quote-prep list (for your report): what to gather before you write

• Target IP(s) as used in the report narrative (choose the correct interface)
• Final “flag + IP” screenshots named consistently
• Exact proof file paths (root and/or user)
• Evidence table rows (Step → Command → Screenshot ID)
• Any pivot notes that explain network context (kept brief)

Neutral action: Spend 10 minutes assembling this before writing—your report will feel effortless. If you want the back-end habit to match the front-end cleanliness, build it into Kali Linux lab logging so your “receipts” exist before you need them.

Last reviewed: 2026-01.