SECURITY: Complete wat0114 security config 2021

Last updated
Jun 12, 2021
About
Personal, primary device
Additional PC users
Not shared with other users
Desktop OS
Windows 10
Linux distro
Debian Buster (10)
OS edition
Pro
Login security
    • Password-less (PIN, Biometric, Face)
    • Password (Aa-Zz, 0-9, Symbols)
Primary sign-in
Local account
Primary user
Standard user - Limited permissions
Other users
Other accounts are Admin users
Security updates
Manual - check for updates, but do not auto-install
Windows UAC
Maximum - always notify
Network firewall
ISP-issued router
Real-time protection
Windows Defender, OSArmor
Software firewall
Microsoft Defender Firewall
Custom RTP, Firewall and OS settings
-ConfigureDefender on Medium, Malwarebytes Firewall Interface for Windows Defender Firewall, severl Group Policy settings enabled.
SRP - Default-deny
-Hard_Configurator_6_Beta1: Recommended Settings
-Full BitLocker encrypted system partition.
-BIOS: passworded, Memory Protection, Intel Virtualization & Intel VT-d- enabled
-Hyper-V enabled
Malware testing
No malware samples
Periodic security scanners
VirusTotal
Secure DNS
Cloudflare
Quad9
VPN
None
Password manager
Lastpass and Browser's built-in
Browsers, Search and Addons
Firefox latest (primary), MS Edge

-uBlockO
-CSS Exfil
-LocalCDN
Maintenance and Cleaning
Occasional system images using IFW (Image for Windows) and Disk cleanup using built-in Disk cleaner
Personal Files & Photos backup
-Separate, encrypted partition
-USB Drive
Personal backup routine
Manual (maintained by self)
Device recovery & backup
IFW (Image for Windows)
Device backup routine
Manual (maintained by self)
PC activity
  1. Browsing the web. 
  2. Browsing to unknown sites. 
  3. Emails. 
  4. Multimedia. 
  5. Streaming. 
Computer specs
Device name Lenovo-E580
Processor Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz 2.70 GHz
Installed RAM 8.00 GB (7.86 GB usable)
System type 64-bit operating system, x64-based processor
Feedback Response

Most critical feedback

Andy Ful

Level 72
Verified
Trusted
Content Creator
Dec 23, 2014
6,105
There has to be more to it than just blocking the launch of

C:\Users\name\AppData\Local\Temp\__PSScriptPolicyTest_*.ps1PathUnrestricted
C:\Users\name\AppData\Local\Temp\__PSScriptPolicyTest_*.psm1

Making a rule to block these scripts from launching (using, for example, Simple Software Restriction Policy or other default deny) in and of itself does not enforce Constrained Language Mode.
Of course, blocking these scripts makes no sense. But no one blocks them to enforce ConstrainedLanguage (in fact, they are whitelisted in this thread). One simply uses SRP Default Protection Level set to Disallowed or Basic User to block all possible files (WSH scripts, MSI, EXE, etc.) by default, and then PowerShell is automatically restricted to ConstrainedLanguage (PowerShell 5.0 or higher is required). The setup in this thread and all predefined H_C profiles (except All-OFF) are properly set to enforce Constrained Language Mode in PowerShell.
Anyway, if one would whitelist the whole folder C:\Users\username\AppData\Local\Temp, then SRP could not use ConstrainedLanguage even without whitelisting these testing scripts.

Edit
The problem with these scripts arises when the user has already applied the SRP setup that uses ConstrainedLanguage in PowerShell and additionally blocks PowerShell scripts in UserSpace (by extensions PS1, PSM1). He/she can see that the legal script is blocked and does not know what to do. The usual (wrong) reaction is to whitelist these testing scripts.
 
Last edited:

wat0114

