In Part 1 of this series, I introduced you to the concept of date/time coincidence and we explored five registry keys that are useful to the forensic examiner. This time, I’ll show you how data can be encrypted and hidden in the registry.
If you’re involved in data security, you’re familiar with cryptography in some fashion and you know that ciphers – algorithms for performing encryption and decryption – are what do the work. You probably also know that there are a few quick-and-dirty algorithms for encrypting data. One such algorithm is known as the Caesar Cipher, or ROT-13, a simple algorithm that encrypts data by shifting each character 13 places in the alphabet while leaving non-alpha characters untouched. It’s so simple that you can decrypt it manually, but it’s enough to fool the casual observer. Anyone coming across something like cnffj beqsb egurf rperg svyrf vfcnf fjbeq, is naturally going to assume it’s encrypted; in fact, it’s ROT-13 for password for the secret files is password. I broke it up into five-character groups to make it more convincing.
For whatever reason, Microsoft uses ROT-13 to encrypt data in some registry keys. One such key is: HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist. Here’s an example: “HRZR_EHACNGU:P:\AFYBBXHC.RKR.” Decrypted, that’s “UEME_RUNPATH:C:\NSLOOKUP.EXE.” (We’ll look at the UserAssist key in Part 3.) A better way to hide data is to encode text-based information in binary format and store it in binary form as a string in registry values of type REG_SZ. Given that binary data is common in the registry, the technique would make it extremely difficult to retrieve the hidden information.
In addition to using ROT-13 and binary encoding to obfuscate data, a suspect could take advantage of a flaw in the registry editor to also make the data invisible to anyone but a forensics examiner who knows about the flaw. From “Forensic Analysis of the Windows Registry:”
The Windows 2000 and XP Registry Editor (regedit.exe or regedt32.exe) have an implementation flaw that allows hiding of registry information from viewing and editing, regardless of users access privilege (Secunia, 2005). The flaw involves any registry values with name from 256 to 259 (maximum value name) characters long. The overly long registry value (regardless of type) not only hides its own presence, but also subsequently created values (regardless of type) in the same key (Franchuk, 2005). The editor stops displaying the remaining of the values thinking the overly long value as the last value in that key. Suspect could exploit such Registry Editor flaw to hide information.
The Windows console registry tool (reg.exe) can display these overly long registry values so the hidden data can be recovered as evidence; however, given the sheer number of entries in the registry, this process is not trivial.
I hope this series is giving you some insight, perhaps even piqueing your interest, in cyber forensics. Hit the comment button and tell me what you think.
In Part 3, we’ll explore some keys that can tell us where a suspect has been storing files.