- Nov 26, 2017
- 726
No. OSA is anti post expoloit program.is OSArmor like voodoo shield?
VA is antiexe.
No. OSA is anti post expoloit program.is OSArmor like voodoo shield?
Not many.how many anti exe programs are there?
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.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.
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.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.
I use the below settings: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?
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.Do you use it for VM?
Nothing else. You can do the same via GPO (keeping the points from the previous posts).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?
Yes. It has nothing to do with this.You're not adding the PSScriptPolicyTest to your environmental variables.
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.You are not setting a registry key (as Language Mode cannot be configured via the registry).
Nothing unusual. The SRP interaction with PowerShell Language Mode was designed in this (unusual) way by Microsoft.So you are doing something in addition to merely blocking PSScriptPolicyTest behind the scenes. What are those system modifications?
Thanks chaotic. Yes, it's used on a laptop.Nice to see you post your security setup my friend. My security setup is similar. Are you using this setup on a laptop?
Yep no problem and I thought that might be the case.Thanks chaotic. Yes, it's used on a laptop.
So you end in a broken system which isn't the goal of hardening.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
It is not so bad and still improving. Yuki uses far more dangerous hardening.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:So you end in a broken system which isn't the goal of hardening.
I think that problem can be related to your rules. Microsoft does not use simply whitelisting and blacklisting....
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.
If you are using third-party VM software, then you should Disable Hyper-V.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.
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
Link: Disable Hyper-V to run virtualization software - Windows ClientThis 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
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.