At thePatchday in June 2021 fixed the print spooler vulnerability CVE-2021-1675 on Windows systems. At the same time, however, the further vulnerability CVE-2021-34527 was discovered, which went through the media under the name “PrintNightmare”. The vulnerability was only discovered by a team of researchers who published a Proof-of-Concept (PoC) for the vulnerability after incorrectly assuming that it was the already patched print spooler vulnerability CVE-2021-1675. Because of this mix-up, PrintNightmare became a zero-day exploit. A number of PrintNightmare PoC exploits that allowed any authenticated user to obtain SYSTEM rights to systems running the print spooler service quickly became popular.
Microsoft initially assigned a low severity level to the CVE-2021-1675 vulnerability, but later increased it to “critical”. The weak point made it possible Remote code executions (RCE: Remote Code Execution) – coincidentally, this is also the case with PrintNightmare, which is why CVE-2021-1675 and PrintNightmare have been confused.
Since the print spooler service – with the exception of “Server Core” – is activated by default, the vulnerabilities are a serious problem. They arise from the fact that every authenticated user can install a new printer driver with a driver file stored on an in-house server is. In this way, the Print Spooler Service executes code with SYSTEM privileges. The public availability of several PoCs opens the door for criminal actors here – the fact that the vulnerabilities CVE-2021-1675 and PrintNightmare are confused with one another makes the situation even worse.
To bridge the gap until a patch, Microsoft recommended for an initial workaround for PrintNightmare to deactivate the print spooler service on computers that are not required. The best way to do this is to deactivate the print spooler for entire domains via the settings for the group policies (GPP: Group Policy Preferences), but this is not particularly practical for some companies.
With the Microsoft security update of August 10th, there was a patch for PrintNightmare: Through research, Microsoft had recognized that the default setting of Point and Print cannot protect users against potential attacks. The patch can no longer be used to install arbitrary files via Point and Print. Instead, admin rights are now required to run Point and Print via a remote server. As a result, some users can no longer access Point and Print, but according to Microsoft, the otherwise existing security risk justifies this restriction.
However, this does not completely eliminate the security gap. On August 11, another zero day in the Windows print spooler became known, which Microsoft now carries under the ID CVE-2021-36958. Since the patch from August 10th, only users with administrator rights can install new printer drivers. However, if the driver is already installed, users without higher rights can still connect to it and smuggle in harmful DLLs using the CopyFile method. Microsoft therefore currently recommends deactivating the print spooler as a temporary fix until a new patch is available.
Preparation of the log data sources
Events in the logs “Microsoft-Windows-PrintServer / Admin” and “Microsoft Windows Print Server / Operational“. You have to do the latter activate manually. First, prepare plans with the administrators to start forwarding the log data from the sources listed to LogPoint. If you also use Sysmon in your IT environment, we recommend that administrators update the configuration to ensure that Sysmon can recognize the artifacts from PrintNightmare. Finally, you can also use IDS / IPS events to capture the network artifacts left by PrintNightmare.
Detection of exploit artifacts with LogPoint
You can identify PrintNightmare artifacts from either endpoint events or network events. The most reliable method of detecting an exploit is to search for event IDs such as 808 and 316. For both events, you can see the name of the malicious DLL that is being loaded by the print spooler service. Event ID 808 was not always generated in our tests. But when it was generated, the defective DLL was loaded successfully.
You can use the Sysmon events for file creation to search for DLL drops in the driver directory of the print spooler. The stored DLLs are then loaded by the print spooler process (spoolsv.exe), as can be seen from the Sysmon image load events.
The loaded DLLs also appear in the registry paths of the printer spooler, as can be seen from the Sysmon registry events.
While the new Sysmon configuration is being transferred to the environment, you can also use native Windows events to search for a possible exploit. You can look for either the distribution of WerFault.exe by the print spooler service or the unexpected termination of the print spooler service. You can use the native Windows events because the print spooler service generates an error while loading the payload DLL. However, you should note that side-loading the DLL can bypass this behavior successfully.
Alternatively, you can use generic exploit detection by looking for the spread of suspicious processes through the print spooler service.
norm_id = WindowsSysmon label = “Process“ label = Create
parent_image = “* spoolsv.exe“ image IN [„*cmd.exe“, „*powershell.exe“, „*rundll32.exe“]
On the network side, you have to look for the transfer of the payload DLL via SMB. If you use an IDS / IPS solution such as Snort and Zeek (Bro) in your IT environment, this is very easy.
You can narrow down the above two queries further by specifically targeting domain controllers, but that may not always be the case.
We should keep in mind that PrintNightmare can also be used for local privilege escalation (LPE), e.g. administrators are advised to keep an eye out for new local user creations after one of the PrintNightmare artifacts has been generated as shown below.
The sysmon configuration is key to detecting an exploit
As you can see, we used Sysmon to detect the various artifacts that PrintNightmare produced. You shouldn’t overlook the importance of Sysmon in today’s threat landscape. You can use Sysmon to enrich the basic Windows event logs, adding to existing sources such as process creation logs and adding support for new data sources such as the creation of pipes, which are essential for threat detection. The configuration of Sysmon is and remains a delicate balancing act between the detection of a large number of relevant events and the avoidance of log flooding – a flood of log data. Ultimately, it boils down to appropriately configuring the guidelines and rules in Sysmon – tailor-made for the IT environment in which you are using the tool.
The SwiftOnSecurity Sysmon configuration is still one of the best places to start with a Sysmon configuration that is tailored to your IT environment. The Sysmon configuration must include rules for the detection of important events such as DLL droppings and EXE droppings. At the same time, an exclusion for permissible but resource-intensive applications must be considered. These include integrated system processes such as svchost, AVs, EDRs, vulnerability scanners and databases such as MSSQL. Start with the use of the basic configuration on selected systems and monitor the log data volume. Then continue with the configuration and rule out disturbing events. Repeat this process until the SIEM memory can handle the log data volume if the tool is used on all systems in your IT environment.
New Sysmon versions also introduce new events. You should therefore make sure that you are using a version of Sysmon that can generate all the events that you need and that are relevant to you. Before using a detection technology based on Sysmon, you should check whether the configuration provided can generate the events required for detection. Blind spots in a Sysmon configuration can certainly occur. This can be avoided with thorough tests – even before extensive use in your IT environment.