Evidence Collection

Evidence collection encompasses the systematic acquisition of digital artefacts from systems, networks, and cloud platforms in a manner that preserves their integrity and maintains an unbroken chain of custody. You perform evidence collection during security incidents when the organisation requires forensic analysis, legal action against threat actors, insurance claims, regulatory reporting, or post-incident review. The outcome is a verified set of evidence items with documented provenance suitable for internal investigation or handover to law enforcement.

Prerequisites

Before beginning evidence collection, ensure you have the following in place.

Authorisation:

• Written approval from incident commander or designated authority
• Legal review completed for incidents involving personal data or potential criminal prosecution
• HR notification if the incident involves employee misconduct
• Data protection officer notification for incidents affecting personal data

Tools and equipment:

• Write blocker (hardware or software) for disk imaging
• Forensic workstation with validated tools installed
• External storage with sufficient capacity (minimum 2x the target data volume)
• Memory acquisition tool appropriate to target operating system
• Network packet capture capability
• Evidence bags and tamper-evident seals for physical media
• Chain of custody forms (paper or digital system)
• Camera or phone for photographing physical evidence and screen states

Storage:

• Designated secure evidence storage location with access controls
• Encrypted storage for evidence at rest
• Evidence management system or secure file share with audit logging

Reference information:

• Asset inventory with system specifications
• Network diagrams showing relevant systems
• Account credentials for administrative access to affected systems
• Cloud platform administrative access credentials
• Contact details for relevant cloud provider forensics teams

Evidence types and collection priority

Digital evidence degrades and disappears at different rates. Volatile evidence exists only in running system memory and vanishes when the system powers off or reboots. Semi-volatile evidence persists through reboots but changes with system operation. Non-volatile evidence remains stable on storage media until explicitly modified.

Collect evidence in order of volatility, starting with the most volatile:

+------------------------------------------------------------------+
|                    EVIDENCE VOLATILITY HIERARCHY                 |
+------------------------------------------------------------------+
|                                                                  |
|  COLLECT FIRST (seconds to minutes of persistence)               |
|  +------------------------------------------------------------+  |
|  | CPU registers, cache, running processes, network           |  |
|  | connections, ARP cache, routing tables, memory contents    |  |
|  +------------------------------------------------------------+  |
|                              |                                   |
|                              v                                   |
|  COLLECT SECOND (minutes to hours)                               |
|  +------------------------------------------------------------+  |
|  | Temporary files, swap space, logged-in users, clipboard    |  |
|  +------------------------------------------------------------+  |
|                              |                                   |
|                              v                                   |
|  COLLECT THIRD (hours to days)                                   |
|  +------------------------------------------------------------+  |
|  | System logs, application logs, security logs, audit logs   |  |
|  +------------------------------------------------------------+  |
|                              |                                   |
|                              v                                   |
|  COLLECT FOURTH (stable until modified)                          |
|  +------------------------------------------------------------+  |
|  | Disk images, file systems, database contents, backups,     |  |
|  | configuration files, email archives                        |  |
|  +------------------------------------------------------------+  |
|                                                                  |
+------------------------------------------------------------------+

Figure 1: Evidence collection priority by volatility

The time pressure varies by incident type. A ransomware incident where systems remain powered demands immediate memory capture before encryption processes complete. An account compromise investigation where the attacker has departed allows more deliberate collection starting with logs.

Procedure

Preparing the collection environment

1. Create an evidence collection case folder with a unique identifier following the format CASE-YYYY-MM-DD-NNN where NNN is a sequential number. All evidence items, documentation, and chain of custody records for this incident belong in this folder.

   # Create case folder structure
   mkdir -p /evidence/CASE-2024-11-16-001/{memory,disk,logs,cloud,network,mobile,docs}

2. Initialise the chain of custody log for this case. Record the case identifier, incident reference, date and time of case creation, and your name as the initial custodian.

   Case ID: CASE-2024-11-16-001
   Incident Reference: INC-2024-1847
   Created: 2024-11-16T09:23:00Z
   Initial Custodian: J. Smith (IT Security)
   Authorisation Reference: AUTH-2024-11-16-003

3. Document the current state of target systems before any collection activity. Photograph screens showing error messages, ransom notes, or unusual behaviour. Record which systems are powered on, network connected, and user logged in.

