The testing is done. The findings are written. What is left is the part nobody budgets for: forty screenshots of evidence, every one of them carrying something that cannot leave the client's building.
Done by hand, this is where reports leak — not through a clever attack, but through the thirty-eighth screenshot at 1am when you stopped checking as carefully as you did on the first.
What has to go
Work from a list, not from judgement. Judgement degrades over a long evening; a list does not.
- Credentials and secrets — passwords, API keys, tokens, JWTs, private keys, connection strings, NTLM and other hashes. Obvious, and still the most commonly missed, because they appear mid-line in output you are skimming for something else.
- Internal identifiers — RFC1918 addresses, hostnames, FQDNs, AD domain and NetBIOS names, share paths. These are the ones people argue about. Include them: an internal naming scheme is reconnaissance you are handing over for free, and clients routinely have contractual reasons they cannot appear.
- People — usernames, email addresses, full names in
net useroutput or directory dumps. Frequently in scope for GDPR quite apart from your NDA. - Third parties — anything identifying suppliers, partners or subsidiaries. The client's NDA usually is not yours to waive on their behalf.
- Incidental context — the browser tab strip, the window title, the bookmarks bar, a Slack notification, the VPN name in your menu bar. This is the category that catches experienced people, because it is not in the terminal you were looking at.
A useful test. For each screenshot ask: if this single image were the only thing that leaked, what would I have to tell the client? If the answer is anything other than "nothing", something in it still needs to go.
Be consistent, or the report stops making sense
The mistake that hurts readability more than any other is redacting the same value
differently across a report. If 10.10.14.7 is a black bar in figure 3, a different
black bar in figure 7, and 10.10.14.x in figure 11, you have destroyed the reader's
ability to follow the attack path — which is the entire point of including the evidence.
Use stable pseudonyms instead. The same value gets the same label everywhere:
10.10.14.7 → [IP-1]
dc01.acme.corp → [HOST-1]
AKIA...EXAMPLE → [AWSKEY-1]
Administrator → [USER-1]Now the reader can trace [HOST-1] from initial access to domain admin across
eleven figures without ever learning its real name. The narrative survives; the secret does not.
Keep the mapping outside the report, so you can answer the client's "which host was HOST-1?"
during the debrief.
Redact, do not crop
Cropping to hide something is a trap. It changes the evidence: reviewers cannot see what surrounded the finding, and it invites the question of what else was removed. Capture the whole relevant window and redact within it. The reader sees the full context and exactly which parts were withheld.
The file, not just the picture
Two failures happen after the visible work is finished.
Reversible styles. Blur and pixelation can be brute-forced back to the original for short, structured strings — which is precisely what an IP address or a six-character password is. Use opaque fill. We wrote about why blur and pixelation fail separately.
Metadata and layers. A black rectangle drawn over text in a PDF or editor is an object on top of the text; the text is still selectable underneath. And screenshots carry EXIF, XMP, device identifiers, sometimes thumbnails of the pre-edit image. Verify rather than assume:
strings evidence-07.png | grep -i "dc01"
exiftool evidence-07.png | head -40A workflow that survives figure thirty-eight
- Close everything not needed for the shot. Notifications off, unrelated tabs closed.
- Capture the full relevant window, not a defensive crop.
- Redact with opaque fill, using consistent pseudonyms across the whole report.
- Export to a new file, metadata stripped. Never overwrite the original in place.
- Spot-check with
stringsandexiftool— on a sample, every time. - Review the finished report on a different day, or have someone else review it.
Steps 3 to 5 are the ones that reward automation, because they are identical every time and they are the ones that decay when you are tired. That is the job Blackbar was built for: OCR the screenshot, detect the 27 categories above, box them to the exact substring, apply consistent session pseudonyms across every screenshot in the report, and export a fresh bitmap with the pixels overwritten and the metadata gone — offline, so the client's evidence never leaves your machine.
It will not decide what is sensitive in your engagement. It will make sure that the thing you marked as sensitive is actually, verifiably, gone from the file you send.