Cold Boot Attacks

Cold Boot AttacksOver the last few months I have seen a few channels talking about Cold Boot Attacks being the hard to counter boogyman of the Priv / Sec world. Cold boot attacks are a class of physical side channel exploits that enable an attacker to recover cryptographic keys or other sensitive data stored in a computer’s Random Access Memory (RAM) after the system has been powered off or at least reset. The attack relies on the data remanence property of Dynamic Random Access Memory (DRAM) and Static Random Access Memory (SRAM) to retrieve memory contents that remain readable in the seconds to minutes following a power switch off. The attack vector gained notoriety in 2009 when researchers demonstrated how to pull a full copy of a Windows machine’s memory from a laptop, decrypting encrypted drives and exposing user secrets. Although newer hardware and software mitigation have reduced their effectiveness, cold boot attacks remain a real threat for highly valuable targets (military, finance, corporate RnD) that may be physically compromised. This article explains the mechanics of cold boot attacks, highlights why they are still relevant, and provides concrete steps to protect against them from hardware hardening to operational best practices.What Is A Cold Boot Attack?A cold boot attack exploits the fact that DRAM retains data for a short period of time after power loss if it is “cooled”. When RAM modules are chilled ypically with compressed air or liquid nitrogen the electrical charges in each capacitor decay more slowly, allowing attackers to read out the contents long enough to capture useful information. The typical attack flow is as follows...

Boot the target machine.

Trigger a reboot or power cycle.

Immediately remove the RAM modules (or stop the system’s power supply entirely).

Cool the memory with a cold source to slow charge decay.

Use an imaging tool (WinPMEM, FTK Imager) to read the RAM contents before they dissipate.

Analyze the dump for information such as encryption keys, passwords, or plain text data.

Cold boot attacks work by expoiting the physical properties of DRAM and SRAM, each DRAM cell stores a single bit in an electric capacitor. Without periodic refresh, the charge leaks away, causing data loss. Refresh cycles happen every ~64 ms on modern CPUs. When power is removed, the capacitors begin to discharge immediately. Cooling reduces leakage rate, experiments show that at -80C DRAM can hold usable data for minutes.While effective cold boot attacks have limitations that can mainly be exploited by a well funded or prepared attacker (AKA FEDS) limitations include...

Decay time, even with cooling, usable data typically lasts 5-30 seconds depending on temperature.

Data volume, only a snapshot of RAM is captured, large data spread across many pages may not be fully recovered.

Physical access, requires close proximity and a quick response.

Mitigation StrategiesPhysical Hardening

Lock the case / chassis - Stops an attacker from opening the machine.

Disable boot from external media (BIOS/UEFI) or limit UUID access - Prevents attackers from loading a custom OS to capture memory.

Enable “Secure Boot” and “Trusted Platform Module (TPM)” - Ensures only signed firmware runs, prevents tampering.

Physical sensors / alarms - Detect tampering or unauthorized opening.

Use of Faraday cages - Blocks radio frequency attacks that might influence memory refresh timing (TEMPTEST).

Software And Operational Controls

LUKS, store LUKS header keys in TPM or use a keyfile stored on removable media that is deleted after boot.

Never store long term data in RAM. Use hardware wallets, Hardware Security Modules (HSM), or secure enclaves.

Use “key derivation” and “salt” to protect passwords before storing them in memory.

Minimize the lifetime of sensitive data in RAM. Immediately zero out buffers after use (`SecureZeroMemory`, `explicit_bzero`).

BIOS / UEFI settings, enable Full Memory Scrub or RAM Clearing on Boot. Some firmware offers “Cold Reset” that zeroes RAM.

Avoid caching passwords in application memory. Prefer token based authentication (OAuth, Kerberos tickets) that expire quickly.

Use memory protected buffers and secure coding practices to prevent accidental leaks.

TailsSome operating systems such as Tails provide a feature that securely writes random data to system memory when the operating system is shut down to mitigate against a cold boot attack. However, video memory erasure is still not possible it is still an open ticket on the Tails forum. Potential attacks which could exploit this flaw are...

Generation of a GnuPG keypair and viewing the private key on a text editor could lead to the key being recovered.

A cryptocurrency seed could be seen, therefore bypassing the wallet (even if encrypted) allowing access to the funds.

Typing a password with visibility enabled might show parts of it or even the whole key. If a key file is used, it could be shown to reduce time needed for a password attack.

Traces of mounted or opened encrypted volumes with plausible deniability might be shown, leading to the discovery of them.

If connected to a .onion service, the URL might be shown and lead to its discovery, whereas otherwise would be extremely difficult.

Usage of a particular program could show user's patterns.

