Two days ago this tweet from vxunderground saw the light:
Being a redteamer this obviously peaked my interest, as evading EDRs is kinda what I do for a living. The whole whitepaper is very interesting but for the sake of this blogpost I want to focus on is the fact that according to the paper DLL hijacking still circumvents a lot of EDR’s.
I feel, from experience, that this very much aligns with what I have been seeing during operations as well. It is due to this article though, that I started thinking about operational security considerations that could (and should) be taken when doing this kind of attack, I actually wrote a blogpost about it earlier here:
I started looking at available tooling and I quickly encountered a familiar name on GitHub – Joe Vest.
For those of you that are not aware, Joe has taken over Raphael Mudge’s place as lead for Cobalt-Strike. He developed a PowerShell script called metatwin that utilizes Resource Hacker in the backend to copy metadata from one binary onto another. It can also copy signatures of these binaries (obviously invalidating them in the process) using SigThief.
Pretty neat!
Another cool project that is often used in DLL Hijacking attacks is called Koppeling by Nick Landers (monoxgas). The cool thing about Koppeling is that it can clone export tables of DLL’s onto other DLL’s AFTER compilation.
This means that you don’t have to recompile your malicious DLL over and over, resolving export forwards.
These two projects are awesome, and provide decent opsec when combined, so I merely glued them together in Invoke-DLLClone.
As a final quality of life feature, I also included my own LazySign project to provide user the option to not just clone signatures, but fake sign binaries with whatever companyname they desire (obviously, these signatures will not be valid though).
%localappdata% AKA the stupidest folder ever.
One of the primary reasons DLL search order hijacking is so darn effective, is because some software gets installed in %localappdata%. COINCIDENTALLY, most of this software is used for web communications (teams,discord,slack,webex,ondedrive).
Fun fact, localappdata is… user writeable. What could possibly go wrong….
Let’s find out, shall we?
Let’s fire up discord with procmon attached to the sucker.
Immediately we get flooded with output (open image in a new tab for readability):
Applications look for their dependencies in their current folder first, there is a whole search order that has been explained on countless other blogs about this topic. Take a pick of a DLL that is not found. In this example use-case I chose powrprof.dll
Note: always TEST your candidate DLL. Not all DLLs work!
Now all we need to do is create a DLL that avoids Loader Deadlock. An interesting project that can help with that is slaeryan’s aquarmory template. Or Vivek’s template
Freshly compiled your DLL probably kinda looks a little bit like this:
Which looks quite a bit different to this…
How can we fix this problem? Well easy!
Once you have your malicious payload DLL compiled we can use Invoke-DLLCopy using C:\Windows\System32\PROPSYS.dll as a source and our evil.dll (in this case totallylegitpropsys.dll) as a target.
Note, discord is a 32 bit application on my system, so I will take the powrprof.dll in SYSWOW64 instead of the one in system32.
Invoke-DllClone -Source C:\Windows\SysWOW64\powrprof.dll -Target C:\Users\Jean\source\repos\SideLoadInjector\Release\totallylegitpowrprof.dll -Output powrprof.dll -SignA new folder in the Invoke-DLL Directory will be created containing both a signed and unsigned copy of your totallylegitpropsys.dll (which now is called propsys.dll and signed_propsys.dll)
Looking good!
Shells, Shells everywhere
Now all we have to do is drop our new powrprof.dll in the discord directory we identified earlier and restart discord. and ….
Shells LITTERALY everywhere.
If you implement this technique, implement logic to only execute your malicious thread once, how to do that…. is an exercise to the reader 😉
Be First to Comment