How to build a DFIR evidence collection plan with ATLANTIS

01 / What is a DFIR evidence collection plan?

A DFIR evidence collection plan defines which forensic artifacts will be collected, from which endpoints, for what investigation purpose and how the returned evidence will be validated. It creates a documented boundary between the investigation question and the acquisition task.

Building a reliable collection plan starts with a defined investigation question. During incident response, collecting every available artifact from every endpoint can increase transfer volume, expose unrelated data and slow analysis. ATLANTIS helps analysts select the appropriate forensic profile, configure the evidence scope, target authorised endpoints and validate the returned collection before making an investigation decision.

02 / Why collection planning matters

Forensic collection is most useful when it answers a specific question. An analyst investigating suspicious execution needs different evidence from an analyst examining lateral movement, persistence, data exfiltration or ransomware impact.

A collection plan gives the investigation a controlled and repeatable structure:

• Purpose: What question must the evidence answer?
• Scope: Which artifacts and systems are relevant?
• Authority: Which endpoints and data sources are approved for collection?
• Destination: Where will the evidence be transferred and retained?
• Validation: How will the analyst confirm that the expected evidence was returned?
• Decision: What investigation or response action can follow from the result?

ATLANTIS turns these decisions into a guided operational workflow. The analyst selects a scenario, tunes the artifact scope, targets one endpoint or an authorised group, reviews the collection plan and dispatches the task with its investigation context preserved.

03 / The ATLANTIS evidence collection workflow

ATLANTIS organises forensic acquisition into four controlled steps:

1. Select an investigation profile. Begin with the incident question and choose the closest operational scenario.
2. Configure the forensic artifact scope. Select the categories and sources needed to answer that question.
3. Select endpoints and groups. Define the authorised systems included in the collection.
4. Review and execute. Confirm the target, destination and collection options before dispatching the task.

This approach keeps the collection focused while allowing the analyst to expand the scope deliberately as new evidence changes the investigation.

04 / Step 1: Select the investigation profile

Start with the investigation question rather than an unstructured artifact list. ATLANTIS profiles align evidence collection with common DFIR and incident-response scenarios.

Profile	Investigation focus	Example trigger
IR Baseline	Rapid host triage, active execution and core operating-system state.	A new endpoint enters an incident and requires an initial state assessment.
Lateral Movement	Network activity, service creation and remote-execution traces.	Remote logons, administrative shares or suspicious service creation are observed.
Persistence Sweep	Autoruns, services, tasks and platform-specific persistence footholds.	Suspicious activity returns after reboot or remediation.
Execution Provenance	Program execution and user-interaction artifacts.	An unsigned or suspicious executable is discovered on an endpoint.
User Activity	Desktop, access, mailbox and interactive-use context.	The investigation requires authorised reconstruction of user actions.
File System Change Audit	File inventory and modification or deletion evidence.	A file was created, altered, moved or removed during the incident window.
Authentication & Access	Accounts, authentication and privilege-elevation context.	Unusual logons, account use or privilege escalation requires review.
Endpoint State Snapshot	A concise system-state view for operational decisions.	The analyst needs a current endpoint snapshot before taking action.
Windows / macOS / Linux Deep Evidence	Platform-specific deeper evidence collection.	Initial triage leaves multiple hypotheses unresolved.
Ransomware / Data Exfiltration	Evidence aligned to impact, transfer and containment questions.	Encryption, staging, archive creation or suspicious transfer activity is detected.
Full Triage	Broad evidence acquisition for investigations requiring maximum configured coverage.	The attack path is unclear and the endpoint may contain evidence across several categories.
Custom Direct Command	Operator-controlled collection for a documented bespoke requirement.	A case requires a specific approved source or command outside a standard profile.

The selected profile is a starting point, not a substitute for analyst judgement. A ransomware investigation may still require a narrow endpoint group, while an IR Baseline collection may need an additional persistence or execution category to answer the case question.

05 / Step 2: Configure the forensic artifact scope

After selecting a profile, tune the evidence scope by category and subcategory. Typical categories include system and network state, execution traces, file system activity, persistence and configuration, user activity, identity and access, targeted scans and platform-specific artifacts.

For example:

