# Known-Good, Now With Known-Bad: Threat Intelligence in Every Lookup

> Reput.io lookups now flag indicators that threat intelligence lists as hostile, on every plan including Free. Here's what changes in the response, the one rule we refused to bend for shared infrastructure, and the 7,000 labels we fixed while getting it ready.

- Published: 2026-10-15
- Author: Reput.io Team
- Tags: Product Update, Threat Intelligence, Engineering, Build in Public
- Canonical: https://www.reput.io/blog/threat-intelligence-in-every-lookup

---
Until this week, a Reput.io lookup answered one question really well: **is this indicator something you can stop worrying about?** Teams traffic, Windows Update, a public resolver, a known CDN. That's still the core of what we do, because most of what lands in a SOC queue is noise.

But analysts kept pointing at the other end of the spectrum. If you already know an IP belongs to a network run by criminals, you don't want "investigate" and a shrug. You want the API to say so, plainly, in the same call. So now it does.

## A new answer: `threat`

Every result already came back as `whitelisted`, `enrichment` or `unknown`. There's now a fourth status, `threat`, for indicators that appear in the threat intelligence lists we ingest every day. Here's a real response for an address inside a well-known bulletproof hosting network:

```json
{
  "indicator": "91.202.233.27",
  "type": "ip",
  "status": "threat",
  "verdict": "malicious",
  "risk_level": "high",
  "risk_context": "Threat Intelligence Match",
  "categories": [
    "Bulletproof Hosting",
    "Criminal ASN",
    "Hijacked/Criminal Netblock"
  ],
  "recommendation": {
    "action": "block",
    "false_positive_likelihood": "very_low"
  }
}
```

The `reasons` field (trimmed above) names the exact list that matched and when it was published, so an analyst can see why we said what we said instead of taking a verdict on faith.

There are two verdicts you'll start seeing that didn't appear before:

- **`malicious`** with action `block`, when the indicator itself is listed as attack infrastructure: a hijacked or criminal-run netblock, an autonomous system operated by or for criminals, a verified phishing domain.
- **`suspicious`** with action `investigate`, when a list reports hostile behaviour rather than infrastructure, such as scanning or brute forcing.

And one rule that matters more than either of them.

## Shared infrastructure is never "malicious"

Here's the trap with threat feeds. Attackers love hiding behind big shared platforms, so sooner or later a CDN edge address, a big-tech hostname or a popular hosting platform shows up on somebody's list. If an API turned that straight into `malicious` and `block`, you'd break thousands of legitimate sites the moment someone acted on it.

So we don't. When a listed indicator turns out to be shared infrastructure, the verdict stays **`investigate`**, the threat reason stays visible, and the hint tells the analyst to look at the specific hostname or tenant behind the request instead of the shared address.

If you've read our [post on borrowed reputation](/blog/borrowed-reputation-cloud-phishing), this is the same principle pointed the other way. A big brand's cloud is never automatically benign, because anyone can rent a box there. And a big brand's edge is never automatically malicious, because one bad tenant doesn't make the edge hostile. **Neither label gets to skip the analyst.**

It also works on a finer grain than you might expect. A verified phishing subdomain on a free hosting platform comes back `malicious`, while the platform's own apex keeps its normal answer. The bad tenant gets flagged and the neighbourhood doesn't.

## On every plan, Free included

We thought about putting this behind a paid tier for about a minute. Then we applied the test we use for every feature: **could this cause a missed detection?** Hiding a known-hostile match from someone because they're on the free plan would be exactly the false negative we promise never to cause.

So Free users see the `threat` status, the verdict, the categories and the reasons. The paid tiers still add what they always added on top: provider detection, the numeric confidence score, and the investigation hints.

## How we picked the sources

This took longer than the code. We set three rules for any list we ingest:

1. **Free and refreshed automatically.** It has to update itself every day without anyone maintaining it by hand.
2. **Primary.** The publisher observes or verifies the data itself; we skip lists that just repackage other lists.
3. **A licence that clearly allows use inside a paid product.** Not "probably fine", clearly.

That third rule ruled out a surprising number of popular feeds, either because their terms say non-commercial, or because commercial use now requires a paid subscription. What passed is a widely used set of lists of hijacked and criminal-run networks and autonomous systems, and a national CERT's list of verified phishing and scam domains. The [API docs](/docs/lookup) credit each source by name.

We'll be honest about the gap: we haven't found a command-and-control feed yet that meets all three rules. When we do, it'll show up in the same `threat` status, and we'll say so here.

## We fixed 7,000 labels on the way

Before switching any of this on, we audited how the API labels infrastructure, because a threat verdict is only as good as the provider context next to it. We replayed every indicator in our CDN, cloud, hosting and VPN categories through the old and the new logic, around **19,000 indicators and 6,400 IP ranges**.

The audit was humbling. A rule that matched on a bare category, without asking for evidence of the brand, had been putting the wrong company's name on things. Thousands of ranges from one VPS provider read as a different, much bigger cloud. A handful of well-known developer and CDN domains carried the name of a security vendor they have nothing to do with. The verdicts were already cautious, but the label pointed the analyst at the wrong question.

Now a brand label requires evidence of that brand, and everything else falls back to a neutral "CDN / Edge Network" or "Datacenter / Hosting". **7,138 labels changed, and not a single verdict became less cautious.** That last number was the condition for shipping.

## Try it

Look up `91.202.233.27` on the [live demo](/api-preview), then something you trust, like `8.8.8.8`, and compare the two. If you're already integrated, the only change you need to handle is the new `threat` status and the `malicious` and `suspicious` verdicts. Everything else in the response is backwards compatible.

---

*This post was written by the small team building [Reput.io](https://reput.io), not a marketing department. Every claim about our own API was checked against it live. [Try the free tier](https://reput.io) or [read the docs](https://reput.io/docs).*