TPFP TI common mistakes
TPFP TI · Understand the traps and how to avoid them.
When asked which source to trust for attribution, the candidate picks the vendor blog post or the news article over the primary technical report, and treats a single-source claim as established fact.
Candidates equate 'recent' and 'well written' with 'authoritative', and skip the step of tracing a claim back to the report that actually contains the evidence (sample hashes, infrastructure, tooling).
What to do instead
For any attribution or capability question, rank sources by proximity to evidence: raw telemetry and malware samples > primary technical report from the analysing team > aggregator/vendor summary > news. State the evidence type explicitly and mark single-source claims as low confidence.
The candidate labels a report 'tactical' or 'strategic' based on how long it is or who wrote it, rather than on the consumer and decision it supports.
The pyramid-of-pain and intelligence-level terminology is memorised as definitions but not applied to a named consumer, so length and format become the proxy for level.
What to do instead
Before answering, name the consumer and the decision: a SOC analyst blocking hashes needs tactical/IOC-level output; a CISO allocating budget needs strategic assessment of intent, capability, and risk. Classify by decision supported, not by document size.
When asked to enrich an indicator, the candidate submits it to a public multi-scanner or paste site and treats the returned verdict as ground truth, without noting the exposure of the indicator or the possibility of poisoning.
These services are the most familiar tool and return a fast, confident-looking score, so the candidate skips the trust and operational-security reasoning the question is testing.
What to do instead
Treat multi-scanner verdicts as one weak signal: corroborate with passive DNS, WHOIS/registration age, and internal telemetry, and state that submitting sensitive indicators to public services discloses them to adversaries. Prefer private or self-hosted analysis for anything sensitive.
The candidate conflates an IOC with a TTP, or treats a TTP such as 'uses signed binary proxy execution' as if it were a single blockable indicator.
Both appear in the same reports and the term 'indicator' is used loosely, so candidates default to the most concrete-looking artefact and lose the durability distinction.
What to do instead
Sort every artefact into atomic (hash, IP, domain), computed (ja3, registry pattern), or behavioural (TTP/ATT&CK technique). Remember atomics are cheap to change and short-lived; behaviours are costlier for the adversary to change and belong in detection logic, not blocklists.
The candidate presents an analytic judgement with no statement of confidence, or uses 'high confidence' and 'high likelihood' interchangeably.
Confidence and probability feel like the same hedge, and candidates want to sound decisive, so they collapse the two into a single qualifier.
What to do instead
Separate the two axes: confidence describes the strength of the underlying sourcing and analytic process; likelihood describes the probability of the event. Write both, e.g. 'likely (high confidence)'. Use a defined scale and apply it consistently.
Asked to assess a competing hypothesis, the candidate lists alternatives but never states what evidence would disconfirm the favoured one, then concludes with the first hypothesis they formed.
Confirmation bias and anchoring: once a plausible narrative exists, subsequent evidence is read as supporting it, and structured techniques are recalled as a checklist rather than applied.
What to do instead
Use analysis of competing hypotheses explicitly: for each hypothesis, record evidence for, evidence against, and the diagnostic indicator that would most distinguish it. Name at least one piece of evidence that would change your judgement, and state why the leading hypothesis wins.
The candidate shares indicators over a TLP:RED or TLP:AMBER channel as if it were TLP:CLEAR, or forwards a report without carrying its TLP marking forward.
TLP is learned as four colours with rough definitions, and the operational rule that the marking travels with the data and binds the recipient is under-weighted.
What to do instead
Memorise the current TLP 2.0 definitions including TLP:AMBER+STRICT, and apply the rule that the recipient is bound by the originator's marking and must re-mark any derivative. When sharing, restate the TLP and the permitted audience in the same message.
The candidate describes a sharing community such as an ISAC as a place to 'get free threat feeds', ignoring the reciprocity obligation and the handling caveats attached to member submissions.
The exam's sharing domain is read as a tools question, so the governance, trust-group, and quid-pro-quo mechanics get skipped.
What to do instead
Frame each sharing arrangement by what you contribute, what you receive, the trust level of members, the handling caveats, and the legal basis for sharing. Note that machine-speed sharing (e.g. STIX/TAXII) still carries the originator's handling restrictions.
When handling a live intrusion, the candidate's first instinct is to publish or query external services with internal indicators, or to collect data in ways that alter evidence on the host.
The urge to get external help and enrichment is strong, and the operational-security and evidentiary consequences of that action are not front of mind under time pressure.
What to do instead
Apply a collection order that preserves evidence: capture volatile data and memory before shutdown, hash and log chain of custody, and keep internal indicators off public services until sanitised. Note explicitly that the analysis method must not tip off the adversary.
During a hunt, the candidate searches only for known-bad atomic indicators from a feed, finds nothing, and concludes the environment is clean.
Feeds are easy to operationalise and give a satisfying yes/no result, so hypothesis-driven hunting based on adversary behaviour is skipped.
What to do instead
Build hunts from a hypothesis tied to a named adversary's TTPs and the environment's attack surface, then look for behavioural anomalies (rare parent-child process pairs, unusual authentication patterns) rather than only matching hashes. Record a null result as 'hypothesis not observed', not 'no compromise'.