Yet another way to hide from Sysinternals’ tools, part 1.5

This little trick can be used to prank your friend more than using it as a real nation-state pwning technique, but it’s worth documenting, as usual, so here it goes…

I mentioned previously the Autoruns program registers the file type HKCR\Autoruns.Logfile.1  / HKCR\.ARN. The file stores the information autoruns grabbed from the system. You can save the autoruns log, and you can load them.

The last bit is the interesting part – if we can force the system to redirect all autoruns instances to one we can control, and also one that will always load the preserved data from the .arn file (instead of loading the fresh data set directly from the system), we will be able to fool the user that the state of the system has not changed.

So… the recipe goes like this:

  • Remove HKCR\Autoruns.Logfile.1 and HKCR\.ARN registry entries
  • Save autoruns.exe as e.g. c:\test\AutoNOruns.exe
  • Run c:\test\AutoNOruns.exe
    • This will create new association for .ARN file in Registry (ones that point to c:\test\AutoNOruns.exe)
    • This will also enumerate all autoruns entries on the system
      • Save these results to e.g. c:\test\AutoNOruns.arn
  • Modify registry key
    HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\
    App Paths\autoruns.exe
    to point to
    c:\test\AutoNOruns.arn
  • Add some ‘bad’ entry to e.g. HKCU\Run
  • Run autoruns from the terminal, or via Windows+R
  • The new ‘bad’ entry won’t be shown.

Caveats:

  • It takes observable time to load c:\test\AutoNOruns.arn
  • Refreshing the view (F5) will unhide all the ‘hidden’ entries as Autoruns will refresh the view directly from the system
  • Double-clicking autoruns.exe is not routed via App Paths key so autoruns.exe will run properly

So, there you have it. The first Autoruns Rootkit ;)))

It’s superlame and has so many caveats that it’s impossible to treat it seriously, but maybe you will be able to fool someone 🙂

Yet another way to hide from Sysinternals’ tools

The recipe is simple:

  • Pick up one of the environment variables.
  • Name your executable as ‘%environment variable%.exe’
  • Drop it in a place where system will find it (as per PATH)
  • Set e.g. Run key to point to it.

Example:

  • Drop c:\WINDOWS\%USERNAME%.exe

And add:

  • HKCU\Software\Microsoft\Windows\CurrentVersion\Run
    “foobar”=”%USERNAME%”

Both Autoruns and Process Explorer (autorun location) won’t be able to locate the file, because they expand the environment variables. They will also mislead the user by showing a path to an executable that is definitely not on the system e.g. if the user’s name is JOHN, the entry I listed above will show up as ‘File not found: john.exe’. Looking for ‘john.exe’ on the system will not bring any relevant results.

Bonus #1:

You could concatenate a number of environment variables – the file will run, but the entry in the Autoruns will look like a bug. Only visiting the actual entry in the Registry will allow you to spot the trick.

Bonus #2:

Using less common environment variables can give even more random misleading information eg. ‘%PROCESSOR_LEVEL%’ can resolve to ‘6.exe’. Finding that ‘6.exe’ on the system will be pretty tricky.

Bonus #3:

Using ‘%ComSpec%’ gives the most intriguing result.

Autoruns will resolve it to ‘c:\WINDOWS\System32\cmd.exe’ instead of ‘c:\WINDOWS\%ComSpec%.exe’ and… since the resolved binary is native OS signed executable… it will be hidden from the view, unless you Unhide the ‘Hide Windows Entries’.