I'm sure most of you have heard about the recent remote code execution (RCE) exploit dubbed as PrintNightmare. It is an attack against the printer spool service that allows an attacker, with normal user credentials, to execute with SYSTEM level privileges on a remote or local system. This means that an attacker would need to have credentials in order to exploit this, but they are trivial for an attacker to obtain if they are already in your network.
As usual, we will run through how to detect this exploit using NetWitness. For this post we utilised the Impacket implementation created by cube0x0: https://github.com/cube0x0/CVE-2021-1675.
The Detection in NetWitness Endpoint
As this exploit works against the printer spooler service, we would want to place our focus on the binary, spoolsv.exe, so we can view what actions it performs. In doing so, we can see that spoolsv.exe has written a few DLL's to disk, two of which are legitimate and part of the normal process, unidrv.dll and kernelbase.dll, and one suspect DLL named, dhsyuebf.dll:
It is common for spoolsv.exe to write DLL’s to disk, so just relying on this behaviour would not be enough, it would require the defender to hunt through those DLL’s in order to identify those that look out of place, or endpoints this is occurring on that it typically does not. The following queries can be used to slim the dataset down to these events:
filename.src='spoolsv.exe' && directory.dst begins 'c:\\windows\\system32\\spool\\drivers\\x64\\3\\'
filename.src='spoolsv.exe' && action = 'writetoexecutable','renametoexecutable'
Further analysis shows that spoolsv.exe seldom writes the kernelbase.dll file, looking for this activity should make for a higher fidelity indicator for this exploit. The following query can be used to identify this behaviour:
filename.src='spoolsv.exe' && filename.dst = 'kernelbase.dll'
The Detection in NetWitness Packets
We can detect this behaviour in NetWitness Packets by looking at SMB traffic that is communicating with the named pipe, spoolss (filename = 'spoolss'). In doing so, we can see the various actions associated with the communication to that named pipe. The ones we are interested in are the, rpcenumprinterdrivers and rpcaddprinterdriverex. This is because the exploit works by adding a printer driver:
The following logic could be used in order to detect this behaviour:
service=139 && filename='spoolss' && action = 'rpcenumprinterdrivers','rpcaddprinterdriverex'
If we reconstruct the payload for these events and analyse them, we can see the malicious DLL file and where it was requested from:
This also means that we could see the SMB transfer of this file within the packets, this would allow a defender to reconstruct the DLL for further analysis:
The Detection in Logs
In order to detect this with log data, you would need to enable the "PrintService-Operational" event log as it is not enabled by default (https://social.technet.microsoft.com/wiki/contents/articles/13308.windows-server-2012-troubleshooting-printing.aspx#PrintService_Event_Log_Channel). After doing so, you will see an Event ID of 316 for this exploit:
Again, this behaviour may be common within your environment and will therefore require some hunting to identify anomalies. The following logic could be used to detect this behaviour:
event.source = 'Microsoft-Windows-PrintService' && reference.id = '316'
Conclusion
While this exploit is somewhat trivial to detect, there are a number of caveats with the detections outlined above. If you are using NetWitness Network, it requires that you are capturing lateral traffic, which is not overly common. Furthermore, if your organisation uses encrypted SMBv3, you won’t be able to see the actions and pipe name. So, it is important to have at least the PrintService-Operational event channel enabled, or the endpoint agent installed in order to have some visibility into the print service. This exploit also does not have to take place over the network, and can be performed locally in order to escalate privileges on that endpoint. In this scenario, you would not see any activity over the network and would need to rely on log or EDR visibility in order to detect it.
