When would you pull the power on a compromised host instead of shutting it down cleanly?

## The question only exists after the live decision A hard power cut and a clean shutdown both end memory. Neither preserves keys, processes or network state. So this is not a choice about volatile evidence — it is a choice about the *stored* state and about what code gets to run before the machine stops. If there is anything you wanted from the running system, it must already be collected before either option is on the table. ## What a graceful shutdown actually does 'Shut down cleanly' means asking the operating system to run its shutdown path. That path is code: - logoff and shutdown scripts configured on the machine or pushed by policy - service and application stop handlers, which flush caches and write final state - temporary-file cleanup, log rotation, and on some configurations clearing of the page file - unmounting of mounted volumes and containers, which discards their keys - scheduled tasks that fire on shutdown On a healthy machine all of that is desirable. On a machine you believe an adversary still controls, it is an execution opportunity handed over on request. Destructive tooling that reacts to shutdown is not exotic, and even without it, the ordinary cleanup path deletes things you might have wanted. A clean shutdown is the machine's chance to tidy itself up, and tidying up is the opposite of what you want. ## What a power cut actually costs Cutting power freezes the storage device exactly as it was at that instant, at the price of an unclean volume: - NTFS replays its `$LogFile` when the volume is next mounted; ext4 and similar filesystems replay their journals - writes in flight are lost, and a file being written may be truncated or partially written - databases and other stateful services come back in crash recovery, which can take time and can lose recent transactions - caches never flushed simply vanish For a forensic examination this is usually acceptable and bounded: you examine a copy, and journal replay affects the mounting system rather than the copy you took. For the business, on a machine doing real work, it may not be acceptable at all. That is the trade you are being asked to weigh. ## How the answer differs by host On a **laptop or workstation** you believe is compromised, the hard cut is the usual default: little is lost, and you deny the shutdown hook. Note that 'pull the plug' on a laptop means holding the power button until it dies — the battery is generally not removable, and unplugging the charger achieves nothing. On a **server** carrying production data, the calculation shifts. If the service owner can quiesce the workload and the host can be cut off from the network first, a controlled stop may well be the better call. A candidate who answers 'always pull the plug' without naming this exception is reciting rather than reasoning. On a **virtual machine**, the equivalent of a power cut is a hard stop from the hypervisor, and the hypervisor may also be able to snapshot memory and state — a materially better option that exists only in that environment. ## Sleep, hibernate and closing the lid are not a middle path The tempting third option — 'just close the lid and deal with it later' — is the worst choice available, because it is a state change you did not choose: - suspend or hibernate can cause a mounted container to dismount and keys to be re-protected - hibernation writes the contents of memory onto the disk, altering the exact volume you were about to acquire - a machine that resumes may resume with the adversary's session still live Decide the power state deliberately. Never let the lid switch decide it for you. ## What a good answer sounds like 'Both kill memory, so this comes after live collection. On a host I believe is owned I take the hard cut, because a clean shutdown runs shutdown handlers I do not control and cleanup tasks that delete evidence. The cost is a dirty volume and journal replay, which I can live with on an endpoint. On a production database I would want the service owner in the conversation and would consider a controlled stop after isolating the host. And I would rule out sleep and hibernate explicitly, because hibernation writes memory onto the disk I am about to image.'