Ransomware early warning: watching leak sites for your name, your clients and your suppliers

On 13 August the Clop ransomware group posted claims naming Shell and Philips, and both companies confirmed they had experienced a security incident once the claims were reported (NL Times). Philips called it an attempted attack on a specific server holding internal data, since brought under control, with no impact on customer environments. The security platform that spotted the listing also warned that the numbers come straight from the attackers and are unverified.

If you run IT for an Australian hospital, imaging practice or aged care group, Philips is not a name from the news. It is on your asset register and in your maintenance contracts. That is the useful part of this story, not the severity of the claim itself. A leak site published a named victim before any customer notification existed. Whoever inside your organisation happened to read that page was your early warning system.

In most organisations, nobody has that job.

The check we run

We run mention monitoring as one of the automated checks in our managed services work. It is not glamorous and it is not a threat intelligence platform. It is a scheduled pipeline with an LLM doing one specific job in the middle.

The shape of it:

• A watchlist of entities: our own legal and trading names and domains, the clients we hold data for, and the suppliers whose failure would stop work. Each entity gets aliases, former names, subsidiary names and email domains, because “Philips Healthcare ANZ” and “Philips” rarely appear the same way twice.
• Collection from public sources on a schedule. Leak site listings from aggregators that mirror them, breach chatter, paste sites, vendor advisories and security press. We read public sources. We do not buy forum access or stolen credentials, and neither should your provider.
• Normalisation into one record shape: source, timestamp, claimed victim string, claimed gang, raw text, URL.
• A cheap prefilter. Plain string and fuzzy matching against the alias list, which is deliberately over-inclusive.
• An LLM classification pass over everything the prefilter caught.
• Deduplication against what we have already alerted on, then routing.

The prefilter is where naive systems stop, and where they generate enough noise that people mute them by week three. In a single four-week window this winter, publicly reported named-victim ransomware events included Shell, Philips, Coca-Cola’s Fairlife dairy and a US bank (NL Times). Now imagine your watchlist contains a supplier called “Shell”, or a client whose trading name is two common English words. Every hit is a coin toss.

What the model is actually asked

The classifier gets one job: decide whether this text refers to the entity on our watchlist, or to something that merely shares a name. It does not decide severity, it does not write the notification, and it does not talk to anyone.

You are classifying a security mention. Given the WATCHLIST_ENTITY
(with aliases, domains, industry, country) and the MENTION text,
return JSON only:

{
  "match": "yes" | "no" | "unsure",
  "match_basis": "domain" | "exact_name" | "alias" | "context_only",
  "claimed_gang": string | null,
  "claim_type": "leak_site_listing" | "news_report" |
                "vendor_advisory" | "chatter" | "other",
  "reasoning": "one sentence",
  "distinguishing_evidence": "the text that decided it"
}

Rules:
- A shared name with a different industry or country is "no".
- Absence of a domain or industry match is not evidence of "no"
  when the text is short; return "unsure".
- Never infer facts not present in MENTION.

Two design decisions matter more than the prompt wording. First, “unsure” is a valid answer and it routes to a human rather than to the bin. A model forced to choose between yes and no on a forty word leak site entry will guess, and the guess costs more than the review. Second, the model must quote the text that decided it. If the evidence field does not contain the phrase that drove the classification, the record is treated as unsure. That single rule kills most confident nonsense.

Nothing leaves the building automatically. An alert reaches a person, and a person decides whether a client or supplier gets contacted. For any mention involving health providers or the data they hold, that human sign-off is a design requirement of the pipeline, not a policy we hope people follow.

Keep the source list alive

The creator of Ransom Cartel was sentenced to 16 years in prison this month (BleepingComputer). Brands get taken down, affiliates scatter, and the same people reappear under a new name with a new onion address. A pipeline keyed to a fixed list of gang names and mirror URLs quietly stops finding anything, and a monitoring system that has gone silent looks exactly like a monitoring system with nothing to report.

We review sources monthly and treat a source that has returned zero results for a fortnight as broken until proven otherwise. Add a synthetic canary entity to the watchlist so you can confirm the pipeline still fires end to end.

The first hour when a supplier appears

The listing itself tells you almost nothing reliable. Assume the claim might be exaggerated, and act on the consequences you can control.

1. Verify the listing exists as described. Screenshot it, record the URL and time in AEST, and note exactly which entity name was published. A subsidiary listing is not the same as the parent.
2. Work out your exposure to that supplier by data and by dependency. What of yours do they hold, what integrations do they have into your environment, and what stops if they go dark for a fortnight? Ransomware at Coca-Cola’s Fairlife dairy suspended production across its US sites (TechCrunch). The equivalent here is a booking, pathology or maintenance service simply not being available on Monday.
3. Cut the machine-to-machine trust you can afford to cut. Rotate shared credentials and API keys, review any supplier VPN or remote support access, and check what their accounts can reach in your tenancy.
4. Contact the supplier through a channel you already had, not one from an email that arrives afterwards. Ask three things: is the claim accurate, what data of ours is in scope, and when will you confirm in writing.
5. Open your breach assessment file now, on the assumption it may become a notifiable data breach. Under the OAIC’s Notifiable Data Breaches scheme you have 30 days to assess a suspected eligible breach, and that clock is much easier to defend when the timeline starts at the leak site listing rather than at the supplier’s letter three weeks later. Report to ReportCyber if it becomes an incident.
6. Route the alert to more than one person, and out of band. Zscaler’s research on one month-long campaign found nearly two thirds of victims held manager-level titles or above, with the average victim a 46 year old (The Register). That profile is the person who owns the alerting inbox. If the alert only ever lands in one mailbox, and that mailbox is a target, you have built a single point of failure.

Keep monitoring after the incident closes. One US bank told regulators it had obtained representations from the attackers that they had deleted the stolen data (The Register). A listing coming down means someone decided to take it down. It is not evidence that anything was destroyed.

Honest limits and costs

This tells you what criminals have published, which is a partial, self-serving and sometimes fabricated view. It will not catch a quiet compromise nobody brags about, and it is not a substitute for logging, backups, MFA or patching. Expect false positives on generic company names and false negatives when a victim is listed only by an abbreviation or a domain you never recorded as an alias.

The model spend is the least interesting line item. A few hundred prefiltered items a day through a small model costs a few dollars a month. The real cost is human: roughly half a day a month keeping aliases and sources current, plus the time to triage what the classifier flags as unsure. Skip that maintenance and you have an expensive way of feeling covered.

This post is part of our Practical AI in Cyber Security series, which looks at small AI components doing narrow jobs inside systems that were already working. Mention monitoring is a good first one, because the pipeline is a weekend of work and the failure mode is embarrassing rather than dangerous.

PicNet builds production AI systems for Australian organisations. Talk to us about what a first project could look like.

Tagged: #ransomware #threat-intelligence #incident-response #supply-chain #notifiable-data-breaches