An alert is enriched with a commercial threat-feed hit on a domain - what does that hit prove?
answer
- someone else's list, not your evidence
- who listed it, when, and why
- sinkholed, resold, shared hosting, red team
- artefact observed, not behaviour proven
- corroborate in your own telemetry
basics
~20 sIt proves only that some curation process put that domain on a list at some point. It says nothing about what your host actually did. Treat a feed hit as one weighted input to a verdict, never as the verdict.
solid answer
~50 sA feed hit is an assertion by a third party that an artefact was interesting to them, at some time, for a reason you usually cannot see. Before it moves my verdict I want three things: which source listed it, when it was first seen and how long it is considered valid, and why it was listed. Domains get sinkholed, resold, parked on shared hosting behind a CDN, and researcher or red-team infrastructure ends up on feeds too - I have had our own purple team's throwaway command-and-control domain come back as an enrichment on an alert about ourselves. So the hit tells me where to look; the verdict comes from what the host or the identity actually did. If the telemetry shows one DNS query and no follow-on session, a listed domain is a benign true positive at best.
code
json · 13 lines{
"type": "indicator",
"spec_version": "2.1",
"id": "indicator--8e2e2d2b-17d4-4cbf-938f-98ee46b3cd3f",
"created": "2026-03-11T09:14:02.000Z",
"name": "Credential-harvesting landing page",
"indicator_types": ["malicious-activity"],
"pattern": "[domain-name:value = 'sso-verify-portal.example']",
"pattern_type": "stix",
"valid_from": "2026-03-11T09:00:00.000Z",
"valid_until": "2026-04-10T09:00:00.000Z",
"confidence": 70
}go deeper
Be ready to say plainly that a feed match is somebody else's observation, not your evidence, and to name what you would check next in your own telemetry before escalating.
An interviewer expects you to walk through the metadata that makes a hit usable - source, first-seen and validity window, stated reason - and to explain how domains end up listed while being harmless today.
Show the judgment: which hits you act on without corroboration, how you spot shared infrastructure, and how you write the case note so the next analyst inherits the reasoning rather than repeating it.
Own the dependency argument - an artefact list you do not control is a queue somebody outside your organisation can influence - and be able to say what weight intel is allowed to carry in an automated response path.
## What the enrichment actually is When your console prints "this domain appears in a commercial threat feed" beside an alert, a matching engine has compared an artefact from your telemetry - a domain, an address, a URL, a file hash - against a list somebody else curated. That is the entire content of the claim. The direction matters and it is the most common thing candidates get backwards: an **indicator** is an *artefact that was observed somewhere*, a **TTP** is a *behaviour*. A feed hit is an artefact match, so it can never on its own tell you what happened on your host. ## What it does establish, and what it does not It establishes: this string was, at some point, added to a list by a process you did not watch, for a reason that may or may not be recorded in the object you received. It does **not** establish that the connection was malicious, that the host is compromised, that the artefact is still attacker-controlled, or that anything at all happened beyond a name being resolved. A DNS query log shows the name a process asked for - not what was returned to it, and not that a session followed. ## Why an artefact ends up on a list - **It was attacker infrastructure, once.** Domains are cheap and short-lived; the listing may have been true for the six hours it mattered and false ever since. - **It was sinkholed.** After a takedown the domain resolves to a researcher's sinkhole, so traffic to it means an infection somewhere - but it also means the destination is now benign infrastructure. - **It changed hands.** Expired domains get re-registered by ordinary businesses, and shared hosting or a CDN address can serve one malicious site and ten thousand legitimate ones. - **It is somebody's test infrastructure.** Researchers, sandbox operators, red teams and purple teams all burn throwaway domains and boxes, and scrapers pick them up. A perfectly normal outcome is your own purple team's short-lived command-and-control domain arriving back in a paid feed and enriching an alert about your own authorised exercise. That last case is the one to name in an interview, because it is a **benign true positive**: the rule was right, the artefact really did behave the way the feed said, and there is still nothing to escalate. It is not a false positive, and calling it one is how tuning decisions get made for the wrong reason. ## The metadata that makes a hit usable A structured intelligence object carries more than the string. In STIX 2.1 an indicator object has a `pattern` (the artefact expression), `valid_from` and `valid_until` (the window in which the author considers the pattern a valid detection), `indicator_types`, a `confidence` value on a 0-100 scale, and often a description with the reason. TAXII is only the transport that delivered it; the meaning lives in the object. So the analyst questions are: does the window in `valid_from`/`valid_until` overlap the time of my event, or am I matching a two-year-old listing against yesterday's traffic? What did the author say the artefact was? How confident were they, and is that confidence a calibrated number or a vendor default? ## Turning the hit into a verdict The hit is a prior, not a conclusion. The verdict comes from your own telemetry: - Did the resolution turn into a session, and how much data moved in each direction? - Which process made the request, with what parent and what command line? - Did anything else on the host or the identity change - a new persistence entry, a token issued, a mailbox rule created? - Is the artefact reached by hundreds of hosts (shared infrastructure, an ad network, a CDN) or exactly one? A hit plus corroborating behaviour is an escalation. A hit with no supporting behaviour is a lookup you record in the case notes and close, ideally with a line explaining why - so the next analyst who sees the same enrichment does not repeat the work. ## The failure mode this prevents SOCs that treat a feed hit as a verdict do two damaging things: they escalate benign traffic to shared hosting and burn analyst hours, and, worse, they let a third party's curation drive their queue. An artefact list you do not control is a list somebody else can influence. Reading the hit as evidence *toward* a verdict, weighted by source and freshness, is the discipline that keeps intel useful instead of authoritative.
- The enriched domain resolves to an address that three hundred of your hosts also contacted this week. How does that change your reading?Sharply downward. Fan-out that wide usually means shared hosting, a CDN edge or an ad or analytics network, where one listed site sits alongside thousands of legitimate ones. I would pivot from the address to the specific URL or the TLS SNI value, and to whether the requesting processes look alike. Breadth of contact across an estate is one of the cheapest sanity checks against acting on an address-level indicator.
- The feed object says confidence 90. Should that raise your verdict?Only if I know how the vendor computes it. Confidence in a STIX object is the author's 0-100 assessment, not a calibrated probability that my alert is malicious, and many producers emit a constant. I use it to order which hits I look at first, never as a multiplier on my own evidence. If a vendor cannot describe how the number is produced, I treat it as a label rather than a measurement.
- Your purple team's C2 domain comes back in the feed and enriches an alert about your own exercise. What do you record?A benign true positive: the detection and the intel were both correct, and there is nothing to escalate. I record the exercise reference against the case, keep the detection untouched - it did exactly its job - and note the artefact locally so the next analyst does not re-investigate. What I do not do is tune the rule, which is how genuine coverage gets removed to fix a paperwork problem.
A feed hit is a stranger's note saying "this address was worth watching last spring". Useful for deciding where to look, useless as proof of what your neighbour did last night.
saying these in an interview costs you the question
- Treats a feed hit as proof the host is compromised
- Says feeds only ever list confirmed attacker infrastructure
- Cannot separate a benign true positive from a false positive
- Reads vendor confidence as a probability of maliciousness
- Ignores whether the indicator's validity window covers the event
- Escalates on an address match without checking estate-wide fan-out