IBM QRadar

 View Only

PrintNightmare: The Critical Windows Print Spooler Vulnerability

By Gladys Koskas posted Fri July 02, 2021 10:56 AM

  

Special thanks to Thomas Bouve and Billy O'Brien for working so hard on the payload execution to provide the most relevant information possible

On June 8th 2021, Microsoft published the CVE-2021-1675. The vulnerability also known as PrintNightmare has been updated on June 21st and it's severity became critical.

Depending on it's execution, the exploitation can be fairly silent and a nightmare to detect (yes I did dare). But my teammates Thomas, Billy and I are here to help and will try to provide you some information so you can implement correlation rules that will help to detect the exploit.

In one line, the vulnerability affects the print spooler service and enables remote code execution capability. The first advise provided by the CISA (Cybersecurity & Infrastructure Security Agency) in their advisory  is for "administrators to disable the Windows Print spooler service in Domain Controllers and systems that do not print". Maybe a little classic, but very valid you'll have to admit!

The behaviour we're looking at might generate a lot of false positives, rules catching authentication to the Spooler service or SMB connection to download the payload might be something to look at but not be the easiest way to go in this particular case.

But we still have two rules to propose ! You can implement them today to start monitoring this CVE as quick as possible, all you need is to configure Sysmon on your Server by following our procedure described here, and download the Windows Custom Properties on the App Exchange here.

The first rule catches when rundll32.exe is spawned by spoolsv.exe.

Apply rundll32 spawned by spoolsv on events which are detected by the Local system
and when the event(s) were detected by one or more of Microsoft Windows Security Event Log
and when the event category for the event is one of the following System.Process Creation Success
and when the event matches Username is any of SYSTEM
and when the event matches Parent Process Name (custom) is any of spoolsv.exe
and when the event matches Process Name (custom) is any of rundll32.exe


This would catch an event similar to the following


The second rule catches when a suspicious file has been created by spoolsv.exe

For this one, you'll need to create one additional custom property with the following parameters:
Screenshot_2021-07-07_at_17_07_39.png
Regex: Image:.*\\(.*?)\sTargetFilename

Apply Malicious DLL created by spoolsv on events which are detected by the Local system
and when the event(s) were detected by one or more of Microsoft Windows Security Event Log
and when the event category for the event is one of the following System.File Created, Audit.Object Load Success
and when the event matches File Extension (custom) is any of dll
and when the event matches Process Name (custom) is any of spoolsv.exe
and when the event matches LOWER("Filename") MATCHES '(myexploit|evil|addcube|rev|rev2 main64|mimilib)\.dll' AQL filter query


This rule would trigger on an event like this one:



Thanks again to the X-Force team for jumping on this so quick and provide all this essential information!

If you are directly impacted and in need of expert assistance, you can contact the IBM Security X-Force Incident Response team, who is available to assist 24×7, at US hotline 1-888-241-9812 | Global hotline (+001) 312-212-8034.

If you are interested in reading more about QRadar Security Content, you can find the complete list of blog entries here.

4 comments
121 views

Permalink

Comments

Tue July 20, 2021 11:20 AM

Hi Andrew

The payload was tested on a Windows 10 - Workstation. It took a few tries to trigger.
If you are afraid of false negatives I would suggest to look at the solution proposed by Florian Roth here: https://github.com/SigmaHQ/sigma/pull/1592/commits/c508e71165b896a3676363660f7c8626ef2cfab7 and add another rule.

I didn't mention it in my blog because I have no trace of this behaviour (in some cases there is an error message, in some other cases there is none, but the attack is a success in both situations), so I couldn't share the sample payload.
The Windows Custom Properties on the App Exchange should provide you all the properties you need: EventID, Error Code, Filename.

I hope you'll succeed in your lab with these information !

Gladys

Fri July 16, 2021 08:02 AM

Hi!
In which context, OS, role do you have spoolsv initiated rundll execution(process creation)?
I tried all of the exploits local, remote, python, c+, ps, and no one has this artifact.
In this case its a wrong scenario, that produces false negatives.

Wed July 14, 2021 12:51 PM

Hi Karl

I'm sorry to hear you had troubles when you enabled the rule (and still recommended the blog !), I hope you'll be able to work with support to find a solution.

In the meantime I would advise for you to create a search in the log activity with the same criteria minus the last 1 or 2 filters and look at the number of results you get. If the number is too important you might want to look at adding other "optimized" filters.
The rules given in the blog try to use a few of these filters to remove a great percentage of events to evaluate with the next filter, like in a funnel.

I've heard good feedback on these rules so far, but your situation might be particular and you might have additional filters at your disposal to optimize it for your environment.

Good filters would be:
- Building block (basically boolean tests when included in rules)
- Log source (rather than log source type)
- Event name
- IP / port / network
- Username
- Other custom properties, numerical tests in priority (then alphanumerical, before any sort of regex)

Sincerely hope this will help !

Gladys

Wed July 14, 2021 10:16 AM

Gladys,
thx a lot for sharing this wonderful policy. We have implemented it and as soon as enabling the new policy our system went down for 45 min until it had restarted itself. Memory got out of control, events were dropped. we opened a support call. Our release is 7.4.2 FP3. RCA still continues. Maybe we ran in some side effect or just coincidence. Anyway we disabled policy and that fixed the problem for now. Just to let you know.
Other experiences from other members?