SDMEMSDMEM, secure memory wiper (secure deletion toolkit), sdmem is designed to delete data which may lie still in your memory (RAM) in a secure manner which can not be recovered by thieves, law enforcement or other threats. Note that with the new SDRAMs, data will not wither away but will be kept static, it is easy to extract the necessary information! The wipe algorythm is based on the paper Secure Deletion of Data from Magnetic and Solid State Memory presented at the 6th Usenix Security Symposium by Peter Gutmann, one of the leading civilian cryptographers. The secure data deletion process of sdmem goes like this...

1 pass with 0x00

5 random passes. /dev/urandom is used for a secure RNG if available.

27 passes with special values defined by Peter Gutmann.

5 random passes. /dev/urandom is used for a secure RNG if available.

Bleachbit

While a tad out of fashion I still recommend using Bleachbit BleachBit deletes unnecessary files to free valuable disk space, maintain privacy, and remove junk. Rid your system of old clutter including cache, temporary files, cookies, and broken shortcuts. It wipes clean Bash, Beagle, Epiphany, Firefox, Flash, Java, KDE, OpenOffice.org, Opera, RealPlayer, rpmbuild, VIM, XChat, and more. I recommend using this in combination of sdmem by using them as a cronjob and / or systemd shutdown module.crontab -e @reboot env DISPLAY=:0 bleachbit --clean all @reboot env DISPLAY=:0 sdmem Now on reboot your systemd will run bleachbit to wipe all temp files and extra data not saved externally, then run sdmem to forcibly clear all memory#!/usr/bin/env bash # clean.sh set -euo pipefail # exit on error, undefined var, or pipe failure IFS=$'\n\t' # safe word splitting echo "Running BleachBit" sudo bleachbit --clean all # cleans everything BleachBit knows how to clean echo "" echo "Running SDMEM" sudo sdmem echo "" echo "Cleanup finished." Save the script. Make it executable (chmod +x ~/clean.sh). And make a exit script (make it executable chmod +x clean_service_stop.sh)$ cat clean_service_stop.sh #!/bin/bash echo "Clean.sh exiting..." Make a systemd module[Unit] Description=Clean Service [Service] ExecStart=/home/alice/work/clean.sh ExecStop=/home/alice/work/clean_service_stop.sh [Install] WantedBy=multi-user.target The ExecStart option in the Service section of the unit file specifies the path of the script that systemd runs as a service. The ExecStop option in the Service section, on the other hand, specifies the path of the script that systemd runs while stopping the service. You can start the service by following...$ cd /etc/systemd/system $ sudo ln -s /home/alice/work/clean_service.service $ sudo systemctl enable clean_service Created symlink /etc/systemd/system/multi-user.target.wants/simple_service.service → /home/alice/work/clean_service.service. $ sudo systemctl start clean_service Now on shutdown systemd will run the same format as the cronjob above. Using this in combonation with an encrypted USB to save all files, a removable disk to hold your operating system files, and now with a secure disk / memory wipe. You data is now secure from cold boot attacks.SmartphonesThe cold boot attack can be adapted and carried out in a similar manner on Android smartphones. A cold boot can be performed by disconnecting the phone's battery to force a hard reset or holding down the power button. The smartphone is then flashed with an operating system image that can perform a memory dump. Typically, the smartphone is connected to an attacker's machine using a USB port. Typically, Android smartphones securely erase encryption keys from random access memory when the phone is locked. This reduces the risk of an attacker being able to retrieve the keys from memory, even if they succeeded in executing a cold boot attack against the phone.The FutureIntel TME / AMD SME, Full memory encryption is increasingly available in consumer laptops. Once enabled, DRAM contents are automatically encrypted, making cold boot extraction impossible. AMD SEV‑ES Extends Secure Encrypted Virtualization to protect guest VMs from a compromised hypervisor, useful for cloud providers. TPM 2.0 and FIPS 140‑2 HSMs Offer stronger key protection and auditability. Quantum Safe Algorithms While not directly mitigating cold boot attacks, they reduce the risk that stolen keys become immediately exploitable.ConclusionCold boot attacks demonstrate that physical access can subvert even well configured software defenses. The attack hinges on the predictable physics of DRAM and a willingness to manipulate hardware conditions. While newer CPUs now encrypt memory or keep keys in secure enclaves, many legacy systems remain vulnerable. By combining physical hardening, hardware level encryption, and robust key management practices, organizations can effectively neutralize this threat vector. For the highest assurance, treat any device that may store sensitive data as a “high risk asset” and enforce a strict Zero Trust security model. Never trust the host OS or its memory contents without hardware verification.