Digital Forensics & Incident Response (DFIR)

1. Define what constitutes a security incident, who may declare and close one, severity criteria, duty coverage, executive ownership, and conditions for external support.
2. Build a role matrix for incident commander, lead investigator, evidence custodian, system owner, identity/cloud/network responders, legal, privacy, HR, communications, insurance, vendors, and law enforcement liaison.
3. Establish out-of-band communications and clean-room access. Assume normal email, chat, identity, endpoint management, and secrets may be observed or unavailable.
4. Inventory telemetry and retention by source: endpoints, identity, DNS, DHCP, VPN, email, proxy, firewall, cloud control planes, workloads, applications, databases, SaaS, backups, and physical systems. Test retrieval—not only collection.
5. Pre-stage signed or hashed tools, trusted boot media where applicable, secure evidence storage, isolated analysis systems, collection scripts, service-provider contacts, legal-hold procedures, and restoration credentials.
6. Exercise decision-heavy scenarios: ransomware, identity-provider compromise, cloud key theft, business email compromise, destructive insider activity, software supply-chain compromise, and loss of primary communications.

Baseline: use NIST SP 800-61 Rev. 3 with the FIRST CSIRT Services Framework 2.1. No team must provide every FIRST service; define what your constituency can actually expect.

Related Cyber Knowledge: Governance, Risk & Compliance (GRC) — Operational resilience, continuity, crisis, and incident governance

1. Record the trigger exactly: source, detection/rule ID and version, raw event references, first-seen time, receiver, affected identity/asset, and what the alert actually asserts.
2. Validate the signal without prematurely modifying the target. Check parser health, duplicate alerts, time zone, clock offset, asset/identity ownership, expected administration, and known maintenance.
3. Declare or reject an incident under documented criteria. Record who decided, when, based on which evidence, and when the decision must be revisited.
4. State testable hypotheses: initial access, affected identities, privilege gained, persistence, lateral movement, collection, exfiltration, impact, and whether the activity is still active. Name evidence that would support or weaken each.
5. Build an initial scope graph around users, hosts, IPs, sessions, processes, applications, cloud resources, tokens, repositories, data stores, and time windows. Treat scope as versioned—not final.
6. Assign severity from business impact, data, safety, privilege, exposure, active adversary control, recoverability, regulatory/contractual context, and confidence. Do not calculate severity from an IOC reputation score alone.

First-party practice: the SOC Tier 1 onboarding guide shows the handoff between monitoring, triage, escalation, evidence, and response.

Related Cyber Knowledge: Blue Team & Defensive Security — Module 6 — Alert triage, investigation, and escalation

1. Obtain authority and define the purpose, systems, accounts, locations, data categories, time range, collection limits, minimization, retention, and permitted recipients.
2. Prioritize volatile information by case value and loss risk: active sessions, processes, network state, memory, temporary storage, local logs, disk, remote logs, snapshots, and backups. “Order of volatility” is a decision aid, not an automatic command to collect everything.
3. Before collection, record collector identity, source identity, physical/logical location, source state, system time and reference time, tool name/version/hash, command or API request, output destination, and known changes introduced.
4. Use forensically appropriate acquisition where required. Hash the acquisition and working copies with an approved algorithm, verify after transfer, restrict access, log every custody transfer, and preserve storage/audit records.
5. Keep raw artifacts immutable where feasible. Perform parsing, carving, enrichment, and annotation on controlled copies; record tool versions, configuration, time-zone conversion, parser warnings, and failed/partial collection.
6. Separate technical integrity from legal admissibility. Consult counsel and qualified forensic personnel for litigation, criminal, employment, privacy, cross-border, regulated, or insurance-sensitive matters.

Primary guidance: RFC 3227 remains useful for collection and archiving principles; NIST SP 800-86 integrates forensic techniques with incident response but is a 2006 technical publication, not current legal advice.

