Process file name spoofing/faking by memory modification

Since the people at the Process Explorer forums don’t really care about this issue, I’m posting it here.

The problem: processes can fake their own file location. This was originally discovered in 2006, but almost no one knew/knows about it. Task managers and security tools often rely on the file names of processes to determine their security risk – through online ratings, file signature verifications, or hashing. The problem is that this information is stored in processes’ memory¹ – which they are free to modify. I’ve tested several process managers/security tools, and an alarming number^TM are vulnerable. You can download the test program.

Operating system: Windows XP
Tested programs (in no particular order):

• Windows Task Manager
• AnVir Task Manager (not the pro version, but I highly doubt it would make any difference)
• HijackFree
• MKN Task Explorer
• PrcView
• Process Explorer
• Process Hacker
• Security Task Manager
• File.net Windows Process Viewer

As you can see, I have renamed the test executable to smss.exe and asked it to disguise itself as the Windows Session Manager (located at C:\Windows\system32\smss.exe). If at any point you think I am faking my screenshots, you can look at the username of my test program – the real session manager always runs under NT AUTHORITY\SYSTEM.

Windows Task Manager

This isn’t unusual; task manager on XP always refuses to end processes which have the name of a critical system process. This has often been exploited by malware authors in the past. The important thing to note is that Windows Task Manager on Windows Vista can show the file names of processes and is not affected by the file name spoofing exploit.

AnVir Task Manager

This program was very disappointing – not only was the user interface extremely ugly and bloated, it actually got fooled by my test program. There were no warnings about the fact that a system process was running under a normal user account, and it told me my test program was “CRITICAL SYSTEM!!!”. This wouldn’t be bad if the program was non-commercial or free software, but it’s nagware and keeps on telling me to “Update to AnVir Task Manager Pro”.

MKN Task Manager

The installer for this program was named “MKN_TaskExplorer_Tryout_Setup.exe”, but there doesn’t seem to be any place I can enter a registration key. I’ll assume it’s freeware. This program gets fooled as well. Interestingly, the process properties window states that my test program has no parent process. Even AnVir Task Manager knew that my test program was started by the Command Prompt. I guess the developers hardcoded a list of processes-to-not-display-parents-for.

PrcView

PrcView is better than the previous two programs in that instead of pretending to know the file name of my test program, it simply fails. The reason for this is that when any program tries to enumerate the modules of my test program, they will find that the main module’s file name is blank (see Process Explorer’s module list below). This is just an interesting side-effect – my program doesn’t actually try to erase it.

HijackFree

Same as above.

Process Explorer

The really bad thing about Process Explorer failing the test is that people often use it to verify the signatures of executables.

Process Hacker

I wrote this program, so I just had to include it here.

Security Task Manager

Security Task Manager also fails to get the test program’s file name. Wait… “Probably system process without file”. Uh… how is a system process supposed to run without a file? I highly doubt the Windows kernel would create a new system process filled with vacuum and then assemble all the code in memory…

File.net Windows Process Viewer

Fails to get the test program’s file name.

Conclusion

So, you ask, what is the correct way to get a process’ file name? Let’s go through what programs usually do to get the file names of processes:

• Some programs use the toolhelp32 functions. This is vulnerable to file name spoofing.
• Some programs (and the .NET Framework) use the file name of the main module. This method gives you blank file names as you saw earlier. Note that this is because my test program erases the original string in order to prevent tools from discovering the real file name. Real malware may not be that nice and may simply overwrite the original string!
• Some programs use QueryFullProcessImageName, which is not vulnerable to the exploit. However, it only works on Windows Vista.
• The best way is to use the (undocumented) function NtQueryInformationProcess with ProcessImageFileName (27, or 0x1b). This gives you the file name in native format, so you’ll have to do some extra work to convert it to DOS format. On Windows Vista, there is a new information class named ProcessImageFileNameWin32 (43, or 0x2b) which gives you the file name in DOS format. This is what QueryFullProcessImageName calls.

Notes

¹ – in RTL_USER_PROCESS_PARAMETERS which is referenced by the PEB. See the excellent NT Internals website for more details.