Technical guideUpdated 2026-06-10~6 min read

Verifying a ClearPhish evidence bundle

If you are an abuse desk, a rights holder or a dispute panel reviewing material we sent, you should not have to trust us. This page explains what is in an evidence bundle and how to verify each layer independently, using nothing but standard open-source tooling.

What a bundle contains

A case bundle packages everything captured at detection time: the full-page screenshot, the served HTML (including the crawler variant where the site cloaks), HTTP response metadata, WHOIS/DNS/TLS snapshots, and a manifest listing each artefact with its SHA-256 digest. Where configured, the manifest's chain digest is additionally sealed with an RFC 3161 token (.tsr file) issued by an independent time-stamping authority.

Layer 1 — the hash manifest

Each artefact's digest must match the manifest. Recompute and compare:

# Recompute the digest of any artefact you received
shasum -a 256 page.html.gz
# → compare with the artefact's entry in the bundle manifest

A matching digest proves the file you are looking at is byte-for-byte the file that was captured — nothing was edited after the fact.

Layer 2 — the RFC 3161 timestamp

The trusted timestamp proves when the evidence existed. The token is issued by a third-party TSA over the bundle's chain digest; we cannot back-date or alter it. Inspect and verify with OpenSSL:

# Inspect the token: shows the digest it covers, the TSA, and the signing time
openssl ts -reply -in evidence.tsr -text

# Verify the token against the digest, using the TSA's published CA certificate
openssl ts -verify -digest <chain-digest-hex> \
  -in evidence.tsr -CAfile tsa-cacert.pem

Verification: OK means an independent authority attests the evidence existed, in exactly this form, at the stated time — typically minutes after the abusive page was live. The TSA's CA certificate is published by the issuing authority; the notice identifies which TSA was used.

Why this matters: abusive sites routinely change or vanish before review. The timestamp converts "they claim it looked like this" into "a neutral authority certifies it looked like this, then".

Layer 3 — write-once storage

Bundles are stored in object storage with S3 Object Lock in compliance mode: for the duration of the retention period the artefacts cannot be overwritten or deleted — by an attacker, or by us. Combined with the hash manifest, this means the copy we produce in any later dispute is provably the original capture.

Layer 4 — the independent archive

Where the page was publicly reachable, a snapshot is also submitted to the Internet Archive's Wayback Machine. That copy lives on infrastructure we do not operate, under a URL anyone can open — a second, independent record of what the site served:

https://web.archive.org/web/<timestamp>/<reported-url>

If something doesn't verify

If a digest doesn't match, a token fails verification, or anything about a notice looks off — treat it as suspect and tell us. Genuine notices come only from abuse@clearphish.org; verification contacts are published in our security.txt and on Abuse & Reports. We would rather re-issue a bundle than have an unverifiable one acted on.


The standard behind this process is described on Evidence & methodology; how it feeds a takedown is on How a takedown works.

Reviewing a notice from us?

If anything fails to verify, or you need the underlying bundle re-issued, contact us — we answer verification requests with priority.