Hard_Configurator - Windows Hardening Configurator

[Burrito]

Andy, I thought that you have commented on Microsoft Office protection in regards to H_C, Syshardener, and OSArmor. But I can't seem to find it. Or maybe I remember it incorrectly.

Did you make a comparison at some point?

My organization did some testing on 1903 that has me thinking about this..

 

[Andy Ful]

Andy, I thought that you have commented on Microsoft Office protection in regards to H_C, Syshardener, and OSArmor. But I can't seem to find it. Or maybe I remember it incorrectly.

Did you make a comparison at some point?

My organization did some testing on 1903 that has me thinking about this..

SysHardener mitigations in the section Vulnerable Software Tweaks, do not work properly on SUA. In fact, if you will start SysHardener on SUA, then you have to enter the admin password and then most of those mitigations will work for that admin account, but not for SUA.
This can be a problem in organizations. OSArmor has a special Anti-Exploit tab to configure hardening of MS Office. If you do not use OSArmor then you can use "Documents Anti-Exploit" tool (part of H_C, but available as standalone tool) for hardening MS Office and Adobe Acrobat Reader (XI or DC) on any standard user account (it has to be run separately on every SUA that you want to harden).

 

[Burrito]

SysHardener mitigations in the section Vulnerable Software Tweaks, do not work properly on SUA. In fact, if you will start SysHardener on SUA, then you have to enter the admin password and then most of those mitigations will work for that admin account, but not for SUA.
This can be a problem in organizations. OSArmor has a special Anti-Exploit tab to configure hardening of MS Office. If you do not use OSArmor then you can use "Documents Anti-Exploit" tool (part of H_C, but available as standalone tool) for hardening MS Office and Adobe Acrobat Reader (XI or DC) on any standard user account (it has to be run separately on every SUA that you want to harden).

Good info. As always, thanks Andy.

What my larger organization saw in limited testing.... 1903 actually is safer in some ways. Some attack vectors have been mitigated. But Microsoft Office is still a known attack surface. Since my organization looks at it in an enterprise sense, it's not that much help to those of us who run Office on our PCs. We just need to listen to Andy..

 

[shmu26]

SysHardener mitigations in the section Vulnerable Software Tweaks, do not work properly on SUA. In fact, if you will start SysHardener on SUA, then you have to enter the admin password and then most of those mitigations will work for that admin account, but not for SUA.

A possible workaround would be to convert the account to admin, run SysHardener, then convert it back to SUA. The problem is that to undo the changes, the user will have to remember to do the same.

 

[shmu26]

Another little flaw in SysHardener is that the firewall rules for MS Office are not correct for Office 365, because it has a different path than the standard Office installations.

 

[Gandalf_The_Grey]

Yes. This is one possibility. After switching OFF the protection you can see the content of the reg file and next apply it by pressing the Enter key on the reg file.

You can do it also without switching OFF the protection. Simply, change the .reg file extension to .txt and see the content of the file in the notepad. Next run regedit.exe and use <File><Import option> to apply the reg keys from this .txt file,

I now know the easiest and most secure way to work with reg files
What would be the best way to start the Command Prompt as Admin when you want to run for example sfc /scannow ?

 

[oldschool]

What would be the best way to start the Command Prompt as Admin when you want to run for example sfc /scannow ?

Go to Command > file location > run as smartscreen? I think that's how I've done it in the past.

 

[Gandalf_The_Grey]

Go to Command > file location > run as smartscreen? I think that's how I've done it in the past.

That's the same way I did it, but maybe there is a smarter way?

 

[shmu26]

I type cmd in the Windows search box, and in the results, there is an option to run as Admin.

 

[Gandalf_The_Grey]

I type cmd in the Windows search box, and in the results, there is an option to run as Admin.

Not for me, it's on the right click for the start menu, but I get an error message:

There is no app for this file...

Caused by a HC setting or something else?

 

[shmu26]

