![]() Windows Server 2012 non-R2, whether DC or not - not affected.Windows Server 2012 R2, whether DC or not - affected.Windows Server 2016, whether DC or not - affected.Windows Server 2019, whether DC or not - affected.The current status, according to our tests, is this: IT Administrators must disable that HIPS rule via console or locally to add a printer or update a driver.Īlso McAfee publish an Expert Rule that is similar to our HIPS solution :Īs you said use this expert rule may cause issues for McAfee users.Īnswer updated : 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. It seems that the only way to work against PrintNightmare is HIPS Rule in such these old environments. So Print PrintNightmare patches can not be installed and print spooler can not be disabled ! So an absolute block on write activity it its sub-directories will cause these updates to fail and possibly other Win Update Thank you.īut in some old networks we have even 2008R2 and windows 7 without ESU. Windows periodically updates its fax drivers in C:\Windows\System32\spool\drivers\ directory. Otherwise, I would have never detected this a FYI. Luckily, I always test my HIPS rules for functionality. The real scary part here is Eset gave no indication that the HIPS was not functioning properly. Appears this corrupted the HIPS module in some way. I cancelled it via Eset GUI option but even then, it "sputtered" a bit. What may have caused this HIPS malfunction was a few days ago, I had an Eset module update hang on me. An Eset reinstall fixed the HIPS issue and it's now detecting properly write activity to C:\Windows\System32\spool\drivers\*.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |