How to Verify a Security Incident Is Real

Every real incident produces a second wave of attacks aimed at the people worried about the first one. That wave is often more effective than the original exploit, because it targets users who are anxious, in a hurry, and actively searching for instructions.

This guide is about establishing what is true before acting on it.

Start from a channel you already had

The single most useful habit is to reach the affected project through a route you established before the incident: a bookmark, an app you already have installed, an account you already follow. Not a search result. Not a link in a message. Not a link in a post about the incident — including, for what it is worth, a post of ours.

Attackers buy advertising against incident-related searches within hours, and clone status pages faithfully. A search for a project’s name plus “hack” during an active incident is one of the most reliably poisoned queries there is.

What counts as a primary source

Conisec logs an incident only when it is supported by a primary document, and the same standard is worth applying personally. In descending order of authority:

1. The affected project or exchange’s own statement, on its own domain or verified account.
2. Its status page, which usually updates before any narrative post.
3. A regulator, law-enforcement or court publication, where one exists.
4. A named security firm’s technical advisory, which will describe the vulnerability class rather than only the loss figure.
5. On-chain evidence, which anyone can inspect on a block explorer.

Secondary reporting is useful for finding out that something happened. It is not sufficient for a loss figure, an attribution or a legal characterisation — the three things most likely to be wrong in early coverage.

Signals that you are looking at a fake

• Urgency with a deadline. “Migrate within 24 hours or lose access.” Real remediation almost never has a countdown.
• Any request for a recovery phrase, private key or signature. No legitimate project asks. Ever. For any reason.
• A wallet-connect prompt to “check if you are affected”. Whether an address was affected is public on-chain information. It requires no connection.
• Support that contacted you first. Legitimate support responds to tickets you opened; it does not appear in your replies or direct messages offering help.
• A tool you had never heard of before today, being widely recommended by accounts created recently.

Establishing whether you are exposed

The useful question is narrow: did you interact with the affected contract, chain or service, in the affected period? That is answerable from public data and your own records. A block explorer will show your address’s transaction history; the project’s advisory will state which contracts and which window are in scope.

This is why our incident records include a Who’s exposed line and a How to verify line, and why the verification line always points at the issuer’s own channel rather than at anything we host. We are trying to hand you the check, not to be the check.

Fund recovery services

They do not work. Firms advertising recovery of stolen crypto for an up-front fee are overwhelmingly a second fraud aimed at people who have already lost money once, and they find their targets in exactly the places victims congregate after an incident.

The legitimate route is the official reporting channel for your country. We maintain a directory of those — government, police and regulator domains only, and nothing else.

What this does not protect you from

Careful verification tells you what happened. It does not undo an approval already exploited, recover funds already moved, or make an insolvent platform solvent. It is a defence against the second attack, not a remedy for the first — which is precisely why it is worth practising when nothing is wrong.