Category Archives: Compromise Detection

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

PsExec going places…

Posted on by

Update 2018-07-19

Today I came across an old post from @mbromileyDFIR who wrote about it in 2016 so adding link as it’s a good article explaining forensic artifacts associated with running psexec

Old Post

As a threat hunter you surely know that PSEXESVC.EXE is one of these nice signature-friendly artifacts that you will want to catch with your process/service creation rules. It’s one of the easiest way to spot the lateral movement.

Unfortunately, there is a catch.

You see, for a number of years now the psexec has that nice command line argument ‘-r’ that allows you to create a service name as per your liking; this affects the artifacts it creates on the remote system.

You can test it by running the following command:

PsExec.exe -r foobar \\localhost cmd.exe

The tool will drop c:\WINDOWS\foobar.exe and will start the service called ‘foobar’:

The flag will cause the named pipes used by Psexec (-stdin, -stdout and -stderr) to be renamed as well (I forgot to mention it in the original post, thx to @spinning_monkey for reminding me).

I guess the original idea behind the introduction of this flag was to allow multiple psexec versions (or instances) to co-exist on the remote system, but the side-effect is that you can’t detect psexec being present by relying on just a service / file name only.