Category Archives: Incident Response

Reusigned Binaries – Living off the signed land, Part 2

Posted on by

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.

Yet another way to hide from Sysinternals’ tools

Posted on by

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’.