Advanced Plus Security wat0114 security config 2021

[Thales]

is OSArmor like voodoo shield?

No. OSA is anti post expoloit program.
VA is antiexe.

 

[carl fish]

how many anti exe programs are there?

 

[Thales]

how many anti exe programs are there?

Not many.
If I were you I would use Windows SRP.
But first thing first you should know why you need an anti-exe.

 

[Andy Ful]

There has to be more to it than just blocking the launch of

C:\Users\name\AppData\Local\Temp\__PSScriptPolicyTest_*.ps1	Path	Unrestricted
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.

 

[wat0114]

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]

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]

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?

 

[Ink]

-Hyper-V enabled

Do you use it for VM?

 

[wat0114]

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.

 

[Andy Ful]

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.

 

[1chaoticadult]

Nice to see you post your security setup my friend. My security setup is similar. Are you using this setup on a laptop?

 

[wat0114]

Nice to see you post your security setup my friend. My security setup is similar. Are you using this setup on a laptop?

Thanks chaotic. Yes, it's used on a laptop.

 

[1chaoticadult]

Thanks chaotic. Yes, it's used on a laptop.

Yep no problem and I thought that might be the case.

 

[wat0114]

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

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

 

[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

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.

 

[Andy Ful]

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]

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]

...
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.

 

[Ink]

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]

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.