Investigation goals in DFIR reports

When a DFIR investigation starts you never know how big it will be. Some cases might give you a hint (if law enforcement have let you know about a compromise, or if EDR alerts tell you about a compromise on a server that has confidential data on it). By using a framework that is consistent for your investigations, you can start with clearly defined investigative goals.

Without a structured approach, investigations remain inefficient, and ultimately ineffective (especially when multiple people commence working on it). The foundation of any successful cyber investigation is knowing what you are looking for before an incident occurs. We can do this by using investigation guides, incident response playbooks and finally, practicing them often.

Doing tabletop exercises that are actually practical, instead of high-level tests where you assume based on the roll of a dice if the action works or not is the only way you’ll discover what works, what doesn’t and where assumptions on the availability of logs and access to those logs are wrong.

Why Investigative Goals Matter

Every digital forensic and incident response (DFIR) case involves a series of unknowns, such as whether an attacker is still in the system, what they accessed, and how they got in. These are the basic questions the leadership team want to know about. Without a predefined set of goals, investigators risk losing access to logs that contain answers to these questions, but can also be derailed by seemingly interesting artifacts within evidence.

A defined investigation framework that is known and tested by everyone on the team helps the DFIR team remain focused, getting the evidence needed as quickly as possible and ensures a structured, efficient, and thorough forensic process. By proactively setting investigative goals, cybersecurity teams can investigate quicker, identifying the root cause and providing recommendations more quickly.

Defining Your Investigation Scope

Defining the scope of an investigation needs to happen at the start of the investigation. While we might start off with a hypothesis of what’s happened and where the evidence is stored for this incident, remember to keep and open mind and follow the evidence.

We need to be open to new ideas and then keep acquiring additional evidence, processing it and then documenting our findings as we go.

1. Identify Key Questions: Before collecting evidence, determine the most pressing questions that need to be answered. Examples include:
   • Was there unauthorised access?
   • What data was accessed, exfiltrated or modified?
   • Are attackers still active in the system?
   • How did they get in?
   • Has the original vulnerability been patched/remediated?
   • Who are the key contacts for the system?
   • Was this vulnerability known about prior to the incident?
   • Has anyone tried remediating this vulnerability previously?
2. Understand Log Retention: Knowing how far back logs are stored is crucial. This is likely different on all systems. Cloud vs local is a big difference. . Practical steps include:
   • Reviewing SIEM configurations to confirm log availability.
   • Checking system-specific log settings, such as Windows Event Logs and firewall logs.
   • Working with system administrators to ensure critical logs are not deleted prematurely
   • Exporting all relevant logs at the start of the investigation and throughout as more affected systems are discovered
3. Consider Evidence Volatility: Different types of evidence have varying lifespans. Prioritize the collection of data that is most at risk of being lost, such as:
   • Memory (RAM) dumps – Capturing live system memory before rebooting a machine.
   • Network traffic logs – These often rotate quickly, making real-time capture essential.
   • Temporary files and execution artifacts (Temp Directories (Windows %TEMP% & Linux /tmp/)) – Prefetch files, shim cache, and temp directories can provide insights into recent activity. Prefetch files remain on disk until the system purges them, typically after 128 entries on Windows 10/11. They persist across reboots but can be manually deleted by attackers or system cleaners. Temporary files can be automatically deleted by the system, overwritten by ongoing processes, or erased upon user logoff or reboot (especially on Linux). Attackers frequently use temp directories for staging payloads or execution, making them valuable but short-lived evidence.
4. Outline an Investigation Plan: Your investigation plan needs to acquire the evidence first. Each investigation will vary. Tailor this based on your incident type.
   • Predefine Evidence Checklists – Develop forensic checklists tailored for specific incident types, such as insider threats, ransomware, and unauthorised access. Include log sources, system artifacts, and command sequences for quick retrieval.
     Windows Event Logs:
   • Security (Event ID 4624, 4625, 4672, 4688) – Identifies login attempts, privilege escalation, and process execution.
   • System (Event ID 1074, 6008) – Detects unexpected shutdowns or reboots initiated by attackers.
   • PowerShell (Event ID 4103, 4104) – Detects script execution related to ransomware payload deployment.
   • Sysmon (Event ID 1, 3, 7, 10, 11, 13, 22, 23) – Tracks process execution, network connections, registry modifications, and file access.
   • File System Logs:
     • NTFS Change Journal (USN Journal) – Tracks mass file modifications and deletions.
   • Shadow Copy Logs (Event ID 33) – Detects deletion of shadow copies, a common tactic to prevent data recovery.
   • Network & Perimeter Logs:
   • Firewall & Proxy Logs – Identifies C2 traffic and external connections to known ransomware IPs.
   • VPN & RDP Logs – Checks for external access before deployment (Event ID 4624, 4776).
   • Backup & Storage Logs:
   • Backup Failure Logs – Attackers often disable backup solutions before encryption.
   • Develop Playbooks for Repeatable Processes – In this case, the playbook is not just a flowchart. Take the time and put the effort in to create step-by-step investigation guides that detail forensic acquisition, analysis workflows, and provide a template for the post incident report.
   • Clarify Stakeholder Needs – Identify the primary audience for your forensic report. Executives require concise overviews with business impact assessments, while security engineers need technical deep dives. Define reporting formats that cater to multiple levels of expertise. This can be achieved in the report by using an executive summary, findings and detailed findings.