• An execution investigation can combine Prefetch, Amcache, Shimcache, UserAssist, Jump Lists and LNK records.
• A persistence investigation can include services, Scheduled Tasks, autoruns, WMI persistence and relevant Registry locations.
• A browser investigation can include history, downloads, cookies and extension evidence within the authorised case scope.
• A lateral-movement investigation can combine logons, active connections, services, event logs and remote-execution traces.
• A file-system investigation can combine MFT, USN Journal, file listings, Recycle Bin and relevant event records.

The operator should understand why each category is included. This creates a clear collection rationale: an artifact is collected because it helps answer the investigation question, not simply because it is available.

How to choose the right evidence scope

Use the narrowest scope capable of answering the investigation question, then expand deliberately:

• What happened? Start with baseline, execution, user activity or endpoint-state evidence.
• How did it persist? Add services, tasks, autoruns, Registry and WMI persistence sources.
• How did it spread? Add lateral movement, authentication, network and remote-execution evidence.
• What changed? Add file-system records, targeted paths and relevant logs.
• What was affected? Add ransomware, data-exfiltration or business-critical application evidence.
• What remains uncertain? Use a deeper platform profile or a documented custom collection.

Evidence minimisation improves both operational efficiency and investigation quality. A focused collection reduces transfer overhead, limits unrelated data exposure and keeps analyst attention on evidence that can change the case decision.

06 / Step 3: Select endpoints and groups

The collection target can be one endpoint, a controlled endpoint group or a cross-platform selection supported by the chosen profile. Before dispatch, confirm:

• the endpoint is within the authorised investigation scope;
• the operating system matches the selected profile;
• the endpoint state and collection path are understood;
• the destination and retention settings are defined;
• the scope is appropriate for the system owner and business criticality;
• an analyst is assigned to review the returned evidence.

For a spreading threat, begin with confirmed and high-value endpoints, then expand to related systems. For broad triage, document the operational reason for selecting the wider group and preserve the same profile logic across the collection.

Endpoint and group targeting allows the same investigation question to be applied consistently. This is especially valuable when analysts must compare similar evidence across workstations, servers, identity systems or business units.

07 / Step 4: Review and execute

The review step is a control point before acquisition begins. Confirm the task name, target endpoints, selected artifact count, destination, compression or transfer options and advanced settings. The summary should make the collection scope understandable before the task is dispatched.

Record the operator, purpose, incident or investigation reference and approval state. If the plan is broader than the question requires, return to artifact configuration and refine the scope before execution.

08 / Example collection plan: suspicious PowerShell activity

The following example demonstrates how an analyst can translate an alert into a focused ATLANTIS collection plan.

Plan field	Selected value
Investigation question	Did a user execute a suspicious PowerShell payload, and did the activity establish persistence?
Initial endpoint	FINANCE-PC-07
Profile	Execution Provenance with selected persistence evidence
Execution evidence	Event Logs, Prefetch, Amcache, UserAssist and LNK records
Persistence evidence	Scheduled Tasks, Services, Registry and WMI persistence artifacts
Control context	Execution-policy state and available endpoint configuration
Destination	Approved investigation evidence repository
Expected outcome	Correlate execution, user context and persistence before selecting further collection or authorised response.

The plan avoids collecting an uncontrolled full set. It starts with evidence that can establish execution and persistence, while preserving a clear path to expand into process, network, file or deeper platform evidence if the initial result supports that decision.

09 / Windows forensic artifact reference

The following reference helps analysts translate an investigation question into a practical Windows evidence scope. The typical role describes how a source commonly contributes to triage; its importance can change according to the investigation hypothesis.

Artifact	What it collects	Typical role
processes	Running process inventory and process context.	Primary for active host triage.
connections	Active network connection snapshot.	Primary for current network activity.
systeminfo	Operating-system, hostname, hardware and system information.	Contextual system baseline.
filelisting	API-based file and directory listing.	Supporting file-system inventory.
rawfilelisting	Lower-level NTFS file listing.	Primary for deeper file-system review.
mft	Master File Table metadata for file-system reconstruction.	Primary file-system timeline evidence.
usnjrnl	USN Journal file-change records.	Primary file creation, change and deletion context.
prefetch	Windows Prefetch execution metadata, recency and run context.	Primary execution-oriented evidence.
eventlogs	Windows Event Log files and selected event records.	Primary operating-system and security-event evidence.
registry	Windows Registry hives and configuration evidence.	Primary configuration and persistence evidence.
shimdb	Shim database artifacts related to compatibility and execution control.	Supporting execution and compatibility context.
shimcache	AppCompatCache history and exposed file paths.	Supporting historical file and execution context.
userassist	UserAssist records for interactive application use.	Primary interactive-user execution context.
amcache	Amcache entries with file, installation and available hash metadata.	Primary file identity and historical system context.
shellbags	Folder-view and directory-access history.	Supporting user and directory-access context.
shortcuts	LNK metadata, target paths, timestamps and link context.	Supporting launch-path and source context.
jumplists	Recent application and file-access paths.	Supporting application and document activity.
recyclebin	Deleted-file metadata retained by the Recycle Bin.	Supporting deletion and user-context evidence.
tasks	Scheduled Task definitions and execution context.	Primary persistence and execution evidence.
services	Windows service configuration and persistence evidence.	Primary persistence and remote-execution evidence.
bits	Background Intelligent Transfer Service job records.	Primary transfer and persistence context.
srum	System Resource Usage Monitor activity records.	Primary application and network-usage context.
wmipersist	WMI persistence and subscription-related artifacts.	Primary persistence evidence.
outlook	Supported Outlook mailbox and local data artifacts.	Supporting communication and delivery context.
search	Windows Search database evidence.	Supporting file and user-search context.
users-windows	Windows local-user and account configuration.	Supporting identity and account context.
logons	Logon and session-related records.	Primary authentication and session evidence.
execpolicy	Script execution-policy state and related control settings.	Contextual script-control evidence.

Use this table as an investigation map rather than a fixed recipe. An execution-provenance review may combine prefetch, amcache, shimcache, userassist, jumplists and shortcuts. A persistence review may prioritise services, tasks, wmipersist, registry and bits. A lateral-movement investigation may bring together logons, connections, eventlogs, services and relevant file-system evidence.

No single source should automatically be treated as a complete verdict. ATLANTIS enables complementary artifacts to be collected under one plan so the analyst can correlate observations and document remaining uncertainty.

10 / Validate the collected forensic evidence

ATLANTIS collection should be assessed by the quality and usability of the returned evidence, not only by whether the task reached a completed state.

Validate the following:

1. Completion state: The task completed successfully or clearly reports partial collection and errors.
2. Endpoint identity: The expected endpoint and operating system appear in the result.
3. Scope fidelity: Returned categories correspond to the approved collection plan.
4. Evidence plausibility: Counts, timestamps, paths and file types are consistent with the endpoint and investigation period.
5. Package usability: The assigned analyst can access, search and interpret the output.
6. Exception visibility: Missing artifacts, access limitations and unavailable endpoints are visible.
7. Investigation continuity: The task, result and analyst assessment remain connected to the related investigation workflow.

11 / Common collection limitations

Forensic evidence is shaped by endpoint state, operating-system behaviour and the selected collection scope. Common limitations include:

• an endpoint being offline or temporarily unavailable;
• an artifact being disabled, expired, cleaned or never created;
• access to locked or protected data requiring an alternate acquisition path;
• the selected profile not including the source needed for a later hypothesis;
• transfer or destination availability affecting completion;
• partial collection returning some categories while others report exceptions;
• timestamps requiring timezone and source-specific interpretation.

An unavailable or empty artifact is a limitation to document, not automatic proof that the activity did not occur. ATLANTIS keeps completion state and collection exceptions visible so the analyst can decide whether to repeat, expand or redirect the acquisition.

12 / Repeat collection and preserved context

Investigations evolve. Preserve the profile, artifact scope, endpoint selection and task timestamp so a later collection can be interpreted against the earlier result.

A repeat collection should state what changed:

• a new investigation period;
• an expanded endpoint group;
• an additional artifact category;
• a follow-up after containment or remediation;
• a targeted attempt to close a known evidence gap.

Repeat collection is most valuable when the analyst understands the limitations of each source. An artifact can show historical exposure without independently proving execution, a log can contain an indicator without proving a network connection, and an absent record can reflect retention or platform behaviour rather than absence of activity.