Related Cyber Knowledge: Malware Analysis & Reverse Engineering — Intake, provenance, and analysis scope

1. Decide whether to observe, isolate, snapshot, collect, or power down based on active harm, safety, encryption, volatile evidence, adversary awareness, business criticality, and legal direction. Record the decision.
2. Confirm host identity using more than display name: asset record, hardware/cloud instance ID, operating system, addresses, owner, management agent, boot time, and current/reference clock.
3. Collect logged-on users and sessions, processes and parent/child relationships, executable paths and hashes, command lines where legally permitted, loaded modules, open files, listening/connected sockets, routes, DNS/cache, scheduled execution, services, and security-tool state.
4. Preserve relevant volatile data before disruptive actions. Memory acquisition may reveal injected code, credentials, keys, and sessions, but also highly sensitive data; secure and minimize it accordingly.
5. Record each command, agent action, remote connection, created file, timestamp change, process start, and network request caused by response. Avoid exploratory commands with uncontrolled output or tools that silently alter artifacts.
6. Validate collection completeness and failures. A successful API response does not prove all fields were returned; a disconnected endpoint does not prove it is offline.

Related Cyber Knowledge: Blue Team & Defensive Security — Module 7 — Endpoint defense and EDR

1. Choose logical collection, snapshot, volume image, or physical image based on question, platform, encryption, scale, legal need, available time, and operational risk. Document sectors, volumes, snapshots, exclusions, and partial acquisition.
2. Preserve partition, file-system, mount, encryption, time-zone, and system-clock context. Record whether timestamps come from source metadata, application content, archive headers, database records, or parser inference.
3. Analyze file creation/modification/access/change metadata, journals, deleted entries, alternate streams/extended attributes, archives, temporary files, browser/application state, user profiles, recycle/trash, and configuration stores.
4. Enumerate persistence and execution surfaces: services, scheduled jobs, startup folders, shell/profile files, login items, systemd/launchd units, registry autoruns, WMI/event subscriptions, browser extensions, package hooks, and cloud-init/user data.
5. Hash and classify suspicious files, preserve path and metadata, compare trusted baselines, search variants, and determine whether absence reflects deletion, non-collection, unsupported parsing, or true absence.
6. Build a file-level timeline, correlate with execution and identity records, and retain exact source references. Do not infer execution from file presence alone unless the artifact’s semantics support it.

Related Cyber Knowledge: Malware Analysis & Reverse Engineering — Static triage: strings, imports, resources, and capabilities

1. Preserve relevant EVTX channels and channel configuration: Security, System, Application, PowerShell, Task Scheduler, WMI, Defender, Sysmon where deployed, Terminal Services, and product-specific logs. Record retention and overwrite state.
2. Investigate logons and tokens using account/domain/SID, logon type, source workstation/address, target, authentication package, process, session/logon ID, privilege assignment, and logoff—while accounting for service accounts, NAT, proxies, and missing auditing.
3. Use registry hives and transaction logs to examine services, autoruns, user activity, USB/device history, network configuration, shell state, and application configuration. Preserve hive origin and last-write semantics.
4. Correlate Prefetch, Amcache, Shimcache/AppCompatCache, SRUM, LNK files, Jump Lists, browser history, PowerShell history/logging, scheduled tasks, services, MFT/USN journal, and EDR telemetry according to OS version and artifact availability.
5. For Active Directory or Entra-linked incidents, scope credential exposure, privileged groups, ticket/token issuance, directory changes, applications/service principals, MFA changes, federation, device registration, risky sessions, and synchronization infrastructure.
6. Validate tooling against known fixtures. Artifact meaning and availability vary by Windows version, settings, cleanup, retention, application, and parser; document those limits.

Related Cyber Knowledge: Blue Team & Defensive Security — Module 9 — Identity defense and ITDR

