Monday, March 15, 2010


Windows 7 XPMode
I was doing some Windows 7 testing not long ago, during which I installed a couple of applications in XPMode. The first thing I found was that you actually have to open the XP VPC virtual machine and install the application there; once you're done, the application should appear on your Windows 7 desktop.

What I found in reality is that not all applications installed in XPMode appear to Windows 7. I installed Skype and Google Chrome, and Chrome did not and would not appear on the Windows 7 desktop.

Now, the next step is to examine the Registry...for both the Windows 7 and XPMode see where artifacts reside.

When it comes to artifacts, there are other issues to consider, as well...particularly when the system you're examining may not have the hardware necessary to run XPMode, so the user may opt for something a bit easier, such as VirtualBox's Seamless Mode (thanks to Claus and the MakeUsOf blog for that link!).

Skype IMBot
Speaking of Skype, the guys at have an excellent technical analysis and write-up on the Skype IMBot. Some of what this 'bot does is pretty interesting, in it's simplicity...for example, disabling AV through 'net stop' commands.

I thought that the Registry persistence mechanism was pretty interesting, in that it used the ubiquitous Run key and the Image File Execution Options key. As much as I've read about the IFEO key, and used it in demos to show folks how the whole thing worked, I've only seen it used once in the wild.

The only thing I'd say that I really wasn't 100% on-board with about the report overall was on pg 7 where the authors refer to "very simple rootkit behavior"...hiding behavior, yes, but rootkit? Really?

I found an update about ZBot over at the MMPC site. I'd actually seen variant #4 before.

Another interesting thing about this malware is something I'd noticed in the past with other malware, particularly Conficker. Even though there are multiple variants, and as each new variant comes out, everyone...victims, IR teams, and AV in react mode, there's usually something about the malware that remains consistent across the entire family.

In the case of ZBot, one artifact or characteristic that remains persistent across the family is the Registry persistence mechanism; that is, this one writes to the UserInit value. This can be extremely important in helping IT staff and IR teams in locating other infected systems on the network, something that is very often the bane of IR; how to correctly and accurately scope an issue. I mean, which would you rather do...image all 500 systems, or locate the infected ones?

From the MMPC write-up, there are appears to be another Registry value (i.e., the UID value mentioned in the write-up) that IT staff can use to identify potentially infected systems.

The reason I mention this is that responders can use this information to look for infected systems across their domain, using reg.exe in a simple batch file. Further, checks of these Registry keys can be added to tools like RegRipper, so that a forensic analyst can quickly...very quickly...check for the possibility of such an infection, either during analysis or even as part of the data in-processing. With respect to RegRipper, there are already plugins available that pull the UserInit value, and it took me about 5 minutes (quite literally) to write one for the UID value.

I was talking with a colleague recently about how pervasive technology is today for the younger set. Kids today have access to so much that many of us didn't have when we were growing computers and cell phones. Some of us may use one email application, whereas our kids go through dozens, and sometimes use more than one email, IM, and/or social networking application at a time.

I've also seen where pictures of people have been posted to social networking sites without their knowledge. It seems that with the pervasiveness of technology comes an immediate need for gratification and a complete dismissal for the privacy and rights of others. While some people won't like it when it happens to them, they have no trouble taking pictures of people and posting them to social network sites without their knowledge or permission. Some of the same people will freely browse social networking sites, making fun of what others have posted...but when it's done to them, suddenly it's creepin' and you have no right.

Combine these attitudes with the massive pervasiveness of technology, and you can see that there's a pretty significant security risk.

From a forensics perspective, I've seen people on two social networking sites, while simultaneously using three IM clients (none of which is AIM) on their computer (and another one on an iTouch), all while texting others from their cell phone. Needless to say, trying to answer a simple question like, "...was any data exfiltrated?" is going to be a bit of a challenge.