Level 3
Apr 5, 2021
141
Of course, blocking these scripts makes no sense. But no one blocks them to enforce ConstrainedLanguage (in fact, they are whitelisted in this thread). One simply uses SRP Default Protection Level set to Disallowed or Basic User to block all possible files (WSH scripts, MSI, EXE, etc.) by default, and then PowerShell is automatically restricted to ConstrainedLanguage (PowerShell 5.0 or higher is required). The setup in this thread and all predefined H_C profiles (except All-OFF) are properly set to enforce Constrained Language Mode in PowerShell.
Yes, my whole approach to this SRP Policy was Default-deny, though out of necessity I had to create some 'Disallow" rules under C:\Windows, C:\Windows\System32 and C:\Windows\SysWow64 because there are some directories within these that allow users to write files to them. BTW, I've updated my Path rules list just now, which excludes the two whitelisted scripts I had.

Also, I see someone fixed the Spoiler issue I was having. Thanks for that :)
 

Andy Ful

Level 72
Verified
Trusted
Content Creator
Dec 23, 2014
6,105
Blocking

__PSScriptPolicyTest_*.ps1

by itself does nothing.

Blocking the script alone does not enforce Constrained Language Mode.

So what other settings in Windows are required to enforce Constrained Language Mode?
I use the below settings:
  1. SRP has to be installed and Default Protection Level has to set to Disallowed or Basic User.
  2. The testing scripts cannot be whitelisted by the Unrestricted folder rule (also with wildcards).
  3. The testing scripts cannot be whitelisted by the Unrestricted file rule (also with wildcards).
 

wat0114

Level 3
Apr 5, 2021
141
Some inexplicable behaviour again with SRP; I have the following "Unrestricted" Path rule:

C:\ProgramData\Microsoft\Windows Defender\Platform\*\*.dll

But checking my Advanced log file moments ago, I see the following was "Disallowed":

C:\ProgramData\Microsoft\Windows Defender\Platform\4.18.2105.5-0\MpOav.dll

Windows Defender seems perfectly fine, nothing about it appears broken, but why the blocked DLL? shouldn't the wildcard "*" cover the "4.18.2105..." part of the Path rule, or am I doing this wrong?
 
  • Like
Reactions: Nevi and venustus

wat0114

Level 3
Apr 5, 2021
141
Do you use it for VM?
No. TBH I'm not even sure if provides any benefits beyond running VM's. I enabled it for some reason a few years ago, maybe because there was some specific security benefit to it that I came across, but I don't remember.
 
  • Like
Reactions: Nevi

Andy Ful

Level 72
Verified
Trusted
Content Creator
Dec 23, 2014
6,105
What settings on Windows is SRP is HC modifying so that Constrained Language Mode is enforced? I am asking for all the individual settings that your utility is modifying to make Constrained Language Mode enforced. Is it GPO or AppLocker settings?
Nothing else. You can do the same via GPO (keeping the points from the previous posts).
You're not adding the PSScriptPolicyTest to your environmental variables.
Yes. It has nothing to do with this.
You are not setting a registry key (as Language Mode cannot be configured via the registry).
It is triggered when SRP Default Security Level is properly set. It is removed when setting Default Security Level to Unrestricted. Changing SRP Default Security Level in this way automatically adjusts PowerShell restrictions.
Default Security Level has its own registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\safer\CodeIdentifiers
and value: DefaultLevel.

So, when SRP is installed then PowerShell Language Mode can be changed by changing this value in the Registry. Furthermore, the ConstrainedLanguage also works even when you remove the PS1 and PSM1 extensions from SRP (testing scripts are not blocked by SRP anymore, but are restricted by ConstrainedLanguage). It will work until the moment of whitelisting testing scripts or changing the SRP Default Security Level to Unrestricted.
Whitelisting any PowerShell script (also any script made by the user) causes the execution of this script in FullLanguage, but PowerShell still works in ConstrainedLanguage for other scripting code. But, if the whitelisting rule whitelists also the testing scripts, then PowerShell runs in FullLanguage for all scripting code.
So you are doing something in addition to merely blocking PSScriptPolicyTest behind the scenes. What are those system modifications?
Nothing unusual. The SRP interaction with PowerShell Language Mode was designed in this (unusual) way by Microsoft.
 
