MITRE Corporation’s ATT&CK framework is a living, curated repository of adversarial tactics and techniques based on observations from actual attacks on enterprise networks. It’s a valuable trove of information for security analysts, threat hunters and incident response teams. Today, I’m going to look at a particular method for evading detection, often used in conjunction with maintaining persistence, which has been abused by recent malware: hiding within the Windows registry. Adversaries are always looking for ways to evade detection and maintain persistence. Techniques are spread across multiple tactics, with Defense Evasion and Persistence being two of the larger tactics by the number of linked techniques. Defense evasion characterizes techniques which adversaries use to avoid detection and defenses. According to Verizon’s 2018 Data Breach Investigations Report, “68% of breaches took months or longer to discover.” Persistence characterizes techniques that allow an adversary to maintain a presence on a system through interruptions such as system reboots, loss of credentials or malware removal tools. These two tactics often go hand in hand. Adversaries have been known to add malicious registry entries to various Windows configuration locations such as HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run in order to maintain persistence through system reboots. Registry entries in this location will execute when the computer reboots or a user logs in, and these entries often Masquerade, a hide-in-plain-sight technique, as legitimate entries to prevent detection. More recently, we’ve seen examples of malicious registry entries hiding rather than masquerading. For example, the ad-fraud Kovter hides persistence-enabling code in the registry by prepending entry names with a null byte in order to make detection, analysis and removal difficult. This is an old trick that has seen renewed use. Additionally, Poweliks is another ad-fraud Trojan that hides in the registry using similar mechanisms. An old version of the "Tips and Trivia" page at Systems Internals suggests how this is possible:
How is this possible? The answer is that a name which is a counted Unicode string can explicitly include NULL characters (0) as part of the name. For example, "Key\0". To include the NULL at the end the length of the Unicode string is specified as 4. There is absolutely no way to specify this name using the Win32 API since if "Key\0" is passed as a name, the API will determine that the name is "Key" (3 characters in length) because the "\0" indicates the end of the name.
A registry monitor using the Win32 API will be unable to view registry entries that contain a null character. In other words, there is a difference between Win32 API and Native API string conventions, and there exists a class of strings that can be described by the Native API but not by the Win32 API. For instance, since both Regedit.exe and Reg.exe use the Win32 API, they are unable to properly view or open registry entries prepended by a null character. A proof of concept can be found in the Sysinternals suite called Reghide, which is created by the estimable Mark Russinovich. Sysinternals contains many good tools to look for potential vulnerabilities. When run, Reghide creates a registry entry that is appended with a null character. You can try it out for yourself:
However, note that when run, the hidden registry key may not be located at ‘HKLM\SOFTWARE\Systems Internals\Can’t touch me!’ Due to registry virtualization in newer versions of Windows, entries that have global impact may be redirected to per-user locations in the virtual store. With newer versions of Windows, the example hidden key will be at the following location: ‘HKCU\Software\Classes\VirtualStore\MACHINE\SOFTWARE\WOW6432Node\Systems Internals\Can't touch me!’ Attempting to open the entry in Regedit results in an error because Regedit expects a null terminated string while the entry is a string containing a null character:
We can use Process Monitor, also part of the Sysinternals suite, to see the registry entry being created here:
Tripwire Enterprise hooks into the Native API, so it can also properly monitor for hidden registry entries. Here Tripwire Enterprise reports that the entry created by Reghide, ‘Can’t touch me!\0’, has string data ‘Hidden Value’ as shown here in Chrome:
Discovering registry entries that contain embedded null characters is a first step in hunting adversaries hiding within our systems using this technique. We’d also like to remove the hidden malicious keys. Fortunately, another Sysinternals tool to can do that. RegDelNull is a command line utility that scans the registry for null embedded entries and provides an option to replace the null character with an asterisk. Although some guides suggest that this hidden registry entry trick can be performed with any nonprintable Unicode character, my testing has shown this is not the case. At least, the mechanism of evasion is not the same. There are other Unicode characters which can be used to masquerade. As an example, another old Unicode trick recently revived to target Windows Telegram users relies on using the right-to-left override character, ‘U+202E’, which reverses the display order of the subsequent characters, misleading users into executing malicious files with nonsuspicious filenames. So, a file named ‘March 20 \u202Excod.scr’ displays as ‘March 20 rcs.docx’, and files with the extension ‘scr’ are executable Windows screensaver files and are a common malware vector. The right-to-left override and other Unicode formatting characters can also be used in the registry to masquarade. It’s important to note that the system still sees this example as an ‘scr’ file, and email filters would still pick it out as an ‘scr’ file. As Defense Evasion methods, hiding in the registry and masquerading are both designed to trick humans and thus are hard to detect manually. However, they don’t trick properly configured tools such as Sysinternals, Tripwire Enterprise or email filters. Hence, it’s important to understand the capabilities and limitations of your security tools. We hope to continually grow MITRE ATT&CK with up-to-date details to help security analysts, threat hunters and incident response teams frame and round out their defensive plans. To learn more about the MITRE ATT&CK framework, you can read the blog series by Travis Smith here.
Mastering Security Configuration Management
Master Security Configuration Management with Tripwire's guide on best practices. This resource explores SCM's role in modern cybersecurity, reducing the attack surface, and achieving compliance with regulations. Gain practical insights for using SCM effectively in various environments.
