BTL1 common mistakes
BTL1 · Understand the traps and how to avoid them.
Reading only the visible From display name and the subject line, then declaring a message phishing or legitimate without inspecting the underlying header fields (Return-Path, Received chain, Message-ID, Reply-To, SPF/DKIM/DMARC results).
The display name is the most obvious and most spoofable element, so candidates anchor on it and stop analysing. Under time pressure, the first plausible verdict feels sufficient, and header parsing feels slow and technical.
What to do instead
Adopt a fixed header checklist for every sample: trace the Received chain bottom-up, compare Return-Path and Reply-To against the From domain, check Authentication-Results for spf/dkim/dmarc pass-fail with alignment, and only then look at body content. Practise on raw .eml files so header reading becomes routine rather than intimidating.
Judging a URL by the visible link text or by the start of the string, without defanging and decoding the actual href, and without noticing punycode, homoglyphs, embedded credentials, or redirect parameters.
Candidates skim for a familiar brand name and accept it. Long URLs and URL-encoded parameters are visually noisy, so the eye stops at the first recognisable token instead of parsing the registered domain.
What to do instead
For every URL, identify the registered domain (the label immediately before the public suffix), defang it (hxxp, [.]), decode percent-encoding, and follow redirect chains in an isolated environment. Build a habit of asking 'what is the actual registrable domain, and does it match the sender's claimed organisation?'
Treating a single VirusTotal detection ratio or a single threat-intel lookup as a definitive verdict, and failing to record the source, timestamp, and confidence of the intelligence used.
Candidates want a clean yes/no answer and latch onto the first number they see. They also underestimate how quickly indicators age and how often legitimate files produce low-level false positives.
What to do instead
Corroborate across at least two independent sources, distinguish passive observation from vendor verdicts, note first-seen and last-seen dates, and state confidence explicitly in the write-up. Practise writing conclusions in the form 'indicator X, observed on date Y from source Z, assessed as malicious with moderate confidence because...'.
Confusing the levels of the Pyramid of Pain and mislabelling an indicator, for example calling a file hash a TTP or describing an IP address as a behavioural indicator.
The terminology is easy to memorise superficially but hard to apply, and candidates rush the classification step because they see it as trivia rather than as the reasoning that drives defensive value.
What to do instead
Learn the ladder (hash, IP, domain, network/host artefact, tool, TTP) and, for each indicator you handle, explicitly justify its level and why it is more or less durable than the level above. Use the classification to justify a recommended detection, not just as a label.
Interpreting every timestamp in an artefact as local time, and building a timeline that mixes UTC, local, and file-system-specific times without normalising them.
Different artefacts store time differently (UTC in some logs, local time in others, with or without daylight saving), and candidates assume a single consistent clock. They also forget that MACB timestamps can be altered or that timezone offsets shift across DST boundaries.
What to do instead
Normalise every timestamp to UTC before correlating, record the original value and the conversion applied, and state the timezone assumption in the report. When a timeline looks impossible, suspect a timezone error before concluding anti-forensics.
Relying on a single artefact to prove an action occurred, for example concluding a file was executed because it exists on disk, or concluding a user downloaded a file because a browser history entry exists.
Candidates find one suggestive artefact and stop, because corroboration is time-consuming. They also conflate artefact presence with user intent or successful execution.
What to do instead
For every claim, name at least two independent corroborating artefacts (e.g. prefetch or shimcache plus event log plus file-system timestamps) and state what each proves and does not prove. Where only one source exists, label the finding as unconfirmed and say what additional evidence would settle it.
Searching a SIEM with a single keyword or a broad wildcard, then reporting the first page of results as the complete picture without checking the time range, index coverage, or whether ingestion gaps exist.
Candidates want quick hits and are unfamiliar with the data sources behind each index, so they assume 'no results' means 'no activity' rather than 'not ingested' or 'outside the window'.
What to do instead
Before drawing conclusions, confirm which log sources feed the query, set and state the time window, and validate with a known-good control query that should return data. Report counts and coverage alongside findings, and explicitly note any source that was unavailable.
Treating SIEM alerts as verdicts, closing or escalating on the rule name alone without pivoting into the raw events to confirm what actually happened and whether the activity was benign.
Alert fatigue and the pressure of a timed exam push candidates toward the fastest disposition. Rule names sound authoritative, so the underlying logic and false-positive conditions go unexamined.
What to do instead
For each alert, reconstruct the raw event sequence, identify the triggering condition, and test at least one benign explanation before concluding. Document the pivot queries used, so the reasoning is auditable rather than asserted.
Jumping straight to eradication (deleting files, blocking hashes, resetting accounts) before scoping the incident, preserving volatile evidence, and establishing the initial access vector.
There is a strong urge to 'fix' the problem and demonstrate action. Candidates also fear losing time, so containment feels like progress even when the scope is unknown and the evidence is being destroyed.
What to do instead
Follow the lifecycle in order: identification, scoping, containment, eradication, recovery, lessons learned. Before any destructive action, capture volatile data and record what was changed and why. In written answers, justify the sequence rather than only the action.
Writing incident reports that describe actions taken but omit the affected assets, the timeline, the evidence supporting each conclusion, the residual risk, and the recommended preventive controls.
Candidates treat the report as a narrative of what they did rather than a decision document for a reader who was not present. Under time pressure, the analysis is written up as shorthand that only the author can follow.
What to do instead
Use a fixed report skeleton: summary, scope and affected assets, timeline in UTC, evidence per finding, containment and eradication actions, residual risk, and recommendations mapped to the root cause. Draft the skeleton early and fill it as you investigate, so nothing is reconstructed from memory at the end.