In my last post I mentioned Sysinternals. While combining the info for that post I came across a few things that gave me enough material to write a #19 in the series.
And it’s based on bugs in Sysinternals’ tools. Bugs that can be spotted easily. Today I’ll explain how you can utilize these bugs to create new persistent mechanisms.
Say, you like Process Explorer.
Nowadays 64-bit systems are very popular so running procexp.exe on a 64-bit system ends up with a procexp.exe dropping its 64-bit version into a %TEMP% folder and launching it.
Now, what you can do is f.ex. copy your notepad.exe to %TEMP% and name it procexp64.exe. Then you need to set up 2 access rights for everyone:
- One that forbids deleting %temp%\procexp64.exe (on the file itself)
- One that forbids deleting subfolders and files inside %TEMP% (on the %TEMP% folder); this is btw. one of the WTFs of NTFS system where prohibiting deletion of the files needs to be extended to its parent folder; there must be some reasons for that, but it is not something you can learn about from a cryptic Security Properties tab
From now on, launching procexp.exe on a 64-bit system will always launch notepad.exe. A nice man-in-the-middle attack especially if the malicious notepad.exe actually does spawn the legitimate procexp64.exe and hides its presence somehow from the Process Explorer GUI.
Of course blocking %TEMP% from deletion is a silly idea, but:
- it is an example only
- it actually works
- there are many other ways to prevent deletion of the procexp64.exe by procexp.exe (on exit), or at least ensure the malicious procexp64.exe is restored after it is being deleted
Another bug I spotted was the way vmmap.exe craves for dbghelp.dll.
VMMAP is not a very popular program and I bet not too many people use it daily, but the way it works requires a special attention; it’s an example of a difference between programming for your own use vs. programming for ‘public’. As a non-professional programmer who writes buggy programs every day I am actually quite surprised by it. Yes, it’s that buggy.
Let me elaborate.
VMMAP has a very peculiar way for searching for dbghelp.dll:
First, it searches for the entry in the Registry:
- HKCU\Software\Sysinternals\VMMap\DbgHelpPath32 = <path to dbghelp.dll>
- #persistence #1
- By modifying HKCU\Software\Sysinternals\VMMap\DbgHelpPath32 to point to a malicious DLL we can ensure that DLL is loaded every time VMMAP is launched
If it is not found, VMMAP goes ballistic (#persistence #2..N).
It calls a LoadLibraryW with a NULL which is a (sort of) result of retrieving data from a non-existing HKCU\Software\Sysinternals\VMMap\DbgHelpPath32 value.
This is when things get crazy. The craving goes totally addictive.
NULL is a Pandora’s box (Or’ Pandor’s since the author is a male) open for LoadLibraryW.
It means it will walk through every directory listed in the PATH environment variable and will attempt to load a library called ‘.dll’ from every single directory on that list.
Yes, ‘.dll’ is a valid library name i.e. a NULL with a ‘.dll’ extension.
So, you can place a DLL called “.dll” in any location that is covered by a PATH environment variable and you will have it launched by VMMAP anytime it starts.
You probably want to hear that this is the end of the story.
Not quite so.
There are still a few places to look at:
- C:\Program Files\Debugging Tools for Windows (x86)\dbghelp.dll
- C:\Program Files\Debugging Tools for Windows\dbghelp.dll
- C:\Debuggers\dbghelp.dll
Dropping a dbghelp.dll in the …
yawnz…
you know the drill 🙂