You are browsing the archive for Random ideas.

PROPagate follow-up – Some more Shattering Attack Potentials

November 7, 2017 in Anti-*, Code Injection, Malware Analysis, Random ideas

We now know that one can use SetProp to execute a shellcode inside 32- and 64-bit applications as long as they use windows that are subclassed.

There are more possibilities.

While SetWindowLong/SetWindowLongPtr/SetClassLong/SetClassLongPtr are all protected and can be only used on windows belonging to the same process, the very old APIs SetWindowWord and SetClassWord … are not.

As usual, I tested it enumerating windows running a 32-bit application on a 64-bit system and setting properties to unpredictable values and observing what happens.

It turns out that again, pretty much all my Window applications crashed on Window 10. These 16 bits seem to be quite powerful…

I am not a vulnerability researcher, but I bet we can still do something interesting; I will continue poking around. The easy wins I see are similar to SetProp e.g. GWL_USERDATA may point to some virtual tables/pointers; the DWL_USER – as per Microsoft – ‘sets new extra information that is private to the application, such as handles or pointers’. Assuming that we may only modify 16 bit of e.g. some offset, redirecting it to some code cave or overwriting unused part of memory within close proximity of the original offset could allow for a successful exploit.

 

Breaking download for breaking purposes

November 6, 2017 in Random ideas

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.