Category Archives: Autostart (Persistence)

Beyond good ol’ Run key, Part 19

Posted on by

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.

procexp

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 🙂

Beyond good ol’ Run key, Part 18

Posted on by

If you hear legitimate & legacy in the same sentence then it is – most likely – not a good news.

The not-so-known persistence mechanisms that have a reason to be there are quite interesting, because they are often obscure and long forgotten. And while left unknown to a general public they may be still heavily utilized for legitimate purposes even if just by a niche group of people.

Maybe that’s why the mechanism I am going to describe survived such a long journey from Windows NT to Windows 10 Preview…

I am talking about Logon Scripts.

There is not much online about their internals. The best I could find was this post:

Logon scripts (both GPO and user) are actually handled by USERINIT.EXE.  If I recall correctly, the user logon script is handled by the same instance of USERINIT.EXE that starts the desktop instance of EXPLORER.EXE (i.e. the one that would be spawned from gina!WlxActivateUserShell), whereas the domain GPO scripts are executed by separate instances of USERINIT.EXE which are requested to be spawned by WINLOGON.EXE via gina!WlxStartApplication.

The easy way to screw up the execution of these login scripts (i.e. works fine with MSGINA so I know the configuration is right, but with my replacement GINA installed they no longer run) would be to miss including the expected environment variables that WINLOGON was trying to impart to the spawned instances of USERINIT.EXE, since its via environment variables that the intention for USERINIT.EXE to run a particular script is commuicated.

Be sure you’re building an environment block that includes all the environment specified in the pEnvironment parameter to the Wlx functions cited.  In the case of GPO scripts you’re looking for an envrionment variable such as “UserInitGPOScriptType”, and “UserInitMprLogonScript” is the environment varibale WlxActivateUserShell is expected to create with the pszMprLogonScript parameter string’s contents.

The funny fact is that userinit.exe is relying on environment variables and these can be always abused – this makes it easy to quickly set up a simple persistence mechanism by using the Registry Environment keys.

There are 3 environment variables the mechanism relies on:

  • A pair of UserInitLogonServer & UserInitLogonScript identifying where to run script from; first one identifies the server, the second location
  • UserInitMprLogonScript – this one is a simple path to a script; there may be more than one; MPR stands for Multiple Provider Router

That’s it.

Setting up the HKEY_CURRENT_USER\Environment variables and dropping scripts in an appropriate location is enough to pull this off.

To test the UserInitMprLogonScript setting:

  • Save the following file as c:\test\UserInitMprLogonScriptlog.bat
@echo off             
@echo # 'UserInitMprLogonScript' 
@if exist c:\test\UserInitMprLogonScript.log @del c:\test\UserInitMprLogonScript.log
@echo UserInitMprLogonScript executed !> c:\test\UserInitMprLogonScript.log
@pause
  • Add the following Registry Entry
Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Environment]
"UserInitMprLogonScript"="c:\\test\\UserInitMprLogonScript.bat"

Once you log off and log on again you should see the script running, and if it is not shown in a dedicated terminal window (e.g. in case of Windows 10 Preview) you can confirm it did execute by checking if the file c:\test\UserInitMprLogonScript.log exists.