4. Verify your forensic tools produce expected output by running a test acquisition against a known clean system. This establishes that your tools function correctly before you rely on them for actual evidence.

Collecting volatile evidence from memory

Memory acquisition captures the contents of system RAM including running processes, network connections, encryption keys, and malware that exists only in memory. You must collect memory before powering off a system or the evidence is permanently lost.

1. Determine the memory size of the target system. Memory acquisition requires storage space equal to the physical RAM plus overhead of 10-15%.

   # Linux: check memory size
   free -h

   # Windows PowerShell: check memory size
   Get-CimInstance Win32_PhysicalMemory | Measure-Object -Property Capacity -Sum

A system with 32 GB RAM requires approximately 36 GB of storage for the memory image.

2. Select the appropriate acquisition tool for the target operating system. For Windows systems, use WinPmem or FTK Imager. For Linux systems, use LiME (Linux Memory Extractor) or AVML (Acquire Volatile Memory for Linux). For macOS, use osxpmem.

3. Execute memory acquisition, writing the output directly to your external evidence storage. Never write evidence to the target system’s local storage as this overwrites potential evidence.

   Linux with LiME:

   # Load LiME kernel module, output to external drive
   sudo insmod lime-$(uname -r).ko "path=/mnt/evidence/CASE-2024-11-16-001/memory/server01-mem.lime format=lime"

Windows with WinPmem:

   # Run WinPmem with raw format output
   winpmem_mini_x64.exe E:\CASE-2024-11-16-001\memory\workstation15-mem.raw

Linux with AVML (for cloud instances):

   # AVML is a single binary, useful for cloud forensics
   sudo ./avml /mnt/evidence/CASE-2024-11-16-001/memory/instance-mem.lime

4. Calculate and record the hash of the acquired memory image immediately after acquisition completes. Use SHA-256 for all evidence hashing.

   sha256sum /mnt/evidence/CASE-2024-11-16-001/memory/server01-mem.lime > \
     /mnt/evidence/CASE-2024-11-16-001/memory/server01-mem.lime.sha256

5. Record the memory acquisition in the chain of custody log including the evidence item identifier, source system, acquisition time, file size, hash value, and your name.

   Evidence Item: MEM-001
   Source: server01.example.org (192.168.1.50)
   Acquisition Time: 2024-11-16T09:47:23Z
   File: server01-mem.lime
   Size: 34,359,738,368 bytes
   SHA-256: 8a7f3b2c1d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a
   Acquired By: J. Smith

6. Capture running process information and network connections before system state changes. This volatile information supplements the memory image.

   Linux:

   # Running processes with full command lines
   ps auxww > /mnt/evidence/CASE-2024-11-16-001/memory/server01-processes.txt

   # Network connections with process information
   ss -tulnp > /mnt/evidence/CASE-2024-11-16-001/memory/server01-netstat.txt

   # Open files by process
   lsof > /mnt/evidence/CASE-2024-11-16-001/memory/server01-lsof.txt

Windows:

   # Running processes
   Get-Process | Select-Object * | Export-Csv E:\CASE-2024-11-16-001\memory\workstation15-processes.csv

   # Network connections
   Get-NetTCPConnection | Export-Csv E:\CASE-2024-11-16-001\memory\workstation15-netstat.csv

   # Loaded DLLs
   Get-Process | ForEach-Object { $_.Modules } | Export-Csv E:\CASE-2024-11-16-001\memory\workstation15-dlls.csv

Creating forensic disk images

Disk imaging creates a bit-for-bit copy of storage media including deleted files, slack space, and unallocated areas. A forensic image differs from a backup in that it captures the complete storage device rather than just active files.

1. If possible, power off the target system and remove storage media for imaging. Imaging a powered-off disk through a write blocker provides the strongest evidence integrity. For systems that cannot be powered off (production servers, critical infrastructure), perform live imaging with appropriate documentation of the limitation.

2. Connect the source media to your forensic workstation through a hardware write blocker. The write blocker prevents any modification to the source media during imaging.

   +------------------+     +------------------+     +------------------+
   |                  |     |                  |     |                  |
   |  Source Disk     |---->|  Write Blocker   |---->|  Forensic        |
   |  (Evidence)      |     |  (Tableau T35u)  |     |  Workstation     |
   |                  |     |                  |     |                  |
   +------------------+     +------------------+     +------------------+
                                    |
                                    | Write operations blocked
                                    | Read operations passed through