Not for me, it's on the right click for the start menu, but I get an error message:
View attachment 213814
There is no app for this file...

Caused by a HC setting or something else?

I think I better let Andy answer this...

********************************************

The DLLs are blocked only when <Enforcement> = 'All files'. This setting is not included in H_C Recommended Settings, because it requires advanced whitelisting for DLLs. But, it may be used by really advanced users.

So far, I have had best luck with Excubits Pumpernickel (FIDES) for blocking dll files. If I block read access to specific dlls, I can make specific allow rules that work. In my experience, dll rules can have unexpected results when execution is blocked. But blocking read access works. I tried this with the dll Sponsor rules from the new H_C.
This is my experimental Pumpernickel config (lots of * because I need to fit it into the demo limitations)

[#INSTALLMODE]
[LETHAL]
[LOGGING]
[WHITELISTMODIFY]
*>*
[BLACKLISTMODIFY]

[WHITELISTREAD]
!*MsMpEng.exe>*
!*svchost.exe>*\*api*
!*svchost.exe>*\*32*
!*smss.exe>*
!*bootim.exe>*32*
!*igfx*.exe>*api*
!ProcLogg*.exe>*32*
!*Off*ToRun.exe>*api*
!*Everything.exe>*
!*Macrium*>*
!*chrome.exe>*
!*armsvc.exe>*32*
!*TeamViewer.exe>*32*
!*WerFault.exe>*api*
!*explorer.exe>*32*
!*explorer.exe>*z*
!*explorer.exe>*vw*
!*csrss.exe>*
!*csrss.exe>*vw*
!*C:\Windows\Sys*Apps*>*32*
!*RuntimeBroker.exe>*32*
!*Set*SyncHost.exe>*vw*
!*Babylon.exe>*
!*rundll32.exe>*api*
!*rundll32.exe>*32*
!*pump*nick*>*
!*Dropbox*.exe>*32*
!*OneDrive.exe>*32*
!*Office16*>*32*
!*notepad.exe>*32*
!*SearchInd*.exe>*32*
!*GoogleUp*.exe>*32*
!*wmpnetwk.exe>*32*
!*reader_sl.exe>*api*
!*FoxitReader.exe>*
!*Smartscreen*.exe>*
[BLACKLISTREAD]
*>*system.management.automation.dll
*>*advpack.dll
*>*Ieadvpack.dll
*>*Ieaframe.dll
*>*jscript*.dll*
*>*jscript*.tlb*
*>*mshtml.dll
*>*lxssmanager.dll
*>*pcwutl.dll
*>*setupapi.dll
*>*shdocvw.dll
*>shell32.dll
*>*syssetup.dll
*>*url.dll
*>*zipfldr.dll
[EOF]

 

[Andy Ful]

Not for me, it's on the right click for the start menu, but I get an error message:
View attachment 213814
There is no app for this file...

Caused by a HC setting or something else?

This is the cause of the setting <Hide 'Run As Administrator'> = ON.
You can run elevated cmd as follows:
type cmd in the Windows search box > use 'Open file location' > use "Run As SmartScreen' on the highlighted entry (shortcut to cmd.exe).
The same will work for PowerShell, but you have to right-click to see the 'Open file location'.

 

[Gandalf_The_Grey]

This is the cause of the setting <Hide 'Run As Administrator'> = ON.
You can run elevated cmd as follows:
type cmd in the Windows search box > use 'Open file location' > use "Run As SmartScreen' on the highlighted entry (shortcut to cmd.exe).
The same will work for PowerShell.

Yes, thanks for the confirmation, that was how @oldschool and I were doing it.
Hoped there was maybe another smarter way, but this works.
Edit: Another option would be a shortcut to cmd.exe on the desktop. Then you can use Run As SmartScreen.

 

[shmu26]

Yes, thanks for the confirmation, that was how @oldschool and I were doing it.
Hoped there was maybe another smarter way, but this works.

Or you can un-hide Run As Administrator. If you are the only one on the computer with an Admin account, and only you know the Admin password, you should be okay with un-hiding it.

 

[Andy Ful]

So far, I have had best luck with Excubits Pumpernickel (FIDES) for blocking dll files.

That will work sometimes, but not always. The problem is that you have to whitelist some system processes like svchost.exe, explorer.exe, etc. These cause loading many DLLs into the memory, where they are ready to load by other applications, and they will not be blocked by FIDES.

Or you can un-hide Run As Administrator. If you are the only one on the computer with an Admin account, and only you know the Admin password, you should be okay with un-hiding it.

I would not recommend this. Both options "Run As SmartScreen" and "Run as administrator" can be easily confused, and then you will run the unsafe file via "Run as administrator" without SmartScreen check.
If you use elevated cmd frequently, then it is better to create a shortcut on Desktop or Start Menu, and use "Run As SmartScreen".

 

[shmu26]

That will work sometimes, but not always. The problem is that you have to whitelist some system processes like svchost.exe, explorer.exe, etc. These cause loading many DLLs into the memory, where they are ready to load by other applications, and they will not be blocked by FIDES.

So is it better not to block the dlls needed by svchost and explorer, and just block dlls from user space (with a few exceptions, such as OneDrive)? If I do it that way, I don't think I will need to whitelist the treacherous svchost and explorer.

EDIT: After mulling it over, I don't think my question was well thought-out. Either way, it will boil down to basically the same thing.
1 - 1= 0, and 0 - 0 = 0.

 

[Andy Ful]

So is it better not to block the dlls needed by svchost and explorer, and just block dlls from user space (with a few exceptions, such as OneDrive)? If I do it that way, I don't think I will need to whitelist the treacherous svchost and explorer.

You can block by default DLLs in UserSpace, but then you will have a problem with whitelisting applications in UserSpace and those which are installed in SystemSpace but update from UserSpace. That is why DLLs are not blocked in H_C's recommended settings.

 

[Andy Ful]

There is also another problem with blocking DLLs by FIDES, or generally by denying read access. The DLLs can be run as the file with any extension. So, you can run the DLL library as malware.txt or malware.tmp, etc. (binary with changed extension). This is the common way used in the wild. FIDES cannot recognize it (Bouncer and SRP can). Furthermore, most security solutions will fail when malware will use reflective DLL loading.
I think that FIDES can be useful for blocking the .NET libraries used by the system, like
system.management.automation.dll .
In my opinion, one cannot rely much on blocking DLLs.

 

[shmu26]

There is also another problem with blocking DLLs by FIDES, or generally by denying read access. The DLLs can be run as the file with any extension. So, you can run the DLL library as malware.txt or malware.tmp, etc. (binary with changed extension). This is the common way used in the wild. FIDES cannot recognize it (Bouncer and SRP can). Furthermore, most security solutions will fail when malware will use reflective DLL loading.
I think that FIDES can be useful for blocking the .NET libraries used by the system, like
system.management.automation.dll .
In my opinion, one cannot rely much on blocking DLLs.

Interesting!
Two questions:
1 If FIDES blocks read access to a certain dll, how can malware even see it, in order to run it with a different extension?
2 What about blocking system.management.automation.ni.dll ? Is there any justification for doing that?

 

[Andy Ful]

Interesting!
Two questions:
1 If FIDES blocks read access to a certain dll, how can malware even see it, in order to run it with a different extension?
2 What about blocking system.management.automation.ni.dll ? Is there any justification for doing that?

SRP and Bouncer can be used as a default deny because they can differ between a DLL with changed extension (for example, malware.dat) from non-executable file with the same name and extension (malware.dat). FIDES cannot do it. It would be hardly possible (or maybe with much effort) to use FIDES as default-deny in UserSpace.

The library system.management.automation.ni.dll has the same information for the concrete computer as system.management.automation.dll, so can be used by malware.