Detect, Respond, Forensics experimental

Detect, Respond, Forensics What to do when prevention fails: telemetry and detection engineering, triage and containment, memory and disk forensics, and timeline reconstruction. Telemetry and detection. Telemetry and detection. Engineer a detection.. Explain detection-engineering principles and build a detection rule from a described attacker technique.. Log sources, Detection engineering, False positives, Coverage Log sources Detection is only as good as the telemetry underneath it. A mature blue team inventories its log sources deliberately: endpoint (Endpoint Detection and Response (EDR) process, file, and registry events), network (NetFlow, Domain Name System (DNS), proxy, firewall), identity (authentication, directory changes, Multi-Factor Authentication (MFA) events), and cloud/application logs (API calls, control-plane changes, app-level audit trails). Each source has a distinct latency, retention cost, and fidelity. Sysmon-style endpoint telemetry gives rich process-lineage detail but is expensive to store at scale; NetFlow is cheap and long-lived but coarse. A detection engineer's first question for any use case is 'do we even collect the field this rule depends on?' Gaps here are invisible until an incident reveals them, so log source inventories should be tested, not assumed. Detection engineering Detection engineering treats rules as software: they have requirements (an attacker behavior, mapped ideally to MITRE ATT&CK), a hypothesis, an implementation (a query or correlation rule), and a test suite (does it fire on the attack, and stay quiet on benign traffic?). Good detections are behavioral rather than purely signature-based when possible, because behaviors survive tooling changes that break atomic indicators. Every rule should have an owner, a documented purpose, and a review cadence, otherwise the rule base rots as the environment changes underneath it. False positives Every detection sits on a precision/recall trade-off. Loosen the logic to catch more true attacks and false positives climb; tighten it and you risk silently missing real activity. Alert fatigue from false positives is not a cosmetic problem; it is a security failure mode, because analysts start reflexively dismissing a noisy rule, at which point the true positive it eventually catches gets triaged away with the noise. Tuning is a continuous discipline: track false-positive rate per rule, suppress known-benign patterns explicitly (not by weakening the whole rule), and retire rules that never produce actionable signal. Coverage Coverage measures how much of the attacker's possible behavior space your detections actually span, commonly visualized against an ATT&CK heat map. High coverage does not mean high rule count; it means deliberate mapping of techniques to data sources to rules, with explicit acknowledgment of blind spots (for example, no coverage for cloud Identity and Access Management (IAM) abuse because those logs are not ingested). Purple-teaming, meaning validating detections against real adversary emulation, is how coverage claims get proven rather than assumed. Detection as code Treating detections as software extends naturally to treating the rule base the same way source code is treated: version controlled, code reviewed before merge, and covered by an automated test suite that replays known attack telemetry against every rule on every change. This catches two failure modes that manual rule management misses reliably: a well-intentioned tuning change that silently breaks an unrelated detection, and a rule that quietly stopped firing months ago because an upstream log format changed and nobody noticed until an incident revealed the gap. A detection-as-code pipeline also makes the rule base auditable: every change has an author, a reviewer, a reason recorded in the commit history, and a rollback path if a tuning change turns out to increase false negatives rather than reduce false positives. Related CCI capabilities Cambridge Cyber International's Global Cyber Incident Database (GCIDB) grounds detection-engineering work of the kind this module describes in documented real attacker behaviour, rather than in a hypothesis nobody has checked against an actual intrusion. See cambridgecyberinternational.com for current coverage. Triage and containment. Triage and containment. Triage and contain.. Describe incident triage priorities and perform containment actions on an active compromise.. Severity, Triage, Containment, Communication Severity Not every alert is an incident, and not every incident deserves the same response. Severity classification should be a documented rubric, not a gut call: consider scope (one host or the domain controller), data sensitivity (a dev laptop versus the customer database), business impact (is production down), and confirmed versus suspected compromise. A ransomware note on a file server and a single phishing click that was not opened sit at opposite ends of the severity scale even though both generated an 'alert'. Getting severity wrong in either direction has cost: over-classifying burns responder time and credibility; under-classifying lets a real breach spread while it is labeled low priority. Triage Triage is the rapid, structured process of turning a raw alert into a scoped, actionable understanding: what fired, what host or user or asset is involved, is it a true positive, and what is the blast radius so far. Effective triage follows a checklist rather than improvisation under pressure; validate the alert, pull related telemetry (process tree, network connections, recent authentications), and establish a provisional scope before jumping to action. Triage order matters: identify and confirm before you contain, because premature containment on a misdiagnosed host wastes response capacity and can tip off an attacker on the real one. Containment Containment stops the bleeding without destroying evidence or over-committing to an incomplete picture. Short-term containment (isolate a host from the network, disable a compromised credential, block a C2 domain) buys time; long-term containment (rebuild from known-good, rotate all potentially exposed secrets) closes the incident. The order of operations matters: contain the immediate access an attacker has before eradicating, and preserve volatile evidence (memory, active connections) before pulling a machine's power, since forensics needs that data intact. Contain too aggressively and too early and you may lose the ability to determine full scope; contain too slowly and lateral movement continues. Communication An incident is also a communication problem. Responders need a single incident commander, a defined cadence of status updates, and separate channels for technical detail versus executive or legal summary. Communication must be need-to-know and out-of-band from any compromised system; do not discuss the incident over email if the attacker may have mailbox access. Clear, honest, and timely communication, including to affected users and, where required, regulators, is as much a part of professional incident response as the technical containment steps. Post-incident review Closing an incident is not the end of the response process; a structured post-incident review turns a single response into an organisational improvement. The review reconstructs the timeline dispassionately, asking what detection gap allowed the initial access to go unnoticed, whether triage classified severity correctly on the first pass, whether containment actions were executed in the right order, and whether communication reached the right people at the right time. The output is a specific list of remediation items with owners and deadlines, not a vague commitment to do better, and the review itself should be blameless: the goal is fixing the process that allowed the gap, not assigning fault to the analyst who happened to be on shift when it was missed. Related CCI capabilities Cambridge Cyber International's Global Cyber Incident Database (GCIDB) provides the kind of real severity and containment-timeline precedent a documented rubric benefits from: how comparable incidents were actually scoped, triaged, and contained, rather than an invented severity ladder with no track record behind it. See cambridgecyberinternational.com for current coverage. Forensics. Forensics. Perform memory and disk forensics.. Explain the artefacts memory and disk forensics rely on to reconstruct attacker activity.. Memory forensics, Disk forensics, Artifacts, Chain of custody Memory forensics Memory is volatile and disappears at power-off, which is exactly why it is often the richest evidence source: running processes, injected code, network connections, decrypted credentials, and malware that never touches disk (fileless attacks) all live in RAM. Tools such as Volatility parse a memory image to enumerate process lists, detect process hollowing or Dynamic-Link Library (DLL) injection by comparing in-memory structures against expected disk images, and extract command-line arguments an attacker thought were ephemeral. Because memory changes every second a machine stays powered on, capturing it is a time-sensitive, order-of-operations-critical step; it must happen before disk imaging or shutdown in almost every scenario. Disk forensics Disk forensics recovers persistence and history that outlives a reboot: file system metadata (Master File Table (MFT) entries, timestamps), deleted-but-not-overwritten files, registry run keys, scheduled tasks, and application logs. A forensic disk image is acquired as a bit-for-bit copy, not a file copy, so that unallocated space and deleted artifacts are preserved, and it is hashed immediately after acquisition to prove nothing changed afterward. Analysts work exclusively from copies of that image, never the original, and every tool run against it should be reproducible from the documented image hash. Artifacts Artifacts are the individual pieces of evidence an investigation stitches together: Windows Prefetch and Amcache (evidence of execution), Shimcache, browser history, Universal Serial Bus (USB) device history, shellbags, event logs, and memory strings. Each artifact answers a narrow question, such as whether a binary was ever executed on a host, and gains power only in combination with others. Part of forensic skill is knowing which artifact survives which anti-forensic technique; event log clearing does not touch Prefetch, and disabling Prefetch does not touch the MFT, so a competent investigator never relies on a single artifact type to prove or disprove compromise. Chain of custody Evidence that cannot be proven authentic and untampered is worthless in any proceeding that matters, whether legal, regulatory, or internal. Chain of custody means every person who touched evidence, every time it moved, and every hash verification is logged from the moment of acquisition onward. A broken chain, such as an unexplained gap, a missing hash match, or an unauthorized copy, can get evidence excluded entirely, regardless of how compelling its content is. Treat chain-of-custody documentation as part of the forensic work itself, not paperwork bolted on afterward. Network forensics Disk and memory are not the only volatile-adjacent evidence sources; captured network traffic, whether a full packet capture or, more commonly at scale, flow records, preserves what actually crossed the wire independent of what an attacker did to host-based logs afterward. A full packet capture lets an investigator reconstruct an exfiltration channel's actual payload, extract a malware family's command-and-control beacon pattern, or confirm exactly which external Internet Protocol (IP) address a compromised host communicated with and when, evidence that survives even if the attacker cleared every local log on the host itself. The tradeoff is storage cost: full packet capture at line rate for any meaningful retention window is expensive, which is why most environments retain flow-level metadata continuously and reserve full packet capture for a short rolling window or for hosts already flagged as high risk. Related CCI capabilities Cambridge Cyber International's EviGen offering automates exactly the technical evidence collection this module covers: acquisition across Windows, macOS, and Linux without a persistent agent, with the hashing and reproducibility discipline chain of custody requires. See cambridgecyberinternational.com for current availability. Timeline reconstruction. Timeline reconstruction. Reconstruct the timeline.. Explain timeline-reconstruction methodology and build a consolidated incident timeline from multiple evidence sources.. Correlation, Timelines, Root cause, Reporting Correlation No single log tells the whole story. Correlation joins events across disparate sources, such as an authentication log, a process-creation event, a firewall connection, and a file-modification timestamp, on shared keys like host, user, Internet Protocol (IP) address, or process ID to build a coherent narrative. This requires normalizing timestamps to a single timezone or clock reference first, since a two-hour clock-skew error between a firewall and an endpoint agent can silently invert cause and effect in the reconstructed sequence. Correlation is where isolated, individually low-signal events, such as a login, then a new scheduled task, then an outbound connection, combine into an unmistakable attack chain. Timelines A timeline is the structured, chronological artifact that results from correlation: every event of interest, its exact timestamp, its source, and a brief description, ordered so a reader can follow the intrusion step by step. Super-timelines built from many artifact types (Master File Table (MFT), event logs, browser history, memory) at once are powerful but noisy, so timeline construction is also an exercise in filtering, including only events that materially support or refute the working hypothesis of what happened, while documenting what was excluded and why. A good timeline is reproducible: another analyst given the same raw data should be able to rebuild the same sequence. Root cause A timeline shows what happened; root cause explains why it was possible. Root cause analysis traces the chain backward from impact to initial access, identifying the specific control gap that allowed each step (an unpatched vulnerability, a reused credential, an overly permissive firewall rule, a missing Multi-Factor Authentication (MFA) requirement) rather than stopping at the proximate cause. Conflating symptom with root cause is a common failure; 'the attacker had valid credentials' is not a root cause until you explain how those credentials were obtained and why no additional control stopped their use. A rigorous root cause analysis produces specific, verifiable remediation items, not vague hardening advice. Reporting The incident report is the durable output of the whole investigation, and it must serve multiple audiences at once: executives need business impact and remediation status, engineers need technical detail sufficient to fix the gap, and legal or compliance teams need a factual, defensible account free of speculation presented as fact. A strong report separates confirmed findings from working hypotheses, cites the specific evidence supporting each claim, includes the reconstructed timeline, and ends with concrete, owned remediation actions and deadlines. Reports that omit uncomfortable findings or blur uncertainty into false confidence undermine the credibility of the entire response function. Automation Manually joining every relevant field across every log source does not scale past a handful of concurrent investigations, so mature detection and response programs invest in correlation and timeline-generation tooling that automates the mechanical joins while leaving judgment calls to the analyst. A Security Information and Event Management (SIEM) platform's correlation engine can join events across sources in near real time using predefined rules, while dedicated timeline tools, such as those built on the Volatility and Plaso ecosystems, can merge disk, memory, and log artefacts into a single reviewable sequence after the fact. Automation accelerates the mechanical parts of correlation and timeline construction, but it does not replace the analyst's judgment about which events are causally connected and which are coincidental, so every automated timeline still needs a human review pass before it becomes the basis of a root-cause finding or a report. Related CCI capabilities Cambridge Cyber International's EviGen offering underlies the kind of defensible, hash-verified evidence trail this module's reporting standard requires: a reconstructed timeline is only as credible as the acquisition discipline behind the artefacts it cites. See cambridgecyberinternational.com for current availability.