Figure 2: Write blocker connection for forensic imaging

3. Verify the write blocker is functioning by attempting a write operation to the source media; it must fail.

   # This should fail with permission denied or read-only filesystem error
   touch /mnt/source-media/test-write-blocked.txt

4. Calculate and record the hash of the source media before imaging begins. This pre-image hash proves the source was unmodified.

   # Hash the entire source device
   sudo sha256sum /dev/sdb > /mnt/evidence/CASE-2024-11-16-001/disk/server01-disk-pre.sha256

5. Create the forensic image using a tool that supports forensic formats with built-in integrity verification. Use EWF (Expert Witness Format, also called E01) or raw format with separate hash. EWF includes compression and segmentation for large images.

   Using ewfacquire (recommended for large disks):

   sudo ewfacquire /dev/sdb \
     -t /mnt/evidence/CASE-2024-11-16-001/disk/server01-disk \
     -f encase6 \
     -c deflate:best \
     -S 4GiB \
     -C "CASE-2024-11-16-001" \
     -D "Server01 primary disk" \
     -e "J. Smith" \
     -N "Server01 incident investigation"

This creates segmented E01 files (server01-disk.E01, server01-disk.E02, etc.) with compression. A 500 GB disk typically compresses to 150-200 GB.

Using dd with dcfldd for raw format:

   sudo dcfldd if=/dev/sdb \
     of=/mnt/evidence/CASE-2024-11-16-001/disk/server01-disk.raw \
     hash=sha256 \
     hashlog=/mnt/evidence/CASE-2024-11-16-001/disk/server01-disk.hashlog \
     hashwindow=1G

6. Verify the image integrity after acquisition completes. For EWF images, use the built-in verification. For raw images, compare hashes.

   # Verify EWF image
   ewfverify /mnt/evidence/CASE-2024-11-16-001/disk/server01-disk.E01

   # Verify raw image matches source
   sha256sum /mnt/evidence/CASE-2024-11-16-001/disk/server01-disk.raw
   # Compare with pre-image hash of source

7. Record the disk image in the chain of custody log with full technical details.

   Evidence Item: DSK-001
   Source: server01.example.org primary disk
   Disk Model: Samsung 870 EVO 500GB
   Disk Serial: S5XXNJ0R123456A
   Acquisition Time: 2024-11-16T10:23:00Z to 2024-11-16T11:47:00Z
   Image Format: EWF (E01)
   Image Files: server01-disk.E01 through server01-disk.E12
   Total Size: 167,234,567,890 bytes (compressed)
   Source Size: 500,107,862,016 bytes
   Pre-Image SHA-256: 1a2b3c4d5e6f...
   Post-Image SHA-256: 1a2b3c4d5e6f... (must match pre-image)
   Image MD5 (from EWF): 9f8e7d6c5b4a...
   Write Blocker: Tableau T35u Serial TB35-12345
   Acquired By: J. Smith

Collecting log evidence

Log files provide chronological records of system events, authentication attempts, application activity, and security events. Unlike memory and disk evidence that requires specialised tools, log collection uses standard file operations but demands careful attention to completeness and integrity.

1. Identify all relevant log sources for the incident. A typical incident requires logs from multiple systems.

   +------------------------------------------------------------------+
   |                       LOG SOURCE MAPPING                         |
   +------------------------------------------------------------------+
   |                                                                  |
   |  ENDPOINT LOGS                                                   |
   |  +------------------------------------------------------------+  |
   |  | Windows Event Logs: Security, System, Application          |  |
   |  | Linux: /var/log/auth.log, /var/log/syslog, /var/log/secure |  |
   |  | Application logs: web server, database, custom apps        |  |
   |  +------------------------------------------------------------+  |
   |                              |                                   |
   |                              v                                   |
   |  NETWORK LOGS                                                    |
   |  +------------------------------------------------------------+  |
   |  | Firewall logs, VPN logs, proxy logs, DNS query logs        |  |
   |  +------------------------------------------------------------+  |
   |                              |                                   |
   |                              v                                   |
   |  IDENTITY LOGS                                                   |
   |  +------------------------------------------------------------+  |
   |  | IdP audit logs, SSO logs, MFA logs, directory changes      |  |
   |  +------------------------------------------------------------+  |
   |                              |                                   |
   |                              v                                   |
   |  CLOUD PLATFORM LOGS                                             |
   |  +------------------------------------------------------------+  |
   |  | Azure AD sign-in, AWS CloudTrail, GCP Audit Logs           |  |
   |  +------------------------------------------------------------+  |
   |                              |                                   |
   |                              v                                   |
   |  SECURITY TOOL LOGS                                              |
   |  +------------------------------------------------------------+  |
   |  | SIEM events, EDR detections, antivirus logs                |  |
   |  +------------------------------------------------------------+  |
   |                                                                  |
   +------------------------------------------------------------------+

