Latest Changes
Dec 28, 2018
Operating System
Windows 10
Windows Edition
Pro
Build
Windows 10 1809
System Architecture
64-bit OS
Security Updates
Automatic Updates - All security and feature updates
User Access Control
Always Notify
Firewall
Windows Firewall - Network security provided by Microsoft
Device Security
Windows Defender SmartScreen (Windows 10)
User Account
Administrator - User has complete control over the device
Recent Security Incidents
No malware or privacy issues
Malware Testing
None - No Malware on host PC or VM
Real-time Web & Malware Protection
Windows Defender with ConfigureDefender
Software Restriction Policy with Hard_Configurator
Custom Settings For Real-Time Protection
Custom - Major changes for Increased Security
Virus and Malware Removal Tools
Macrium Reflect does the job just fine...
Browsers and Extensions
Chrome
Edge
Web Privacy
uBlock Origin w/added filters, Netcraft
Password Management
LastPass
Default Web Search
Google
System Utilities
Hard_Configurator, SysHardener, BandiZip, PatchCleaner, autoruns
Data Backup
Dropbox
OneDrive
GoogleDrive
Frequency of Data backups
Always-on Sync
System Backup
Macrium Reflect, Timeshift (Ubuntu)
Frequency of System backups
Regularly

shmu26

Level 78
Content Creator
Trusted
Verified
My rule was not quite right. It was missing the asterisk after automation
But anyways, they say that powershell can launch, even if the dll is blocked. Check out that post over on the other forum. This discussion is a little over my head :)
 

Andy Ful

Level 41
Content Creator
Trusted
Verified
My rule was not quite right. It was missing the asterisk after automation
But anyways, they say that powershell can launch, even if the dll is blocked. Check out that post over on the other forum. This discussion is a little over my head :)
Your rule:
*>*System.Management.Automation.dll
was correct to block the System.Management.Automation.dll from loading by any program.
The rule proposed on WildersSecurity forum:
*powershell.exe>*System.Management.Automation*.dll
was correct to block both System.Management.Automation.dll and System.Management.Automation.ni.dll from loading only by powershell.exe.
The correct rule to block both DLLs from loading by any program (like fake powershell) is:
*>*System.Management.Automation*.dll
I repeated the test with all the above rules and still, powershell.exe can be executed on my system.
.
The executable powershell.exe cannot be run on my Windows version (Windows 10 Pro FCU 64-bit) when the DLL in the below location is properly blocked:
c:\Windows\Microsoft.NET\assembly\GAC_MSIL\System.Management.Automation\v4.0_3.0.0.0__31bf3856ad364e35\System.Management.Automation.dll
You can easily check this by yourself after renaming the above DLL (for example to !!!System.Management.Automation.dll).
 
Last edited:

Andy Ful

Level 41
Content Creator
Trusted
Verified
The test on WildersSecurity forum:
MemProtect - Support & Discussion
has nothing to do with blocking System.Management.Automation.dll .
In fact, only System.Management.Automation.ni.dll was blocked - that can be seen from the log at the end of the post. This DLL is the native image (compiled version) of System.Management.Automation.dll .
.
I am not sure, but it seems that the test on Wilderssecurity forum
could be made on another Windows version - my test was made on Windows 10 FCU 64-bit.
It may be that on some Windows versions it is sufficient to block the System.Management.Automation.ni.dll (native image) to disable powershell.exe . Still, that says nothing about MemProtect ability to block .NET DLLs.
Blocking System.Management.Automation.ni.dll is nothing special, any DLL blocking soft can do it (SRP, SOB, etc.).
 
Last edited:

shmu26

Level 78
Content Creator
Trusted
Verified
The test on WildersSecurity forum:
MemProtect - Support & Discussion
has nothing to do with blocking System.Management.Automation.dll .
In fact, only System.Management.Automation.ni.dll was blocked - that can be seen from the log at the end of the post. This DLL is the native image (compiled version) of System.Management.Automation.dll .
.
I am not sure, but it seems that the test on Wilderssecurity forum
could be made on another Windows version - my test was made on Windows 10 FCU 64-bit.
It may be that on some Windows versions it is sufficient to block the System.Management.Automation.ni.dll (native image) to disable powershell.exe . Still, that says nothing about MemProtect ability to block .NET DLLs.
Blocking System.Management.Automation.ni.dll is nothing special, any DLL blocking soft can do it (SRP, SOB, etc.).
Andy, you need to get on the other forum and talk to those people.
 

shmu26

Level 78
Content Creator
Trusted
Verified
Memprotect and Pumpernickel/Fides, how long can you use the demo? What limitations is there in demo versions?
Sorry, I don't know why I didn't see your post before.
The demo needs to be reinstalled every year. That means reinstalling the driver, which is no big deal once you know how to do it :) , but your config file stays the same like before.
The limitation in demo is the number of characters in the config file. You need to write your rules tersely, and there is a limit how much you can squeeze in. But you can do a lot.
 

