ShareX OSCP Proof Screenshots: Auto File-Naming Pattern That Sorts Chronologically (Report-Ready)

ShareX Screenshot Naming Pattern

Stop Fighting Your Screenshots: Evidence That Behaves Under Pressure

At some point in an OSCP-style run, the clock stops feeling like time and starts feeling like pressure. You captured the proof—yet your screenshot folder looks like confetti at 2:13 AM, and every “IMG_” file becomes an argument with your future self.

ShareX OSCP proof screenshots don’t fail because you forgot the hotkey. They fail because the filename can’t carry a timeline once the files leave the app and enter Explorer, ZIPs, or your final report. Every guess is a tiny tax: re-opening images, re-checking context, and rewriting sections out of order.

The Solution: A timestamp-first naming scheme (YYYY-MM-DD_HH-mm-ss) so alphabetical order always equals chronological order—even after copy, zip, or upload.

This approach introduces a minimalist proof taxonomy so each filename explains itself at a glance:

enum foothold privesc proof
Fast Answer (snippet-ready):

Use a timestamp-first naming pattern so every ShareX screenshot sorts in true time order across folders, ZIPs, and report uploads. Format as YYYY-MM-DD_HH-mm-ss (24-hour time), then append target + proof tag (e.g., 2026-01-20_14-07-33_10.11.1.5_enum.png). In ShareX, set the file name pattern in your Task Settings, avoid AM/PM and locale month names, and add a simple proof taxonomy so you can assemble a report without “where did this screenshot go?” panic.


1) Who this is for / not for

For you if…

  • You’re doing OSCP / OSCP-like labs and need screenshots that prove each step cleanly (especially the “grader-facing” moments described in OSCP proof screenshot requirements).
  • You want evidence that sorts correctly in Windows Explorer, ZIPs, Git repos, and report folders
  • You’ve felt the specific dread of “I know I captured it… but where?”

Not for you if…

  • You don’t use screenshots at all and rely only on full terminal logs (rare, but valid)
  • Your program requires a strict naming scheme already—follow their rulebook first (and align it with your OSCP VM lockdown checklist so your evidence workflow still holds under constraints).

I learned this the annoying way: I once “fixed” my naming by starting with the target name. It felt tidy… until I tried to write a narrative. The report became a jigsaw puzzle: every box looked neat, but time disappeared. By the time I found the right screenshot, I’d forgotten what I needed it to prove.

Takeaway: Evidence isn’t just proof—it’s a timeline your future self can read under pressure.
  • Sort by Name, not by metadata
  • Put time first, always
  • Use small, consistent tags so filenames explain themselves

Apply in 60 seconds: Create one folder called OSCP_Evidence and promise yourself: “timestamp first, every time.”

ShareX Screenshot Naming Pattern

2) Timestamp-first naming: the only sorting rule that never betrays you

Put time first, always

Computers don’t “understand” that Jan comes before Feb the way humans do. They sort strings. That’s the whole trick. So you build filenames that behave like time even when treated like plain text.

  • Use an ISO-style date: YYYY-MM-DD
  • Use a zero-padded 24-hour clock: HH-mm-ss
  • Use separators that won’t break Windows or sync tools: _ and

When you do that, the filename itself becomes your “portable truth.” Whether the file lives in OneDrive, Dropbox, a USB stick, a ZIP, a Git repo, or a report upload portal, the order survives the journey.

The open loop: what breaks chronological order even when “it looks fine”?

  • Locale months (Jan/January): visually readable, algorithmically messy
  • 12-hour time (AM/PM): easy for humans, easy to misconfigure across patterns
  • Missing zero padding (2026-1-2): string sorting will punish you
  • Metadata reliance: “Date taken” and “Date modified” can shift during copy/zip/upload

My personal low point: I had a perfect screenshot of a proof file…and a second screenshot that proved the shell context. The timestamps were right, but the filenames were not. Sorting by name made the story look reversed, and I spent 12 minutes verifying what I already knew. Twelve minutes doesn’t sound like much—until it happens six times in one report.

