Advanced Plus Security wat0114 security config 2021

[wat0114]

If you are using third-party VM software, then you should Disable Hyper-V.



Link: Disable Hyper-V to run virtualization software - Windows Client

I'm not running any 3rd-party VM software. I did try Windows sandbox quite a while ago but that didn't work out too well.

 

[Andy Ful]

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.

Interesting. Could you export the Registry keys?
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\safer\CodeIdentifiers
HKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\Windows\safer\CodeIdentifiers

These keys contain all SRP rules. If you send them as a txt file to me privately then maybe I could tell more about this issue. The second Registry key normally should not exist (but some software can install it).

 

[wat0114]

Interesting. Could you export the Registry keys?
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\safer\CodeIdentifiers
HKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\Windows\safer\CodeIdentifiers

These keys contain all SRP rules. If you send them as a txt file to me privately then maybe I could tell more about this issue. The second Registry key normally should not exist (but some software can install it).

Hi Andy,

I don't see the "safer" key under the HKCU keys. Not sure if it makes any difference, but I'm not using Hard Configurator for my SRP policy. Just via Group Policy editor.

 

[1chaoticadult]

If you are using third-party VM software, then you should Disable Hyper-V.



Link: Disable Hyper-V to run virtualization software - Windows Client

Actually this is incorrect. I use Virtualbox 6 with Hyper-V. Virtualbox has access to Hyper-V API and will use it if Hyper-V is enabled. You need Windows 10 v1803 or newer though for it to work.

 

[wat0114]

@Andy Ful

I sent you the HKLM SRP string of registry keys from my policy. I'm actually quite happy with things at this point, since the disallowed .exe rule (C:\Users\name\AppData\Local\Microsoft\OneDrive\*\*\*.exe) for the OneDrive Path rule tested perfectly fine; it allows everything except .exe binaries, and everything else is working as expected. Still, if you can identify an issue, then great. Thanks again for your help!

 

[wat0114]

BTW, the attached png screenshot was completely broken in OneDrive before without the one permissive rule in place. No new files dropped into the drive would even sync. It's all good now.

 

[wat0114]

Thanks to @Andy Ful , the OneDrive issues I was struggling with are resolved

I was able to get rid of the overly-permissive Path rule:

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

and instead use Andy's suggested Path rules:

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

I think it's the last one in particular that I had overlooked previously when I was encountering problems.

Thanks again Andy for your help

EDIT

As Andy explained to me in pm, there are some folders with DLL's under: C:\Users\username\AppData\Local\Microsoft\OneDrive\21.099.0516.0003\qml\QtQuick which are not present on his system. I had missed those, but finding them was made difficult because nothing was getting logged in either the Advanced logs, nor in Event Viewer.

 

[Ink]

Actually this is incorrect. I use Virtualbox 6 with Hyper-V. Virtualbox has access to Hyper-V API and will use it if Hyper-V is enabled. You need Windows 10 v1803 or newer though for it to work.

OP said there is no VM software installed. Safe to disable.

 

[1chaoticadult]

OP said there is no VM software installed. Safe to disable.

I know that. I’m was responding to your quote: “If you are using third-party VM software, then you should Disable Hyper-V.” which is incorrect. OP can do what he wants with his system. Whether he disables it or not doesn’t make a difference. This is about his security setup. I’m done with this discussion about hyper-v with you.

 

[Andy Ful]

...
As Andy explained to me in pm, there are some folders with DLL's under: C:\Users\username\AppData\Local\Microsoft\OneDrive\21.099.0516.0003\qml\QtQuick which are not present on his system. I had missed those, but finding them was made difficult because nothing was getting logged in either the Advanced logs, nor in Event Viewer.