Deletedmessiah

Level 21
Content Creator
Verified
Sorry, I don't know why I didn't see your post before.
The demo needs to be reinstalled every year. That means reinstalling the driver, which is no big deal once you know how to do it :) , but your config file stays the same like before.
The limitation in demo is the number of characters in the config file. You need to write your rules tersely, and there is a limit how much you can squeeze in. But you can do a lot.
Thanks! And you answered all of it two days ago on Windows Security's config :)
 
5

509322

Your rule:
*>*System.Management.Automation.dll
was correct to block the System.Management.Automation.dll from loading by any program.
The rule proposed on WildersSecurity forum:
*powershell.exe>*System.Management.Automation*.dll
was correct to block both System.Management.Automation.dll and System.Management.Automation.ni.dll from loading only by powershell.exe.
The correct rule to block both DLLs from loading by any program (like fake powershell) is:
*>*System.Management.Automation*.dll
I repeated the test with all the above rules and still, powershell.exe can be executed on my system.
.
The executable powershell.exe cannot be run on my Windows version (Windows 10 Pro FCU 64-bit) when the DLL in the below location is properly blocked:
c:\Windows\Microsoft.NET\assembly\GAC_MSIL\System.Management.Automation\v4.0_3.0.0.0__31bf3856ad364e35\System.Management.Automation.dll
You can easily check this by yourself after renaming the above DLL (for example to !!!System.Management.Automation.dll).
The test on WildersSecurity forum:
MemProtect - Support & Discussion
has nothing to do with blocking System.Management.Automation.dll .
In fact, only System.Management.Automation.ni.dll was blocked - that can be seen from the log at the end of the post. This DLL is the native image (compiled version) of System.Management.Automation.dll .
.
I am not sure, but it seems that the test on Wilderssecurity forum
could be made on another Windows version - my test was made on Windows 10 FCU 64-bit.
It may be that on some Windows versions it is sufficient to block the System.Management.Automation.ni.dll (native image) to disable powershell.exe . Still, that says nothing about MemProtect ability to block .NET DLLs.
Blocking System.Management.Automation.ni.dll is nothing special, any DLL blocking soft can do it (SRP, SOB, etc.).
It is best to use block rule: *System.Management.Automation*

to avoid any unintentionally missed loading - especially given the fact that Microsoft is continually changing PowerShell and never tells anyone about the changes until it is way too little, way too late = 2 years later and there has been a major comprise due to Microsoft's undocumented this-or-that in PowerShell made 2 years prior and that it negligently didn't notify anyone about.

Microsoft is a menace to Windows security.
 
Last edited by a moderator:

shmu26

Level 78
Content Creator
Trusted
Verified
I too would like to hear what you think of it. When I tried it not long ago, I really liked it! If I didn't have a free licence for SHP, I wold have most probably purchased SPEC.
I can say that it runs super light, it's a real pleasure. And it is quite configurable to various levels of protection. As for how well it actually protects, for that we need to ask the testers.
I am running it together with Software Restriction Policy (managed by Andy Ful's Hard_Configurator).
 
I

illumination

I can say that it runs super light, it's a real pleasure. And it is quite configurable to various levels of protection. As for how well it actually protects, for that we need to ask the testers.
I am running it together with Software Restriction Policy (managed by Andy Ful's Hard_Configurator).
If you're disabling vulnerable processes with SRP combined with SEPC, you're good.

It is super light and bloat free.
 

shmu26

Level 78
Content Creator
Trusted
Verified
I updated to Windows 10 1809, played around with a few AVs.
Settled on Windows Defender -- it runs very light on 1809.
Current security config:
Windows Defender with Attack surface reduction (ConfigureDefender)
Software Restriction Policy (Hard_Configurator)
Standard user account
 
5

509322

I updated to Windows 10 1809, played around with a few AVs.
Settled on Windows Defender -- it runs very light on 1809.
Current security config:
Windows Defender with Attack surface reduction (ConfigureDefender)
Software Restriction Policy (Hard_Configurator)
Standard user account
Make a backup with Windows Backup or Macrium so you don't have to mess with configuring it again. Configuring a SUA is a pain (and the reason a lot of people won't do it, and therefore, won't even bother to create a SUA - if they even know that SUA exists).

The above is the exact config I am using on my personal laptop. Exactly. With SRP one simply does not need the overhead of AV\IS.
 
Last edited by a moderator:

Windows_Security

Level 22
Content Creator
Trusted
Verified
Make a backup with Windows Backup or Macrium so you don't have to mess with configuring it again. Configuring a SUA is a pain (and the reason a lot of people won't do it, and therefore, won't even bother to create a SUA - if they even know that SUA exists).

The above is the exact config I am using on my personal laptop. Exactly. With SRP one simply does not need the overhead of AV\IS.
??? So no AppGuard :oops:
 
  • Like
Reactions: ZeroDay and shmu26