Takeaway: A naming scheme is “good” only if it survives stress: fast captures, messy folders, and report assembly.
  • Yes/No: Do your files sort correctly by Name today?
  • Yes/No: Can you find a screenshot in 10 seconds without opening images?
  • Yes/No: Can you reconstruct the sequence after a ZIP + upload?

Apply in 60 seconds: Take 3 screenshots across 2 minutes, sort by Name, and confirm the order matches reality. (Neutral next step: write down the result.)


3) The OSCP “proof taxonomy”: make filenames explain themselves

Your 3-part filename payload (after timestamp)

  1. Target (IP / hostname / box name)
  2. Stage tag (enum / foothold / privesc / proof)
  3. Artifact hint (nmap / smb / creds / hash / flag / config / exploit)

Think of this like the spine of a book. The timestamp is your page number. The rest is the chapter title. You’re not trying to write a novel in the filename—you’re trying to stop future-you from guessing.

A tiny, workable tag set

  • enum — discovery that narrows the search (this pairs well with your Obsidian OSCP enumeration template so screenshots and notes share the same “labels”).
  • foothold — first code execution / shell / session (a nice complement to an OSCP initial access checklist when you’re moving fast).
  • privesc — escalation steps and proofs
  • proof — proof file, flag, or required confirmation screenshot
  • clean — the “final” screenshot you want to show a grader (optional)

Why “proof” gets its own tag: because requirements tend to care about it. For example, OffSec’s OSCP+ Exam Guide explicitly emphasizes retrieving the proof files (like local.txt or proof.txt) and including them in a screenshot with your documentation. When the folder is chaotic, the “proof” tag becomes a lifesaver.

I keep this honest: I don’t tag everything perfectly. Nobody does. But I always tag the screenshots that would hurt the most to lose: proofs, pivots, and the one command output that explains the whole chain (especially when you’re hopping hosts and your Obsidian OSCP host template starts filling with parallel threads).


4) ShareX setup: where to change it (without breaking your flow)

Set it once in the right place

ShareX is a workflow engine wearing a screenshot hat. The file naming pattern lives in the place you might not expect: your Task Settings. This matters because you probably have multiple capture tasks (fullscreen, region, active window), and each can have its own naming behavior.

  • Configure the naming pattern at the task level you actually use (e.g., Capture region / Fullscreen / Active window)
  • Keep screenshots landing in a single evidence root folder, then branch into predictable subfolders
  • Run one sanity test after changes: don’t trust “I think it’s correct” at 1 AM

Sanity check (the 30-second test)

  1. Take 3 screenshots over ~2 minutes
  2. Open the folder and sort by Name (not Date)
  3. If they appear in the exact order you took them, you’re done

Small confession: I used to skip this test. Then I discovered I’d accidentally used a pattern that produced time without seconds. The filenames collided during a fast burst capture. Two screenshots overwrote each other. I didn’t notice until I tried to write. That’s the kind of mistake that feels cheap—and then costs you a full hour.


ShareX Screenshot Naming Pattern

5) Pattern templates you can copy

Below are patterns you can paste and then adapt. The exact token syntax depends on ShareX’s naming variables, but the core idea stays the same: timestamp first, then context.

Minimal, bulletproof (fastest)

YYYY-MM-DD_HH-mm-ss

If you do nothing else, do this. It will sort correctly, survive zip/upload moves, and remove the “which day was this?” friction.

YYYY-MM-DD_HH-mm-ss_TARGET_STAGE_DETAIL

Example: 2026-01-20_14-07-33_10.11.1.5_enum_nmap.png

Report-assembly mode (best when you’re disciplined)

YYYY-MM-DD_HH-mm-ss_TARGET_STAGE_ARTIFACT_TOOL

Example: 2026-01-20_14-18-02_10.11.1.5_foothold_revsh_powershell.png

Let’s be honest: if you won’t reliably type “DETAIL,” don’t include it. A “perfect” pattern you don’t follow is worse than a simple one you do.