Yes. There are some serious cons related to blocking DLLs by SRP. They are logged for processes running with high privileges (Advanced SRP Logging). In the case of OneDrive, such logging is useless because one cannot run it with high privileges. Furthermore, most applications run with standard rights and can work with silent DLL blocks (no evens in the Log) that may have an impact on their stability and functionality. There are even more problems with applications on SUA because running them as Administrator changes the user account.
Generally, blocking DLLs by SRP requires much attention and caution. Anyway, in many cases, one can guess the right rules for whitelisting DLLs. One has to generate a list of all DLLs into the application folder and subfolders to see how deep (in the directory tree) the DLL rules must be applied.

Edit.
It is worth remembering that SRP can block also such files as OCX, CPL, etc. when DLL blocking in enabled.

 

[Andy Ful]

Okay I checked again and found that I could write a file into it. Thanks for pointing that out. I have run accesschk64 from withing the root directory, and ported the results to a text file with the following strings:

accesschk64 -w -s -q -u Users "C:\Program Files"
accesschk64 -w -s -q -u Users "C:\Program Files (x86)"
accesschk64 -w -s -q -u Users "C:\Windows"
accesschk64 -w -s -q -u Everyone "C:\Program Files"
accesschk64 -w -s -q -u Everyone "C:\Program Files (x86)"
accesschk64 -w -s -q -u Everyone "C:\Windows"
accesschk64 -w -s -q -u "Authenticated Users" "C:\Program Files"
accesschk64 -w -s -q -u "Authenticated Users" "C:\Program Files (x86)"
accesschk64 -w -s -q -u "Authenticated Users" "C:\Windows"
accesschk64 -w -s -q -u Interactive "C:\Program Files"
accesschk64 -w -s -q -u Interactive "C:\Program Files (x86)"
accesschk64 -w -s -q -u Interactive "C:\Windows"

I am going over the results carefully and will modify the SRP policy as necessary.

Additional CmdLines can be also used:
Icacls "c:\Program Files" /findsid %username% /T /C >> programfiles.txt
accesschk64 -w -s -q -u "This Organization" "C:\Program Files" >> programfiles.txt
accesschk64 -w -s -q -u "Authentication authority asserted identity" "C:\Program Files" >> programfiles.txt
accesschk64 -w -s -q -u "Mandatory Label\Medium Mandatory Level" "C:\Program Files" >> programfiles.txt

The first CmdLine can give similar entries to the CmdLine for Users, but there can be also some additional entries. It should be performed on every user account. The last three CmdLines are probably important in Enterprises.
Similar procedures have to be done for "C:\Program Files (x86)" and for "C:\Windows".

Edit1.
The terms Users, Everyone, "Authenticated Users", Interactive, etc. depend on the language. For example, in my version of Windows, I have: Użytkownicy, Wszyscy, "Użytkownicy uwierzytelnieni", Interaktywna, etc.
These Groups can be found by using the CmdLine in the CMD console:

whoami /groups

In English-type Windows versions we have:

Edit2.
I had to use icalcs instead of accesschk64 to get the proper results for the current user. The accesscheck returned the results for the user with Admin rights.

Edit3
Everyone group includes all members of the Authenticated Users group, so the CmdLines with "Authenticated Users" are not necessary. Although the Everyone group includes "Authenticated Users" the CmdLines can give different results (checked by myself).

 

[wat0114]

Additional CmdLines can be also used:
Icacls "c:\Program Files" /findsid %username% /T /C >> programfiles.txt
accesschk64 -w -s -q -u "This Organization" "C:\Program Files" >> programfiles.txt
accesschk64 -w -s -q -u "Authentication authority asserted identity" "C:\Program Files" >> programfiles.txt
accesschk64 -w -s -q -u "Mandatory Label\Medium Mandatory Level" "C:\Program Files" >> programfiles.txt

The first CmdLine can give similar entries to the CmdLine for Users, but there can be also some additional entries. It should be performed on every user account.

When I process that first command, I get:

No files with a matching SID was found
Successfully processed 45711 files; Failed processing 3 files

I'm not really sure what this means, as this might be a bit above my technical reach

