Someone Says They Stole Your Data. What Does the Message Prove?

Separate an extortion claim from evidence of access or theft. A short guide to preserving the message and giving the incident team a useful first report.

A dark sealed envelope on one side of a small balance scale and an empty tray on the other.

Does an extortion message prove that company data was stolen?

No. Preserve and report the message promptly through the established incident channel. Keep the sender’s claims separate from independently corroborated facts, and let the response team assess any sample and available system evidence.

If someone threatens to publish company files, preserve and report the message through your incident channel. You do not need to decide whether the sender is telling the truth before asking for help.

An extortion message establishes that somebody made a threat. It does not, on its own, establish access, theft, or the sender’s identity. The incident team needs those questions kept separate while it investigates. Treat an unresolved claim seriously without turning it into a confirmed breach in the first ticket.

A real group name can appear in a false claim

Barracuda’s March 2025 threat report describes scammers posing as Clop, claiming they exploited Cleo software and stole company data. Their message pointed to media coverage of genuine attacks to make the story persuasive. That is evidence of impersonated extortion claims, not a reason to dismiss all messages using that name. Barracuda: observed Clop impersonation

Real theft can also precede a later demand. In its August 2025 update on Salesforce-focused intrusions, Google Threat Intelligence Group separately tracked follow-on extortion as UNC6240. GTIG described calls and emails demanding payment and claiming the ShinyHunters name, sometimes months after the initial theft. The report distinguishes the observed activity from the identity the sender claimed. GTIG: UNC6240 update

A deadline, recognizable group name, or news link therefore cannot settle the question. Neither can the absence of those details. Our UNC6040 article covers the app-authorization intrusion; this guide begins when a person receives a claim about what happened.

Give the incident team the original context

Use the organization’s established security or incident-reporting channel, found independently of the threatening message. Preserve the original message using the team’s approved method, including its time and delivery channel. If it arrived by phone, note the time, displayed caller information, and what you remember being asked to do. Label recollections as recollections.

Report whether you replied, opened a link, downloaded a file, entered information, or took another action. A precise account helps responders identify what to examine. You can say “I do not remember” rather than guessing.

Do not open a supplied archive or follow its links to decide whether the demand is real. Do not upload a purported data sample to a public analysis service or forward it widely. Give the response team the reference through the approved route so it can handle potentially sensitive or hostile material. The original recipient should not become the negotiator or investigator by accident.

Keep claims and facts separate

Proposed extortion intake model

  • Sender’s claim

    “We took all customer records.” Preserve the message, time, and channel.

  • Independent corroboration

    For example, three supplied names are public. Record the source and scope of each fact.

  • Incident-owner assessment

    Compare the claim with the evidence. Keep missing information visible.

State whether the claim is supported in part, contradicted, or unresolved, with its limits.

A proposed intake model. Claims and corroboration stay separately labeled; evidence may support only part of a claim. Open full-size diagram.

What supports the sender’s claim?

Describe what the supplied material contains before adopting the sender’s explanation of it. A screenshot of names already on the company website does not establish theft of a private customer database. Public information also cannot rule out a separate compromise. The incident owner still needs to investigate the alleged dataset, time window, and relevant access records.

If a sample contains nonpublic material, restrict access to it and investigate where it came from. Even a genuine sample does not tell you whether every claimed record was taken, when that happened, or whether the sender carried out the intrusion. Likewise, a quiet monitoring dashboard is not a complete answer if the relevant activity was never collected.

Keep the sender’s allegation, independently confirmed facts, and unresolved questions distinct in the first report. That lets the response team revise its assessment as evidence arrives without having to unwind a premature breach declaration.

Make sure someone owns the report

Send the original context, actions already taken, and any independently confirmed facts to the incident owner. Confirm that someone has accepted responsibility for the report. If the primary contact is unavailable, use the backup escalation route.

The incident owner coordinates the investigation and brings in the people responsible for legal, communications and any negotiation decisions. The first recipient should not have to resolve those questions before reporting the threat.

Find out where an extortion report would go.

Plan a simulated extortion message with GhostEye and agree on who should receive it. The exercise stops before any interaction with the purported sender.