Evidence Collection and Preservation

Once the scoping call is done and the written engagement is signed, Phase 2 is where the forensic work actually begins. The goal is simple. Get a forensically sound copy of every piece of evidence in scope before anything happens that could change it, and document that collection in a way another examiner could reproduce. The copies are what we analyze. The originals stay untouched, under lock, with every handoff recorded on a chain-of-custody form.

This sounds procedural because it is. Preservation is where forensic work looks the least exciting and matters the most. The conclusions you read in a Phase 4 report are only as strong as the preservation work in Phase 2. A thousand-dollar workstation can generate ten thousand dollars of useful evidence if preserved correctly, or zero dollars of useful evidence if the IT team rebooted it first. Our Phase 2 procedures align with ISO/IEC 27037 (identification, collection, acquisition, and preservation of digital evidence) and with NIST SP 800-86 (integrating forensic techniques into incident response).

Our approach borrows heavily from the practice of keeping everything simple, reproducible, and documented. Open-source tools. Command-line invocations captured in writing. Hash verifications recorded twice: at collection and again before analysis. Chain-of-custody forms that any forensic examiner would recognize. There is nothing proprietary about this. That is the point. Proprietary processes are harder to defend in front of a skeptical expert on the other side.

1. CPU registers, cache, and process state. Seconds of lifespan. Usually accessible only through memory acquisition at the moment the system is still running.
2. Routing tables, ARP cache, process tables, kernel statistics. Captured through live-response commands before the host is disconnected.
3. Physical memory (RAM). Captured before shutdown or reboot. Contains running processes, injected code, network connections, decryption keys, credential caches, and clipboard contents.
4. Temporary file systems. Collected through live acquisition because a reboot flushes most temp locations.
5. Disk. Hard drives and SSDs imaged with write-blocking after volatile data is captured. Stable on the timescale of hours to days as long as the system is untouched.
6. Remote logging and monitoring data. Cloud SIEM, firewall syslog, EDR cloud telemetry. Stable on the timescale of the retention policy.
7. Physical configuration and network topology. Documented from switch and firewall configs, network diagrams, and asset management systems.
8. Archival media. Backups, optical media, offline storage. Stable on the timescale of months to years.

A single Phase 2 often skips several of these categories because they are not relevant to the specific incident. What matters is that we think about them in order and do not skip a volatile category because we forgot.

Disk Imaging

Our default is ewfacquire from the libewf project, producing Expert Witness (E01) format with embedded hash and metadata. For evidence that needs format-neutral preservation we use dd or dc3dd to produce raw sector-for-sector images. Both are paired with a hardware write-blocker so the source drive cannot be modified during acquisition. The Tableau and WiebeTech lines are our field workhorses.

SSD and NVMe Considerations

Solid-state drives introduce complications a spinning-disk process does not face. TRIM commands can silently erase deleted data before acquisition. Wear leveling scrambles the physical-to-logical mapping. Encrypted self-encrypting drives (SEDs) require the disk password before meaningful imaging. Our Phase 2 checklist flags these conditions, captures them in the acquisition notes, and adapts the approach where possible (disconnecting power to prevent TRIM completion, chipping the drive to bypass controller-level encryption when authorized, or acquiring a logical image plus memory in cases where physical acquisition is not viable).

Memory Acquisition

For Windows hosts we default to winpmem, the open-source memory acquisition tool from the Rekall / Volatility community. For Linux we use lime loaded as a kernel module. For macOS we use OSXPmem, acknowledging that modern SIP and pointer authentication on Apple Silicon have meaningful impact on what memory acquisition can capture. Memory images are compressed, hashed, and stored in the same chain-of-custody workflow as disk images.

Network and Cloud

For live packet capture we use tcpdump or tshark with rotation-to-file and SHA-256 manifest. For cloud artifact acquisition we use vendor-native export APIs rather than screen scraping: Graph API for M365, Azure AD PowerShell for sign-in and OAuth grant logs, the eDiscovery Premium content search for mailbox and OneDrive preservation, and Google Workspace Admin SDK for Workspace cases. Every API call is logged with timestamp and parameter for reproducibility.

Every image we acquire gets two cryptographic hashes computed at the source and again on the resulting file. MD5 stays in the workflow for legacy interoperability because many case-management systems, expert-witness reports, and court filings already accept MD5 as the standard. SHA-256 is the modern reference that gives us collision resistance MD5 no longer provides. When a skeptical opposing expert challenges our evidence integrity, we can show both.

The hashes get recorded in the chain-of-custody form, in the acquisition log, in the image file where the format allows (E01 embeds hashes natively), and in the final report appendix. They are regenerated before analysis begins to confirm the file has not been modified in transit or in storage. Any hash mismatch stops the investigation and triggers a fresh acquisition from the original evidence.

A common question is whether SSDs even allow reproducible hashing since TRIM and wear leveling can change the underlying physical state between two reads. Our answer is that we are hashing the logical acquisition, not the physical drive, and the logical image produced at acquisition is reproducible and verifiable. Where SSD integrity is specifically at issue, we document the acquisition conditions carefully in the methodology section.

Chain of custody is a paper trail that lets anyone reading the file reconstruct where a piece of evidence was, who had access to it, and what was done with it, from the moment it entered forensic control until the moment it left. A good chain-of-custody record is boring. That is the goal. The more boring the record, the less room there is for an opposing expert to raise doubt about whether the evidence was tampered with, contaminated, or substituted.

Every piece of evidence gets its own chain-of-custody form. The form records: a unique evidence identifier, the source (device, user, mailbox, account), the date and time of acquisition, the acquiring examiner, the method of acquisition (tool and command), the cryptographic hashes at acquisition, the storage location, and every subsequent movement or access with timestamp and examiner name. Forms are kept on paper and in an encrypted digital case-management system with the paper originals locked away.

Handoffs between examiners are initialed on the form. Handoffs to third parties (a second examiner for peer review, counsel for inspection, law enforcement for seizure) are captured in full with a receipt signed by the receiving party. Evidence return or certified destruction at case close is documented the same way with a signed disposition record.

The fastest way to improve a forensic engagement is to stop the most common Phase 2 mistakes from happening in the first place. These are the patterns we see repeatedly across North Carolina SMBs during active incidents.

• Rebooting the infected workstation. Kills volatile memory, including running malware processes, injected code, and sometimes in-memory decryption keys. The single most damaging action a well-meaning IT team takes.
• Restoring a server from backup before imaging. Rolling back a ransomware-affected VM to a clean snapshot before forensics destroys our ability to establish initial access and lateral movement. The symptom goes away, the root cause stays.
• Letting EDR auto-remediate. Endpoint detection platforms often quarantine the attacker's binaries, delete persistence mechanisms, and clean registry artifacts automatically. Disable auto-remediation on affected hosts until forensic collection completes.
• Changing passwords without exporting session state first. For cloud accounts, a password change can invalidate persistent refresh tokens, revoke OAuth grants, and silently rotate session identifiers that would have shown attacker activity. Export audit and session evidence first, rotate credentials second.
• Ignoring cloud audit log retention clocks. M365 Unified Audit Log is 90 days by default. By the time a BEC is identified four weeks in, you have two months of runway to preserve the earlier-compromise evidence. Move fast.
• Imaging over a prior image. Naming collisions in acquisition workstations can result in overwriting the first image with the second. Use strict evidence-naming conventions and never allow two acquisitions to write to the same destination file.

None of these mistakes are career-ending. We have recovered useful evidence in cases where most of these happened. But every one of them narrows what the investigation can establish, and avoiding them costs nothing.

Once a piece of evidence is acquired, preserved, and hashed, it needs a place to live where it stays intact and confidential through the life of the case and any legal or regulatory hold period afterward. Our default storage approach is intentionally simple: encrypted storage on hardware we own, in a physically controlled space we control, with logical access limited to the examiners working the specific case.

Physical Storage

Primary evidence copies sit on encrypted direct-attached storage inside our forensic workstations, which themselves live in a locked workspace with recorded entry. Working copies for analysis are thawed from the primary evidence on demand and cannot be modified (the primary is treated as read-only). Backups of evidence are maintained on separately encrypted media in a second physical location to protect against single-point-of-failure loss.

Logical Access

Access to a case's evidence directory is limited by case assignment. An examiner who is not on the case does not see the files. Access attempts are logged. Every opening, copying, mounting, or export action on an evidence file is recorded and associated with the examiner and case. This gives us a digital counterpart to the paper chain-of-custody form and means we can produce an access log on request.

Retention And Destruction

Evidence retention follows the engagement letter. Default is to retain for the duration of the matter plus one year, after which we destroy on written client instruction. For cases where regulatory or litigation holds require longer retention, we extend on counsel's written direction. Destruction is performed through cryptographic shredding of encrypted container keys followed by physical media destruction where the media is being retired. We issue a signed certificate of destruction at the end of the process.

Client-Controlled Storage Options

For clients who prefer evidence to reside in their own systems rather than ours, we can acquire directly to client-owned encrypted storage. Chain of custody still runs through us from acquisition to formal hand-off, but after hand-off the client's physical and logical controls take over. This is a common pattern for clients with internal legal departments or strict data residency requirements.

Preservation does not have to mean the affected user cannot work. For almost every engagement, we can pair the forensic acquisition with a same-day stand-up of a replacement device so the user keeps working while the original gets imaged. The original is imaged from a write-blocked connection. The replacement is built from a fresh OS install, a password reset, and a minimal set of restored data from validated backups. We never restore user data directly from the suspect device to the replacement without first validating against a known-clean baseline.

For server infrastructure, live imaging through hypervisor snapshots is usually possible without taking the host offline. VMware, Hyper-V, and Proxmox all support snapshot export to a portable format we can acquire from without touching the live VM disks. For physical servers that cannot be taken down, live memory capture and targeted collection of log files and high-value directories is often enough to preserve the investigation before scheduled downtime for full imaging.

Mailbox preservation is painless on the business side. Cloud tenants support legal-hold placement without user awareness and without disrupting mail flow. Retention policies can be paused in place. Unified Audit Log exports run through Graph API without any user-facing impact.