First Responder & Digital Search-and-Seizure

The first officer to arrive at a digital crime scene can preserve or destroy the evidence depending on what they do in the first five minutes. This chapter covers the first responder's priorities, how to handle volatile evidence before it disappears, and the correct procedure for seizing and imaging digital devices.

3.1The First Responder's Role

A first responder may be a police officer, an IT security staff member, or a trained forensic examiner. Regardless of background, every responder must follow the same discipline — act carefully, document everything, and touch as little as possible.

What NOT to do:

• Do not switch the device on if it is off. Powering on creates new files, overwrites timestamps, and may trigger auto-run scripts.
• Do not pull the power cord on a running device. An abrupt power cut can corrupt the file system and destroy unsaved volatile data.
• Do not browse files or open applications on the original device. Every read access updates timestamps; every action risks evidence contamination.
• Do not install software on the suspect device for any reason.

What TO do:

• Photograph the screen immediately if the device is on — capture what is visible before it changes.
• Note all physical connections: USB devices, network cables, power adapters, external drives.
• Call in the digital forensics unit before taking any further action.
• Secure the area to prevent others from accessing the device.

Triage decision — on or off?

The single most important question at the scene is whether the device is currently powered on.

• Device is ON: Volatile data (RAM contents, active sessions, encryption keys) exists right now and will vanish the moment power is cut. Proceed immediately to a live memory capture before considering any shutdown.
• Device is OFF: The risk of volatile loss is already gone. It is now safe to image the storage media without powering the device on.

Governing principles:

The ACPO (UK Association of Chief Police Officers) Good Practice Guide and NIST SP 800-101 both rest on four principles:

1. No action taken should change data on digital devices or storage media.
2. When access to original data is necessary, a competent person must do it and explain why.
3. An audit trail of all actions must be created and preserved so an independent third party can repeat the process and reach the same result.
4. The officer in charge of the investigation is responsible for ensuring the law and these principles are followed.

3.2Volatile vs Non-Volatile Evidence

Volatile evidence exists only while the device is powered. The moment power is cut, it is gone forever. Non-volatile evidence survives power loss.

Volatile evidence includes:

• RAM contents — running program data, decrypted file contents, typed-but-unsaved text
• Active network connections — IP addresses of remote hosts currently communicating with the device
• Running processes — the list of programs currently executing
• Clipboard contents — copied text or images not yet pasted
• Encryption keys in memory — if a VeraCrypt volume or BitLocker drive is mounted, the key lives in RAM
• Logged-in user session tokens — authentication cookies, OAuth tokens

Order of volatility (most volatile first, must capture in this order):

1. CPU registers and cache (nanoseconds to microseconds to capture)
2. RAM — main memory (seconds to minutes; captured with memory dumping tools)
3. Virtual memory / swap file / page file (still on disk but may be overwritten)
4. Temporary files (/tmp, %TEMP%)
5. Disk contents — files on HDD or SSD
6. Remote logs — server and network device logs
7. Archived/backup media — tapes, cloud backups

Non-volatile evidence survives power-off: HDD and SSD contents, USB flash drives, optical discs (CD/DVD/Blu-ray), NVRAM, cloud storage, and router logs stored on the device.

Practical implication — live vs dead acquisition:

If you suspect a running device uses full-disk encryption and you power it off, you may lose access to the data entirely — the encryption key was in RAM. In such cases, perform a live RAM acquisition first, then power off and image the disk.

3.3Search & Seizure Procedure

No digital evidence has value in court if it was seized without proper legal authority or documented procedure. Both the legal and procedural steps are equally important.

Legal authority:

• In India, seizure of computers and digital devices is authorised under Section 91/93 CrPC (now mirrored in the BNSS) with a magistrate's order.
• For cybercrime investigations, IT Act Section 69 empowers CERT-In to direct any agency or intermediary to preserve, retain, or produce data.
• The scope of the search warrant matters: a warrant that says "seize computers" may not cover smartphones, IoT devices, or smartwatches. Always read the warrant text before seizing additional devices.

Step-by-step seizure procedure:

