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 🙂

Reusigned Binaries – Living off the signed land, Part 2

Signed binaries can be used to do a lot of funny, unexpected stuff – today I will cover a simple proxy execution technique that can be used as a possible EDR evasion, and who knows, perhaps could throw some sandboxes off as well.

For a quick demo I chose Autoruns as a culprit, because it’s popular, but bear in mind that it can be any application really that registers its own file type in the Registry.

So…

When you run the Autoruns program it will, apart from showing you the startup entries, register a file type .ARN:

HKCR\.ARN

that points to

HKCR\Autoruns.Logfile.1

which tells the system how to open the file:

HKCR\Autoruns.Logfile.1\shell\open\command=

"<PATH>\Autoruns.exe" "%1"

Since the entry is created using a signed binary, one could drop autoruns on the system, and execute it (GUI is not such a big deal as it could be either partially, or fully hidden e.g. using ‘start /min’, launching on a different desktop, etc.).

One could now replace the autoruns in the path where it was executed from with the malicious autoruns.exe, create a dummy foo.arn file, and

  • launch the foo.arn file – this will execute the payload
  • add the foo.arn file to e.g. Run key; since the file is non-malicious, it won’t trigger an alert from a typical AV; next time the user logs in, the dummy .arn file will be ‘opened’ i.e. launched via Explorer leading to malicious autoruns.exe being executed (Update: I recently learnt that Kovter is using similar trick since at least 2016)

It is really trivial, but as I explained in the first post in this series, the idea is to delegate atomic actions, especially ones that are easy to spot by monitors, to signed binaries. Combining various functional bits and bobs offered by various tools one can build a decent chain of commands that will hide, or at least obfuscate the real purpose of the whole activity.