itman 1,659 Posted July 5, 2021 Share Posted July 5, 2021 Created an ask rule to monitor "Write to File" activity in C:\Windows\System32\spool\drivers\*. It doesn't alert on any write activity and allows file creation. Worse when I go to delete the just created file, the rule triggers with an Eset alert showing attempted write activity. Note I did not enable the delete mitigation in the rule. I need this fixed ASAP. I am trying to mitigate the current print spooler vulnerability that is now affecting all Win 10 non-domain joined devices. Link to comment Share on other sites More sharing options...
Administrators Marcos 5,074 Posted July 6, 2021 Administrators Share Posted July 6, 2021 No problems here: Link to comment Share on other sites More sharing options...
kamiran.asia 5 Posted July 6, 2021 Share Posted July 6, 2021 We test this solution and we think it is useful for CVE-2021-34527. It work and block : C:\Windows\System32\spool\drivers\* Link to comment Share on other sites More sharing options...
itman 1,659 Posted July 6, 2021 Author Share Posted July 6, 2021 Well, it doesn't work for me. Possibly the EIS ver. 14.2.19 upgrade borked something in the HIPS. Looks like I will have to do an Eset reinstall. Link to comment Share on other sites More sharing options...
Solution itman 1,659 Posted July 6, 2021 Author Solution Share Posted July 6, 2021 An Eset reinstall fixed the HIPS issue and it's now detecting properly write activity to C:\Windows\System32\spool\drivers\*. What may have caused this HIPS malfunction was a few days ago, I had an Eset module update hang on me. I cancelled it via Eset GUI option but even then, it "sputtered" a bit. Appears this corrupted the HIPS module in some way. The real scary part here is Eset gave no indication that the HIPS was not functioning properly. Luckily, I always test my HIPS rules for functionality. Otherwise, I would have never detected this issue. @kamiran.asia a FYI. Windows periodically updates its fax drivers in C:\Windows\System32\spool\drivers\ directory. So an absolute block on write activity it its sub-directories will cause these updates to fail and possibly other Win Update issues. Link to comment Share on other sites More sharing options...
kamiran.asia 5 Posted July 7, 2021 Share Posted July 7, 2021 22 hours ago, itman said: An Eset reinstall fixed the HIPS issue and it's now detecting properly write activity to C:\Windows\System32\spool\drivers\*. What may have caused this HIPS malfunction was a few days ago, I had an Eset module update hang on me. I cancelled it via Eset GUI option but even then, it "sputtered" a bit. Appears this corrupted the HIPS module in some way. The real scary part here is Eset gave no indication that the HIPS was not functioning properly. Luckily, I always test my HIPS rules for functionality. Otherwise, I would have never detected this issue. @kamiran.asia a FYI. Windows periodically updates its fax drivers in C:\Windows\System32\spool\drivers\ directory. So an absolute block on write activity it its sub-directories will cause these updates to fail and possibly other Win Update issues. @itman Thank you. But in some old networks we have even 2008R2 and windows 7 without ESU . So Print PrintNightmare patches can not be installed and print spooler can not be disabled ! It seems that the only way to work against PrintNightmare is HIPS Rule in such these old environments. IT Administrators must disable that HIPS rule via console or locally to add a printer or update a driver. Also McAfee publish an Expert Rule that is similar to our HIPS solution : https://kc.mcafee.com/corporate/index?page=content&id=KB94659 As you said use this expert rule may cause issues for McAfee users. Link to comment Share on other sites More sharing options...
itman 1,659 Posted July 7, 2021 Author Share Posted July 7, 2021 (edited) 2 hours ago, kamiran.asia said: But in some old networks we have even 2008R2 and windows 7 without ESU . So Print PrintNightmare patches can not be installed and print spooler can not be disabled ! To begin, use this as a reference to what OS versions are affected by this vulnerability: Quote Answer updated 7/5/2021: Due to the discovery of a new attack vector, which also affects non-DC servers and Windows 10 machines in their default configuration, the set of affected Windows platforms has significantly expanded. The current status, according to our tests, is this: Windows Server 2019, whether DC or not - affected Windows Server 2016, whether DC or not - affected Windows Server 2012 R2, whether DC or not - affected Windows Server 2012 non-R2, whether DC or not - not affected Windows Server 2008 R2, whether DC or not - affected Windows Server 2008 non-R2, whether DC or not - not affected Windows Server 2003, whether DC or not - not affected Windows 10 (all versions), domain-joined - not affected Windows 10 (all versions), non domain-joined - affected Windows 7 - not affected https://blog.0patch.com/2021/07/free-micropatches-for-printnightmare.html You might also what to checkout 0Patch since they provide patches for non-supported Win OS versions. Unfortunately, a single HIPS monitoring rule is insufficient to mitigate this vulnerability. Scroll down to this section, Detections for PrintNightmare, in this article: https://www.splunk.com/en_us/blog/security/i-pity-the-spool-detecting-printnightmare-cve-2021-34527.html Alternatives are: 1. https://blog.truesec.com/2021/06/30/fix-for-printnightmare-cve-2021-1675-exploit-to-keep-your-print-servers-running-while-a-patch-is-not-available/ 2. Quote Option 2 - Disable inbound remote printing through Group Policy You can also configure the settings via Group Policy as follows: Computer Configuration / Administrative Templates / Printers Disable the “Allow Print Spooler to accept client connections:” policy to block remote attacks. You must restart the Print Spooler service for the group policy to take effect. Impact of workaround This policy will block the remote attack vector by preventing inbound remote printing operations. The system will no longer function as a print server, but local printing to a directly attached device will still be possible. https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-34527 Edited July 7, 2021 by itman Link to comment Share on other sites More sharing options...
Recommended Posts