1. Photograph the scene. Capture all devices, cables, screen states, and physical layout before touching anything.
2. Label every device and cable. Use numbered evidence tags. Record: make, model, serial number, condition, and location found.
3. Record details on the seizure form. Include device identifier, location, date/time, and the name of the officer seizing it.
4. Handle a running device carefully.
   • Photograph the screen.
   • If live RAM capture is required (encryption suspected), perform it now using a forensic tool (e.g., WinPmem, Magnet RAM Capture).
   • Power off by removing the battery or holding the power button — do not use the OS shutdown command, which may run cleanup scripts, flush caches, or overwrite temporary files.
5. Place devices in anti-static bags. Phones and tablets go into Faraday bags — sealed metallic pouches that block all radio signals and prevent remote-wipe commands from reaching the device over GSM, Wi-Fi, or Bluetooth.
6. Complete the panchnama in the presence of at least two independent witnesses. Witnesses must sign the seizure form.
7. Hash all media before transport. Compute MD5 or SHA-256 of every drive or storage device at the scene. Record hash values on the seizure form. This establishes the baseline against which the forensic copy will later be verified.

3.4Disk Imaging & Hash Verification

Every forensic examination must be performed on a verified copy of the original evidence — never on the original itself. If you work on the original and make a mistake, the evidence is contaminated and potentially inadmissible.

Write blocker:

A write blocker sits between the source disk and the forensic workstation. It allows all read commands through but blocks every write command at the hardware or driver level, ensuring no data on the source disk changes. Hardware write blockers (Tableau, Wiebetech) are preferred over software write blockers because they operate independently of the OS and are harder to bypass accidentally.

Imaging formats:

Hashing procedure:

1. Connect source disk through the write blocker.
2. Compute MD5 or SHA-256 hash of the source disk before imaging. Record this value on the case form.
3. Create the forensic image (using dd, dcfldd, FTK Imager, Guymager, or EnCase).
4. Compute the same hash of the destination image file after imaging completes.
5. Compare the two hash values. They must be identical.

Any single bit difference — even one flipped bit out of billions — produces a completely different hash value. An identical hash is court-admissible proof that the copy is a perfect duplicate of the original.

Common tools:

• dd — Unix command-line; simple but no progress indicator
• dcfldd — enhanced dd with hashing and progress output
• FTK Imager — GUI, Windows; creates E01 with embedded hash
• Guymager — GUI, Linux; fast, multi-threaded, E01/AFF output
• EnCase — commercial; creates E01; widely accepted in court

3.5Recovering Deleted, Hidden & Altered Files

Deleting a file does not destroy the data — it only removes the pointer to that data. Understanding exactly what happens at the file-system level tells us how to recover it.

How deletion works:

• FAT file system: The first byte of the directory entry is overwritten with 0xE5 (the file name is effectively erased from the directory). The clusters holding the file's data are marked as free in the FAT table — but the actual data bytes in those clusters are not zeroed. The data remains until another file is written over those clusters.

• NTFS file system: The Master File Table ($MFT) entry for the file is flagged as "unallocated" but the entry itself remains, often with the file's full metadata (name, timestamps, size). The data clusters are marked free in the $Bitmap but not erased. Recovery is often straightforward using $MFT parsing tools.

File carving:

File carving is a technique that ignores the file system entirely and scans the raw bytes of a disk partition looking for known file signatures (magic bytes). It can recover files even from a formatted partition or a disk whose file system is corrupted.

Common magic byte signatures:

Tools: PhotoRec, Scalpel, Foremost — all scan raw disk images and output recovered files grouped by type.

Hidden files:

• Linux/macOS: files with a dot prefix (.bashrc, .ssh) are hidden from normal directory listings.
• Windows: files with the Hidden attribute set are invisible in Explorer by default.
• Alternate Data Streams (ADS) on NTFS: data hidden in a named stream of an existing file (covered in depth in Chapter 4).
• Steganography: data hidden inside an image, audio, or video file; the container file looks completely normal.
• Encrypted volumes: a VeraCrypt container looks like a file of random bytes with no identifiable header.

Detecting file alteration:

• Hash mismatch: compute the hash of a file at acquisition and again later — any change means the file was altered.
• Timestamp anomalies: a file whose creation time is after its last modification time has had its timestamps manipulated.
• Metadata inconsistencies: EXIF data recording a camera model that does not match the device the suspect claims to have used.

Deletion recovery summary: