Houston We’ve Had a Problem – Wow64
Wednesday, March 13, 2013
This is a piggyback post to an issue Harlan has been raising about the Wow64 issue. His most recent post on the subject Wow64Node: Registry Redirection goes into detail about what Wow64 is, it’s impact on registry analysis, and contains links to great resources. After giving some thought to this issue I’m in full agreement with Harlan when he said “this is huge”. Computing is moving on from 32-bit to 64-bit platforms. I am already witnessing the transition since the majority of the systems I see running Windows 7 are 64-bit. We are entering a 64-bit world and as this transition occurs systems will run both 64-bit and 32-bit applications. This is where Wow64 comes into play and I wanted to follow up Harlan’s post with a few more examples about why we should be aware about this issue. I’m not only expanding on what Wow64 is but I’m highlighting issues with our processes and tools to demonstrate why this is an important issue.
In addition to the links provided by Harlan, the Windows Internals book contains information about Wow64. It states “Wow64 (Win32 emulation on 64-bit Windows) refers to the software that permits the execution of 32-bit x86 applications on 64-bit Windows”. Part of the emulation involves redirecting a 32-bit application in both the file system and registry.
Windows Internals states the following about file system redirection:
“To maintain application compatibility and to reduce the effort of porting applications from Win32 to 64-bit Windows, system directory were kept the same. Therefore, the \Windows\System32 folder contains native 64-bit images. Wow64, as it hooks all the system calls, translates all the path-related APIs and replaces the path name of the \Windows\System32 folder with \Windows\Syswow64. Wow64 also redirects \Windows\LastGood to \Windows\LastGood\syswow64 and \Windows\Regedit.exe to \Windows\syswow64\Regedit.exe. Through the use of system environment variables, the %PROGRAMFILES% variable is also set to \Program Files (x86) for 32-bit applications, while it is set to \Program Files folder for 64-bit applications."
The file system redirection occurs transparently when a 32-bit application tries to access the System32 or LastGood folders. Something similar happens when 32-bit applications access the registry. Windows Internals mentions:
“the registry is split into two portions: Native and Wow64. By default, 32-bit components access the 32-bit view and 64-bit components access the 64-bit view”. “To implement this, Wow64 intercepts all the system calls that open registry keys and retranslates the key path to point it to the Wow64 view of the registry. Wow64 splits the registry at these points: HKLM\Software and HKEY_CLASSES_ROOT”. “Under each of these keys, Wow64 creates a key called Wow6432Node. Under this key is stored 32-bit configuration information. All other portions of the registry are shared between 32-bit and 64-bit applications (for example, HKLM\SYSTEM)."
The Win32 emulation on 64-bit Windows impacts our DFIR work because there are now additional locations we need to know about and examine. If we don’t Christian Wojner sums up the end result when he said
“In the worst case this can lead to an entirely wrong interpretation of a case/situation”
Wow64 is one of the topics that have not been discussed extensively within our community. Harlan has been on his soapbox trying to raise awareness about its impact on our work and he provided examples how it affects registry analysis. Both Christian Wojner in his paper The “Wow-Effect” and Lenny Zelster in his post Incident Response on 64-Bit Windows Using 32-Bit Tools highlighted the impacts of file system redirection. Basically, the authors were demonstrating that an analyst may not be getting the whole picture when running 32-bit applications on a 64-bit system. The 32-bit applications were redirected to the \Windows\Syswow64 folder and were incapable of seeing the files located in the Windows\System32 folder. The “Wow-Effect” paper mentioned there are more situations and scenarios where the “Wow-Effect” can impact DFIR. He even suggested the reader could instantly come up with a lot more scenarios. I came up with a few and they impact: live, malware, and post-mortem analysis.
Both of Christian and Lenny's articles illustrated the Wow64 issue when performing live analysis. Wow64 introduces another wrinkle when performing live analysis besides running 32-bit executables on a 64-bit system. Indicators of Compromise (IOCs) are becoming more mainstream within enterprise environments. It appears more and more people are trying to leverage IOCs to determine if their organization is compromised. The wrinkle Wow64 throws into the process is on the way people use IOCs. IOCs are written by an author based on their systems and their environment. If a user downloads an IOC and runs it in their environment without knowing about the author's environment then the user may reach a false conclusion if the IOC performs a file and registry check.
There are very few public IOCs on the Internet. To illustrate my point I selected the publicly available Skyipot/Wyksol Trojan IOC. The IOC does a check on the following key:
Registry Path contains SOFTWARE\Microsoft\Windows\CurrentVersion\Run
If a user were to download this IOC and run checks against a 64-bit system they may encounter an issue and not even know about it. The Run key in the IOC is either for a 32-bit Skyipot/Wyksol Trojan on a 32-bit system or a 64-bit Skyipot/Wyksol Trojan on a 64-buit system. If a 64-bit system was infected with a 32-bit Skyipot/Wyksol Trojan then the Run key of interest will be located underneath the HKLM\ SOFTWARE\Wow6432Node. The current registry check in the Skyipot/Wyksol IOC will miss it. As more and more organizations start to use IOCs it will be critical for them to make sure they are using IOCs that are compatible with their 64-bit/32-bit environments. Otherwise the IOCs won't be as effective as they should be.
Practical Malware Analysis defines malware analysis as "the art of dissecting malware to understand how it works, how to identify it, and how to defeat or eliminate it". At times when reversing malware dynamic analysis is performed to see how the malware behaves as it executes. This is an excellent technique to identify what changes are made to the system such as file creation or registry modification. The intelligence gained by identifying these changes can be used to write IOCs, provide others will indicators to look for, or to perform checks on other systems to determine if they are infected. The Wow64 issue comes into play when doing malware analysis; both if it is done using an online service or your own platform.
Online malware analysis services provide an easy method for people to perform dynamic analysis on a piece of malware. There are numerous free online services to choose from and I randomly selected ThreatExpert. Unfortunately, a good number of these services don’t provide detailed information about the systems the malware executes on so the information they provide may not be complete. To illustrate let’s use the Wow64 issue to see what we can find out about the systems on ThreatExpert. The Run key I mentioned before (it’s also the same one Harlan mentioned) is a popular location for malware to maintain persistence on a system. Searching the ThreatExpert site shows numerous malware reports with this registry key (Google search had 10,400 results). Now let’s search for the same key but taking Wow64 into account by searching for this key.
SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Run
The Google search resulted in two hits; seriously only two hits. This demonstrates the majority of the ThreatExpert analysis is not running 32-bit malware on a 64-bit system to reveal all artifacts. ThreatExpert is not the only service where this occurs; happens at Anubis (419 Google Results vs. Zero Google Results) and antivirus sites such Symantec (8,800 Google Results vs. Zero Google Results).
Side note: to perform the Google search use the site: operator to point it at the website. My attempts to included the links to the search results didn't work.
Wow64 has the same impact on those who perform malware analysis themselves as opposed to online services. Are 32-bit malware being executed on 64-bit systems? If not, then the end result will be similar to the antivirus and automated analysis sites.
Harlan did an outstanding job highlighting the impact Wow64 has on registry analysis. There are a lot more autostart locations beneath the Wow6432Node then just the Run key. These locations are not getting parsed by numerous registry analysis tools. From open source tools to really expensive software such as the one that starts “En” and ends in “Case” (I’m running v6.X). Side note: as Harlan mentioned RegRipper is getting updated to account for Wow64. There are other important registry keys that have a 32-bit equivalent beneath Wow6432Node that has nothing to do with malware or autostart locations.
One of my initial steps in any case is to profile the system to get a better understanding about what I’m facing. One of the areas I consider when profiling is the installed software on a system. It tells me a lot about what type of data and artifacts I should expect. Harlan mentioned in a previous post how the Uninstall key beneath the Wow6432Node contained references to software not listed in the 64-bit Uninstall registry key. Well, I just looked at my system and I’m seeing the same thing. If I don’t take into account the Wow64 issue when profiling a system then I won’t see the complete picture.
Despite how the phrase is constantly misquoted: “Houston, we have a problem”. The proper quote and one that more closely resembles the Wow64 issue is “Houston, we’ve had a problem”. As in past tense, as in the problem has already occurred. The Wow64 issue is a significant problem and in the near future it will only become worse as the computing environment continues to move from the 32-bit to 64-bit world. Those of us who are aware about Wow64 can adjust to account for this when faced with 64-bit systems. Those who aren’t aware; well the misquote will apply to them. They will have a problem and it could lead them to “an entirely wrong interpretation of a case/situation.”
In closing, I wanted to say thank you to Harlan. Thanks for being consistent with trying to bring this issue to the forefront and making the community more aware about its significance.
What Is Wow64
In addition to the links provided by Harlan, the Windows Internals book contains information about Wow64. It states “Wow64 (Win32 emulation on 64-bit Windows) refers to the software that permits the execution of 32-bit x86 applications on 64-bit Windows”. Part of the emulation involves redirecting a 32-bit application in both the file system and registry.
Windows Internals states the following about file system redirection:
“To maintain application compatibility and to reduce the effort of porting applications from Win32 to 64-bit Windows, system directory were kept the same. Therefore, the \Windows\System32 folder contains native 64-bit images. Wow64, as it hooks all the system calls, translates all the path-related APIs and replaces the path name of the \Windows\System32 folder with \Windows\Syswow64. Wow64 also redirects \Windows\LastGood to \Windows\LastGood\syswow64 and \Windows\Regedit.exe to \Windows\syswow64\Regedit.exe. Through the use of system environment variables, the %PROGRAMFILES% variable is also set to \Program Files (x86) for 32-bit applications, while it is set to \Program Files folder for 64-bit applications."
The file system redirection occurs transparently when a 32-bit application tries to access the System32 or LastGood folders. Something similar happens when 32-bit applications access the registry. Windows Internals mentions:
“the registry is split into two portions: Native and Wow64. By default, 32-bit components access the 32-bit view and 64-bit components access the 64-bit view”. “To implement this, Wow64 intercepts all the system calls that open registry keys and retranslates the key path to point it to the Wow64 view of the registry. Wow64 splits the registry at these points: HKLM\Software and HKEY_CLASSES_ROOT”. “Under each of these keys, Wow64 creates a key called Wow6432Node. Under this key is stored 32-bit configuration information. All other portions of the registry are shared between 32-bit and 64-bit applications (for example, HKLM\SYSTEM)."
The Win32 emulation on 64-bit Windows impacts our DFIR work because there are now additional locations we need to know about and examine. If we don’t Christian Wojner sums up the end result when he said
“In the worst case this can lead to an entirely wrong interpretation of a case/situation”
Wow64 Impact on Our Processes and Tools
Wow64 is one of the topics that have not been discussed extensively within our community. Harlan has been on his soapbox trying to raise awareness about its impact on our work and he provided examples how it affects registry analysis. Both Christian Wojner in his paper The “Wow-Effect” and Lenny Zelster in his post Incident Response on 64-Bit Windows Using 32-Bit Tools highlighted the impacts of file system redirection. Basically, the authors were demonstrating that an analyst may not be getting the whole picture when running 32-bit applications on a 64-bit system. The 32-bit applications were redirected to the \Windows\Syswow64 folder and were incapable of seeing the files located in the Windows\System32 folder. The “Wow-Effect” paper mentioned there are more situations and scenarios where the “Wow-Effect” can impact DFIR. He even suggested the reader could instantly come up with a lot more scenarios. I came up with a few and they impact: live, malware, and post-mortem analysis.
Wow64 Impact on Live Analysis
Both of Christian and Lenny's articles illustrated the Wow64 issue when performing live analysis. Wow64 introduces another wrinkle when performing live analysis besides running 32-bit executables on a 64-bit system. Indicators of Compromise (IOCs) are becoming more mainstream within enterprise environments. It appears more and more people are trying to leverage IOCs to determine if their organization is compromised. The wrinkle Wow64 throws into the process is on the way people use IOCs. IOCs are written by an author based on their systems and their environment. If a user downloads an IOC and runs it in their environment without knowing about the author's environment then the user may reach a false conclusion if the IOC performs a file and registry check.
There are very few public IOCs on the Internet. To illustrate my point I selected the publicly available Skyipot/Wyksol Trojan IOC. The IOC does a check on the following key:
Registry Path contains SOFTWARE\Microsoft\Windows\CurrentVersion\Run
If a user were to download this IOC and run checks against a 64-bit system they may encounter an issue and not even know about it. The Run key in the IOC is either for a 32-bit Skyipot/Wyksol Trojan on a 32-bit system or a 64-bit Skyipot/Wyksol Trojan on a 64-buit system. If a 64-bit system was infected with a 32-bit Skyipot/Wyksol Trojan then the Run key of interest will be located underneath the HKLM\ SOFTWARE\Wow6432Node. The current registry check in the Skyipot/Wyksol IOC will miss it. As more and more organizations start to use IOCs it will be critical for them to make sure they are using IOCs that are compatible with their 64-bit/32-bit environments. Otherwise the IOCs won't be as effective as they should be.
Wow64 Impact on Malware Analysis
Practical Malware Analysis defines malware analysis as "the art of dissecting malware to understand how it works, how to identify it, and how to defeat or eliminate it". At times when reversing malware dynamic analysis is performed to see how the malware behaves as it executes. This is an excellent technique to identify what changes are made to the system such as file creation or registry modification. The intelligence gained by identifying these changes can be used to write IOCs, provide others will indicators to look for, or to perform checks on other systems to determine if they are infected. The Wow64 issue comes into play when doing malware analysis; both if it is done using an online service or your own platform.
Online malware analysis services provide an easy method for people to perform dynamic analysis on a piece of malware. There are numerous free online services to choose from and I randomly selected ThreatExpert. Unfortunately, a good number of these services don’t provide detailed information about the systems the malware executes on so the information they provide may not be complete. To illustrate let’s use the Wow64 issue to see what we can find out about the systems on ThreatExpert. The Run key I mentioned before (it’s also the same one Harlan mentioned) is a popular location for malware to maintain persistence on a system. Searching the ThreatExpert site shows numerous malware reports with this registry key (Google search had 10,400 results). Now let’s search for the same key but taking Wow64 into account by searching for this key.
SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Run
The Google search resulted in two hits; seriously only two hits. This demonstrates the majority of the ThreatExpert analysis is not running 32-bit malware on a 64-bit system to reveal all artifacts. ThreatExpert is not the only service where this occurs; happens at Anubis (419 Google Results vs. Zero Google Results) and antivirus sites such Symantec (8,800 Google Results vs. Zero Google Results).
Side note: to perform the Google search use the site: operator to point it at the website. My attempts to included the links to the search results didn't work.
Wow64 has the same impact on those who perform malware analysis themselves as opposed to online services. Are 32-bit malware being executed on 64-bit systems? If not, then the end result will be similar to the antivirus and automated analysis sites.
Wow64 Impact on Post-mortem Analysis
Harlan did an outstanding job highlighting the impact Wow64 has on registry analysis. There are a lot more autostart locations beneath the Wow6432Node then just the Run key. These locations are not getting parsed by numerous registry analysis tools. From open source tools to really expensive software such as the one that starts “En” and ends in “Case” (I’m running v6.X). Side note: as Harlan mentioned RegRipper is getting updated to account for Wow64. There are other important registry keys that have a 32-bit equivalent beneath Wow6432Node that has nothing to do with malware or autostart locations.
One of my initial steps in any case is to profile the system to get a better understanding about what I’m facing. One of the areas I consider when profiling is the installed software on a system. It tells me a lot about what type of data and artifacts I should expect. Harlan mentioned in a previous post how the Uninstall key beneath the Wow6432Node contained references to software not listed in the 64-bit Uninstall registry key. Well, I just looked at my system and I’m seeing the same thing. If I don’t take into account the Wow64 issue when profiling a system then I won’t see the complete picture.
Summary
Despite how the phrase is constantly misquoted: “Houston, we have a problem”. The proper quote and one that more closely resembles the Wow64 issue is “Houston, we’ve had a problem”. As in past tense, as in the problem has already occurred. The Wow64 issue is a significant problem and in the near future it will only become worse as the computing environment continues to move from the 32-bit to 64-bit world. Those of us who are aware about Wow64 can adjust to account for this when faced with 64-bit systems. Those who aren’t aware; well the misquote will apply to them. They will have a problem and it could lead them to “an entirely wrong interpretation of a case/situation.”
In closing, I wanted to say thank you to Harlan. Thanks for being consistent with trying to bring this issue to the forefront and making the community more aware about its significance.
Labels:
malware,
malware analysis,
registry,
regripper
Posts
Corey,
As always, awesome post!
I think that you hit a couple of nails squarely on the head...in particular, regarding online resources. With no identification of the testing platform, the assumption becomes malware writes to a particular key or file path. Look at Beth's presentation at the SANS Summit last year...she culled an AV vendor's web site, and I don't remember her ever seeing "Wow6432Node"...
Good post - it gives the topic once more some attention.
Last year I gave about 9 presentations about the "WOW-Effect" at security conferences all around the world. Everytime it was absolutely new stuff to most of the people in the audience.
Because of your post I decided to upload my presentation slides to our website (you can download the slides here: http://www.cert.at/static/downloads/papers/cert.at-the_wow_effect_the_whole_dimension-slides.pdf) so that everyone has access to my full investigation on that topic. I tried to cover every aspect one might find necessary on this.
In some weeks my last presentation of my "WOW-Effect" tour last year will be available as video recordings (thx to the folks of Deepsec). You will find a link to that video at our website (http://www.cert.at/downloads/papers/wow_effect_en.html).
So, be aware of the "WOW-Effect"! :-)
Cheers,
Christian Wojner.
@Christian,
Thanks for uploading the material and sharing the links. I think you have done an outstanding job highlighting the Wow64 issue. In your slide deck I really like how you broke down what gets redirected in both the registry and filesystem.
@Corey,
thx for your kind words. I'm glad you like it.
I'm finding "wow64" being registered in the CS(User-Agent) when the User is running on a 32-bit OS and the Server is Windows Server 2003 R2 SP2, but not all the time.
For my personal User-Agent, it does not record "WOW64" when it also records either "GTB7.4" or "AskTbORJ/". I thought they might represent some clues.
Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+6.1;+WOW64;+Trident/4.0;+SLCC2;+.NET+CLR+2.0.50727;+.NET+CLR+3.5.30729;+.NET+CLR+3.0.30729;+Media+Center+PC+6.0;+.NET4.0C;+.NET4.0E;+InfoPath.2)
Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+6.1;+Trident/4.0;+GTB7.4;+SLCC2;+.NET+CLR+2.0.50727;+.NET+CLR+3.5.30729;+.NET+CLR+3.0.30729;+Media+Center+PC+6.0;+.NET4.0C;+.NET4.0E;+InfoPath.2;+Tablet+PC+2.0;+MS-RTC+LM+8)
Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+6.1;+Trident/4.0;+GTB7.4;+SLCC2;+.NET+CLR+2.0.50727;+.NET+CLR+3.5.30729;+.NET+CLR+3.0.30729;+Media+Center+PC+6.0;+.NET4.0C;+.NET4.0E;+InfoPath.2;+Tablet+PC+2.0;+MS-RTC+LM+8;+AskTbORJ/5.15.14.29495)
Okay, I a little late to the conversation. But I have recently noted the WOW64 popping up briefly during start up. About the same time, I seem to have picked up some malware which I CANNOT get rid of, I have scanned my computer with three programs one of them being Norton 360.
How do you protect yourself or find and get rid of it, without getting rid of Wow64? Can you somehow turn Wow64 off, scan for viruses? Any ideas, I would be greatful.
K
@Kira,
Wow64 is a feature of Windows and can't be removed. This convo might be better by email. My contact information is on my about page. Send me an email and we can discuss.