Show me the nerdy details

ShareX supports name pattern tokens for date/time and context. In ShareX’s own project notes, a classic date-time pattern often looks like %y-%mo-%d_%h-%mi-%s, and a commonly used “include process name” version looks like %pn_%y-%mo-%d_%h-%mi-%s. ShareX has also used random alphanumeric tokens for uniqueness (e.g., a random string appended) in some default setups. The key operator move is to keep the timestamp at the front even if you add process/target tags afterward.

Takeaway: Pick a pattern that matches how you’ll search when you’re tired—not how you’ll search when you’re proud.
  • Time-first if you write reports as a narrative (recommended)
  • Target-first only if you always write per-host and never need cross-host chronology
  • Add a uniqueness suffix if you capture rapidly (bursts, scrolling, multi-monitor)

Apply in 60 seconds: Decide: are you more often searching by when or by which host? Then commit to the pattern that serves that reality. (Neutral next step: update your pattern once and test.)


6) Folder strategy that doesn’t rot

One root folder, many clean lanes

  • Root: OSCP_Evidence/
  • Per target: OSCP_Evidence/10.11.1.5/
  • Optional per phase: .../01_enum/, .../02_foothold/, .../03_privesc/, .../99_proof/

Here’s the trap: folders feel like control… until your workflow zigzags. Maybe you enum host A, pivot, then come back to A later. Or you bounce between an AD set and a standalone box (and if you’re doing AD without graph tooling, AD enumeration without BloodHound tends to produce exactly this kind of “zigzag”). If your folder structure assumes a linear story, you’ll end up duplicating files, re-sorting, or “temporarily” dropping everything into one messy folder.

The curiosity gap: should the folder hold the story, or the filename?

  • If your phases are clean and linear, folders can carry more structure
  • If your work zigzags (most real life), let filenames carry context and keep folders simple

My compromise: I keep folders boring and filenames smart. Folders answer “where is this host’s evidence?” Filenames answer “what happened, in what order, and why do I care?”

Operator tip: If you use Git for notes, don’t commit raw images unless you have a reason (repo bloat is real). But even if you never commit images, a Git-style mindset helps: consistent naming, predictable structure, minimal surprises.


7) Common mistakes (the ones that silently ruin sorting)

Mistake: using “Date taken” instead of filename sorting

Metadata is fragile. It can change on copy, zip/unzip, upload/download, and “helpful” sync tools. The filename is stubborn. The filename survives.

Mistake: mixing underscores, spaces, and parentheses

Pick one separator style and stick to it. I recommend:

  • Underscore between “big chunks” (timestamp, target, stage)
  • Hyphen inside the timestamp (HH-mm-ss) to avoid forbidden characters

Mistake: relying on IMG_#### or auto-increment alone

Counters reset. Counters collide across folders. Counters don’t carry meaning. They’re fine as a suffix for uniqueness—but not as the spine of your evidence timeline.

Personal scar tissue: I once moved an evidence folder between machines and Windows adjusted modified times in a way that made everything look “new.” Sorting by Date became a lie. Sorting by Name stayed honest.


8) “Don’t do this” pitfalls (proof gaps are born here)

Don’t use 12-hour time or AM/PM in filenames

Humans read it fine. Systems sort it unpredictably when formats vary. Also: you do not want a future debate about whether 02-07 meant 2 AM or 2 PM.

Don’t start with the target name

You’ll sort by host, not by time. Then your narrative becomes fragmented and you’ll constantly “jump around” while writing (which is exactly how people end up in OSCP rabbit holes while trying to reconstruct what happened).

Don’t use forbidden filename characters

Windows paths have restrictions. The big one people accidentally include is the colon in time (14:07:33). Use hyphens instead (14-07-33). You want boring filenames that never break during compression, sync, or upload.

Don’t let “perfect” be the enemy of “consistent”

The best naming scheme is the one you’ll still follow when you’re tired, behind schedule, and your brain is basically a browser with 47 tabs open.

