Quick look at CVE-2021-1675 & CVE-2021-34527 (aka PrintNightmare)

Recent vulnerabilities in Windows Print Spooler service


Last week Microsoft warned Windows users about vulnerabilities in the Windows Print Spooler service – CVE-2021-1675 and CVE-2021-34527 (also known as PrintNightmare). Both vulnerabilities can be used by an attacker with a regular user account to take control of a vulnerable server or client machine that runs the Windows Print Spooler service. This service is enabled by default on all Windows clients and servers, including domain controllers.

Kaspersky products protect against attacks leveraging these vulnerabilities. The following detection names are used:

  • HEUR:Exploit.Win32.CVE-2021-1675.*
  • HEUR:Exploit.Win32.CVE-2021-34527.*
  • HEUR:Exploit.MSIL.CVE-2021-34527.*
  • HEUR:Exploit.Script.CVE-2021-34527.*
  • HEUR:Trojan-Dropper.Win32.Pegazus.gen
  • PDM:Exploit.Win32.Generic
  • PDM:Trojan.Win32.Generic
  • Exploit.Win32.CVE-2021-1675.*
  • Exploit.Win64.CVE-2021-1675.*

Our detection logic is also successfully blocks attack technique from the latest Mimikatz framework v. 2.2.0-20210707.

We are closely monitoring the situation and improving generic detection of these vulnerabilities using our Behavior Detection and Exploit Prevention components. As part of our Managed Detection and Response service Kaspersky SOC experts are able to detect exploitation of these vulnerabilities, investigate such attacks and report to customers.

Technical details


When using RPC protocols to add a new printer (RpcAsyncAddPrinterDriver [MS-PAR] or RpcAddPrinterDriverEx [MS-RPRN]) a client has to provide multiple parameters to the Print Spooler service:

  • pDataFile – a path to a data file for this printer;
  • pConfigFile – a path to a configuration file for this printer;
  • pDriverPath – a path to a driver file that’s used by this printer while it’s working.

The service makes several checks to ensure pDataFile and pDriverPath are not UNC paths, but there is no corresponding check for pConfigFile, meaning the service will copy the configuration DLL to the folder %SYSTEMROOT%\system32\spool\drivers\x64\3\ (on x64 versions of the OS).

Now, if the Windows Print Spooler service tries to add a printer again, but this time sets pDataFile to the copied DLL path (from the previous step), the print service will load this DLL because its path is not a UNC path, and the check will be successfully passed. These methods can be used by a low-privileged account, and the DLL is loaded by the NT AUTHORITY\SYSTEM group process.


The local version of PrintNightmare uses the same method for exploitation as CVE-2021-34527, but there’s a difference in the entrypoint function (AddPrinterDriverEx). This means an attacker can place a malicious DLL in any locally accessible directory to run the exploit.


Kaspersky experts anticipate a growing number of exploitation attempts to gain access to resources inside corporate perimeters accompanied by a high risk of ransomware infection and data theft.

Therefore, it is strongly recommended to follow Microsoft guidelines and apply the latest security updates for Windows.

Quoting Microsoft (as of July 7th, 2021):
“Due to the possibility for exposure, domain controllers and Active Directory admin systems need to have the Print spooler service disabled. The recommended way to do this is using a Group Policy Object (GPO).
While this security assessment focuses on domain controllers, any server is potentially at risk to this type of attack.”

Quick look at CVE-2021-1675 & CVE-2021-34527 (aka PrintNightmare)


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



  1. RiderExpert

    Are Kaspersky home products also able to stop that attack?

    1. Yuliya

      Hi, Rider!

      Yes, they are.

  2. Ian Midgley

    Are there checks on the pConfigFile DLL to confirm it is signed or is that check missed too before it is copied? Is the local pDataFile checked to see whether it is signed before it is loaded?

    1. Alexey Kulaev

      Due to historical reasons it’s not always possible to check file signing, the same thing happens in our case, they cannot check file signatures because otherwise many legal files used by printer’s set up procedure may stop working.

      1. Ian Midgley

        Thanks Alexey. So are you basically saying that signed drivers are about as secure as unsigned ones? Sounds like this is the bit that Microsoft need to fix. If it is not always possible to check file signing there isn’t much point it being there. Was hoping that restricting users to Package Point and Print servers and so using signed drivers would fully mitigate the issue, but it looks like it doesn’t. I did see Microsoft say it doesn’t in KB5005652 but wondered why. From your answer I take it that signed drivers don’t give us the protection that we had hoped.

        1. Alexey Kulaev

          Obviously signed files are more secure than unsigned ones but in this case MS cannot make it thus way that only signed files will be allowed for installation, it would just break legal but unsigned files which still exists.

  3. David

    Reviewing exploit code, seems that the variable with can have a UNC value is pDataFile, not “pConfigFile” as it is said in the article.



APT trends report Q1 2024

The report features the most significant developments relating to APT groups in Q1 2024, including the new malware campaigns DuneQuixote and Durian, and hacktivist activity.

Subscribe to our weekly e-mails

The hottest research right in your inbox