Figure 3: Common log sources for incident investigation

2. Determine the relevant time window for log collection. Start with the known incident timeline and extend backwards by at least 7 days to capture reconnaissance activity and extend forwards to the present to capture ongoing attacker actions.

   For an incident detected on 2024-11-16 with suspected compromise starting 2024-11-10:

   • Collection start: 2024-11-03 (7 days before suspected compromise)
   • Collection end: 2024-11-16 (present)

3. Collect Windows Event Logs using wevtutil or PowerShell. Export in EVTX format to preserve all metadata.

   # Export Security log
   wevtutil epl Security E:\CASE-2024-11-16-001\logs\workstation15-Security.evtx

   # Export System log
   wevtutil epl System E:\CASE-2024-11-16-001\logs\workstation15-System.evtx

   # Export Application log
   wevtutil epl Application E:\CASE-2024-11-16-001\logs\workstation15-Application.evtx

   # Export PowerShell operational log (critical for investigation)
   wevtutil epl Microsoft-Windows-PowerShell/Operational E:\CASE-2024-11-16-001\logs\workstation15-PowerShell.evtx

4. Collect Linux logs by copying the relevant files. Preserve file metadata including timestamps and permissions.

   # Create timestamped archive of log directory
   sudo tar --preserve-permissions --acls --selinux \
     -cvzf /mnt/evidence/CASE-2024-11-16-001/logs/server01-var-log.tar.gz \
     /var/log/

   # Hash the archive
   sha256sum /mnt/evidence/CASE-2024-11-16-001/logs/server01-var-log.tar.gz > \
     /mnt/evidence/CASE-2024-11-16-001/logs/server01-var-log.tar.gz.sha256

5. Export logs from centralised logging systems (SIEM, log aggregator) covering the relevant time window and systems.

   # Example: Export from Elasticsearch/OpenSearch
   curl -X POST "https://siem.example.org:9200/logs-*/_search?scroll=5m" \
     -H "Content-Type: application/json" \
     -d '{
       "query": {
         "bool": {
           "must": [
             { "range": { "@timestamp": { "gte": "2024-11-03", "lte": "2024-11-16" } } },
             { "terms": { "host.name": ["server01", "workstation15"] } }
           ]
         }
       },
       "size": 10000
     }' > /mnt/evidence/CASE-2024-11-16-001/logs/siem-export-batch1.json

6. Record each log source in the chain of custody with collection details.

Collecting cloud evidence

Cloud environments present unique challenges for evidence collection. You do not have physical access to underlying infrastructure, evidence may span multiple geographic regions, and cloud providers control the retention and availability of certain log types.

1. Identify which cloud services and accounts are in scope for the incident. Map affected resources to the cloud accounts and subscriptions that contain them.

2. Preserve cloud identity provider logs before they age out. Most cloud identity logs retain for 30 days by default. Export immediately.

   Microsoft Entra ID (Azure AD):

   # Connect to Microsoft Graph
   Connect-MgGraph -Scopes "AuditLog.Read.All", "Directory.Read.All"

   # Export sign-in logs (last 30 days maximum)
   Get-MgAuditLogSignIn -Filter "createdDateTime ge 2024-11-03" -All |
     Export-Csv -Path "E:\CASE-2024-11-16-001\cloud\entra-signin-logs.csv"

   # Export audit logs
   Get-MgAuditLogDirectoryAudit -Filter "activityDateTime ge 2024-11-03" -All |
     Export-Csv -Path "E:\CASE-2024-11-16-001\cloud\entra-audit-logs.csv"

