Methodology

Last updated 2026-10-09

Security reports mention a lot of things that should never be blocked: victims, legitimate services, examples, old infrastructure. This page explains every check an indicator passes before it reaches a block list (Blocking, and the shorter Confident list), and what we still can't tell you.

All of this is done by automated software that follows fixed, tested rules. Every rule below is enforced in code and has a test. Where a check is planned but not built, we say so.

1. Read the report, not just the indicator

• We only take indicators the author defanged (written like evil[.]com or hxxp://), because that's how researchers mark something as an indicator rather than an ordinary link.
• Each indicator keeps the sentence or table row it came from, the section heading, the publisher, the article link and the publication date.
• Rules read the indicator's own part of the sentence, not the whole paragraph, and give it a role: command and control, phishing, malware download, data theft, malware file, listed by researchers, attacker address, compromised site, legitimate service, victim, or unknown.
• When a harmless reading and a malicious reading are both possible, the harmless one wins. "Unknown" is a valid answer, and it keeps an indicator off every block list.

2. Count independent sources, not articles

• The same indicator from several reports becomes one record with all the evidence attached.
• Each publisher counts once, however many of its posts repeat the claim. An article that links to another report about the same indicator counts with that report: a write-up of someone else's findings isn't a second confirmation.
• Confident needs two or more independent sources that call it malicious.
• We read the 30 newest articles from each feed, so reports weeks or months apart can back each other up.
• If any source calls an indicator a victim or a legitimate service, it's held back.
• We can't detect copying without a link, or research two teams did together.

3. Safety checks nothing overrides

An indicator never reaches a block list when:

• it's on our allowlist of critical destinations (identity providers, DNS resolvers, security vendors, major platforms). This matches whole names, so google.com.evil.example and evilgoogle.com don't get a free pass from google.com;
• it's a shared CDN address or a hosting platform itself (such as azurewebsites.net or pages.dev). One customer's site on a platform can be listed; the platform never is;
• it's one of the 100,000 most popular sites. That doesn't make it innocent, so these stay on Hunting;
• it was only seen inside a URL. A URL is never widened into blocking the whole host;
• it's past its blocking lifetime: 30 days for IP addresses, 90 days for domains and URLs, counted from the first report. A repeat mention doesn't renew it;
• it's a private, internal, reserved or documentation address;
• it's the hash of an empty file, or of a known legitimate file; or
• it's the hash of a legitimate admin or remote-access tool the attacker brought along (such as PsExec, AdFind, rclone or AnyDesk). Those stay on Hunting. A copy the report calls fake, trojanized or disguised can still be blocked.

A release gate refuses to publish anything if a list would block a known-critical destination (such as Google DNS, Microsoft sign-in or a major security vendor), or if any safety dataset is missing or more than 21 days old. It then re-checks the finished lists separately from the steps that built them, and refuses the release if anything is out of place. When a release is refused, you keep the previous one, and our Watch page says so.

4. Find out what the destination is

Every candidate for a block list is checked against passive public records only. We never visit, scan or look up the indicator ourselves. Only indicators that pass this step reach a block list; the rest wait on Hunting until a later run settles them.

From these we decide what kind of thing it is:

• Newly registered (within 180 days before the report): probably set up by the attacker. That supports the report.
• Established (registered or archived more than two years before the report): a long-lived site now reported as malicious. Age never clears an indicator, because attackers compromise real sites. We treat it as probably compromised, recommend the narrowest block (that exact host or URL, not the whole domain), and hold it for review if the report gives no role.
• Re-registered: old history, but registered again just before the report. Someone bought a dropped domain for its old reputation. The new owner holds the whole domain, so it's treated as theirs.
• Suspended: the registrar has put it on hold. It probably doesn't work right now, and it could be registered again later.
• Known legitimate file: held for review. Block it only if you don't use that software.
• Shared infrastructure: an address run by a major cloud or CDN provider is held for review, because blocking it blocks unrelated customers.

If a lookup fails, is rate-limited or returns nothing, the indicator is held for review until a later run gets an answer. A failed lookup never counts as a clean result.

5. Check the evidence is current

• An article whose feed gives no publication date isn't used at all. Without a date we can't tell how old its indicators are, so they could never age out.
• If the report places the activity years before it was published ("in 2019"), the indicator is historical and held for review. A new article doesn't make old infrastructure new.
• "Active since 2019" doesn't count as historical (it means it still is), and neither do malware family histories, ATT&CK or CVE identifiers, or version numbers.
• If the report mentions a takedown or clean-up, the indicator is held for review.

6. Trusted services named in attacks

Reports often name services many organizations depend on: a messaging app used to control malware, a code-hosting site serving downloads, a cloud sign-in page. These are never put on a block list, but they aren't hidden either. The daily report lists them, so you can block one you don't use, or hunt for unusual use of one you do.

7. Recommend the narrowest block that works

8. What we can't tell you

• The effect on your network. We can't see your traffic. Something we list could still be something one of your systems depends on. Check your DNS, proxy and firewall logs, ideally over 30 to 90 days, before you block.
• Accuracy figures. There's no labeled benchmark yet, so we have no precision or recall numbers. "Confident" describes the evidence. It isn't a probability.
• When the attack happened. Reports rarely say in a form we can extract. We use the publication date and flag explicit older years.
• Whether two publishers are truly independent.

Every decision explains itself

Each candidate carries a record of the decision, the reasons, what's still uncertain, a timeline (registered, first archived, first reported), the recommended scope and a review date. Versions of every part of the pipeline are recorded with each release, so any decision can be reproduced from the stored evidence.

How the collector protects itself

Feeds and articles are other people's content, so the collector treats them with suspicion. It only connects to public internet addresses and re-checks every redirect, refuses oversized downloads and feeds with risky XML features, escapes all text from articles, and moves each release into place whole, so a half-finished release is never published. This website re-checks every file against its published checksum before it goes live, and shows indicators defanged and never as links.

Third-party data

Some commercial services (such as VirusTotal) don't allow their results to be redistributed. Where we use them at all, it's for internal checks only: their results never change a public decision and are never published.