So I did quite a bit of testing with the latest internal version of MemProtect with support for filtering .DLL modules. Particularly, I was testing using a Default Allow type of concept and blocking known application whitelisting bypass techniques with the following rules below: Code: [MODULEWHITELIST] *>* [MODULEBLACKLIST] # Blocking the regsvr32 application whitelisting bypass techniques # Source: https://github.com/iadgov/Secure-Host-Baseline/tree/master/EMET *regsvr32.exe>*scrobj.dll *regsvr32.exe>*scrrun.dll *regsvr32.exe>*mshtml.dll *regsvr32.exe>*jscript*.dll # Blocking the rundll32 application whitelisting bypass techniques *rundll32.exe>*scrobj.dll *rundll32.exe>*scrrun.dll *regsvr32.exe>*mshtml.dll *regsvr32.exe>*jscript*.dll # Blocking rundll32 from loading PowerShell *rundll32.exe>*System.Management.Automation*.dll # Blocking malicious OLE packages in Microsoft Office products *\OFFICE1*\EXCELC.EXE>*flash*.ocx *\OFFICE1*\EXCELC.EXE>*packager.dll *\OFFICE1*\WINWORDC.EXE>*flash*.ocx *\OFFICE1*\WINWORDC.EXE>*packager.dll By default, it would have been Default Deny if I had not added the *>* to the [MODULEWHITELIST] section. But the great thing about any of Florian's kernel-mode drivers is that you can take different security concepts in many different directions of granularity dependent upon the users' own needs and goals that they want to achieve. Certainly you could go much deeper and specify every single .DLL module to load into any specific executable (eg. chrome.exe) and therefore any other unknown module would be blacklisted, if you went Default Deny. This is just preliminary testing prior to this build hitting Beta. But essentially this replicates EMET's ASR (attack surface reduction) feature in which you can whitelist and/or blacklist specific .DLL modules from loading/injecting into any process in Windows. Super, super powerful feature. And from my testing so far this seems to have much greater reach and depth in comparison to EMET's ASR feature. I believe EMET's ASR feature was being implemented in user-mode whereas MemProtect is entirely kernel-mode. In my testing, this has blocked any kind of .DLL module injections that I have tried thus far. And on top of that, I have experience zero issues. Kudos to Florian for this achievement. On a side note, Florian tells me that he has been developing at least one kernel-mode networking filter driver. Interesting times to come... Anyway, later on today I will catch up with Florian again when I have a moment and I will let him know how well testing is going so far as far as stability and usability goes.