An intruder is logged in on an unlocked, encrypted laptop with a container mounted, and a non-forensic technician is standing at it - what do you tell them?
answer
- two different encryptions on one laptop
- one key is escrowed, one is not
- lid, lock and logoff are all changes
- the plaintext lives at the mount point
- not an examiner at the keyboard
basics
~20 sChange nothing about power or session state: no lid, no lock, no logoff, no reboot. The mounted container's plaintext exists only while the machine stays as it is, so capture from external media first and log every step.
solid answer
~50 sFreeze the situation without freezing the machine. Say the do-not list first: do not close the lid, lock the screen, log off, reboot or shut down, and do not browse around in the session. Suspend and hibernate can dismount the container and re-protect keys, and hibernation writes memory onto the disk you still want to acquire. Then give a short ordered script a non-specialist can execute: photograph the screen, note the wall-clock time, attach the prepared external media, run the approved collection from it with output written back to it, and copy the mounted container's contents while they are still reachable through the mount point. The corporate volume key is normally escrowed to a directory or MDM, so that disk will be readable later; the container passphrase is escrowed nowhere, so this copy is the only chance at it.
go deeper
Know the do-not list for a live compromised machine: no lid, no screen lock, no logoff, no reboot, no shutdown, and nothing run from the host's own disk.
Explain why the mounted container is the perishable item — its key is in memory and escrowed nowhere — while the corporate encrypted volume usually has a recovery key retrievable afterwards.
Show you can direct a non-specialist under pressure: a short ordered script, prepared external media, output kept off the host, notes taken as it happens, and an explicit call on the network link.
Own whether a globally scattered fleet gets a pre-staged live-response capability at all, and state plainly what evidence loss the organisation accepts on the machines that do not get one.
## Two encryptions, two very different fates The laptop is protected twice over, and the two protections behave completely differently when the power goes. The **corporate full-disk encryption** is managed. Enterprise deployments escrow a recovery key — BitLocker to Active Directory or Entra ID, FileVault to an MDM. When the machine is powered off, the image is ciphertext, but the organisation holds the key and can unlock it later. Losing that volume's live state is unpleasant, not fatal. The **container the intruder mounted** is not managed by anybody. Its key was derived from a passphrase you do not have, it exists only in memory while the container is mounted, and nothing escrowed it anywhere. The moment power ends, that data is gone in every practical sense — you can produce a flawless image of the disk and still never read the file the whole investigation is about. This is the failure this scenario exists to teach: a perfect acquisition of a machine whose most important evidence died because somebody did the tidy, responsible-looking thing and shut it down. ## The technician's instincts are all wrong here, and that is not their fault An engineer standing at a machine with an intruder on it wants to do three things immediately: lock the screen, disconnect it, and shut it down. Each of those is reasonable in ordinary IT work and each is damaging here. So the instruction has to *lead with the prohibition*, plainly and before anything else, because it is competing with a strong instinct and with adrenaline. - **Do not close the lid.** It suspends or hibernates. Suspend can dismount the container and cause keys to be re-protected; hibernation writes memory onto the volume you intend to acquire untouched. - **Do not lock the screen or log off.** A logoff tears down the session and can dismount user-mounted volumes with it. - **Do not reboot or shut down.** Both end memory, and a clean shutdown runs code you do not control. - **Do not explore.** Opening the container in a file browser to 'see what is in there' updates metadata, can be visible to whoever is on the other end, and answers a question the capture will answer properly in ten minutes. - **Do not run anything from the local disk.** Everything comes from prepared external media, and output goes back to that media. ## The instruction set has to fit the person holding the keyboard The person at the machine is a desk-side technician on a phone bridge, not an examiner. That constrains the plan more than the technology does. Give them a short numbered sequence with unambiguous actions and one decision point at most; say what each step is for in a single clause so they can recover if reality does not match; stay on the line while they do it; and tell them to say out loud what they are doing so it can be recorded as it happens. A workable sequence looks like: photograph the screen exactly as found — it is free, it is fast, and it captures the mounted drive letter, the visible filenames and the session state before anyone touches anything. Note the time from a source you trust, not the laptop's clock. Attach the prepared media. Run the approved memory collection from it, output to it. Then copy the mounted container's contents through its mount point, because that plaintext exists only while it is mounted. Then stop and report, and let the power-state decision be made deliberately rather than by whoever is nearest the cable. ## The network question is a genuine trade, not a reflex The technician will ask whether they should pull the network. It ends the intruder's interactive session and any transfer under way, and it also tells them they have been seen, may trigger tooling that reacts to lost connectivity, and ends your ability to watch. If data is visibly leaving right now, take the tip-off and cut the link. If it is not, keeping it up until the capture completes usually buys more than it costs. Either way it is a decision someone makes on purpose, and it goes in the log with a time. ## The failure mode, stated plainly The way this goes wrong is not dramatic. Nobody deletes anything. Somebody helpful powers the laptop off to 'secure it', the volume key and the container key die with memory, and the case ends up with a beautifully hashed image, a complete disk, and an encrypted blob nobody will ever open — with the contents of that blob being precisely the collected files the whole investigation was about. Every prohibition in the list above exists to prevent that one outcome.
- The technician asks whether to unplug the network to stop the transfer. What do you say?It is a trade, not a reflex. Cutting the link ends the intruder's session and any transfer in progress, but it tells them they have been detected, can trigger tooling that reacts to lost connectivity, and ends your ability to observe. If data is visibly leaving right now, take the tip-off. If it is not, keep the link up until the capture is done, and log the decision with a time.
- Why is the mounted container more urgent than the encrypted disk beneath it?Because the keys are escrowed differently. Corporate full-disk encryption normally escrows a recovery key to a directory or an MDM, so the volume can be unlocked from the image afterwards. A container the user mounted with their own passphrase escrows nothing, so its key dies with memory and the image holds ciphertext nobody can open.
- What do you have the technician record while they work?The wall-clock time of every action from a trusted clock, what they ran and from which media, the account used, what was on the screen, and anything they touched by mistake. A photograph of the screen before anyone types costs nothing and captures the mounted volume, the session and visible filenames. 'I clicked the wrong folder at 02:44' is worth far more than a tidy reconstruction later.
- Is there any argument for doing nothing at all until a specialist arrives?Only if one can arrive while the machine is still in this state and nothing forces a change in the meantime. Battery level, power management, an enforced lock policy and the intruder's own actions all work against you, so 'wait' is a decision with a countdown attached. Usually the right call is a small, scripted capture now rather than a perfect one that never happens.
saying these in an interview costs you the question
- Tells the technician to lock the screen first
- Shuts the machine down before any capture
- Assumes the disk image will contain the container's plaintext
- Browses the mounted container to see what is inside
- Gives a non-specialist a long improvised list with no order
- Runs collection tools from the host's own disk