AWS CloudTrail:

   # Download CloudTrail logs from S3 for date range
   aws s3 sync s3://your-cloudtrail-bucket/AWSLogs/123456789012/CloudTrail/ \
     /mnt/evidence/CASE-2024-11-16-001/cloud/cloudtrail/ \
     --exclude "*" \
     --include "*2024-11-*"

   # Or query CloudTrail directly for specific events
   aws cloudtrail lookup-events \
     --start-time 2024-11-03T00:00:00Z \
     --end-time 2024-11-16T23:59:59Z \
     --output json > /mnt/evidence/CASE-2024-11-16-001/cloud/cloudtrail-events.json

Google Cloud Audit Logs:

   # Export audit logs via gcloud
   gcloud logging read \
     'logName:"cloudaudit.googleapis.com" AND timestamp>="2024-11-03"' \
     --project=your-project-id \
     --format=json > /mnt/evidence/CASE-2024-11-16-001/cloud/gcp-audit-logs.json

3. Capture cloud resource configuration state. The current configuration provides context for understanding the incident and may reveal attacker modifications.

   Azure resource export:

   # Export all resources in affected subscription
   Get-AzResource |
     ForEach-Object { Get-AzResource -ResourceId $_.ResourceId -ExpandProperties } |
     ConvertTo-Json -Depth 10 > E:\CASE-2024-11-16-001\cloud\azure-resources.json

AWS configuration snapshot:

   # Use AWS Config or manual export
   aws configservice get-resource-config-history \
     --resource-type AWS::EC2::Instance \
     --resource-id i-1234567890abcdef0 \
     --output json > /mnt/evidence/CASE-2024-11-16-001/cloud/ec2-config-history.json

4. For cloud compute instances requiring disk forensics, create snapshots before any remediation. The snapshot preserves the disk state for later forensic imaging.

   AWS EC2 snapshot:

   # Snapshot the root volume
   aws ec2 create-snapshot \
     --volume-id vol-0123456789abcdef0 \
     --description "Forensic snapshot CASE-2024-11-16-001" \
     --tag-specifications 'ResourceType=snapshot,Tags=[{Key=Case,Value=CASE-2024-11-16-001}]'

