Category Archives: EDR

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.

PROPagate – a new code injection trick – 64-bit and 32-bit

Posted on by

I have recently discovered a new trick that allows to execute code in other processes without using remote threads, APC, etc. While describing it, I focused only on 32-bit architecture. One may wonder whether there is a way for it to work on 64-bit systems and even more interestingly – whether there is a possibility to inject/run code between 32- and 64- bit processes.

To test it, I checked my 32-bit code injector on a 64-bit box. It crashed my 64-bit Explorer.exe process in no time.

So, yes, we can change properties of windows belonging to 64-bit processes from a 32-bit process! And yes, you can swap the subclass properties I described previously to point to your injected buffer and eventually make the payload execute! The reason it works is that original property addresses are stored in lower 32-bit of the 64-bit offset. Replacing that lower 32-bit part of the offset to point to a newly allocated buffer (also in lower area of the memory, thanks to VirtualAllocEx) is enough to trigger the code execution.

See below the GetProp inside explorer.exe retrieving the subclassed property:

So, there you have it… 32 process injecting into 64-bit process and executing the payload w/o heaven’s gate or using other undocumented tricks.

The below is the moment the 64-bit shellcode is executed:

p.s. the structure of the subclassed callbacks is slightly different inside 64-bit processes due to 64-bit offsets, but again, I don’t want to make it any easier to bad guys than it should be 🙂