Breaking download for breaking purposes

Posted on by

This is a thought experiment only – it occurred to me that a number of available hacked sites that malware authors use for the purpose of payload delivery is making the the infection process not only easy and resilient. It also makes it easy to deliver a fragmented download mechanism that is similar to P2P technology and one that could potentially affect a number of security solutions.

Imagine having 2 or more hacked web sites – each of them hosting segments of the final deliverable e.g. it could be in a form of odd and even bytes, sectors, clusters, or the payload broken into pieces using some fancy, customized algorithm. The moment the malware loader (e.g. Office macro) is executed, it could download these pieces from various places and reassemble them on the host. Since they will be coming from different web sites, they will be different network streams associated with these downloads and as such every single security solution put in place will fail to detect an executable as a whole. This will therefore break the IDS, IPS, inline proxy, inline sandbox, the on-host EDR and AV, and whatever else is inspecting the network traffic, and in some cases – files.

There is also another angle to it; not having plain-vanilla .exe residing on hacked servers will make it harder to detect them – since they are just fragments of the final payload – no security solution will detect them as executables, hence they can escape .yara scans, etc. (file integrity monitors is a different story).

Obviously, one could simply encrypt the payload, or even encode it, but this is not the point here – many malicious samples still download pure vanilla .exes and they come from a single location.

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 🙂