Azure managed disk snapshot:

   # Create snapshot of managed disk
   $snapshotConfig = New-AzSnapshotConfig `
     -SourceResourceId "/subscriptions/.../disks/affected-vm-osdisk" `
     -Location "uksouth" `
     -CreateOption Copy

   New-AzSnapshot -ResourceGroupName "forensics-rg" `
     -SnapshotName "CASE-2024-11-16-001-osdisk" `
     -Snapshot $snapshotConfig

5. Document cloud evidence with provider-specific identifiers (ARN, resource ID, subscription ID) that uniquely identify the source.

Preserving email evidence

Email evidence requires preservation of complete message data including headers, attachments, and metadata. A forwarded or printed email loses critical header information that establishes message routing and authenticity.

1. Identify mailboxes containing relevant messages. This includes mailboxes of affected users, mailboxes that received phishing emails, and mailboxes involved in business email compromise.

2. Place litigation hold or in-place hold on relevant mailboxes to prevent evidence deletion during the investigation.

   Microsoft 365:

   # Connect to Exchange Online
   Connect-ExchangeOnline

   # Place hold on specific mailbox
   Set-Mailbox -Identity "affected.user@example.org" -LitigationHoldEnabled $true -LitigationHoldDuration 365

   # Or create eDiscovery hold for multiple mailboxes
   New-ComplianceCase -Name "CASE-2024-11-16-001"
   New-CaseHoldPolicy -Name "CASE-2024-11-16-001-Hold" -Case "CASE-2024-11-16-001"
   New-CaseHoldRule -Name "Hold All" -Policy "CASE-2024-11-16-001-Hold" -ContentMatchQuery "*"

Google Workspace:

   # Use Google Vault to create matter and hold
   # (typically done through Vault web interface)

3. Export relevant messages in a format that preserves all data. PST or EML formats preserve headers and attachments. Use eDiscovery search to identify and export specific messages.

   # Create compliance search
   New-ComplianceSearch -Name "CASE-2024-11-16-001-Search" `
     -ExchangeLocation "affected.user@example.org" `
     -ContentMatchQuery "received:2024-11-03..2024-11-16"

   # Start the search
   Start-ComplianceSearch -Identity "CASE-2024-11-16-001-Search"

   # Export results (via Compliance Center or script)
   New-ComplianceSearchAction -SearchName "CASE-2024-11-16-001-Search" -Export -Format FxStream

4. For individual messages requiring immediate preservation, export as EML (preserves headers) rather than MSG (Microsoft proprietary).

5. Calculate hashes of exported email archives and record in chain of custody.

Collecting mobile device evidence

Mobile devices require specialised handling due to their connectivity, encryption, and the ease with which evidence can be remotely wiped.

1. Immediately isolate the device from networks to prevent remote wipe commands and evidence modification. Place the device in aeroplane mode, then disable Wi-Fi and Bluetooth. For high-security situations, use a Faraday bag.

2. Do not power off the device if it is unlocked. A locked device may require passcode or biometric authentication you cannot provide, losing access to evidence. Keep unlocked devices powered with screen timeout disabled.

3. Document the device state including screen contents, visible notifications, and running applications. Photograph the screen before any interaction.

4. For devices managed by MDM, collect MDM logs showing device activity, installed applications, and compliance state before any forensic acquisition.

5. Mobile forensic acquisition requires specialised tools (Cellebrite UFED, GrayKey, Magnet AXIOM, or open source tools like MVT). The acquisition approach depends on device type, OS version, and security state:

   Device State	Acquisition Type	Evidence Obtained
   Unlocked, unencrypted	Full filesystem	Complete device data
   Unlocked, encrypted	Full filesystem (after first unlock)	Complete device data
   Locked, passcode known	Full filesystem	Complete device data
   Locked, passcode unknown	Logical or backup	Limited to accessible data
   Locked, strong encryption	May be impossible	Depends on tool capability

6. If full forensic acquisition is not possible, extract available data through device backup mechanisms (iTunes backup, Android backup) which may not require the device passcode.

7. Document the device in chain of custody with make, model, serial number, IMEI/MEID, and operating system version.

Maintaining chain of custody

Chain of custody establishes an unbroken record of who possessed evidence, when, and what actions they performed. A broken chain renders evidence inadmissible in legal proceedings and undermines the credibility of investigation findings.

Every transfer of evidence custody requires documentation:

+------------------------------------------------+
|           CHAIN OF CUSTODY FLOW                |
+------------------------------------------------+
|                                                |
|        ACQUISITION                             |
|        +-----------------------+               |
|        | Acquired by: J. Smith |               |
|        | Date: 2024-11-16      |               |
|        | Time: 09:47 UTC       |               |
|        | Action: Memory dump   |               |
|        | Hash: 8a7f3b2c...     |               |
|        +-----------+-----------+               |
|                    |                           |
|                    v                           |
|        TRANSFER TO STORAGE                     |
|        +-----------------------+               |
|        | Released by: J. Smith |               |
|        | Received by: Evidence |               |
|        |   Storage (M. Jones)  |               |
|        | Date: 2024-11-16      |               |
|        | Time: 14:30 UTC       |               |
|        | Condition: Sealed bag |               |
|        +-----------+-----------+               |
|                    |                           |
|                    v                           |
|        ANALYSIS                                |
|        +-----------------------+               |
|        | Released by: M. Jones |               |
|        | Received by: Forensic |               |
|        |   Analyst (K. Brown)  |               |
|        | Date: 2024-11-18      |               |
|        | Time: 09:00 UTC       |               |
|        | Hash verified: Yes    |               |
|        +-----------+-----------+               |
|                    |                           |
|                    v                           |
|        RETURN TO STORAGE                       |
|        +-----------------------+               |
|        | Released by: K. Brown |               |
|        | Received by: Evidence |               |
|        |   Storage (M. Jones)  |               |
|        | Date: 2024-11-20      |               |
|        | Time: 17:00 UTC       |               |
|        | Condition: Unchanged  |               |
|        +-----------------------+               |
|                                                |
+------------------------------------------------+

Figure 4: Chain of custody documentation for a single evidence item

Each evidence item requires its own custody record. For digital evidence, record hash values at each custody transfer and verify they match. A hash mismatch indicates evidence modification and compromises its integrity.

Physical evidence (hard drives, mobile devices, printed documents) requires tamper-evident packaging. Document the seal number and verify the seal is intact at each transfer. Photograph seals when applying and when breaking.

Securing evidence storage

Store evidence in a dedicated location with access controls that limit access to authorised personnel and maintain an access log.

1. Store digital evidence on encrypted storage. Use full-disk encryption on evidence storage drives. For cloud evidence storage, use platform-provided encryption with customer-managed keys.

   # Example: Create encrypted evidence volume
   cryptsetup luksFormat /dev/sdc
   cryptsetup open /dev/sdc evidence-volume
   mkfs.ext4 /dev/mapper/evidence-volume
   mount /dev/mapper/evidence-volume /mnt/evidence

2. Implement access controls that restrict evidence access to case-assigned personnel. Log all access attempts.

3. Maintain working copies separate from evidence originals. Analysts work with copies; originals remain sealed in storage.

4. Store evidence for the required retention period. Criminal investigations may require indefinite retention. Civil litigation typically requires retention until case resolution plus appeal periods. Internal investigations require retention per organisational policy, typically 7 years.

5. When retention period expires, destroy evidence securely and document destruction in the case file.

Handing over evidence to external parties

When transferring evidence to law enforcement, external forensics providers, or legal counsel, document the transfer and obtain acknowledgment.

1. Prepare an evidence inventory listing all items being transferred with identifying information, hash values, and chain of custody summary.

2. Obtain a written receipt from the receiving party that itemises all evidence received.

3. If transferring physical media, photograph the transfer including the evidence packaging and receiving party.

4. Provide hash values to the receiving party and request they verify upon receipt.

5. Retain copies of all evidence transferred externally unless legal requirements prohibit it.

6. Update the case chain of custody log to reflect the transfer and close organisational custody.

Verification

After completing evidence collection, verify the following:

• All evidence items have SHA-256 hashes calculated and recorded
• Chain of custody documentation exists for every evidence item
• Each custody transfer has release and receipt signatures or digital acknowledgment
• Hash values verified at each custody transfer match original acquisition hashes
• Evidence storage location is encrypted and access-controlled
• Case folder contains complete documentation: case log, evidence inventory, chain of custody forms, acquisition notes
• Digital evidence has been copied to working copies; originals remain sealed

Run integrity verification on all evidence files:

# Verify all hashes in case folder
cd /evidence/CASE-2024-11-16-001
find . -name "*.sha256" -exec sh -c 'sha256sum -c "$1"' _ {} \;

Expected output shows OK for each verified file:

./memory/server01-mem.lime: OK
./disk/server01-disk.raw: OK
./logs/server01-var-log.tar.gz: OK

Any FAILED result indicates potential evidence integrity compromise. Document the failure and isolate the affected evidence for review.

Troubleshooting

Incident report template

Use this template to document evidence collection activities for the case file. Complete one report per incident.

Incident Evidence Collection Report

Case Information

Case Identifier: [CASE-YYYY-MM-DD-NNN]
Incident Reference: [INC-YYYY-NNNN]
Report Date: [YYYY-MM-DD]
Report Author: [Name, Role]
Authorisation Reference: [AUTH-YYYY-MM-DD-NNN]

Incident Summary

[Brief description of the incident requiring evidence collection: what happened, when discovered, systems affected]

Evidence Collection Scope

[Systems, accounts, time period, and data types in scope for collection]

Evidence Inventory

Collection Methods

[For each evidence type collected, describe the tool, version, and method used]

Chain of Custody Summary

[Current custodian, storage location, and summary of all custody transfers]

Exceptions and Limitations

[Any evidence that could not be collected, reasons, and impact on investigation]

Verification Status

All items hashed: [Yes/No]
All hashes verified: [Yes/No]
Chain of custody complete: [Yes/No]
Evidence secured: [Yes/No]

Attachments

• Detailed chain of custody forms
• Acquisition tool output logs
• System photographs
• Evidence storage access log

See also

• Digital Forensics -forensic analysis methodology and techniques
• Incident Response Framework -overall incident response approach
• Ransomware Response -evidence needs for ransomware incidents
• Data Breach Response -evidence requirements for breach notification
• Incident Triage Matrix -incident classification and routing