Hard_Configurator - Windows Hardening Configurator

[shmu26]

What version of MS Office you have and what is the error alert?

Office 2016 Standard. It says there are macros in the document, but the "document" is the .dotm add-on files in STARTUP folder

 

[Andy Ful]

Office 2016 Standard. It says there are macros in the document, but the "document" is the .dotm add-on files in STARTUP folder

Delete the below value (VBAOFF), or set the value to 0:
[HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Office\16.0\Common]
"VBAOFF"=dword:00000001
This mitigation disables VBA interpreter system-wide for all MS Office applications. If you unblock VBA, then you will be able to control the execution of macros in MS Office applications.
The above will be possible also in the next Hard_Configurator version (thanks to you).

 

[shmu26]

Delete the below value (VBAOFF), or set the value to 0:
[HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Office\16.0\Common]
"VBAOFF"=dword:00000001
This mitigation disables VBA interpreter system-wide for all MS Office applications. If you unblock VBA, then you will be able to control the execution of macros in MS Office applications.
The above will be possible also in the next Hard_Configurator version (thanks to you).

I don't seem to have the registry key in that place, and when I searched registry for VBAOFF I didn't find anything.
I tried creating a key with those values, but it didn't work.

 

[Andy Ful]

Strange. Do you have <Documents Anti-Exploit> = ON ?
Is the issue still present when <Documents Anti-Exploit> = OFF ?

 

[shmu26]

Strange. Do you have <Documents Anti-Exploit> = ON ?
Is the issue still present when <Documents Anti-Exploit> = OFF ?

Wait, I think I know the problem. This registry key is created only when I have <Documents Anti-Exploit> = ON ?
I did it the other way around. I looked for the key before I enabled that setting.

 

[Andy Ful]

Hard_Configurator writes to the Registry only one macro-related key:
[HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Office\16.0\Common]
"VBAOFF"=dword:00000001
If changing <Documents Anti-Exploit> to OFF did not work, then probably some other program made changes related to macros. SysHardener uses another key:
HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Word\Security]
"VBAWarnings"=dword:00000001

 

[shmu26]

Nope, that didn't do it. I enabled the setting, but I don't see that registry key. See screenshots.

 

[shmu26]

Hard_Configurator writes to the Registry only one macro-related key:
[HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Office\16.0\Common]
"VBAOFF"=dword:00000001
If changing <Documents Anti-Exploit> to OFF did not work, then probably some other program made changes related to macros. SysHardener uses another key:
HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Word\Security]
"VBAWarnings"=dword:00000001

Just saw your post. Now I will try "off" and see if that helps.

 

[Andy Ful]

Nope, that didn't do it. I enabled the setting, but I don't see that registry key. See screenshots.

This is not the right key!!! You missed Policies.

 

[shmu26]

This is not the right key!!! You missed Policies.

Duh!! Now it worked. I deleted the key. The anti-exploit setting now says "partial", and I can use Word normally.
What protection does this give me, if I am not using WD?

 

[Andy Ful]

Duh!! Now it worked. I deleted the key. The anti-exploit setting now says "partial", and I can use Word normally.
What protection does this give me, if I am not using WD?

This is a very strong protection. It disables totally the macros in all MS Office applications. It is also in HKLM Registry hive, so cannot be reverted by non-elevated malware/exploit. WD ASR is also strong, but macros can still be run. If one would try to compare VBA to PowerShell, then ASR is on the level of Constrained Language Mode and VBAOFF is like blocking System.Management.Automation.dll.
.
But, if you have blocked macros in MS Office via Trust Center, then it is also OK (if you are cautious) - the main difference is that this setting can be changed by non-elevated malware/exploit. Furthermore, the inexperienced user can easily press the button in MS Office to allow macros for the infected document.

 

[shmu26]

This is a very strong protection. It disables totally the macros in all MS Office applications. It is also in HKLM Registry hive, so cannot be reverted by non-elevated malware/exploit. WD ASR is also strong, but macros can still be run. If one would try to compare VBA to PowerShell, then ASR is on the level of Constrained Language Mode and VBAOFF is like blocking System.Management.Automation.dll.