1. Identify distribution/build, kernel, boot/session state, file systems, containers/virtualization, time synchronization, audit configuration, log rotation, endpoint tooling, package manager, and mounted remote storage.
2. On Linux, preserve journald and syslog sources, authentication/sudo records, auditd, shell histories with their limitations, cron and systemd timers/units, SSH configuration and keys, package history, web/application logs, persistence paths, and process/network state.
3. On macOS, examine Unified Logs, FSEvents, APFS snapshots, launch agents/daemons, login items, quarantine and download metadata, TCC, shell and application artifacts, persistence extensions, user sessions, and endpoint security telemetry where available.
4. Review accounts, groups, SSH/remote-access state, authorized keys, sudoers, PAM, environment/profile files, credentials/tokens, cloud CLI state, package repositories, kernel/system extensions, and security-control changes.
5. Correlate inode/file metadata, journal records, process accounting/audit, package records, service activation, network flows, and centralized logs. Treat shell history as user-controlled and incomplete.
6. Preserve ownership, permissions, ACLs, extended attributes, capabilities, symbolic links, namespaces, and container volume mappings; a simple archive can lose material metadata.

Related Cyber Knowledge: Blue Team & Defensive Security — Module 7 — Endpoint defense and EDR

1. Acquire memory with an approved, validated tool appropriate to operating system, architecture, virtualization, security controls, and case authority. Record acquisition tool, driver/module, output, duration, host changes, and hash.
2. Establish image metadata and analysis compatibility. Preserve symbols, profiles, kernel/build information, plugin versions, failed translations, and unsupported structures.
3. Enumerate processes and cross-check multiple structures for hidden/terminated activity; inspect parentage, command lines, environment, handles, loaded modules, threads, sockets, and security tokens where supported.
4. Investigate executable and anomalous memory regions, injections, hooks, unsigned/unbacked mappings, decoded configurations, command-and-control state, and credential material only within authorization and data-handling rules.
5. Extract candidate files, strings, keys, connections, and indicators into controlled derivatives. Hash them, link them to memory offsets/process context, and validate with disk, endpoint, network, and threat-intelligence sources.
6. State negative results narrowly: “this plugin found no matching structure in this image” is defensible; “the host had no malware” is not.

Tooling: use the maintained Volatility 3 project and its documentation; preserve framework, symbol, plugin, and command versions in every result.

Related Cyber Knowledge: Malware Analysis & Reverse Engineering — Memory forensics, injection, and resident behavior

1. Map observation points and visibility: endpoint, switch/TAP, firewall, NAT, VPN, resolver, proxy, load balancer, CDN, WAF, cloud flow logs, email gateway, and SaaS audit. State whether records contain packets, metadata, sampled flow, or derived alerts.
2. Preserve packet captures and logs with interface/sensor identity, capture filter, snap length, loss/drop counters, time source, encapsulation, retention, export query, and checksum. Analysis should use a working copy.
3. Normalize addresses through DHCP, NAT, VPN, IPv6 privacy addresses, proxies, cloud elastic addresses, and load balancers before assigning activity to an asset or user.
4. Correlate DNS query/response, passive DNS where authorized, proxy and TLS metadata, HTTP records, network flows, EDR sockets, process identity, and server/application logs. Encryption may limit content while preserving useful metadata.
5. For email, preserve the original message and headers, authentication results, envelope, message trace, mailbox/audit activity, URLs, attachments, sender infrastructure, user actions, and tenant changes. Do not rely on the visible From field.
6. Use baselines and peer comparison for beaconing, data staging/exfiltration, lateral protocols, scanning, tunneling, unusual authentication, and protocol mismatch. Validate that collection and parsing can observe the hypothesized behavior.

First-party practice: Protocol-Level Network Threat Hunting develops a Wireshark-centered method for translating hypotheses into packet and protocol evidence.

Related Cyber Knowledge: Blue Team & Defensive Security — Module 8 — Network defense, protocol analysis, and NDR