Accenture has released research involving these millenials, those younger folks for whom technology is so pervasive, and in many cases, for whom "privacy" means something totally different from what it means to you, me, and even our parents. In many ways, I think that this is something that lots of us need to read. Not too long ago, I noted that when examining a system and looking for browser activity, a number of folks responded that they started by looking at the TypedURLs key, and then asked, what if IE isn't the default browser? Let's take that a step further...what if the computer isn't the default communications device? Many times LE will try to tie an IP address from log files to a specific device used by a particular person...but now the question is, which device? Not only will someone have a laptop and a cell phone, now what happens when they tether the devices?

The next time you see some younger folks sitting around in a group, all of them texting other people, or you see someone using a laptop and a cell phone, think about the challenges inherent to answering the most basic questions.

USN Journal
Through a post and some links in the Win4n6 Yahoo Group, I came across some interesting links regarding the NTFS USN Journal file (thanks, Jimmy!). Jimmy pointed to Lance's EnScript for parsing the NTFS transaction log; Lance's page points to the MS USN_RECORD structure definition. Thanks to everyone who contributed to the thread.

An important point about the USN Journal...the change journal is not enabled by default on XP, but it is on Vista.

So, why's this important? Well, a lot of times you may find something of value by parsing files specifically associated with the file system, such as the MFT (using, for example).

Another example is that I've found value bits in the $LogFile file, both during practice, and while working real exams. I simply export the file and run it through strings or BinText, and in a couple of cases I've found information from files that didn't appear in the 'active' file system.

For more detailed (re: regarding structures, etc.) information about the NTFS file system, check out and the NTFS documentation on Sourceforge.

MFT Analysis/Data Structures
Missing MFT Entry

LNK Files
Speaking of files...Harry Parsonage has an interesting post on Windows shortcut/LNK files, including some information on using the available timestamps (there's 9 of them) to make heads or tails of what was happening on the system. Remember that many times, LNK files are created through some action taken by a user, so this analysis may help you build a better picture of user activity.


Aaron said...

Check out the Zbot writeup over at secureworks. The new version of the malware is showing the signs of more advanced capabilities. It's one of the better writeups on the subject.

Keydet89 said...

Very cool, thanks!

Philip Elder SBS MVP said...

With regards to XP Mode apps, the shortcuts created during an application install routine need to be dropped into the D&Ss\All Users\Start Menu\Programs folder before they are picked up by the Win7 Win XP Mode Apps menu.

If the shortcuts get dropped into the user profile's D&Ss\UserName\Start Menu\Programs location, a cut and paste of the program's folder/shortcuts into the All Users location will get them to show up in Win7.


Keydet89 said...


That's pretty interesting and definitely an analysis tip! Thanks!

randall said...


I also found Harry Parsonage's write-up about Link files fascinating but from the standpoint of one of my favorite interests system time manipulation. First of all, the time embedded in the link file is not likely to be manipulated by the user or by evidence elimination software. Second, the time associated with the link file is not when the link was created but the time of the last boot up. At first glance I didn't think this would be that helpful but then realized the only way it could do this would be to read the registry key of last boot (I haven't confirmed this yet but suspect it). So if someone runs timecpl or any other time manipulation software during the current boot session (and clears event logs and all other tracks) the link file evidence will show descrepancies compared to MACE times. Powerful stuff. Third, a sequential sequence number is added to each new link file made. Harry shows how the sequence numbers and dates/times can be compared to show date manipulation. I think analyzing link file ObjectID's may be something every investigator might want to add to their toolbox if there is any question regarding time validities.
The only problem is decoding the ObjectID has to be done on individual link files using our forensic software or using LinkAlyzer (100EUR) on multiple files. How hard would it be to write a Perl script that reads the first two bytes (Sequence number) and 64-bit Filetime of the ObjectID on a list of link files and output them to a CSV file? Just askin'.

Keydet89 said...

How hard would it be to write a Perl script that reads the first two bytes (Sequence number) and 64-bit Filetime of the ObjectID on a list of link files and output them to a CSV file?

Not hard at all...