The role of DFIR during an active attack

TL;DR:

• During active cyber incidents, DFIR functions as a continuous, parallel process that guides response efforts in real time. Preserving volatile evidence through network isolation and thorough documentation is crucial, while segmentation strategies prevent evidence loss and attacker movement. Effective incident management depends on preparedness, rapid response, and integrating forensic thinking into every decision to prevent ongoing damage.

Most cybersecurity teams instinctively separate two things during a breach: stop the attack first, investigate later. It is an understandable impulse, but it is wrong. The role of DFIR during an active attack is to run forensic investigation and incident response simultaneously, not sequentially. Digital Forensics and Incident Response (DFIR) creates a continuous feedback loop where what the forensics team finds directly shapes what the response team does next, and vice versa. Getting this integration right is the difference between effective breach management and a drawn-out, evidence-poor recovery.

Table of Contents

• Key takeaways
• The role of DFIR during an active attack
• Forensic evidence during active incidents
• Building the incident timeline in real time
• Balancing containment and forensic integrity
• Implementing DFIR best practices during live breaches
• What working on the front line has taught me about active DFIR
• How Makkarisecurity supports active incident response
• FAQ

Key takeaways

The role of DFIR during an active attack

DFIR functions as a continuous parallel workflow during active compromises. Forensic actions and response activities happen at the same time, each informing the other. This is not a theoretical model. It is the operational reality that separates well-managed incidents from chaotic ones.

When a threat actor is inside your environment, the forensic team is capturing artefacts and building an attacker picture while the response team acts on those findings in near real time. The feedback loop works like this: forensics reveals where the attacker currently sits and how they moved laterally, which tells the response team exactly which systems to isolate and in what order. Response actions, in turn, create new forensic events that refine the investigation.

The practical workflow looks like this:

• Live memory capture on affected hosts before any containment action modifies system state
• Network traffic logging to document active command-and-control (C2) connections
• Endpoint isolation via network segmentation, not power-off, to sever attacker access without erasing volatile data
• Live response tooling to query running processes, open network connections, and loaded modules in real time
• Parallel documentation of every action taken, with timestamps, to maintain chain of custody

Pro Tip: Never assign the same analyst to both forensic capture and containment decisions during an active incident. Cognitive load under pressure leads to shortcuts. Keep those roles separated from the start.

Understanding this workflow prevents a critical mistake: treating DFIR as two separate disciplines that hand off to each other. Separating forensic investigation from response risks missed threat actor footholds and allows ongoing damage to accumulate while teams wait for the other side to finish.

Forensic evidence during active incidents

Evidence during an active attack is extraordinarily fragile. The volatility hierarchy determines your capture order, and deviation from it is one of the most costly mistakes in the field.

The order of priority for evidence capture runs from most volatile to least:

1. CPU registers and cache (lost the moment a process ends)
2. RAM and volatile memory (lost on reboot or power-off)
3. Running processes and network connections (change constantly)
4. Temporary files and swap space (may persist briefly but are overwritten)
5. Disk images and persistent storage (survives power cycle)
6. External logs and SIEM data (most durable, but may be incomplete without endpoint context)

Memory forensics captures evidence that disk analysis cannot recover: injected shellcode, credentials held in process memory, active network sessions established by fileless malware. Rebooting a host eliminates all of this permanently. This is not recoverable. The investigation continues without it.

Pro Tip: Stage memory acquisition tools on a dedicated, pre-imaged USB drive before any incident occurs. During a live breach, the time spent locating and validating tools costs you evidence.

Network isolation rather than system shutdown is the preferred first containment action precisely because it severs the attacker's access while leaving volatile memory intact. The host continues running. Processes remain. Memory can be captured. The attacker simply loses their communication channel.

There are several additional forensic considerations specific to active incidents:

• Chain of custody documentation must begin the moment a system is identified as potentially compromised, not after containment.
• Timestamped action logs covering every command run, every file accessed, and every system touched are non-negotiable. Comprehensive documentation supports forensic accuracy, legal defence, and after-action review.
• Evidence storage location matters. Storing forensic images on compromised network shares is a critical failure. Use dedicated, isolated, write-protected storage with controlled access credentials.
• Centralised logging outside the incident blast radius ensures log survivability even when a threat actor wipes local logs. Forward Windows events to a SIEM or isolated syslog server from day one, not during the incident.

Building the incident timeline in real time

The incident narrative is not something you construct after the fact. Building it during the active response is what allows your team to make informed decisions about scope and prioritisation, not guesses.

A defensible and operationally useful timeline covers six elements:

Incident narratives built with this structure serve insurance claims, legal defence, and internal remediation simultaneously. That multi-purpose value makes the investment in real-time documentation an operational necessity.

Constructing the timeline requires correlation across multiple data sources: endpoint logs, memory artefacts, network flow data, identity provider logs, and cloud control plane events. Early investigative clarity depends on anchoring on confirmed evidence of execution and building outward. Teams that attempt to process everything simultaneously drift. Anchor on a known-bad event, map backwards to initial access, and map forwards to current attacker position.

Automated correlation tools, specifically SIEM platforms and SOAR workflows, reduce the manual burden of this correlation work during a live incident. Graph-based visualisations of attacker movement are particularly effective for communicating blast radius to stakeholders who are not analysts.

Balancing containment and forensic integrity

This is where most teams feel the sharpest tension. Speed of containment and preservation of evidence pull in opposite directions. The decision-making framework for resolving that tension is not complicated, but it requires discipline to follow under pressure.

The foundational principle is this: network isolation is almost always the right first move. Balancing containment speed with evidence preservation means choosing network isolation as the early containment strategy rather than powering off affected systems. You stop the attacker's access and maintain the forensic state of the host simultaneously.

Several common containment errors destroy investigations:

• Rebooting a compromised host before memory capture erases injected code, active sessions, and credentials held in volatile memory. Rebooting destroys volatile artefacts critical for attribution and scoping. There is no recovery from this.
• Reimaging without prior forensic capture permanently removes the only record of what the attacker did on that system.
• Mass credential revocation without scoping first can alert a threat actor that discovery is underway, prompting destructive action such as ransomware detonation or data deletion.
• Terminating attacker-controlled processes prematurely closes the forensic window on tools and techniques that would otherwise be fully visible in memory.

Network isolation techniques include VLAN reassignment, firewall rule enforcement at the host or perimeter level, and where supported, endpoint detection and response (EDR) platform isolation. Isolating resources directly from investigative interfaces without switching tools accelerates containment and maintains the forensic trail. Platforms that unify investigation and response in a single interface are substantially more effective than those that require tool-switching between teams.

For cloud environments, containment decisions extend to snapshot creation before instance termination, preservation of cloud trail logs, and revocation of compromised identity credentials in a sequence that does not tip off the attacker before forensic capture is complete.

Implementing DFIR best practices during live breaches

Preparation determines how fast and how cleanly DFIR operates when it matters. Teams that have never staged their forensic tools or rehearsed their memory acquisition workflow lose critical minutes during a live incident. Those minutes cost evidence.

1. Prepare and validate toolkits in advance. Memory acquisition tools, live response frameworks, and evidence handling scripts should be tested and staged before any incident. Validate them against your current operating system versions quarterly.
2. Build and rehearse playbooks for parallel workflows. Your forensic capture playbook and your containment playbook should be separate documents with clearly defined handoff points. Rehearse both together so analysts understand the interdependencies.
3. Establish out-of-band communication channels. If your primary communication infrastructure is compromised, incident response coordination collapses. Pre-establish a secondary channel that operates outside your main environment.
4. Automate evidence collection where possible. Automated collection of process lists, network connections, and prefetch data at investigation onset reduces manual error and accelerates triage. Integrated investigation and response platforms improve efficiency and forensic trail preservation.
5. Coordinate forensic outputs with legal and compliance teams from the start. Breach counsel needs forensically sound data to manage regulatory notification timelines. If you wait until the investigation concludes, you will miss notification deadlines. Bring breach counsel into the process early and maintain a continuous evidence handoff protocol.