Cool, thanks

 

[Andy Ful]

But, if you have blocked macros in MS Office via Trust Center, then it is also OK (if you are cautious) - the main difference is that this setting can be changed by non-elevated malware/exploit. Furthermore, the inexperienced user can easily press the button in MS Office to allow macros for the infected document.

 

[oldschool]

I’m considering switching to H_C when I change my configuration. It’s evolved enough and possibly I have as well.

 

[shmu26]

I’m considering switching to H_C when I change my configuration. It’s evolved enough and possibly I have as well.

Do you use standard (limited) user account? It's part of the SRP ecosystem. SRP doesn't do much to stop elevated processes, so you want to keep the bad ones from elevating.

 

[shmu26]

@Andy Ful could this new tool be useful?
EOPRadar - Privilege escalation vulnerability scanner

 

[Andy Ful]

@Andy Ful could this new tool be useful?
EOPRadar - Privilege escalation vulnerability scanner

What this app does:

1. It can check only already running programs, so the user has to run one program (at least) from every folder which contains executables.
2. It can check if the program path can be writable.
3. If the path is writable and the process is running as standard user, then it will be marked as yellow.
4. If the path is writable and the process managed to elevate on SUA, then it will be marked as red (vulnerable).
5. If the program from point 3 is executed via "Run as administrator" from Explorer context menu, then it will be also marked as red (vulnerable).

For the Hard_Configurator user (default-deny setup), this app can be useful to check the concrete application from Program Files or whitelisted paths. Sometimes, but rarely, applications can use some folders by changing their ACL privileges to writable (normally all subfolders in Program Files are not writable as standard user). Almost all folders whitelisted by the user in the Userspace are also writable (by default) if the user did not adopt ACL restrictions.
Whitelisted folders area is the potential vulnerability, but it is very hard to make use of it in the home user environment (network protected by NAT router), with default-deny settings and forced SmartScreen. Even when something will be exploited, the malware will not know which folders are whitelisted, except the standard possibilities like OneDrive path. The OneDrive path is specially whitelisted in Hard_Configurator so if the malware with the random name will be copied there, then execution will be blocked. For the paranoid type of security, the user can also whitelist executables by hash.
Another solution will be restrict whitelisted folders by ACL to make them not executable with admin rights or not writable. The first possibility is OK, if executables located in the whitelisted folder do not elevate and update program from that folder does not require elevation, too (quite possible).
The second possibility is OK, if the executable does not write anything essential in that folder.
Another (paranoid) possibility is using a special program (Fides, Secure Folders, Easy File Locker, etc) or WD Controlled Folder Access.

 

[Andy Ful]

Do you use standard (limited) user account? It's part of the SRP ecosystem. SRP doesn't do much to stop elevated processes, so you want to keep the bad ones from elevating.

I’m considering switching to H_C when I change my configuration. It’s evolved enough and possibly I have as well.

Generally, SUA is much safer than Admin Account. But, when using Hard_Configurato default-deny setup, the difference is less important.
The malware on Admin Account is more dangerous, because it has much more possibilities to elevate. But with default-deny setup + forced SmartScreen, the malware execution will be mostly blocked or mitigated in the Userspace, before it can elevate. That is valid also for exploits distributed as executables. Other vulnerabilities come from applications that can be exploited by opening the files with vulnerable content. Most such files are blocked by Hard_Configurator, except media files, documents and some other frequently used file types. This is also well mitigated by default-deny setup. In fact, the Hard_Configurator restrictions for MS Office applications, are stronger on Admin Account (because it is more vulnerable).
Assuming that you are using well-updated Windows and Edge (or Chrome), the last dangerous area is related to the vulnerable & not patched applications. If you have such applications, then it is really better to use SUA + apply Exploit Guard restrictions + block outbound Internet connection for those applications.

 

[oldschool]

Do you use standard (limited) user account? It's part of the SRP ecosystem. SRP doesn't do much to stop elevated processes, so you want to keep the bad ones from elevating.

Yes. SUA.

 

[Andy Ful]

Yes. SUA.

Do you use some applications installed outside of Program Files (except OneDrive)?