Executing a Cold‑Boot Attack on LUKS‑Encrypted Linux Systems

Background

Researchers at GDS examined the feasibility of a cold‑boot attack against Linux systems that use full‑disk encryption with LUKS. While the attack is theoretically possible, they investigated how difficult it is to carry out in practice.

Target System and Attack Surface

Linux systems with full‑disk encryption keep a small unencrypted boot partition (mounted at /boot) that contains the kernel and the initial RAM disk (initrd). The initrd is a temporary filesystem loaded before the real root filesystem is mounted; it holds the minimal set of binaries and scripts needed to decrypt and mount the encrypted root.

Debian‑based initrds are gzip‑compressed cpio archives executed by an ash shell, whereas Red Hat‑based distributions (Fedora, RHEL, CentOS) use dracut with an uncompressed cpio image and systemd‑based startup.

Attack Method

The team created a tool named EvilAbigail that leverages an LD_PRELOAD‑based bootkit. The idea is to inject a shared object into the first executable run after decryption (usually /sbin/init, PID 1). By modifying the init script inside the initrd to copy the malicious .so file and export LD_PRELOAD, the shared object is loaded when the pivot_root occurs.

cp /hack.so ${rootmnt}/hack.so
export LD_PRELOAD=/hack.so

Because the real root filesystem is mounted under the temporary initrd filesystem, the rootmnt variable points to the correct mount point. The script also remounts the target filesystem as read‑write before copying the payload.

Three Technical Challenges

Copying the payload into the decrypted root filesystem – solved by adding two ExecPre directives to the systemd service that performs the pivot, which remounts the filesystem read‑write and copies the .so file.

Injecting LD_PRELOAD without a shell script – addressed by moving the original init binary, placing a wrapper script that sets LD_PRELOAD, and then invoking the original binary. This injects the shared object into the initrd’s PID 1 process.

Bypassing clearenv() called by systemd before switch‑root – achieved by overriding the standard clearenv() function in a custom shared library, which first clears the environment and then re‑adds the LD_PRELOAD variable, ensuring the payload remains loaded.

Password Extraction

After the three challenges are resolved, the malicious shared object can hook the crypt_activate_by_passphrase function used by systemd to decrypt the disk. By using dlsym to call the original function and capturing the password argument, the attacker stores the password in the shared object itself.

The stored password is later read from the end of the shared object file (located via the LD_PRELOAD path) and placed into an environment variable named PASSWORD. A reverse shell (e.g., a Python‑based Meterpreter) can then retrieve it with getenv PASSWORD.

Mitigations

Several defensive measures are discussed:

Move the bootloader, kernel, and initrd to an external USB drive and boot from it, though this is inconvenient for users.

Disable booting from external media entirely, which blocks automated attacks but may still be bypassed by manually mounting and modifying the initrd.

Enable a BIOS/UEFI boot password to prevent unauthorized boot attempts.

Extend Secure Boot to verify the initrd signature; however, if an attacker can flash the BIOS/UEFI to disable Secure Boot, this protection fails.

Ultimately, the most reliable protection is to keep the device out of attackers’ physical possession, as the PoC demonstrated that the attack can compromise a target within two minutes, and more sophisticated payloads could succeed in seconds.