13 / What ATLANTIS adds to the DFIR workflow

ATLANTIS turns forensic acquisition into a controlled operational workflow:

• Question-led profiles: Start with execution, persistence, lateral movement, user activity, ransomware or platform-specific investigation scenarios.
• Scoped artifact selection: Configure categories and subcategories instead of collecting an uncontrolled full set.
• Endpoint and group targeting: Apply the same plan to individual systems or authorised endpoint groups.
• Review before dispatch: Make the target, scope, destination and collection options visible before execution.
• Evidence continuity: Keep task context, completion state, exceptions and analyst interpretation connected to the investigation.
• Cross-platform acquisition: Apply Windows, macOS and Linux-oriented evidence plans through a consistent operational model.
• Investigation handoff: Use the returned evidence to guide file analysis, behavioural review, IOC hunting, repeat collection and authorised response.

The result is not simply an archive of collected files. It is a traceable path from the investigation question to the evidence scope, endpoint task, validated output and analyst decision.

14 / Comparing DFIR collection capabilities

When comparing ATLANTIS with a point-in-time collector, EDR or broader DFIR platform, assess the complete collection lifecycle rather than the number of artifacts listed in a catalogue.

Evaluation area	ATLANTIS emphasis
Scenario selection	Ready-made investigation profiles combined with operator-controlled scope.
Scope control	Artifact category, subcategory, endpoint, group and destination decisions before dispatch.
Platform coverage	Windows, macOS and Linux-oriented evidence profiles through a consistent workflow.
Evidence handling	Compression, transfer, approved destination and result validation.
Operational context	Task identity, selected scope, completion state, exceptions and analyst ownership remain visible.
Follow-up	Results guide targeted analysis, IOC hunting, repeat collection or authorised response.

ATLANTIS is designed to connect acquisition with investigation. The analyst can begin with a focused question, preserve the scope behind the task and use the returned evidence to determine the next proportionate action.

15 / DFIR evidence collection checklist

Before dispatching or closing an ATLANTIS collection task, confirm:

• The investigation question and selected profile are documented.
• Every selected artifact category has a clear purpose.
• Endpoint scope and system-owner expectations are confirmed.
• Destination, retention and transfer settings are defined.
• The review step was completed before dispatch.
• Partial collection and unavailable artifacts are visible.
• The returned package is accessible and usable by the assigned analyst.
• Timestamps and timezone assumptions are understood.
• The result is documented in the related investigation workflow.
• The next collection, analysis or response action has an owner.

16 / Frequently asked questions

What is the purpose of a DFIR evidence collection plan?

The plan connects an investigation question to a defined set of artifacts, endpoints, handling options and validation steps. It prevents acquisition from becoming an uncontrolled collection exercise and makes the result easier to interpret and defend.

Which Windows forensic artifacts should be collected first?

The first artifacts depend on the investigation question. Execution investigations often begin with Prefetch, Amcache, UserAssist, LNK records and event logs. Persistence investigations commonly prioritise services, Scheduled Tasks, Registry, WMI and BITS evidence. ATLANTIS profiles provide a scenario-based starting point that analysts can refine.

Does a missing artifact prove that activity did not occur?

No. Artifact availability depends on endpoint configuration, retention, operating-system behaviour, permissions and collection timing. Missing evidence should be recorded as a limitation and correlated with other available sources.

When should an analyst use Full Triage?

Full Triage is appropriate when the investigation contains several unresolved hypotheses or requires broad configured coverage. For focused questions, a narrower profile usually reduces transfer volume and review effort while preserving the ability to expand later.

Can ATLANTIS collect evidence from multiple endpoints?

Yes. Analysts can apply a collection plan to an authorised endpoint or controlled endpoint group, allowing consistent evidence scope across systems involved in the same investigation.

How should returned evidence be validated?

Confirm the task completion state, endpoint identity, scope fidelity, evidence plausibility, package usability and visible exceptions. The final result should remain connected to the investigation question and the analyst decision it supports.

17 / Practical outcome

An ATLANTIS collection plan creates a defensible bridge between investigation question → evidence scope → authorised endpoint collection → validated output → analyst decision.

The value is not simply more artifacts. It is a repeatable way to collect the right evidence, understand what was returned and move the investigation forward without losing operational context.