( Original text by hexacorn )
I love evasion tricks of any sort. Sometimes they can be very elaborate, and sometimes… incredibly trivial, almost stupid really. Such is the trick I am describing below. It works on 32-bit Windows only, and that’s because it relies on a folder structure that is (exclusively) present on 64-bit systems.
If we look at logs from various process monitoring tools we can notice that they omit a very important info. They don’t tell us what is the architecture of the logging system. Unless it is somehow self-evident (e.g. ‘bitness’ is a part of a host naming convention) there is no way to tell whether the process is executed on a 32- or 64- box.
These 3 folders are present on 64-bit systems only:
- c:\windows\syswow64\
- c:\windows\sysnative\
- c:\Program Files (x86)\
Nothing (apart from access rights) stops us from re-creating them on a 32-bit system.
Imagine seeing the following logs indicating that calc.exe or iexplore.exe was launched on a system:
- c:\windows\syswow64\calc.exe – from a 64-bit system
- c:\windows\syswow64\calc.exe – from a 32-bit system
- c:\windows\sysnative\calc.exe – from a 64-bit system
- c:\windows\sysnative\calc.exe – from a 32-bit system
- c:\Program Files (x86)\Internet Explorer\iexplore.exe – from a 64-bit system
- c:\Program Files (x86)\Internet Explorer\iexplore.exe – from a 32-bit system
For all logs from 32-bit systems it’s obvious that they are fake.
How can you tell the difference though if your logs don’t tell you the architecture of the system where they come from?
This opens up a lot of opportunities for an impersonation.
Threat hunting efforts that rely on full paths for analysis purposes (whitelisting, LFO, etc.) could be easily fooled to accidentally exclude, or include bad processes that are executed from locations that pretend to be ’64-bit legitimate’.
And since most of the orgs are mixed 32/64 environments, the logs from all systems will be inevitably clustered together, and detection rules will be applied to them as a whole.
Admittedly, a malicious svchost.exe executed from c:\windows\syswow64\svchost.exe is definitely less suspicious than one starting from %APPDATA%:
Now, could this be a bad process?
- c:\Program Files (x86)\Windows Defender\MpCmdRun.exe