Welcome back, aspiring investigators!
Even if you take good care to protect your data, avoid sticking notes with passwords to your monitor, encrypt your hard drive, and always lock your computer before stepping away, it does not necessarily mean that your information is safe. Many users follow what appear to be all the correct security practices. They use strong passwords, enable full disk encryption, and keep their operating systems updated. From the outside, everything looks secure. However, computer security is often about understanding where data actually lives inside a machine at any given moment. One of the most overlooked places where sensitive information resides is system memory, also known as RAM. The contents of memory can sometimes be captured surprisingly easily, even with something as ordinary as a USB flash drive.
Imagine that you step away to take a phone call, grab a snack, or simply go for a short walk, leaving your computer or laptop unattended for ten or fifteen minutes. Perhaps you are an office employee stepping out between meetings or a university student taking a short break during a long study session. Being a responsible user, you locked your computer before leaving. Your HDD or SSD is encrypted. You use a reasonably strong login password, and the operating system is fully patched with the latest updates. From the user’s point of view everything appears to be in order. Your data should be protected.
But from a security professional’s point of view, it is always useful to ask a different question. What would an attacker see when they approach this machine?
Let’s think about the situation from the perspective of someone attempting to compromise the system while time is limited. The first and simplest thing an attacker might try is connecting directly to the computer using an Ethernet cable. This approach does not require logging into the system at all. By plugging in a network cable we may establish a communication channel with the machine, and once that connection exists, several possible attack techniques become available. An attacker might attempt exploiting vulnerabilities such as MS17-010, BlueKeep, or PrintNightmare if the system happens to be missing patches. Another possibility would be NetBIOS or LLMNR spoofing using a tool such as Responder in order to capture authentication hashes. If remote services are exposed, brute-force attacks against SMB or RDP could also be attempted. In other cases a man-in-the-middle approach may be used, employing tools like Evilgrade, BDFProxy, or exploiting issues such as MS16-101.
Each of these attack paths is interesting and worth studying in its own right. Entire books have been written about network exploitation techniques like these. For the purposes of this article, however, we will assume the system is relatively modern, fully patched, and protected by a strong password. In other words, the simple network attacks do not succeed.
The second option an attacker might consider is forcing the machine into sleep mode or hibernation and then attempting direct access to the storage device. In sleep mode the system stops actively using the disk. The RAM remains powered so that the system state can be preserved, but the drive itself becomes inactive. If an attacker has physical access to the machine, they could remove the hard drive and connect it to another computer using a simple adapter or disk docking station.
In many real-world situations that alone would already be enough to access the data. If the drive were a normal unencrypted HDD or SSD, all files would become available. Documents, configuration files, browser databases, system files, and user data could be copied or analyzed offline. Password hashes could be extracted and cracked later. The attacker would not even be limited to passive access. With full disk access they could modify files as well.
For example, one classical technique involves abusing the Windows Sticky Keys feature. Sticky Keys is normally triggered by pressing the Shift key five times at the login screen. If an attacker replaces the Sticky Keys executable with the command prompt binary, they can spawn a system shell directly from the login screen. With direct disk access this modification is trivial. The following commands illustrate the idea:
bash# > mount /dev/sdb2 /media/hdd
bash# > cp /media/hdd/Windows/System32/cmd.exe /media/hdd/Windows/System32/sethc.exeAfter performing this modification, pressing Shift five times at the login screen launches a command prompt running with high privileges. From there the user password can be reset and the system accessed normally.
This scenario is relatively straightforward, although it contains its own technical nuances. Our goal in this discussion, however, is slightly different. We will assume the system uses full disk encryption, meaning that removing the drive does not immediately reveal the stored data. In that case the attacker must think about where the decrypted information currently exists.
And this leads us to the third option: the cold boot attack.
Cold Boot Attack
A cold boot attack is a well-known technique for accessing the contents of RAM. It exploits a physical property of computer memory known as data persistence. Although RAM is considered volatile memory, its contents do not disappear instantly when power is removed. Instead, the stored electrical charges fade gradually over a short period of time. If the system is rebooted quickly enough, a significant portion of that data may still be present. The key idea behind the attack is performing what is known as a cold reboot. This is a reboot that occurs without the operating system shutting down normally. Instead of allowing the system to clean up memory, we force the hardware to restart immediately. During a normal reboot the operating system performs a controlled shutdown. Processes are terminated, files are unmapped from memory, and many systems actively wipe portions of RAM before restarting. By bypassing the operating system entirely we prevent these protective steps from occurring, preserving the data that was previously stored in memory.
There are several ways such a reboot might be triggered. One approach is quickly cutting and restoring power to the machine. Another is pressing a hardware reset button if the system has one. A third possibility is deliberately causing a Blue Screen of Death so that the system crashes and restarts abruptly. In each of these cases the operating system loses control before it has time to clear RAM. If a bootable USB drive is already inserted into the system, the firmware may transfer execution to it during startup. At that moment custom boot code can begin reading the remaining contents of memory. On laptops this process introduces additional challenges. Many modern laptops no longer include a dedicated hardware reset button. Batteries are often non-removable, which makes quickly cutting power difficult. These design choices make physical attacks slightly more complicated. In some situations, however, it is still possible to force a crash by inserting a USB drive containing a deliberately corrupted filesystem. When Windows attempts to interact with it, the system may trigger a Blue Screen of Death and reboot.
For example, such an image can be downloaded and written to a USB drive in the following way if you are using Linux and have Git installed:
bash# > git clone https://github.com/mtivadar/windows10_ntfs_crash_dos
bash# > dd if=tinyntfs of=/dev/sdbThe exact technique used to trigger the reboot depends on the environment. The attacker must be careful, because mistakes could result in losing the memory contents entirely. Interestingly, modern Windows systems that frequently enter sleep or hibernation states can sometimes make the attack easier. In certain cases RAM contents are restored from the hibernation file, meaning sensitive data may reappear in memory after the system resumes.
There is also a more extreme variation of the attack. In theory, DRAM or SRAM modules could be physically removed from the motherboard, cooled to slow down data decay, and then inserted into another system for analysis. This approach has been demonstrated in research laboratories, but it is far more complicated in practice because it requires disassembling the machine and working very quickly. For that reason we will not focus on it here. A bootable USB drive is much simpler and more practical because almost every computer has accessible USB ports. From a technical perspective the primitives we need are surprisingly simple. We only require the ability to read physical memory and write that data somewhere safe, such as a disk sector on the USB drive.
The following boot code demonstrates the basic concept.
If compiled and placed at the beginning of a USB drive or disk, the BIOS will execute it as boot code:
bash# > nasm bootcode.asm
bash# > qemu-system-i386 -hda bootcodeOn systems with a traditional BIOS, boot code executes in real mode, which is a 16-bit operating environment used during the early stages of the boot process. In this mode memory is accessed using physical addresses. The address being read is specified through the ES:BX register pair. Writing data to a storage device can be performed using BIOS interrupt 0x13. This interrupt essentially functions as a small API provided by the BIOS firmware, allowing boot code to interact with disks without needing full drivers. Using this mechanism, the code can copy 512 bytes of RAM and write them to a disk sector. By repeating this process inside a loop, it becomes theoretically possible to read the entire contents of memory.
Fortunately we do not need to implement this functionality ourselves in assembly language. A convenient tool already exists that performs exactly this task. As you may have guessed, we will exploit the cold boot attack using a simple bootable USB drive.
Preparation
The first step is preparing an attacking bootable USB drive capable of dumping RAM into an unallocated region of the disk while leaving the filesystem intact. This approach avoids corrupting the drive while still capturing the memory contents.
The required files can be obtained and written to the USB drive using the following commands:
bash# > wget https://github.com/baselsayeh/coldboot-tools/releases/download/2/bios_memimage64.zip
bash# > dd if=grldr.mbr of=/dev/sdb conv=notrunc
bash# > fdisk /dev/sdb
bash# > mkfs.fat /dev/sdb1
bash# > mount /dev/sdb1 /media/usb
bash# > cp grldr menu_sec_part.lst scraper*.bin /media/usb/The configuration file menu_sec_part.lst instructs the bootloader to dump RAM into a secondary partition on the USB drive:
title Dump the ram (64bit Halt)
map (hd0) (hd1)
# Flash drive partition where the RAM dump will be saved
map (hd0,1)+1 (hd0)
map --hook
rootnoverify (hd0,0)
# Use long mode to copy more than 4 GB of RAM
chainloader --force --boot-cs=0x7c0 --boot-ip=0x200 (hd1,0)/boot/grub4dos/scraper/scraper64_haltonly.binImportantly, the data is written directly to the partition rather than through the filesystem. In theory GRUB could create a virtual disk from a file and store the memory dump inside that file. While this might seem more convenient, modern filesystems introduce complications. FAT32 cannot store files larger than four gigabytes, and on NTFS the Master File Table is positioned roughly in the middle of the partition. Writing large contiguous data blocks directly could damage filesystem structures.
Because of these limitations, dumping memory directly to a partition is often the safest and simplest solution.
Exploitation
The target system does not necessarily need to be configured to boot automatically from USB devices. Many BIOS implementations allow the user to select a temporary boot device by pressing a key such as F8 or F12 during startup. If that option is not available, it may still be possible to change the boot order within the BIOS setup menu. From the outside the attack looks almost harmless. Someone simply plugs in a USB drive and restarts the computer. While the legitimate user is away, the system boots into the attacker’s environment and begins copying the contents of RAM onto the removable drive.
The process can take some time depending on the amount of memory installed in the machine. Once the operation finishes, an exact copy of RAM will be stored inside the second partition of the USB drive, typically visible as /dev/sdb2.
To make analysis easier, the raw partition contents can be converted into a normal file:
bash# > dd if=/dev/sdb2 of=ram.img bs= status=progressIn one example the memory dump appeared slightly offset by 0x53000 bytes. This can easily be corrected by padding the file appropriately:
bash# > truncate -s $[0x53000] pad.img
bash# > cat pad.img ram.img > _ram.imgAt this stage we now possess the contents of system memory exactly as they existed at the moment the hardware reset occurred. Any secrets that were stored in RAM at that time may still be present inside the dump.
Tools such as radare2 allow us to quickly search for interesting strings inside the image:
bash# > radare2 -n ram.img
/wi cookie # looking for cookies
/wi passw # looking for passwordsUsing this simple signature-based approach we can scan for keywords like “password,” “secret,” or “cookie.” This often reveals credentials, authentication tokens, or fragments of sensitive data. Signatures can also identify recognizable file formats such as RSA keys, images, PDFs, compressed archives, and database files. Below you can see what was running on the system before the computer was locked and the attack began.
The string that was entered is present in the machine memory.
But searching for strings is only the beginning. A memory dump also contains internal operating system structures that allow us to reconstruct the state of the system at the moment the reboot occurred. An attentive reader may wonder whether running boot code from the USB drive overwrites part of RAM. The answer is yes, but experiments show that the affected regions are relatively small. For example, measurements show that the Windows bootloader overwrites approximately five megabytes of memory. GRUB2 overwrites roughly eight megabytes, and BURG around nine megabytes. A live forensic operating system overwrites far more, often around one hundred seventy megabytes. The Coldboot-Tools boot code itself occupies about ninety-five kilobytes. The full GRUB4DOS plus scraper chain overwrites roughly eight hundred twenty kilobytes of memory. On modern machines with tens of gigabytes of RAM, this is a very small fraction of the total memory space.
Nevertheless, overwriting even a few megabytes in the wrong location could damage important operating system structures. Experiments on Windows 7 systems suggest that the first one hundred megabytes of RAM typically contain relatively little critical information, which reduces the risk of damaging useful forensic artifacts. In practice, memory dumps obtained using GRUB4DOS together with scraper64_haltonly.bin remain suitable for analysis because most operating system structures reside beyond that early memory region. The entropy of the dump shows the overall picture of how data and empty spaces are arranged within it.
Extracting Secrets
This stage moves us firmly into the domain of digital forensics. Once a memory image has been captured, specialized analysis frameworks can reconstruct the state of the operating system at the time of acquisition.
Two well-known tools for this purpose are Volatility and Rekall. These frameworks understand the internal structures used by operating systems to manage processes, memory, networking, and files. A good starting point for analysis is listing running processes. If the tool can correctly identify processes from the memory image, it is a strong indication that the forensic profile and analysis environment are configured properly.
Another interesting artifact stored in memory is the Windows registry. Portions of registry hives may still be present inside RAM, allowing investigators to extract password hashes of local accounts.
In some situations domain credentials may also appear, occasionally even in plaintext depending on how authentication occurred.
For example, the following command demonstrates the use of a Volatility plugin designed to recover credential material:
bash# > vol.py --plugins=/path/to/volatility_plugins/FrancescoPicasso -f ram.img mimikatzAdditional artifacts can also be recovered from the same memory image. Open files can be identified and extracted, network connections can be reconstructed, clipboard contents can be recovered, and screenshots of the desktop environment may even be present if graphical buffers remain in memory.
The following commands will help with it:
bash# > vol.py -f ram.img filescan
bash# > vol.py -f ram.img dumpfiles -r '.sqlite' -D files/
bash# > vol.py -f ram.img netscan
bash# > vol.py -f ram.img clipboard
bash# > vol.py -f ram.img screenshot -D .Through this process investigators or attackers gain access to a wide range of information about the system’s activity immediately before the reboot occurred.
EFI Considerations
One important limitation of this attack is that it primarily affects systems using traditional BIOS firmware. Through practical testing on different manufacturers’ EFI systems, it has been observed that immediately after a reboot, during the initial hardware initialization stage, random bytes are written across the entire RAM. This effectively protects users of modern EFI‑based PCs from this type of attack by overwriting the contents of memory. It is easy to verify this using the same GRUB4DOS bootloader. GRUB4DOS supports reading and writing arbitrary regions of RAM through special commands. First, you find any address in memory for testing, view its contents, and remember it.
GRUB4DOS > map --rd-base=0xADDR
GRUB4DOS > map --rd-size=0x200
GRUB4DOS > rdcat --hex (rd)0x0+1Next, overwrite it with a value, for example the word test, and then reboot.
GRUB4DOS > write (rd)0x0+1 test
GRUB4DOS > rebootDuring a reboot, the GRUB4DOS bootloader itself does not wipe the memory, so this process is equivalent to performing a cold reboot. Afterward, you check whether EFI erased the memory or whether your data in RAM remained untouched after the reboot. In our case, the memory contents changed. This was tested on laptops from HP and Lenovo. Nevertheless, the Memory Scrapper tool is also available for EFI systems.
Conclusion
We have seen that all data in RAM is exposed, and the attack described above makes it possible to bypass full disk encryption, even on a locked computer. We were able to attack a genuinely protected machine, one that is usually considered the security standard for typical corporate workstations, not to mention ordinary home computers. Although computers with classic BIOS are gradually disappearing, many older desktop systems can still be found in the corporate sector, where replacing hardware on a large scale is expensive and employees continue to work on existing machines. In addition, modern motherboards with EFI still support the old legacy BIOS mode, which makes them vulnerable to this attack as well.
If you’re interested in digital forensics, we recommend our Advanced Digital Forensics training.
Source: HackersArise
Source Link: https://hackers-arise.com/digital-forensics-extracting-secrets-after-a-cold-boot-attack/