Takeaway: Before you compare tools, configs, or workflows, gather the “evidence plumbing” once.
  • Your evidence root folder path (where files must land)
  • Your required proof items (e.g., proof file screenshot rules)
  • Your preferred tags (enum/foothold/privesc/proof)

Apply in 60 seconds: Write those three items on a sticky note (digital or physical) and keep it next to your capture hotkey list. (Neutral next step: keep it visible for a week.)


9) The quiet superpower: report assembly speed (and fewer disputes)

“Proof pack” thinking

A good naming scheme turns your screenshot folder into a timeline you can trust. That trust buys you speed. Not hype-speed. The real kind: fewer pauses, fewer rechecks, fewer “open 12 images to find the one with the right prompt.”

OffSec’s OSCP+ workflow also has a very real time shape: the exam window is 23 hours and 45 minutes, and then you get another window to upload your documentation. That’s not the moment you want to be reverse-engineering your own evidence trail (it’s also why pairing evidence with a repeatable Kali lab logging habit is quietly powerful).

The open loop: what if you need to prove sequence, not just results?

Sometimes the story matters: “I enumerated, then pivoted, then escalated.” A timestamp-first naming scheme makes “what happened when” visible without opening files. It’s subtle, but it changes how calm you feel while writing.

Short Story: The folder that saved my sanity (120–180 words) …

It was the kind of night where everything technically worked, but nothing felt stable. I had a shell, then I lost it, then I got it back—three times. I kept capturing screenshots, telling myself I’d “organize later.” Later arrived like a rude email. My folder was a pile: random names, mixed phases, half a dozen near-duplicates, and one image that mattered more than the rest: the proof file on the right host with the right context.

I didn’t panic because the filename itself was the map. I sorted by Name. The timeline snapped into place. I could literally watch the story reassemble: enum → foothold → privesc → proof. I didn’t have to trust my memory. I just had to trust the clock I baked into the file. That’s the quiet superpower: your folder tells the truth even when you’re tired.

Takeaway: Chronological filenames don’t just “feel organized”—they reduce report time in measurable minutes.
  • Less hunting per screenshot
  • Faster mapping from evidence → section
  • Fewer “prove the sequence” rechecks

Apply in 60 seconds: Use the mini calculator below once, then pick the simplest pattern that saves you the most time. (Neutral next step: record your estimate.)

Mini calculator: Estimate minutes saved by better sorting

“`

Estimated savings:

No data is stored. This is just a quick sanity check for your workflow.

“`

10) FAQ (quick answers that prevent dumb pain)

1) What’s the best timestamp format for screenshots that sort correctly on Windows?

YYYY-MM-DD_HH-mm-ss is the safe, portable choice. It sorts correctly as plain text and avoids forbidden characters like colons. If you want even tighter filenames, YYYYMMDD_HHmmss also works—but the dashed version is easier to read under stress.

2) Should I use YYYY-MM-DD or YYYYMMDD in ShareX file names?

Both sort correctly. Use YYYY-MM-DD if you want human readability. Use YYYYMMDD if you want shorter filenames. The key is consistency and zero padding—don’t mix styles mid-project.

3) How do I include the target IP/hostname in ShareX filenames efficiently?

Use a short “target token” you can type fast: IP for standalone hosts, and short hostnames for AD environments. If you can’t type reliably while capturing, keep the filename minimal and put the target in the folder name (OSCP_Evidence/10.11.1.5/).

4) Will screenshot metadata (“Date taken”) survive zipping and uploading to portals?

Sometimes. Not always. Different tools preserve metadata differently, and “Date modified” can shift during transfers. That’s why timestamp-first filenames are the safer anchor: the sorting logic travels with the file.

5) Should I name files by phase (enum/foothold/privesc) or by artifact (nmap/creds/flag)?

If you’re a beginner: start with phase—it’s easier to keep consistent. If you’re more experienced: phase + artifact gives you the best searchability. Either way, keep the tag set small enough that you’ll actually use it (and if you’re routinely doing service verification, be mindful of Nmap -sV false positives so your “enum” screenshots don’t become misleading later).