1. Prepare a clean forensic/security account or project, cross-account roles, immutable evidence storage, encryption keys, automation, region coverage, organization-level logging, and provider escalation before an incident.
2. Preserve control-plane and data-plane audit logs, identity-provider events, session/token issuance, configuration history, network flow/DNS, workload and application logs, object access, secret/KMS activity, security findings, billing, and support records.
3. Record tenant/account/subscription/project, resource ID, region, API and request ID, principal/session, source address, user agent, time, event version, ingestion delay, export query, retention, and evidence-store object version.
4. Snapshot disks/volumes and collect instance/container state using provider-supported methods. Do not attach an affected disk to an unprotected analyst workstation; isolate analysis and restrict egress.
5. For Kubernetes and containers, preserve cluster audit logs, API events, RBAC, service accounts/tokens, admission and runtime alerts, image digests, manifests, node/runtime logs, network policy/flow, persistent volumes, registry and CI provenance, and ephemeral-container use.
6. For SaaS, export admin, authentication, sharing, mailbox, application consent, API token, file access, and retention records before short windows expire. Confirm provider time semantics and export completeness.
7. Scope credentials and infrastructure as code: keys, temporary sessions, workload identity, roles/policies, federated trust, secrets, pipelines, repositories, state files, and changes replicated across regions or organizations.

Primary practice: AWS describes separating collection from analysis and storing evidence before automated analysis in its forensics-in-IR guidance. Adapt the principle—not service-specific commands—to your environment.

Related Cyber Knowledge: Cloud Security — Cloud incident response, forensics, containment, and recovery

1. Preserve the original message, file, script, archive, document, URL, or memory-derived object; record source, delivery context, filenames, container relationships, passwords, hashes, and handling restrictions.
2. Perform static triage in an isolated environment: type/signature, metadata, strings, imports, configuration, macros/scripts, packer/obfuscation, certificates, embedded content, and known reputation—without opening on a normal workstation.
3. Use controlled dynamic analysis only when authorized: instrumented host, network simulation or tightly controlled egress, snapshots, process/file/registry/API/network capture, time controls, cleanup, and evidence preservation.
4. Extract behaviors first, indicators second. Record how each domain, IP, URL, hash, mutex, path, key, user agent, certificate, or command was observed and its expected lifetime and false-positive risk.
5. Map behaviors to ATT&CK as an analytical index, not attribution. Develop Sigma/YARA/network/EDR candidates with source evidence, scope, required telemetry, test fixtures, and review.
6. For ransomware, prioritize safety, active spread, privileged access, backup integrity, encryption/inhibition behavior, exfiltration evidence, and trusted recovery. Do not run unverified decryptors on the only evidence copy.

Deep dive: continue in the Malware Analysis & Reverse Engineering field guide, then use AdversaryGraph’s malware-family investigation workflow to organize reviewed evidence.

Related Cyber Knowledge: Malware Analysis & Reverse Engineering — Family classification, behavior models, YARA, and ATT CK

1. Retain raw timestamps, source time zone, precision, clock offset, event semantics, ingestion time, parser, and record locator. Normalize to one analysis time zone only as a derived field.
2. Merge endpoint, file-system, memory, identity, network, email, application, cloud, physical, and analyst-action records. Deduplicate carefully; repeated records across collectors may corroborate or simply mirror one source.
3. Build anchor events from high-confidence records such as verified authentication, provider API request IDs, process start linked to EDR, or message trace. Expand before and after each anchor and test alternative explanations.
4. Map entities and relationships: user, credential/session/token, device, process, file, address, domain, application, resource, repository, data object, alert, and evidence item. Preserve source-level links for every edge.
5. Use ATT&CK technique mapping to structure observed behavior. Record procedure evidence, platform, data source, mapping rationale, and confidence; a technique match does not establish actor identity.
6. Enrich indicators and techniques with current CTI while keeping external claims separate from local evidence. Check source date, confidence, collection method, sharing restrictions, revocation, and infrastructure reuse.
7. Assign confidence per conclusion and list supporting, contradicting, and missing evidence. Mark unknowns and collection gaps rather than converting them to negative findings.

