ZeroAccess, Windows command line code pages, alternate data streams, spaces in file paths, and more. Also an update to the Windows Live Response collection!

Good news everyone!! There is a lot to cover in this blog post, so please ensure your seat belt is securely fastened because it is going to be one heck of a ride!

All of the items in this particular blog post came about as I was messing around on the Malware Box of Evil with a ZeroAccess rootkit sample (you can read more about this sample here). Many months ago, back when I used EnCase to perform my analysis, I wrote an EnScript to digest file paths when searching for Unicode characters in file paths. (I have since moved on an use X-Ways pretty much exclusively as it is a MUCH better tool than EnCase. I, for one, welcome our new X-Ways overlords! ) I wanted the Windows Live Response script to perform similar functions to highlight files and directories of possible interest and save that output. What I didn't realize is how much research, frustration, alcohol, and eventual joy and happiness this process would involve.


Windows Code Pages

The first thing that I encountered was the Windows Code Page. There are many, many different code pages, but on US-based, English systems, the default code page used by the Windows command prompt seems to be 437 (MS-DOS Latin US). You can open a command prompt and see what code page it uses by typing the command 'chcp'. What this means for the typical user is, even if you have installed different language packs to view files/languages on your US English Windows system, when you view those files from a command prompt you are likely to see "????" instead of "папка" (a Russian word for "folder")

Command line view and Windows Explorer view of "папка"folder. The Active code page is 437.

So I updated the Windows Live Response batch script to perform a directory listing and then use the built-in Windows command "findstr" to look for anything with a "?" in the output. While it may produce a lot of results, especially if you have a lot of files/paths in other languages, it should help you to determine some areas of interest in which to look.


Alternate Data Streams

As I got to thinking about this particular ZeroAccess sample, the more that I realized simply finding Unicode in filepaths wouldn't be enough. What if the sample you are trying to detect doesn't use Unicode in the file path, such as the one in this writeup? What if it just utilizes one of the main indicators such as an Alternate Data Stream (ADS)? (I won't go into detail on Alternate Data Streams in this post but there are several posts, such as this one, that you can easily find if you want to learn more). Starting with Windows Vista, the built-in Windows "dir" command has a "/r" option that allows you view Alternate Data Streams. 

"dir" command options for Windows Vista and later. Retrieved 14 May 2014 from "http://blogs.msdn.com/b/junfeng/archive/2006/04/21/580285.aspx"

This is an outstanding feature, however, the "dir" command on Windows XP systems (which I know are still in use <sad face>) does not have that option. Fortunately Mark Russinovich released a tool in the Sysinternals Suite called "streams" which works on Windows systems, including Windows XP. I have updated the Windows Live Response collection to include this tool and the script will now search the %HOMEDRIVE% for Alternate Data Streams. The output of streams.exe also includes the "." character to show that it is working. So be aware that you may end up with file paths that look like they contain Morse code (for example, the screenshot below contains "..." before the path). This is a result of the tool output and can easily be cleaned by the end user, if they so desire.


By combining the findstr "?" search and the Alternate Data Stream search, we can clearly see possible evidence of a ZeroAccess infection on the Malware Box of Evil.

Alternate Data Stream search and possible Unicode search results

Spaces in file paths and environment variables to help

As I was running/working on the script, I realized that the entire batch script had a potentially serious issue. I have always tried to save files connected by underscores or dashes and never until my most recent round of testing did I contemplate "what if the user had a space in the file path"? This was particularly highlighted by placing the collection on the "Documents and Settings\<USERNAME>\Desktop" of a Windows XP system. While a majority of the commands worked OK with the "%~dp0" variable, some did not, and one command not working properly makes me unhappy. So after quite a bit of trial and error, I realized two things about the Windows command line interface:

1) You can escape characters using the caret "^" symbol. However, if you use the caret symbol as an escape character, you cannot place that command in either single or double quotes.

What works and what doesn't work with space on the Windows command line

2) The variable "%~dps0" gives the file location of the batch script, but uses the "short" file/path name method. So it is a built-in way to allow for spaces in the name. I wish I would have figured that out early on before devoting a lot of time and effort, but it was a great learning experience and I learned a lot of  "what not to do" and hopefully sharing my experiences will help you during the course of your research/investigations.

Batch script output using %~dps0. Note the ~ in the paths instead of escaped spaces

Lastly, updates to the Windows Live Response collection

All of these items that I covered in this post have found their way into the updated version of the Windows Live Response collection. I also included the most recent version of PEStudio (8.26) which you can download from Marc's website. 



LiveResponseCollection-Cedarpelta.zip - download here 

MD5: 7bc32091c1e7d773162fbdc9455f6432
SHA256: 2c32984adf2b5b584761f61bd58b61dfc0c62b27b117be40617fa260596d9c63
Updated: September 5, 2019