Category Archives: Forensic Analysis

Beyond good ol’ Run key, Part 69

Posted on by

This is just a quick post to highlight a possibility of abusing yet another configuration setting for persistence reasons. It’s not really a lot of trickery at work – it’s actually a legitimate feature documented by Microsoft and which allows to change the way executable manifests are loaded.

By changing the registry key:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\SideBySide
"PreferExternalManifest"=dword:00000001

– the system will start using an external .manifest file for the executables, if such .manifest files exists. Modification of such external .manifest allows to load malicious component (DLL side-loading via Side by Side /SxS/).

While googling around about this setting I came across these posts that highlight issues that you may come across when this setting is changed and the Windows Sxs Activation Context Cache is not refreshed (the settings and external manifest will be ignored until you force the cache refresh by manipulating the timestamps):

 

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.