Haxilio.com

My journey on becoming a hacker

Grandpa Hackthebox-WriteUp

Introduction

After we hacked poor old Granny already, now it’s time for Grandpa from hackthebox as well.

Write-Up

This box is very similar to Granny. The main difference is, that the we do not have write-access to WebDAV. Luckily, there is a vulnerability in IIS 6, which we could’ve used for Granny as well. In case, your not familiar with WebDAV, hop over to my Write-Up on Granny, where I explain the most important details at the end.

But for now, let’s do Grandpa (without cheating ;))

Here is what we’ll do:

Walkthrough

Enumeration

First of all, as always, let’s nmap the target to figure out, what our attack-surface looks like:

On the fist glance, it seems like we have write access to the server, again. But this time, we can’t confirm this with davtest:

Seems like, we need to figure out another way in. A quick search on the web suggests that IIS 6, the webserver in use might be vulnerable to a buffer-overflow which grants a shell. Let’s try that.

Gaining a Foothold

And in fact, opening metasploit, setting the proper options and executing the script, gives us a really simple way in:

Aaaaand we’re in. Onto the next stage to become root (or rather NT/AUTHORITY System, since this is a windows box).

Privilege Escalation

Basically, we can use the same exploit for the privilege escalation, that we used to Granny as well. But we have to take an extra step. (I’m not covering the failed attempt here). Just executing the exploit will fail due to missing rights. Let’s try migrating our meterpreter-session into another process and try that again (more information on what we technically do and why that helps: look down below).

Now, we can try to run the exploit again:

Aaaand we’re root. Congratulations!

If you’re already familiar with process-migration in metasploit and know what it is/how it works, I hope you have a great day and Happy Hacking!

If you want to learn something more, read ahead:

Metasploit Process-Migration

The following explanation is based on this great blog-post and stackoverflow-knowledge. Basically, when we open a meterpreter-reverse-shell on our victim’s computer, this computer has to spin up a process to execute the payload. For various reasons this process might not be optimal, which is why we might want to migrate into another process

Reasons to migrate the process

First of all, this new process might not be very stable. An automated job or an attentive admin might spot an unexpected process and shut down our shell. If we migrated into another process, spotting meterpreter isn’t as easy as looking at the process-list. The admin would’ve to look into the behaviour of the process.

Furthermore, we might find ourselves in an architectural-discrepancy. Our new process might not match the systems architecture which might cause trouble when executing further scripts, commands or exploits through metasploit. My guess is, that we faced this exact issue on this box.

Technical Details

Now onto the nerdy-stuff. How does it work? What happens under the hood? While gaining knowledge about this topic, Jorge Lajara’s Blog post helped me a lot. For more info, go check it out! Basically, the migration is separable in 3 phases:

1. Preparation: First of all, meterpreter executes some checks. We need to have the SeDebugPrivilege privilege. This privilege allows us to adjust the memory of a process owned by another account. Otherwise we won’t be able to call the following functions (Hint for Blue-Teamers: Don’t ever give anyone this privilege, unless absolutely necessary.) At last meterpreter examines whether the target process is running on 32- or 64-bit architecture to properly manage the memory and prepares the payload from the handler which is going to be migrated into the target process.

2. Migration: Thereafter, the actual migration happens. Meterpreter calls 4 different System-APIs: OpenProcess() to gain access to the virtual memory of the target process, VirtualAllocEx() to allocate memory in the target process, WriteProcessMemory() to actually transfer the payload to the allocated memory of the target process and, finally, CreateRemoteThread() to spin up a new thread in the target process which is running our injected payload.

3. Cleanup: Finally, after the migration has been finished successfully, meterpreter shuts down the old process to hide its tracks.

 

That’ll be it for today. If you like what you read, or have any feedback, please let me know @h4xil10.

 

Happy Hacking!

 

Share on facebook
Share on twitter
Share on linkedin

Related Articles

H4xil10

Content creator

Become a hacker they said… It’ll be fun they said … AND IT ACTUALLY IS. Even better so than I thought it might be. Therefore, I want to make my learnings and knowledge as accessible as possible and hope many will join me on a journey into the great world of itsec.

haxilio

Explore