Last edited:

wat0114

Level 3
Apr 5, 2021
141
Discovered that file syncing with OneDrive is a problem with my current, restrictive rules, and no easy fix for it either. Something mysterious and complex is going on. I think I will simply uninstall OneDrive and access it from my web browser instead, then I can discard all the OneDrive rules (y)

EDIT 1

I forgot to mention, nothing was found in either the Event viewer logs or Advanced logs

EDIT 2

as an added bonus, I was able to ditch several firewall rules for OneDrive as well :)
 
Last edited:
F

ForgottenSeer 85179

Discovered that file syncing with OneDrive is a problem with my current, restrictive rules, and no easy fix for it either. Something mysterious and complex is going on. I think I will simply uninstall OneDrive and access it from my web browser instead, then I can discard all the OneDrive rules (y)

EDIT 1

I forgot to mention, nothing was found in either the Event viewer logs or Advanced logs

EDIT 2

as an added bonus, I was able to ditch several firewall rules for OneDrive as well :)
So you end in a broken system which isn't the goal of hardening.
 
  • Like
Reactions: venustus and Nevi

Andy Ful

Level 72
Verified
Trusted
Content Creator
Dec 23, 2014
6,105
So you end in a broken system which isn't the goal of hardening.
It is not so bad and still improving. Yuki uses far more dangerous hardening.:)
There are some other problems with OneDrive and blocking DLLs by SRP (Personal Vault). Similar problems could be with other applications. That is why I skipped blocking DLLs in H_C and focused on preventing malware before it could use malicious DLLs.
 

wat0114

Level 3
Apr 5, 2021
141
So you end in a broken system which isn't the goal of hardening.
Not the system, only OneDrive is broken, and that's only if I utilize specific strict Path rules. I can get it to work without issues if I use the Path:

C:\Users\name\AppData\Local\Microsoft\OneDrive\*\*\* Unrestricted
...along with:
C:\Users\name\AppData\Local\Microsoft\OneDrive\*\*\*.exe Disallowed

This achieves anything at or below this directory level to run with the exception of .exe binaries.

I think what I'm really discovering is that SRP has issues that are not going to be resolved because MS no longer develops it. There are some files within these directories with the extension: .dll.mui. I tried adding them to Path rules but it didn't help, so maybe they aren't the culprits.
 

Andy Ful

Level 72
Verified
Trusted
Content Creator
Dec 23, 2014
6,105
...
I think what I'm really discovering is that SRP has issues that are not going to be resolved because MS no longer develops it. There are some files within these directories with the extension: .dll.mui. I tried adding them to Path rules but it didn't help, so maybe they aren't the culprits.
I think that problem can be related to your rules. Microsoft does not use simply whitelisting and blacklisting.
The Unrestricted and Dissallowed path rules can modify each other, so one has to be very cautious with them.
Some rules are stronger than others, in some cases one cannot use rules with environmental variables, etc.
Here are the Unrestricted rules (from H_C) that worked without the issues (about year ago):

C:\Users\username\AppData\Local\Microsoft\OneDrive\OneDrive.exe
C:\Users\username\AppData\Local\Microsoft\OneDrive\OneDrivePersonal.cmd
C:\Users\username\AppData\Local\Microsoft\OneDrive\OneDriveStandaloneUpdater.exe
C:\Users\username\AppData\Local\Microsoft\OneDrive\*\*.dll
C:\Users\username\AppData\Local\Microsoft\OneDrive\*\*\*.dll
C:\Users\username\AppData\Local\Microsoft\OneDrive\*\OneDriveStandaloneUpdater.exe
C:\Users\username\AppData\Local\Microsoft\OneDrive\*\FileSyncConfig.exe
C:\Users\username\AppData\Local\Microsoft\OneDrive\*\FileCoAuth.exe
C:\Users\username\AppData\Local\Microsoft\OneDrive\*\OneDriveSetup.exe
C:\Users\username\AppData\Local\Microsoft\OneDrive\*\CollectSyncLogs.bat
C:\Users\username\AppData\Local\Microsoft\OneDrive\Update\OneDriveSetup.exe

