PrintNightmare and SSH Tunnels for Fun

Today I wanted to cover a subject that has been covered many times before, but writing about the techniques and tools I am learning helps me solidify my knowledge so here we go. Today’s post will be about, testing out the PrintNightmare exploit in my homelab through dynamic and remote SSH tunnels. I got the idea for this blog post from The Cyber Mentor YouTube channel as he covered this in a video, minus the SSH tunnels here. This is a really well put together video and walkthrough that will definitely help you if you are struggling with the concepts.

Now that we have a sense of what we will be covering, let’s begin!

Network:

PFSense VM

Parrot:10.0.0.12

Ubuntu Proxy: 10.0.0.22|192.168.10.10

Domain Controller: 192.168.10.5

The way I set up my lab is fairly simple. I used a Parrot VM as my attack machine, an Ubuntu box as my proxy, and a Windows Server 2016 VM which had the Print Spooler service enabled. The gist of PrintNightmare according to the referenced Forescout blog post is, that this is a vulnerability in Spooler print service that fails to restrict access to the functionality that allows users to add printers and related drivers. This will allow any authenticated user to run code with SYSTEM privileges. In my walkthrough I use a regular domain user named latreides. 

The first thing I did was set up my SSH tunnels to the Ubuntu proxy machine. I created a dynamic tunnel and a remote tunnel using the following commands. 

The SSH dynamic tunnel creates a socks proxy that you can use with proxychains to throw your exploit through the Ubuntu proxy. Ensure you check in /etc/proxychains.conf to make sure proxychains is using the correct port. In the above example I needed to change the port from 9051 to 9050. The next SSH command opens up port 5555 on my proxy and will throw any traffic that hits that port back to my Parrot box, which will have Metasploit listening on port 5555 to catch my meterpreter call back. 

After this I set up my Metasploit session to catch my call back. 

Here all I did was set up a multi-handler with a payload of windows/x64/meterpreter/reverse_tcp. I set my LHOST to 127.0.0.1 and my LPORT to 5555. Localhost is being used because the Windows Domain Controller is on a different network than my Parrot box and I am catching the call back from my remote tunnel from my Ubuntu proxy VM. So we need to keep this in mind when building our payload with msfvenom. Which we will do next.

We now need to build our payload with the following command.. 

So here we are building our payload with the IP of our Ubuntu proxy and port 5555 and made it a DLL because that is what the exploit I am using calls for. Once the payload is built I scp’d it over to my proxy VM. Which already has the Impacket tool smbserver.py installed. This is the tool I will use to host my payload for the exploit.

Here is the smbserver.py command.

 Now that my file is hosted and everything is set up, let’s throw the exploit.

Here I use proxychains to run the exploit using the credentials of a normal domain user latreides, pointing it at the Domain controller at 192.168.10.5 and using the smb server that was created so the payload can be downloaded and run.

Here you can see the DC downloaded the payload.

Here is my meterpreter session.

Once the exploit is run you should get a meterpreter session running as SYSTEM. Side note, if you have Windows Defender running this will be caught if you are using a plain msfvenom payload with no evasion. Evading AV is something I will leave up to you to try. In my next post I will show the defensive side of what artifacts this will leave behind.

So, until next time…

Marcus

References:

PrintNightmare

https[:]//github.com/cube0x0/CVE-2021-1675

https[:]//github.com/cube0x0/impacket