Known bad is a detection approach that flags activity only when it matches previously observed malicious indicators such as bad IP addresses, malicious domains, or known signatures. It works best against repetitive threats, but it struggles when attackers use new infrastructure, trusted domains, or novel lures.
What Known Bad Detection Actually Means
known bad detection is a signature-driven approach: it alerts when activity matches a previously observed malicious indicator, such as a hostile IP, a malicious domain, or a known hash or signature. It is fast and precise for repeatable abuse, but it only sees what defenders already know.
The strength of this model is its clarity. If an indicator has already been validated, blocking or alerting on the same pattern can stop commodity malware, repeat infrastructure, and other recurring threats with low analyst effort. The weakness is equally important, because an attacker who changes infrastructure, rotates infrastructure quickly, or uses trusted services can fall outside the known-bad list.
How Known Bad Differs From Broader Detection Approaches
Known bad is narrower than behavior-based detection, anomaly detection, or threat hunting. It does not try to infer intent from unusual patterns; it compares observed activity to an existing blocklist, reputation feed, signature set, or curated indicator catalog.
That narrowness is not a flaw by itself. In many environments, known-bad controls are the first line of automated filtering, especially at the network edge, email gateway, DNS layer, or endpoint control plane. The trade-off is coverage: when the adversary uses fresh domains, compromised legitimate services, or changing delivery paths, the control may not trigger even though the activity is malicious.
Where Known Bad Fits in the Detection Stack
Known bad works best as one layer in a broader detection program. It is most effective when combined with logging, correlation, and higher-context analysis so that a match on a bad indicator becomes one signal among several, not the only basis for confidence.
For example, a known malicious domain may be highly actionable if the surrounding telemetry also shows suspicious process creation, unusual outbound traffic, or repeated contact attempts. The same indicator may be far less useful if the environment only records the domain lookup and nothing else. The value of the approach therefore depends on how well the indicator is maintained, consumed, and paired with other telemetry.
When teams rely too heavily on known bad, they can create blind spots around fast-moving adversaries, living-off-the-land tradecraft, and abuse of legitimate infrastructure. That is why known-bad logic is often paired with control validation against broader detection and response guidance, such as CISA Known Exploited Vulnerabilities Catalog for prioritising active exploitation and with MITRE ATT&CK Enterprise Matrix for understanding the techniques that may bypass simple indicator matching.
Operational Limits and Common Failure Modes
The main limitation of known bad is indicator freshness. A blocklist or signature set decays quickly if it is not updated, validated, and retired when no longer relevant. Over time, stale indicators produce noise, reduce analyst trust, and create the false impression of protection.
Another limitation is adversary adaptation. Attackers can rehost payloads, use disposable infrastructure, compromise trusted sites, or change artifacts faster than indicators are published. In those cases, the defender is still secure only if other controls, such as sandboxing, reputation layering, behavioral analytics, and response playbooks, fill the gap.
The most useful mental model is that known bad is reactive by design. It is strongest after a campaign has been observed and weakest against first-seen infrastructure or novel delivery methods.
Risk and Threat Considerations
Known bad creates a coverage risk when defenders treat indicator matching as a primary detection strategy instead of a narrow control. The control can miss novel infrastructure, compromised legitimate services, and rapidly changing attacker tradecraft, which gives adversaries room to operate before a signature or block entry exists.
Failure mechanism: The detection logic only fires on preknown indicators, so any new domain, rotated IP, trusted hosting platform, or changed signature can bypass the control until intelligence is updated.
Impact: Monitoring gaps can delay detection, allow repeated access attempts, and leave the organisation dependent on other layers to catch what known-bad logic cannot see.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | Enterprise Matrix | Maps attacker tradecraft that known-bad filtering may miss. |
| Recommendation — Map observed patterns to ATT&CK techniques and hunt beyond indicator matches. | ||
| NIST CSF 2.0 | DE.CM-01 — Monitoring for Anomalies and Events | Known-bad detection is one input to ongoing monitoring and event analysis. |
| Recommendation — Tune monitoring to combine indicator matches with broader anomaly and event review. | ||
| CIS Controls v8 | CIS-13 — Network Monitoring and Defense | Known-bad feeds commonly support network-based detection and blocking. |
| Recommendation — Use network defense controls to consume and refresh bad-indicator lists. | ||
Practitioner Guidance
Why practitioners should care: Known bad should be treated as a fast, high-confidence filter, not as a complete detection strategy. Its value comes from speed and precision on repeatable threats, but its limits mean it must be measured against the organisation’s tolerance for unseen, first-seen, or reputation-abusing activity.
What to watch for: Rising false confidence is the common failure mode. If analysts assume that blocklist coverage equals threat coverage, they may underinvest in telemetry correlation, behavioral detection, and indicator lifecycle management.
Practitioner takeaway: Use known bad to stop what is already understood, then rely on broader detection methods to find what the indicator list has not learned yet.
Related resources from NHI Mgmt Group
- What breaks when fraud detection relies only on known-bad indicators?
- What breaks when email security still depends mainly on known bad indicators?
- What breaks when phishing detection still depends on known-bad indicators and blocklists?
- What happens when analysts cannot search for known bad strings anywhere in their logs?