Simply, all EXE, DLL, CMD, BAT files installed in the OneDrive folder/subfolders were whitelisted.
I did not use any Disallowed folder path rules for Appdata, AppData\Local, AppData\Local\Microsoft, and other subfolders. I also did not use any Disallowed rules for files in OneDrive folder/subfolders.
 
Last edited:

Spawn

Administrator
Verified
Staff member
Jan 8, 2011
21,076
No. TBH I'm not even sure if provides any benefits beyond running VM's. I enabled it for some reason a few years ago, maybe because there was some specific security benefit to it that I came across, but I don't remember.
If you are using third-party VM software, then you should Disable Hyper-V.

Many third-party virtualization applications don't work together with Hyper-V. Affected applications include VMware Workstation and VirtualBox. These applications might not start virtual machines, or they may fall back to a slower, emulated mode.

These symptoms are introduced when the Hyper-V Hypervisor is running. Some security solutions are also dependent on the hypervisor, such as:
  • Device Guard
  • Credential Guard
This behavior occurs by design.

Many virtualization applications depend on hardware virtualization extensions that are available on most modern processors. It includes Intel VT-x and AMD-V. Only one software component can use this hardware at a time. The hardware cannot be shared between virtualization applications.

To use other virtualization software, you must disable Hyper-V Hypervisor, Device Guard, and Credential Guard
Link: Disable Hyper-V to run virtualization software - Windows Client
 

wat0114

Level 3
Apr 5, 2021
141
I think that problem can be related to your rules. Microsoft does not use simply whitelisting and blacklisting.
The Unrestricted and Dissallowed path rules can modify each other, so one has to be very cautious with them.
Some rules are stronger than others, in some cases one cannot use rules with environmental variables, etc.
Here are the Unrestricted rules (from H_C) that worked without the issues (about year ago):

C:\Users\username\AppData\Local\Microsoft\OneDrive\OneDrive.exe
C:\Users\username\AppData\Local\Microsoft\OneDrive\OneDrivePersonal.cmd
C:\Users\username\AppData\Local\Microsoft\OneDrive\OneDriveStandaloneUpdater.exe
C:\Users\username\AppData\Local\Microsoft\OneDrive\*\*.dll
C:\Users\username\AppData\Local\Microsoft\OneDrive\*\*\*.dll
C:\Users\username\AppData\Local\Microsoft\OneDrive\*\OneDriveStandaloneUpdater.exe
C:\Users\username\AppData\Local\Microsoft\OneDrive\*\FileSyncConfig.exe
C:\Users\username\AppData\Local\Microsoft\OneDrive\*\FileCoAuth.exe
C:\Users\username\AppData\Local\Microsoft\OneDrive\*\OneDriveSetup.exe
C:\Users\username\AppData\Local\Microsoft\OneDrive\*\CollectSyncLogs.bat
C:\Users\username\AppData\Local\Microsoft\OneDrive\Update\OneDriveSetup.exe

Simply, all EXE, DLL, CMD, BAT files installed in the OneDrive folder/subfolders were whitelisted.
I did not use any Disallowed folder path rules for Appdata, AppData\Local, AppData\Local\Microsoft, and other subfolders. I also did not use any Disallowed rules for files in OneDrive folder/subfolders.

Thanks Andy, but I can confirm at least in my case those exact rules you posted will break OneDrive. The culprit, as it was yesterday, is:

C:\Users\username\AppData\Local\Microsoft\OneDrive\*\*\*.dll

I have to weaken it to:

C:\Users\username\AppData\Local\Microsoft\OneDrive\*\*\*

I re-installed the OneDrive app and applied your rules above to verify.
 
Top