I feel pretty confident my policy protects against by far the most common userspace directories that malware targets, but ofc I don't want to overlook anything.

 

[wat0114]

Oops, found out C:\Windows\Tasks. Authenticated users have (WD) rights.

 

[Andy Ful]

When I process that first command, I get:

No files with a matching SID was found
Successfully processed 45711 files; Failed processing 3 files

You did it for the Windows folder which has permissions created mostly by Microsoft, so the result is OK. It can be useful for finding misconfigured application folders/files in "Program Files ...".

The CmdLine:
Icacls "c:\Program Files" /findsid %username% /T /C >> programfiles.txt
seeks the folders/files that can be accessed by the current user SID with standard rights (not necessarily RW permissions). Often, the current user SID is hidden under the "Creator Owner" template. Normally the application installation can create permissions both for the Users group and "Creator Owner" template. So, in my case, there is no difference in the results when using Icacls CmdLines for User and %username%.

 

[Minimalist]

You did it for the Windows folder which has permissions created mostly by Microsoft, so the result is OK. It can be useful for finding misconfigured application folders/files in "Program Files ...".

I found some directories with user assigned rights in Program files when I used Chrome installed system-wide. As I remember that change happened after one of updates so I had to blacklist that path.

 

[Andy Ful]

Blocking all writable paths in "Program Files ..." folders is necessary in Enterprises against targeted attacks. The attacker can already have information about installed applications and security layers via lateral movement.

I think, that It is not necessary in the Home environment on Windows 10 (well updated system and software) when the access to CmdLine is restricted by SRP (including shortcuts).
Nowadays, there are several fileless methods to run executable code (EXE, DLL, etc.) encoded in non-executable files. So, SRP should be focused on restricting access to CmdLine and scripting. If so, then in the Home environment it is improbable to drop malware into "Program Files ..." (except for some exploits).

 

[Ink]

I know that. I’m was responding to your quote: “If you are using third-party VM software, then you should Disable Hyper-V.” which is incorrect. OP can do what he wants with his system. Whether he disables it or not doesn’t make a difference. This is about his security setup. I’m done with this discussion about hyper-v with you.

Could you direct me to a source for your information, if not from Microsoft?

OP requested most critical feedback for their overall configuration.

Not seeing any VM software listed but with Hyper-V enabled could have meant two things; Hyper-V VM, Application Guard for Edge, Windows Sandbox. It was later stated they were not impressed by Windows Sandbox, nor any third-party VM software.

If I recall Hyper-V runs on boot, suspended in the background for on-demand use. I was suggesting a recommendation based on limited information. It could be using resources that may not be fully utilized, so from my perspective there's not much point of having it enabled. All Windows Features can be easily turned on and off. Streamlining Windows makes much more sense than having features you will never use.

You self-invited yourself to the conversation. "I'm done with this discussion".

 

[wat0114]

You did it for the Windows folder which has permissions created mostly by Microsoft, so the result is OK. It can be useful for finding misconfigured application folders/files in "Program Files ...".

Thanks, I will check "Program Files" again using icacls command.

 

[wat0114]

OP requested most critical feedback for their overall configuration.

Correct, I did and still welcome critical feedback, but only on my security configuration. As I stated earlier, I can't remember why I enabled it, but I'm pretty sure it was to support some sort of function of a program or a Windows process. As long as Hyper-V is harmless to keep it enabled, then with all due respect and with sincere thanks for providing feedback in trying to help, I'd rather not see feedback about it.

 

[Ink]

Correct, I did and still welcome critical feedback, but only on my security configuration. As I stated earlier, I can't remember why I enabled it, but I'm pretty sure it was to support some sort of function of a program or a Windows process. As long as Hyper-V is harmless to keep it enabled, then with all due respect and with sincere thanks for providing feedback in trying to help, I'd rather not see feedback about it.

Understood. I am not a pro-security Windows user, and rely on using web searches to find answers and post accordingly, with a source to verify.