Threat Intelligence Feed Poisoning: Protect Your Evidence

Three threat intelligence feeds flag the same domain. A scoring rule treats them as independent confirmations, an assistant summarizes the apparent consensus, and an analyst receives a proposed block. If all three feeds copied one unsupported report, the decision rests on a single claim disguised as corroboration.

Threat intelligence feed poisoning exploits the influence that incoming data has on analysis or action. An attacker may try to introduce misleading claims, hide useful observations, or steer an automated consumer. Accidental collection errors can cause similar operational damage. Defenders need controls that contain the effect before they can establish the cause.

The central question is practical: which evidence justified the decision, how did it reach us, and how can we retract its consequences? This guide develops that question through a synthetic case and an offline exercise. It does not claim that a particular feed provider has been compromised or that every threat intelligence platform is vulnerable to the same mechanism.

Separate malicious manipulation from ordinary bad data

Poisoning implies intentional interference. A stale indicator, a malformed date, or an overly broad classification does not establish intent. Preserve the artifact, assess the effect, and investigate provenance before describing a quality defect as an attack.

Three failure classes need different controls. Semantic failure changes the meaning: a legitimate domain is labeled malicious without adequate support. Structural failure affects processing: unexpected encodings, oversized inputs, or invalid fields break assumptions. Instruction failure occurs when a consumer treats collected content as authority, such as a language model following directions embedded in a report.

The OWASP Data and Model Poisoning risk category describes manipulation risks for AI systems. It is a useful taxonomy, not a diagnosis of your CTI platform. A conventional pipeline without machine learning still needs source attribution, validation, and controls over downstream decisions.

Define the consequence before choosing the control. Displaying an unverified note, opening an analyst task, raising incident priority, and blocking a business service have different costs. The required evidence and approval should increase with the action's impact and reversibility.

A synthetic case: one assertion becomes three votes

In this fictional exercise, Boreal Workshop uses billing-boreal.example as a demonstration domain for a supplier service. Feed Alpha publishes a phishing assertion at 09:00. Feed Beta imports Alpha at 09:07. Feed Gamma imports Beta at 09:12. None includes an inspectable page capture, network observation, or analysis report.

At 09:20, the receiving pipeline counts three sources and raises the score. At 09:25, it proposes blocking the domain. At 09:40, the service owner challenges the classification and supplies a dated internal inventory record showing a known business relationship.

That inventory does not prove the domain was never compromised. The feed assertion does not prove it hosted a phishing page. The case contains two claims with different scopes: an external malicious classification with missing support and an internal record of authorized use.

Averaging them into one score would hide the analytical problem. Keep both claims, request the missing observation, and choose a temporary action consistent with the available evidence. No malicious intent is established in this exercise. The aim is to contain an unsupported decision and test whether the same controls would help under deliberate manipulation.

All organizations, domains, and records here are fictional. Keep the dataset offline. No live phishing URL, working injection payload, or contact with attacker infrastructure is needed to test the workflow.

Preserve provenance before normalizing away the context

For every incoming assertion, retain the source identifier, original record identifier, acquisition time, and a reference to the received content. Store the claimed observation time and publication time separately. Record the parser version and any transformation that changed the representation.

Where retention rights and policy permit, keep a controlled copy of the original artifact. A content hash helps identify identical bytes and later changes. It does not prove that the artifact is accurate. Similarly, authenticated transport and valid signatures establish particular sender or integrity properties; they do not certify the analytical judgment.

The STIX 2.1 specification provides objects, references, and relationships that can help preserve context during exchange. Check what your implementation actually carries. Converting a record to STIX does not reconstruct an origin that the upstream source never supplied.

In the Boreal case, all three received records retain Alpha as the known upstream origin while preserving their separate delivery paths. The platform can report three distributors and one asserted origin. That distinction supports both source analysis and operational monitoring without treating delivery redundancy as independent evidence.

The broader threat intelligence platform architecture guide explains the ingestion layers. Provenance needs to survive every layer that can influence a later decision.

Distinguish mirrors from independent observations

Two feeds can contain the same indicator because both observed the same activity independently. They can also share a supplier, copy a public report, or import one another. Matching values alone cannot distinguish those explanations.

Look for explicit upstream references, shared report identifiers, matching descriptions, publication sequences, and declared redistribution relationships. Record dependencies as known copies, documented common origins, or unknown independence. Text similarity is a review lead; it is not conclusive proof of copying.

Do not award independence merely because a provider omitted its references. Missing provenance is missing information. Your scoring policy should explain how it handles that uncertainty without silently turning it into extra support.

Keep distributor-level information even after grouping origins. A mirror may deliver an assertion faster or more reliably than another route. That can have operational value while adding no new observation. Measure those contributions separately.

The feed ROI benchmark offers a way to test marginal contribution without treating repeated assertions as new intelligence. Use the dependency information from this review as an input to that measurement.

The source evaluation guide is most useful when freshness, coverage, delivery, and evidential independence remain distinct. A provider can accurately transport a weak claim. One mistaken assertion also does not justify labeling the provider deceptive without further evidence.