6) How long should an OSCP evidence filename be before it becomes counterproductive?

If you can’t skim it in 2 seconds, it’s too long. Keep it to: timestamp + target + 1–2 tags. Any more detail belongs in your notes, not in the filename.

7) What separators are safest for Windows + cloud sync (_ vs – vs spaces)?

Underscore and hyphen are the safest. Spaces usually work, but they can be annoying in terminals and scripting. Avoid punctuation that’s path-sensitive or visually ambiguous.

8) How do I avoid duplicate names when taking rapid screenshots?

Include seconds (HH-mm-ss) at minimum. If you capture multiple times within one second, add a uniqueness suffix (like a short counter or random string) or include milliseconds if your tooling supports it.

9) Can I standardize naming across ShareX + terminal logs for a single timeline?

Yes—by making timestamp-first the shared rule. Use the same date/time style in your notes (or log filenames) so your “evidence pack” sorts as one story. Even if the content differs (images vs text), the timeline aligns.

10) What’s a “minimum viable” proof screenshot set for OSCP-style reports?

At minimum: proof file screenshot(s) with clear context, plus the key command outputs that explain how you got there. OffSec’s guidance specifically emphasizes including the relevant proof file in a screenshot with your documentation. Build outward from that minimum: each extra screenshot should justify itself as “this prevents a grading dispute or narrative confusion.”


11) Next step

Set your ShareX screenshot naming to timestamp-first (YYYY-MM-DD_HH-mm-ss) and take three test shots. If they sort correctly by Name, add TARGET + STAGE as the next two tokens and lock the pattern for the rest of your prep.

If you want one small “discipline upgrade” that pays back fast: create a 99_proof subfolder per target and move only the final proof screenshots there. Not everything. Just the ones you’d cry over if they vanished (and when you start assembling, a consistent pentest report template makes those “proof” shots land exactly where they should).


Infographic: the “report-ready filename” in one glance

YYYY-MM-DD_HH-mm-ss
Chronology spine
TARGET
IP / hostname
STAGE
enum / foothold / privesc / proof
DETAIL
nmap / creds / flag / config

Example: 2026-01-20_14-07-33_10.11.1.5_enum_nmap.png

If you can read this filename cold, you can usually write the report faster than you can panic.


ShareX Screenshot Naming Pattern

FAQ

Q1) Where exactly do I change ShareX file naming?
A: In ShareX, file naming patterns are configured in Task Settings for the capture workflows you use. Update the pattern, then run the 30-second test: capture 3 images, sort by Name, confirm correct order.

Q2) What does “timestamp-first” practically mean?
A: The very first characters of the filename should be the sortable timestamp (year → month → day → hour → minute → second). That ensures alphabetical sorting equals chronological sorting.

Q3) Do I have to include the target in the filename?
A: No—but it helps. If typing target info slows you down, put the target in the folder name and keep filenames time-first + stage tag.

Q4) What if I take multiple screenshots in the same second?
A: Add a uniqueness suffix (counter/random) or capture with higher time precision if available. The goal is: never overwrite, never collide, never guess.

Q5) How do I keep filenames short but still useful?
A: Keep two tags only: TARGET + STAGE. Put all other details in your notes or your report draft. Short filenames reduce friction and improve compliance.

Q6) Why not just rely on ShareX history?
A: ShareX history is helpful, but your report workflow usually lives outside ShareX—folders, zips, uploads, and editors. Timestamp-first filenames keep the “truth” attached to the file itself.


Conclusion

Here’s the loop we opened at the top: “What breaks chronological order even when it looks fine?” It’s not your memory. It’s not a lack of discipline. It’s that the default file ecosystem is indifferent to narrative. So we build narrative into the filename—quietly, mechanically, reliably.

If you do one thing in the next 15 minutes: set a timestamp-first pattern, run the 30-second test, and capture one proof-style screenshot with your new taxonomy. Your future self will feel the difference immediately—less searching, fewer doubts, faster writing.

Last reviewed: 2026-01.