2. Preservation
Securing the scene and initial preservation
In short: freeze the scene, find out who has been there, and make the power-state decision deliberately.
An office scene is rarely dramatic: a desk, a dock, a laptop, a phone, a drawer of USB sticks, a server room down the corridor. It is still a scene. It is at its most fragile in the first hour, when colleagues are curious and the user may still have access.
First actions at a workstation
- Stop. Do not touch the keyboard, mouse, screen, cables or power. Do not sit at the desk.
- Look and record. Power state, what is on screen, whether someone is logged in, link lights on network ports, any activity (disk light, fan noise, a progress bar).
- Photograph everything before anything moves (section 3).
- Decide power state and isolation method (below, and section 4). These two choices shape everything else, so make them on purpose and write down why.
- Only then acquire, in the order set out in sections 6 to 8.
Control physical access
- Draw the boundary and say it out loud: this desk, this office, this rack. Kit at a home address is a separate scene with its own authority.
- Put one named person in charge. Everyone else asks them before entering or touching anything.
- Lock the room or cordon it off. If you cannot, keep someone physically present until every device is collected.
Shut the side doors
- Suspend accounts, badge and remote access at the same moment the scene is secured. Too early tips the user off; too late gives them time to act. Agree this with HR and legal beforehand.
- No tidying up. Colleagues do not collect their belongings from the area until it is documented.
- Assume the machine can be reached remotely until you have isolated it (section 4).
Who has already touched it?
Someone nearly always has: the manager who found it, the IT engineer who "just checked something", the colleague who closed the lid. Ask, in this order, and record names and times:
- Who has been at the desk since the matter was raised, and what did they do? Ask specifically about logging in, moving the mouse, closing windows, plugging or unplugging anything, and shutting down or restarting.
- Has anyone connected remotely, including automated tools such as endpoint management, antivirus scans or backup agents?
- Has it been powered off or restarted since? By whom, and how?
Why bother
These answers are observed facts, not accusations. They explain artefacts you will find later (a logon at 09:14 by the IT engineer's account), and they are far easier to get on the day than months later.
Keep an entry and exit log
From the moment the scene is secured, log everyone who comes and goes: name, role, time in, time out, reason. Keep it on paper or on a device that is not part of the evidence.
The power-state decision
On or off is the single most consequential fact at the scene. It decides what evidence still exists and what your first acquisition must be.
| You find it | Do this | Because |
| Powered off | Leave it off. | Booting writes to disk, runs scheduled tasks, starts sync clients and may burn an encryption boot counter. There is nothing volatile to gain. |
| On and unlocked | Keep it on. Capture memory first (section 7). | Memory holds processes, connections, sessions, unsaved work, memory-only malware and the keys to any unlocked encrypted volume. |
| On but locked | Keep it on, isolate it, and pursue credentials through legitimate channels. | The keys are still in memory, but software capture needs an unlocked session. |
Stop and think
On a machine with full-disk encryption, a shutdown can turn a readable disk into one nobody can decrypt without a key you do not have. There is no undo.
Powered off: the one usual exception is a deliberate, authorised decision to boot a forensic copy in a virtual machine later, in the lab. Never the original.
Powered on: once volatile evidence is captured, the shutdown method is itself a decision to record.
- Graceful shutdown writes to disk and may run shutdown scripts.
- Pulling the power avoids those writes but leaves the filesystem mid-flight, which journalling filesystems cope with well.
- Encryption or suspected malware: pulling the power after memory capture is usually preferred.
- A server or an unusual filesystem: get advice first.
Locked screen: do not guess the password. Credentials can come from the user, an administrator account or the recovery sources in section 12; logging in with a lawfully obtained credential is a documented live interaction like any other. Hardware-assisted memory capture exists, but it is specialist work. If there is no route to an unlocked session in reasonable time, capture what you can see, record the decision, then shut down and image, accepting that the volume may not be decryptable later. Sections 13 to 15 give the platform steps.
Example
A workstation is on, screen locked. IT does not hold the BitLocker recovery key. Shutting down now leaves a fully encrypted disk and no key. Leaving it on, isolating it and capturing memory first gives a real chance of pulling the volume key from RAM. The decision, the reasons and the time go in the notes before anything is done.
Before you move on
- Scene boundary set, one person in charge, entry log running.
- Accounts and remote access suspended at the right moment.
- Everyone who touched the machine named, with times.
- Power-state decision made and the reason written down.
3. Documentation
Initial documentation
In short: record the scene exactly as found, because within an hour it will not be.
Documentation starts before acquisition and carries on after it. This first pass is the one you can never repeat.
Photograph, wide to narrow
- Wide shots first, then each device, then details: cables, ports, labels, screens, sticky notes, anything that looks like a password or recovery key.
- Screens before touching: lock screen, error messages, open windows, notifications, and the system clock if visible.
- Every peripheral in place: dock, monitors, external drives, USB devices, card readers, and which port each is in.
- Backs and undersides for serial numbers and asset tags. Add a scale where size matters.
- Check your camera's clock first, make sure it writes the time into the image metadata, and note any offset.
Record each device's condition and state
Before anything is moved, note for every device:
- Identity: make, model, serial, asset tag, any damage or signs the case has been opened.
- Power state: on, off, sleeping, hibernating, locked, unlocked. A dark screen is not the same as off; look for power lights and listen for fans.
- Users: the logged-in user and any other names on a lock or switch-user screen.
- On screen: applications, documents, dialogue boxes, notifications.
- Connections: mains, network cable, dock, external drives, phones, USB devices, and which port each uses.
- Network state: Ethernet link lights, wireless indicators, VPN or remote-access icons, network name if shown.
- Encryption clues: a BitLocker, FileVault or LUKS prompt, pre-boot authentication, a padlock on a drive, a third-party encryption client in the system tray.
Record times and your own actions
- Key times: date, arrival, scene secured, each device collected. Use one time source for the whole scene and say which.
- Clock drift: compare each device's clock with your reference and note the difference. Timeline work later depends on it.
- Contemporaneous notes: what you did, in what order, and why.
- Never rewrite notes. Corrections go in as dated additions.
The standard to aim for
"14:12, disconnected Ethernet cable from port 1 after photographing link state, to prevent remote access; screen remained locked."
Example
A screen shows a file copy at 63 per cent, going to a drive labelled "E:". That one photograph, with the system clock in shot and your reference time in your notes, is an observed fact of the first importance. It also tells you the external drive is being written to right now and must not be yanked out casually.
Before you move on
- Wide, device and detail photographs taken, screens included.
- Every device's identity, state and connections noted.
- Reference clock chosen and every device's offset recorded.
- Notes are timed, in order, and never rewritten.
4. Preservation
Network isolation
In short: a machine that can reach a network can still be changed from outside. Cut it off physically, with the smallest footprint you can manage.
What you are protecting against
- Remote wiping. Endpoint management, mobile device management and some consumer services can wipe a machine on command, and a user who knows an investigation has started may send it.
- Cloud sync. A sync client uploads local changes and pulls remote ones, including deletions made elsewhere.
- Remote access. Remote desktop, support tools and SSH let someone else act on the machine while you stand in front of it.
- Command and control. Malware may take instructions, exfiltrate data or remove itself once it spots an investigation.
- Quiet background writes. Time sync, update agents, backup agents and scheduled jobs all write to the machine and all need the network.
Every live interaction changes something
There is no zero-footprint way to touch a running computer. Unplugging a cable logs a link-down event. Running a tool overwrites memory. So the goal is not "no change", it is the smallest necessary change, understood in advance and written down at the time.
- Unavoidable alteration: a change you can explain in court. "I disconnected the cable; the system logged a link-down event at 14:12; nothing else was altered."
- Contamination: a change you cannot explain, or did not need to make.
Isolation methods, best first
- Pull the Ethernet cable at the workstation end, after photographing the port, cable and link lights. One well-understood event, minimal footprint.
- Use hardware wireless controls. A physical radio switch (photograph its position), or unplug an external wireless adaptor after photographing it. Neither touches the operating system's interface.
- RF isolation where there is an internal wireless adaptor, no hardware switch, and a real risk of remote wiping: a Faraday bag or enclosure, or a shielded workspace.
- Software isolation, last resort only. Aeroplane mode, disabling an adaptor or leaving a wireless network all mean using the interface, which changes state (input events, configuration writes, possibly dismissing a screen saver). Do the minimum and record every click.
Faraday bag gotchas
A device in a Faraday bag may crank up its transmit power and drain its battery faster. Mains power has to come through a filtered feed, or the bag defeats itself. Use it when justified and planned, not as a reflex.
Docking stations: disconnecting the dock's uplink counts as pulling the cable, provided the laptop has no other active adaptor.
Virtual machines: isolate at the hypervisor by disconnecting the virtual network adaptor. The guest's state stays untouched.
Bluetooth and other radios
Bluetooth and near-field radios are rarely a route for remote wiping of a workstation. A mobile broadband adaptor is a different story: it is a network connection like any other, so remove it or shield it.
Example
A laptop sits on a dock with a wired connection and an internal wireless adaptor with no hardware switch. The examiner photographs the dock, disconnects its Ethernet uplink and records the time. Instead of opening network settings, they put the open laptop in a shielded enclosure with a filtered mains feed, record that too, and move on to memory capture. The only alterations are a link-down event and possibly a wireless roaming attempt, both noted.
Before you move on
- Every network path identified: cable, dock, wireless, mobile broadband.
- Each one cut by the most physical method available.
- Every isolation action timed and recorded, with its expected footprint.