Hard_Configurator - Windows Hardening Configurator

[Andy Ful]

Would it be a good Idea to add two new lolbins: update.exe and squirrel.exe ?

Microsoft Teams Can Be Used to Download and Run Malicious Packages

The update mechanism as it is currently implemented in Microsoft Teams desktop app allows downloading and executing arbitrary files on the system.

www.bleepingcomputer.com

Edit: My guess is Discordapp.com (desktop version) also use them. Atleast there is an squirrel.exe and update.exe in the folder.

These applications rely on the open source Squirrel project to manage installation and updating routines. They can be used by many applications, and their paths can be different. I tested these executables from the newest Discord and they can download the payload (.nupkg package).
Blocking them will block the application updates, so it has to be an individual decision. The best method would be manually blocking the concrete paths of update.exe and squirrel.exe by Firewall Hardening tool.
It is worth to remember that LOLBins can be dangerous only if something was already exploited. This is hardly possible on the well updated system/software on Windows 10.

 

[Freki123]

Thanks for your detailed explanation I really find them helpful
After you mentioned Firewall Hardening I wanted to take a look at your beta Firewall Hardening Tool.
x86 Version VT 7/66, Opswat with 3/37
x64 Version VT 3/68, Opswat 1/37 (Avira - read the note about the x86 version)
I know they will be FP but I got to admit it scared me off

 

[Marana]

EAM + H_C or HmP.A + H_C, would be fine.
H_C + OSA would not be a good idea.

@Andy Ful Out of curiosity, did you write that H_C + OSA would not be a good idea because you see a potential conflict, or just because there would be unnecessary overlap / "Defense in superfluous depth"?

 

[Andy Ful]

@Andy Ful Out of curiosity, did you write that H_C + OSA would not be a good idea because you see a potential conflict, or just because there would be unnecessary overlap / "Defense in superfluous depth"?

Some advanced OSA settings are in conflict with some H_C features (for example with ConfigureDefender). Both overlap a lot. H_C is more restrictive for the processes initiated with standard rights. Using them both is possible only for advanced users who understand well all their features.

 

[Marana]

Ah, now I see... (I hope). However with default settings OSA would most likely not conflict with H_C / ConfigureDefender, or what do you think?

 

[Andy Ful]

Ah, now I see... (I hope). However with default settings OSA would most likely not conflict with H_C / ConfigureDefender, or what do you think?

It will work well. You will probably never see OSA to work on default settings, because H_C is far more restrictive as default-deny setup.

 

[shmu26]

Some advanced OSA settings are in conflict with some H_C features (for example with ConfigureDefender).

Could you give us some details on that?

 

[Andy Ful]

Could you give us some details on that?

Advanced settings in OSArmor can block PowerShell actions required by ConfigureDefender.

Advanced settings in OSArmor can block PowerShell actions required by ConfigureDefender.

ConfigureDefender is whitelisted in OSA, but if you block PowerShell, then ConfigureDefender cannot work.

 

[shmu26]

ConfigureDefender is whitelisted in OSA, but if you block PowerShell, then ConfigureDefender cannot work.

Okay, but that's not exactly a showstopper, because you will see those popups from OSA telling you that powershell is blocked, and you can just disable OSA for a few minutes when you run ConfigureDefender. Anything more subtle that people should know about?

 

[Andy Ful]

Okay, but that's not exactly a showstopper, because you will see those popups from OSA telling you that powershell is blocked, and you can just disable OSA for a few minutes when you run ConfigureDefender. Anything more subtle that people should know about?

I do not know. I did not test OSArmor thoroughly. Many options are not documented, so this is a task for the user who runs them both for a long time. The best practice would be turn off OSArmor > run H_C and apply changes > turn on OSArmor again.

 

[shmu26]

I do not know. I did not test OSArmor thoroughly. Many options are not documented, so this is a task for the user who runs them both for a long time. The best practice would be turn off OSArmor > run H_C and apply changes > turn on OSArmor again.

Got it. There is always the possibility that OSA advanced settings might will prevent H_C configuration changes from being properly implemented.

 

[oldschool]

The best practice would be turn off OSArmor > run H_C and apply changes > turn on OSArmor again.

Or not bother with OSA in the first place if one uses H_C.

@Marana - The two together are overkill and unnecessary. Stay safe, not paranoid!

 

[shmu26]

Or not bother with OSA in the first place if one uses H_C.

Right! I just like to know what's under the hood.

 

[Marana]

It will work well. You will probably never see OSA to work on default settings, because H_C is far more restrictive as default-deny setup.

Yeah, that's what I'd expect. I have been running SSRP for years and configured WD via GPO, but it seems to me now that H_C might have become a more preferable solution that could replace them both.

One reason I'm interested in running both OSA and H_C is that AFAIK the MS Office Anti-Exploit feature in OSA is implemented via a separate kernel mode driver - meaning that it would need a technique of its own to bypass. I'm however willing to keep also Windows 10 built-in MS Office ASR rules (that are easy to configure via H_C / ConfigureDefender) active, although there are already documented ways to bypass at least some of them.

 

[shmu26]

the MS Office Anti-Exploit feature in OSA

This feature is not like ASR. It is like the "block child processes" ASR rule, with smart exceptions, but I don't think it does more than that one ASR rule.

 

[Andy Ful]

Yeah, that's what I'd expect. I have been running SSRP for years and configured WD via GPO, but it seems to me now that H_C might have become a more preferable solution that could replace them both.

One reason I'm interested in running both OSA and H_C is that AFAIK the MS Office Anti-Exploit feature in OSA is implemented via a separate kernel mode driver - meaning that it would need a technique of its own to bypass. I'm however willing to keep also Windows 10 built-in MS Office ASR rules (that are easy to configure via H_C / ConfigureDefender) active, although there are already documented ways to bypass at least some of them.

You will probably never see the malware trying to exploit MS Office or SRP policies (tweaked by H_C). So, using the OSA option to protect MS Office is unnecessary. Furthermore, WD ASR rules are probably more comprehensive and harder to bypass.
In theory, OSA advanced settings can save you if the exploit could achieve privilege escalation. But, such exploits are quickly patched by M$.
In the real world, you will get nothing from using H_C (default-deny) and OSA together, except a headache. After some time you will skip one of them for sure. If you like restricted default-allow (like most users), then keep OSA. Otherwise, keep H_C.

 

[Marana]

You will probably never see the malware trying to exploit MS Office or SRP policies (tweaked by H_C). So, using the OSA option to protect MS Office is unnecessary. Furthermore, WD ASR rules are probably more comprehensive and harder to bypass.
In theory, OSA advanced settings can save you if the exploit could achieve privilege escalation. But, such exploits are quickly patched by M$.
In the real world, you will get nothing from using H_C (default-deny) and OSA together, except a headache. After some time you will skip one of them for sure. If you like restricted default-allow (like most users), then keep OSA. Otherwise, keep H_C.

Thank you for your explanation. Since I have been using default-deny SRP for years, I cannot imagine living without it in the future, either. I guess that I'll keep OSA, too; at least till the first headache...

I was a bit surprised of your mentioning that WD ASR rules would probably be harder to bypass than OSA Anti-Exploit, although I must confess that I have not checked if the vulnerabilities presented in February's OffensiveCon have already been fixed (Emeric's presentation can be found here).

 

[Andy Ful]

...
I was a bit surprised of your mentioning that WD ASR rules would probably be harder to bypass than OSA Anti-Exploit, although I must confess that I have not checked if the vulnerabilities presented in February's OffensiveCon have already been fixed (Emeric's presentation can be found here).
...

They probably were not, because they are not vulnerabilities. ASR rules prevent techniques seen in the wild. If something new and prevalent will show up, then MS simply add more rules. Microsoft applied the anti-malware tactics which makes exploiting Windows security not profitable for malc0ders. It is more practical than trying to invent the bullet-proof security.
If you read the security reports, then it is evident that the malc0ders prefer social engineering methods, which are more profitable.
Bypassing ASR rules and exploiting AV modules is possible, but it is profitable only for the spying agencies, targetted attacks on big Enterprises, etc. For the home user, they are as dangerous as the meteor hitting Mars.

Edit.
From the fact that for most people using H_C + OSArmor is a bad idea, it does not follow that in your personal case it can be a good idea. I heard about some people who were happy with two wives (both alive).

 

[Marana]

- -
Edit.
From the fact that for most people using H_C + OSArmor is a bad idea, it does not follow that in your personal case it can be a good idea. I heard about some people who were happy with two wives (both alive).

... Well, actually the main reason for me to keep OSA (along with H_C and WD ASR) is the granularity it provides via Exclusion rules to allow controlled execution of selected PowerShell scripts, as well as to control what processes e.g. explorer.exe and mshta.exe are allowed to launch.

I find the Exclusions.db syntax both powerful and versatile, and I especially appreciate the possibility to use regular expressions within the rules!

 

[Andy Ful]

...
I find the Exclusions.db syntax both powerful and versatile, and I especially appreciate the possibility to use regular expressions within the rules!

Yes, it is a nice tool if you cannot block/restrict something by H_C. Did you see it working when using H_C in default-deny setup?

Edit.
Nobody can deny that the life ring (OSA) is a great thing on the boat (AV). But, is it really necessary on the boat in the desert (AV + H_C)? You will probably never see it working (the Noah case can be an exception).