You are browsing the archive for EDR.

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

November 3, 2017 in Anti-*, Code Injection, Compromise Detection, EDR, Incident Response, Malware Analysis

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 🙂


Running programs via Proxy & jumping on a EDR-bypass trampoline, Part 4

October 29, 2017 in Anti-Forensics, Compromise Detection, EDR, Forensic Analysis, Incident Response, Living off the land, Malware Analysis, Sideloading

Here’s yet another subclass of tricks one can use to distort the process tree seen by EDR and sandbox solutions.

Many Windows programs launch other internal Windows programs (native to OS). They do so carefully so they typically launch them from %SystemRoot%. Many of them use GetSystemDirectory to build a path, but there are still quite a few that rely on an environment variable – they need to use an ExpandEnvironmentStrings API to obtain the actual path.

Changing that environmental variable and copying the required files to a redirected location while replacing the target application enables us to launch a payload of choice making it look like it was executed by a signed binary.


In this old post I mentioned AtBroker. When you launch it from a command line without any arguments it will simply launch Narrator.exe.

We can:

  • create a test folder
  • change the SystemRoot to point to it
  • copy all the necessary files from the original system32 and Registration folder (procmon helps)
  • launch atbroker.exe
  • the narrator.exe payload will be executed

This launches C:\Test\System32\Narrator.exe: