Thursday, September 06, 2012

32-bit EXEs on a 64-bit System

Anyone who's done digital analysis of Windows systems knows that they can be pretty complex beasts to analyze.  To add a little "fun" to the mix, the location of artifacts on a 64-bit Windows system will depend on whether the programs used are 32- or 64-bit programs.

Wait...what?

Now, what does all this mean?  Let's say you have a copy of a malware sample, and you submit it to VirusTotal, or you already know what the malware is identified and known as to some of the various AV vendors.  When you read the AV vendor write-ups on the malware, you'll notice that they very rarely identify the analysis platform used; so, if the malware uses the Run key for persistence, you might open the Software hive in a viewer and navigate to the Run key, not find any unusual entries, and then simply assume that the malware either didn't execute, or failed to completely install and run.

You should be aware that 64-bit Windows system perform redirection when it comes to 32-bit applications.  What this means is that if you check the PE header of the malware file and find that it was compiled for 32-bit platforms, and the system you're analyzing is a 64-bit platform, you're going to need to look in a few additional (maybe I should say "other", instead) areas for your artifacts.

Registry redirection primarily affects the Software and NTUSER.DAT hives; there's (apparently) no "WOW6432Node" subkey in the System hive (I haven't seen one yet).  As such, if malware usually uses the Run key, then you should check the Run keys in both the HLKM\Software\Microsoft\Windows\CurrentVersion and the HLKM\Software\Wow6432Node\Microsoft\Windows\CurrentVersion paths.

Something to be aware of is that none of the RegRipper plugins available in the current archive that check the Run keys in either the Software or NTUSER.DAT hives account for redirection.  I have a number of plugins in my own repository that do take this into account, and have been responsible for some pretty cool/significant finds.

Now, most times, within the file system, all we usually see with respect to redirection is that when we install 32-bit applications on a 64-bit system, we'll see a C:\Program Files directory as well as a C:\Program Files (x86) directory.  However, due to file system redirection, 32-bit malware that, for example, attempts to write a file to the  C:\Windows\config\systemprofile \AppData\Local folder (on a Windows 7 or Win2008R2 system), on a 64-bit system will actually write that file to the to C:\Windows\SysWOW64\config\systemprofile\AppData\Local folder.  Use of environment variables such as %Temp% will have a similar effect.

Again, I have yet to see any Registry redirection that applies to the System hive.  I have seen 32-bit malware installed on 64-bit Windows systems as a service, and the services entries went right into the ControlSet00n\services\ subkeys.

Note: The current version of the appcompatcache.pl plugin includes some simple checks (via grep()) for potentially suspicious paths, such as those that contain the term "temp".  Based on some recent findings, I'm going to go back to that and add a check for SysWOW64...and I will likely add that check to other plugins, as well.

So What?
So, why should anyone care about any of this at all?  Well, let's say that you're doing some analysis of a system, and you think that there may be malware on the system, malware for which several AV vendor write-ups state that it uses the Run key for persistence.  Okay, so we run RegRipper or open the hive in a viewer and navigate to that key...but we don't see a reference to any unusual files.  At this point, what do we do?  In some cases, many of us might check that item off of our checklist, and move on to the next step.  However, did we really complete that check?  After all, AV vendor write-ups are notorious for not providing complete information...I have yet to see a write-up that states, "...here is the PE header info for this malware, and we performed dynamic analysis by running the malware in a Windows XP SP3 (32-bit) VirtualBox VM..", and to be honest, I don't think that I've seen that because to the AV vendors, none of that is important.  But to an incident responder or a digital forensic analyst, it can be very important.

A couple of months ago, I was looking at a Software hive from a system that had been compromised, and I found some interesting artifacts in the Microsoft\Tracing key.  Now, this was a 64-bit Windows system I was analyzing, and I knew that at least one of the programs that had been installed on the system was 32-bit, so I decided to check the WOW6432Node\Microsoft\Tracing key, and not only did I find the subkeys that I thought would be there, but I also found references to other 32-bit programs, as well. 

So, when performing analysis or asking questions in order to further your analysis, it is important to realize that not only is it very important to be aware of the version of Windows that you are analyzing, but it's also important to be aware of whether the version is 32- or 64-bit, as this can have a significant impact on where you look for artifacts, in both the file system as well as the Registry.

This also applies to when we're sharing information within the community; for example, after having read this blog post, it should be pretty clear that this write-up of ADrive on ForensicArtifacts.com involved a 32-bit app run on a 64-bit system.  However, if you weren't aware of this, would you look for the \Wow6432Node\Microsoft\Tracing\ADrive Desktop_RASAPI32 key, not find "Wow6432Node" in the Software hive, and then just figure that the application had not been run?

Resources
Registry Redirection
File System Redirector

1 comment:

YeahIt'sMe said...

Very timely post. Have been confronting the issue of 32-bit malware on 64-bit systems. So far the persistence mechanisms have been in Services, but will definitely be adding this info to my arsenal. Thank you sir.

--Eric