Securing evidence of a fake website: what to capture and how

Why secure evidence before you report?

Because the page you report today may be gone or changed tomorrow. Operators move kits between hosts, swap domains and show neutral content once they notice attention. Without evidence you cannot prove what was there, link a new copy to an old case or give your lawyers anything to work with.

Evidence also makes the report itself stronger. Registrars need actionable evidence before they suspend a domain, and ICANN names a screenshot and the complete URL as useful examples (ICANN). A notice to a host in the EU must name the exact location of the content (DSA, Article 16). Capture first, report second.

What belongs in an evidence package?

A complete package answers four questions: what did the page show, where did it live, who runs the infrastructure and how did people get there. These eleven items cover them:

How do you take screenshots that hold up?

You take them complete, untouched and in context. A cropped image of a login form proves little; a full-page capture with the address bar, the date and the time proves where and when:

1. Use a clean, isolated browser. A separate profile or virtual machine keeps the fake away from your accounts and your network. Never enter real credentials or personal data on a suspicious page.

2. Capture the whole page, twice. Once on desktop and once with a mobile browser or mobile emulation, because many kits show different content per device.

3. Keep the context visible. The full address bar, the date and time with time zone, and the page title belong in the image.

4. Do not edit the files. No cropping, no arrows, no compression. If you want to annotate, make a copy and keep the original.

5. Save the page itself. Store the HTML or an MHTML file next to the screenshots, and create a public archive copy with the Internet Archive's Save Page Now where that is safe. Archives often fail on pages that need parameters, so they complement your own files rather than replace them.

How do you capture domain, DNS, hosting and certificate data?

You query the public sources and save the raw answers with the time of the query:

• Registration: ICANN's lookup tool returns registrar, creation date, status and abuse contact via RDAP for generic domains. Country-code registries such as DENIC for .de publish less, so note the registrar and the name servers.

• DNS: record the A and AAAA records for the IP addresses, the NS records for the DNS provider and the MX records, which show whether the domain is set up to send or receive mail.

• Hosting: look up the network that owns the IP address. If it belongs to a CDN such as Cloudflare, the real host is hidden behind it and the CDN's abuse process reveals it. That is how you find the hosting provider of a website even when a CDN sits in front of it.

• Certificate: save the certificate details from the browser and search the domain in a Certificate Transparency log such as crt.sh. Other domains on the same certificate, or certificates issued on the same day, often belong to the same operator. That is why it pays to analyze the SSL certificates of phishing sites before you close a case.

What about pages that only show up with the right link?

Some phishing pages are built to hide. They show a blank page or a harmless one unless the visitor arrives with the exact link, the right device or the right country. Fake verification pages for certificates work this way: the forged certificate carries a QR code with parameters, and only that full link displays "certificate valid" with your logo.

Document these pages with the exact link from the lure, not a shortened version. Capture the neutral version too, because the difference itself is evidence of deception. Note the device, browser and network you used, so someone else can reproduce the result. Because search engines and scanners rarely see such pages, the people who hold the link are your best source, which is what a report widget on your own website is for.

How do you store evidence so it stays credible?

You store it so that anyone can see it has not changed since capture. Three habits are enough for most brand cases:

• One folder per case, with the original files read-only and a separate folder for annotated copies.

• A checksum per file. A SHA-256 hash recorded at capture time shows later that a file is unchanged.

• An evidence log that records who captured what, when, with which tool and from which network. This log is your chain of custody.

Personal data of victims can end up in evidence, for example in forwarded emails. Keep only what the case needs and limit access to the people working on it.

What does your law firm need from you?

Your law firm needs a file it can read without calling you: a short summary of the case, your proof of rights, the evidence package with the log, every report you sent with its date and every answer you received. For dispute procedures over a domain, the registration data and screenshots showing use in bad faith matter most.

Which mistakes weaken evidence?

Most weak evidence fails for simple reasons:

• A screenshot without the address bar, date or time.
• A shortened or retyped URL that no longer matches the original.
• Only one capture, so there is no proof of the mobile version or of changes over time.
• Edited or compressed images without the original.
• Real credentials or test data entered on the fake page, which can alert the operator and expose accounts.
• Files spread over inboxes and chats instead of one case folder.

How does AI Fraud Protect help?

AI Fraud Protect builds an evidence package for every find, from the very first scan: screenshots on desktop and mobile, registration data, DNS records, hosting and IP, the TLS certificate, an AI analysis report with the copied elements and your trademark evidence. The package is attached to every report automatically, and the activity history records who sent which report and when. New copies are linked to earlier cases through shared infrastructure and page templates.

FAQ

Sources

• ISO/IEC 27037:2012, guidelines for identification, collection, acquisition and preservation of digital evidence

• UC Berkeley Human Rights Center: Berkeley Protocol on Digital Open Source Investigations

• ICANN: launching RDAP, sunsetting WHOIS, 27 January 2025

• ICANN advisory: DNS abuse obligations in the registrar and registry agreements, 5 February 2024

• Digital Services Act, Article 16, with the official text on EUR-Lex

• Chrome Certificate Transparency policy

• Cloudflare: our approach to abuse

• Internet Archive: Save Page Now

More in this series

• TakedownsHow to take down a fake website: the complete guide
• RespondHow to report a phishing website in Europe: who to tell, what to send, what happens next
• DetectCloned login pages: how to spot them before your customers do
• DetectQuishing: when the QR code leads to the fake
• BasicsPhishing kits: how cloned pages are mass-produced
• BasicsFrom email to landing page: tracing the full phishing chain