Keep contradictory claims visible and time-bounded

A contradiction record should identify the assertion, source, relevant period, supporting artifact, and confidence assessment. “This domain is an approved supplier today” and “this domain hosted a hostile page yesterday” can both be true. A compromised account or subdomain could explain the difference.

In the synthetic case, Alpha provides no page evidence. The collection question becomes: what observation supports its classification, at what time, and with what limitations? Another numerical score cannot answer that question unless its underlying evidence is available and relevant.

Mark the assertion as disputed and prevent automatic promotion into high-impact destinations while it is reviewed. Preserve it for investigation and notify consumers who already received it. Where appropriate and authorized, targeted monitoring can continue without treating an unverified domain-wide block as the only available response.

Avoid creating a permanent exception solely because the service is business-critical. The exception needs a reason, owner, expiry, and reopening conditions. Otherwise, today's correction can conceal tomorrow's genuine compromise.

This is part of risk scoring and false-positive control: the decision policy around a score matters as much as the arithmetic that produced it.

Validate ingestion and constrain its side effects

Check types, lengths, encodings, timestamps, and required fields before accepting a record. Route invalid data to an explicit quarantine with a reason. Do not silently reinterpret an invalid domain as a generic search string or replace an absent observation time with the current time.

Set bounded download, decompression, and per-source volume limits. If the pipeline follows references for enrichment, constrain network destinations and permissions. A URL found in a report is data; its presence does not authorize the service to contact arbitrary internal or external systems.

Consider the next interpreter as well. A description rendered as HTML, a cell exported to a spreadsheet, and a clickable link have different behaviors. Encode or escape values for their destination and avoid executing embedded macros, scripts, or commands as part of validation.

Track rejected records by source and parser version. A sudden rise can indicate a legitimate format change rather than an attack. The control should create enough evidence to decide whether to update the parser, contact the source, or suspend ingestion.

The STIX/TAXII pipeline guide covers transport and integration. Successful delivery should not be confused with successful validation; both need observable outcomes.

Keep LLM summaries outside the authorization boundary

External reports, log entries, filenames, and page text are untrusted inputs to an assistant. Their inclusion in an analysis workflow does not give them authority to change the application's instructions. A summary should preserve evidence identifiers, uncertainty, and disagreements.

The Architecting Secure AI-SOC preprint, submitted on 9 September 2026, studies indirect prompt injection through poisoned logs in an AI-SOC setting. Its scope does not establish that every TIP or CTI summarizer has the same vulnerability. It provides a reason to examine where observed content can become interpreted instruction.

Separate text generation from permission to publish, change a score, close a case, or deploy a block. A model proposal should pass independently enforced application checks that verify the required evidence and authorization. Sensitive actions need documented human approval within the organization's policy.

A prompt telling the model to ignore hostile instructions is not equivalent to that separation. Restrict available tools, validate action parameters, and ensure the model cannot approve its own proposal by writing persuasive text into the evidence field.

Also test omission. A summary can mislead without executing any command. In the Boreal case, “three sources agree” fails review if it omits their common origin. A polished paragraph cannot compensate for a missing dependency or a suppressed contradiction.

Design retraction before distributing the first verdict

At 11:00 in the exercise, Alpha withdraws its classification. The receiving team must locate the mirrored records, derived scores, exports, tickets, and proposed rules that depended on it. Removing the local row does not recall a file already delivered or a rule already imported elsewhere.

Publish a correction or withdrawal with a stable reference and the known reason. Preserve the previous version when policy permits so that historical decisions remain explainable. If a downstream channel lacks acknowledgments, assign an owner to confirm that high-impact consumers received the update.

Rollback should restore the prior configuration and verify the affected service and relevant side effects. The operational blocklist guide provides a related workflow. Track destinations with unconfirmed correction status instead of declaring the case complete when Alpha's feed changes.

Do not erase the fact that the assertion was once distributed. That history helps explain why an alert fired or why an analyst made a decision earlier. It also supports a later review of whether the control failed at source evaluation, propagation, approval, or correction.

Run a small exercise with observable pass conditions

Create an offline dataset with one unsupported assertion, two mirrors, a business-owner challenge, and a withdrawal. Add one malformed record and a prepared summary that incorrectly treats the mirrors as independent. No functional attack payload is required.

The expected outcomes are specific: one origin counted, three delivery paths preserved, one disputed assertion identifiable, one malformed record rejected without silent loss, one block proposal held for review, and one correction traceable through every output.

Measure the interval between the challenge and the suspension of derived high-impact decisions. Record the time needed to identify every downstream consumer. These are exercise measurements, not claims about attacks prevented or production resilience.

Review failures individually. A correct parser does not compensate for a correction that never reaches consumers. Human approval does not help if the reviewer cannot see copied sources. Assign each gap an owner, a proposed fix, and a targeted retest.

For a real indicator you are authorized to investigate, an IsMalicious report can add another dated source to the evidence package. Preserve its provenance and scope like any other input. The resulting action should remain explainable through inspectable evidence and a correction path that reaches the systems affected by the decision.