Platform workflow: AdversaryGraph can store reports and investigation sessions, correlate reviewed entities, map ATT&CK, and produce analyst-reviewed outputs. Start with From Log to Report and the third-party report validation guide. It does not convert enrichment into proof.

Related Cyber Knowledge: Cyber Threat Intelligence (CTI) — Module 5 — Analysis Techniques Tradecraft

1. For each containment option, assess expected harm reduction, evidence impact, adversary reaction, operational/safety cost, reversibility, dependency, owner, approval, and rollback. Preserve volatile evidence first when risk permits.
2. Contain identities and sessions as well as hosts: revoke tokens, rotate exposed credentials and keys, disable or restrict accounts/apps, repair federation/trust, control egress, isolate segments/resources, and protect backups and response tooling.
3. Eradicate root cause, persistence, malicious access, vulnerable paths, unauthorized applications, compromised build/deployment artifacts, and poisoned configuration. Search variants and adjacent trust relationships.
4. Recover from a defined trusted state. Validate image/artifact provenance, patch/configuration, identity, secrets, backups, data integrity, dependencies, logging, detection, access, and business function before staged reconnection.
5. Monitor for recurrence using behaviors, identities, affected resources, newly learned indicators, and control-health signals. Define owner, duration, expected baseline, thresholds, and exit criteria.
6. Maintain technical and executive situation reports with confirmed facts, uncertainty, impact, decisions, actions, owners, next update, and handling classification. Legal/privacy/communications teams decide notification under applicable requirements.
7. Close only when scoped systems and identities are addressed, recovery is accepted, monitoring criteria are met, evidence retained, reports reviewed, and residual risks have accountable owners.

Worked workflow: follow Ransomware intrusion investigation for an evidence-preserving ransomware case structure.

Related Cyber Knowledge: Governance, Risk & Compliance (GRC) — Operational resilience, continuity, crisis, and incident governance

1. Conduct a blameless but accountable review: intended controls, what occurred, detection and decision timeline, evidence gaps, containment/recovery effectiveness, communication, business impact, contributing conditions, and successful practices.
2. Create owned, time-bounded improvements for prevention, telemetry, detection, response automation, evidence retention, access, architecture, backup/recovery, training, suppliers, and policy. Verify completion rather than closing on ticket creation.
3. Measure capabilities with distributions and context: time to validate, declare, scope, contain, recover, and close; evidence-source availability; collection success; decision latency; recurrence; exercise findings; and overdue improvements. Averages alone can hide severe outliers.
4. Use an approved LLM to summarize sanitized records, propose hypotheses, draft queries or timelines, explain artifacts, map candidate ATT&CK behaviors, and suggest missing evidence—but require a human to review every claim against sources.
5. For RAG, enforce source-level authorization before retrieval and response, preserve citations and immutable evidence IDs, separate original artifacts from chunks/embeddings/summaries, version the index, and reconcile additions, updates, deletions, and access changes.
6. For MCP or other tool connections, allowlist tools and targets, validate strict schemas, use least-privilege identities, isolate execution, cap time/data/cost, log every request/result, and require confirmation before containment, collection, scanning, deletion, or external communication.
7. Test prompt injection in reports, logs, webpages, documents, filenames, and retrieved content. Treat model output and tool output as untrusted until validated; never let the model approve its own evidence or expand its own authority.
8. Record provider/model/version, prompt/template, data classification, retrieved source IDs, tool calls, policy decisions, output, reviewer, corrections, and final disposition. Redact secrets and regulated content according to policy.

Implementation context: review the AdversaryGraph unified RAG and MCP guide and platform documentation. These define analysis assistance and auditability; they do not authorize collection or response actions.

Related Cyber Knowledge: Blue Team & Defensive Security — Module 13 — AI-assisted defense, RAG, agents, and MCP