Latest Changes
Dec 28, 2018
Operating System
  • Windows 10
  • Windows Edition
    Pro
    Version or Build no.
    Windows 10 1809
    System type
    64-bit operating system; x64-based processor
    Security Updates
    Automatic Updates (recommended)
    User Access Control
    Always Notify
    Network Security (Firewall)
    Windows Defender Firewall
    Device Security
  • Windows Defender SmartScreen (Windows 10)
  • User Account
    Administrator
    Sign-in Accounts
    Malware Testing
    I do not participate in downloading malware samples
    Real-time Web & Malware Protection
    Windows Defender with ConfigureDefender
    Software Restriction Policy with Hard_Configurator
    RTP - Custom security settings
  • Major changes for Increased security
  • Virus and Malware Removal Tools
    Macrium Reflect does the job just fine...
    Browsers and Extensions
    Chrome
    Edge
    Privacy-focused Apps and Extensions
    uBlock Origin w/added filters, Netcraft
    Password Managers
  • LastPass
  • 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 83
    Verified
    Trusted
    Content Creator
    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 48
    Verified
    Trusted
    Content Creator
    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 48
    Verified
    Trusted
    Content Creator
    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 83
    Verified
    Trusted
    Content Creator
    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 83
    Verified
    Trusted
    Content Creator
    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 22
    Verified
    Content Creator
    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 83
    Verified
    Trusted
    Content Creator
    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 83
    Verified
    Trusted
    Content Creator
    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 23
    Verified
    Trusted
    Content Creator
    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