Pro Tip: Run a tabletop exercise specifically focused on the conflict between forensic preservation and containment speed. Force your team to make decisions under simulated time pressure. The decisions they make badly in a tabletop are the ones they will make badly in a real incident.

You should also review field notes on DFIR operations regularly. The field changes fast, and operational lessons from live incidents are more useful than theoretical frameworks.

What working on the front line has taught me about active DFIR

I have seen the sequential approach fail repeatedly. A team isolates a host, considers the immediate threat stopped, and then begins the investigation. By the time they reconstruct the attacker's path, they discover persistence mechanisms on three additional systems that were never isolated. The attacker re-established access while the investigation was still in triage.

The uncomfortable truth is that separating forensic investigation and incident response does not feel like a mistake in the moment. It feels organised. Rational, even. You stop the bleeding, then you look at the wound. But cyber attacks do not work like physical trauma. The attacker does not pause while you investigate. They continue operating in parallel, on systems you have not yet identified.

What I have learned is that the teams who manage active incidents most effectively are the ones who have genuinely internalised the feedback loop. They do not think of themselves as the forensics team or the response team. They think in terms of what the current forensic picture tells them about where the attacker is right now, and what action that demands immediately.

Cloud environments have made this harder, not easier. Visibility into control plane logs, identity events, and runtime behaviour requires a forensic approach that goes well beyond endpoint telemetry. Cloud-native DFIR requires visibility into control plane logs and runtime events to fully capture modern attacks. Teams that are still running endpoint-only forensic workflows are flying blind across a significant portion of their attack surface.

Embed forensic thinking into every response step. Not as an afterthought, but as the discipline that shapes the quality of every decision you make during a live breach.

— Makkari

How Makkarisecurity supports active incident response

Makkarisecurity's integrated DFIR capabilities are built specifically for the realities of live breaches. The proprietary forensic engine delivers live memory capture and cross-verified results with speed that generic providers cannot match, giving your team the forensic picture it needs to make containment decisions in real time rather than retrospectively.

Court-admissible forensic outputs from Makkarisecurity's breach counsel support service meet the evidentiary requirements of regulatory notification, insurance claims, and legal proceedings simultaneously. The Eviction Pledge adds a further layer of assurance: once a threat actor is evicted, they will not return for a minimum of 60 days, or you will not be charged. Makkarisecurity operates across the UK, Gibraltar, and broader Europe. If you are managing a live breach or preparing your organisation's response capability, contact the team directly.

FAQ

What is the role of DFIR during an active attack?

DFIR combines forensic evidence collection and incident containment into a single parallel workflow during active attacks. Forensic findings guide response priorities in real time, while containment actions preserve the evidentiary trail for investigation and legal purposes.

Why should you avoid rebooting a compromised host during an incident?

Rebooting destroys volatile memory artefacts permanently, including injected code, active network sessions, and credentials held in RAM. Network isolation preserves this evidence while severing the attacker's access.

What should be documented during a live DFIR operation?

Every action taken, every system touched, and every piece of evidence collected must be timestamped and logged from the moment an incident is escalated. This documentation supports forensic accuracy, legal defence, and regulatory reporting.

How does an incident timeline support breach management?

A time-anchored incident narrative covering initial access, lateral movement, data accessed, and persistence mechanisms informs remediation priorities and satisfies requirements for insurance claims, regulatory notification, and legal proceedings.

When should breach counsel be brought into a DFIR operation?

Breach counsel should be engaged at the start of a confirmed incident, not after investigation concludes. Early coordination aligns forensic outputs with regulatory notification timelines and legal defence requirements.

Recommended

• Insights | Field notes from Makkari Security
• Breach Counsel & Panel Support | Court-admissible DFIR | Makkari Security
• Mission | Makkari Security
• Capabilities | Incident Response, Digital Forensics, IR Retainer | Makkari Security