New Update Simple Windows Hardening

[rndmblk]

Hi @Andy Ful

Kaspersky with Application Control can be set to work similarly to Trusted Application Mode, so all executables and some popular script types run in the Untrusted group if they are unknown in KSN. Such settings + disabling the option which trusts applications that have a digital signature are sufficiently strong and do not require additional protection via SWH.

Is this comment referring to the settings outlined by @RoboMan here - Kaspersky's Application Control: what is it, how it works

The reason I ask is that I reinstalled KIS today and configured it in line with those settings (there are some slight window layout changes since 2019 but otherwise the same AFAIK):

1. Under Settings, open Application Control
2. Untick ‘trust digitally signed applications’ (due to possibility of stolen/bad certs)
3. Set ‘Trust group for applications that could not be added to existing groups’ to Untrusted
4. Set ‘Trust group for applications started before startup of Kaspersky’ to Low Restricted

Hope it's ok to ask here - I know this isn't the eKaspersky forum but I do use SWH so was interested in your comment.

 

[Evjl's Rain]

hello Andy, I would like to ask a question about this app
I entered Protected SRP extensions -> remove BAT extension from the list -> save -> my .bat script (non-elevated) was still blocked unless I ran it with admin's privileges
Did I do something wrong
I use my Admin account on windows 8.1
Thank you

 

[Andy Ful]

hello Andy, I would like to ask a question about this app
I entered Protected SRP extensions -> remove BAT extension from the list -> save -> my .bat script (non-elevated) was still blocked unless I ran it with admin's privileges
Did I do something wrong
I use my Admin account on windows 8.1
Thank you

SRP protects scripts and scriptlets in 2 ways:

1. By file extension (VBS, JS, ..., BAT, CMD, PS1, MSI, CHM, JAR, HTA, etc.)
2. By monitoring scripting engines (VBScript, JScript, Windows Command Shell, MSI Installer)

The first is related to file associations and can block also other file types (included in the list of Protected SRP extensions). It is similar to SysHardener, but SWH allows whitelisting (not possible in SysHardener).

The second is independent of file associations and is triggered when the scripting engine is executed (wscript.exe, cscript.exe, cmd.exe). It will block scripting in SWH when the <Software Restriction Policies>. So even the script embedded in a TXT file will be blocked, for example:
wscript.exe /e:vbscript D:\helloworld.txt”.

If you want to run scripts managed by VBScript, JScript, Windows Command Shell, or MSI Installer engines you have to whitelist them (scripts in the Windows and Program Files .... folders are whitelisted by default).

 

[Evjl's Rain]

SRP protects scripts and scriptlets in 2 ways:

1. By file extension (VBS, JS, ..., BAT, CMD, PS1, MSI, CHM, JAR, HTA, etc.)
2. By monitoring scripting engines (VBScript, JScript, Windows Command Shell, MSI Installer)

The first is related to file associations and can block also other file types (included in the list of Protected SRP extensions). It is similar to SysHardener, but SWH allows whitelisting (not possible in SysHardener).

The second is independent of file associations and is triggered when the scripting engine is executed (wscript.exe, cscript.exe, cmd.exe). It will block scripting in SWH when the <Software Restriction Policies>. So even the script embedded in a TXT file will be blocked, for example:
wscript.exe /e:vbscript D:\helloworld.txt”.

If you want to run scripts managed by VBScript, JScript, Windows Command Shell, or MSI Installer engines you have to whitelist them (scripts in the Windows and Program Files .... folders are whitelisted by default).

Thank you for you answer
is it possible to whitelist .bat or cmd.exe universally without having to whitelist one by one?

 

[Andy Ful]

Thank you for you answer
is it possible to whitelist .bat or cmd.exe universally without having to whitelist one by one?

Yes (not recommended) by using whitelisting entry:
*.bat
It can be done via <Add Path*Wildcards> button.
Anyway, it is better to keep these files in a previously whitelisted folder(s). The detection of BAT and CMD files is not supported by AMSI so generally, their detection is poor. The attack vector via BAT and CMD files is dangerous due to abusing LOLBins.

Post edited.

 

[Andy Ful]

Hi @Andy Ful



Is this comment referring to the settings outlined by @RoboMan here - Kaspersky's Application Control: what is it, how it works

The reason I ask is that I reinstalled KIS today and configured it in line with those settings (there are some slight window layout changes since 2019 but otherwise the same AFAIK):

1. Under Settings, open Application Control
2. Untick ‘trust digitally signed applications’ (due to possibility of stolen/bad certs)
3. Set ‘Trust group for applications that could not be added to existing groups’ to Untrusted
4. Set ‘Trust group for applications started before startup of Kaspersky’ to Low Restricted

Hope it's ok to ask here - I know this isn't the eKaspersky forum but I do use SWH so was interested in your comment.

Something like that. Please ask @Harlan to confirm.

 

[Andy Ful]

I'm confused, where did this Interactive setting come from all of a sudden? Its not a setting I see in Configure Defender. And what are these 3 ASR rules?

Microsoft extended the ASR options (Warn option was added).
https://malwaretips.com/threads/configuredefender-utility-for-windows-10.79039/post-935829
These 3 rules are the only ASR rules disabled in the HIGH preset. In the INTERACTIVE setup, they are set to WARN.
All ASR rules that support the Warn setting are set to WARN in the INTERACTIVE preset. From the security viewpoint, the INTERACTIVE preset will block/detect the same as HIGH preset + these 3 rules.

 

[harlan4096]

Something like that. Please ask @Harlan to confirm.

Yes, I use a similar approach, I am a bit more paranoid:



But as I said in previous pots about this config, it may lead to block some "legit" applications (no digitally signed) during install and/or execution if They are not enough known or unknown in KSN... but still We can to manually move them to Trusted group to avoid the blocking...

 

[Kuttz]

Hello, does SWH compatible with Windows 10 May 2021 update (21H1) ??

 

[Andy Ful]

Hello, does SWH compatible with Windows 10 May 2021 update (21H1) ??

Yes.

 

[Kuttz]

@Andy Ful

A fabulous peace of software and been using it for past 2 weeks. For my usage pattern not much block incidents happened yet if at all any, a truly set and forget style. Despite I love default deny software like NVT EXE Radar Pro, HIPS in general the inconvenience it causes during installation of legitimate programs, running .exe files the amount of prompts is a turn off for me.

As you rightly said protection from execution of .exe and MSI files can be taken care of by a good Anti Virus. Reducing the attack surface yet without interfering my system usage pattern is what I was looking for and this is the perfect software people like me needed.

Currently I am using SWH + ESET Anti Virus + YogaDNS (NextDNS service) Enabled all hardware security features meeting "Windows Standard Hardware Security"

Everything is running lean, unhindered, responsive yet Secure.

 

[Andy Ful]

...
Everything is running lean, unhindered, responsive yet Secure.

Be safe.

 

[Andy Ful]

Post updated.

Simple Windows Hardening vs. NOBELIUM attacks.

I posted about these attacks in another thread, but it is interesting that simple prevention can stop such sophisticated attacks.

LNK file is used to run the malicious payload (like malicious DLL or shellcode encoded in the RTF document). It is a common technique to make detection harder by abusing LOLBins.
SWH will prevent the attack on the delivery stage by blocking the LNK files in UserSpace, so the execution of the malicious payload is stopped.
If the user does not use ISO images of optical disks (CD, DVD, Blue-ray), then the ISO file extension can be also added to the extensions blocked by SWH settings

Edit1.
Unfortunately, the opening of the ISO files is managed by the Windows built-in handler that does not support SRP. But, ISO files can be still protected by SRP when they are opened by 3rd party applications like WinISO or Deamon Tools.

Edit2.
Nobelium uses RunDll LOLBin to execute DLL payloads. This can also be blocked when using Microsoft Defender with the enabled ASR rule "Block executable files from running unless they meet a prevalence, age, or trusted list criteria".

 

[ForgottenSeer 85179]

LNK file is used to run the malicious payload (like malicious DLL or shellcode encoded in the RTF document). It is a common technique to make detection harder by abusing LOLBins.
SWH blocks by default the LNK files in UserSpace, so the execution of the malicious payload is prevented.
If the user does not use ISO images of optical disks (CD, DVD, Blue-ray), then the ISO file extension can be also added to the extensions blocked by SWH settings.

Same for Hard_Configurator?

 

[wat0114]

Simple Windows Hardening vs. NOBELIUM attacks.

I posted about these attacks in another thread, but it is interesting that simple prevention can stop such sophisticated attacks.

View attachment 258772
LNK file is used to run the malicious payload (like malicious DLL or shellcode encoded in the RTF document). It is a common technique to make detection harder by abusing LOLBins.

So in this case the malicious file is actually the msdiskmountservice.dll Beacon loader? The .LNK file only serves to launch it, much like a shortcut launching an executable? I use SRP in Windows 10 Pro to restrict all file types (DLL included) and I don't retrict .LNK file types because they are associated to shortcuts, meaning I'd have to whitelist a ton of them if I did restrict them.

 

[Andy Ful]

Same for Hard_Configurator?

Yes.

So in this case the malicious file is actually the msdiskmountservice.dll Beacon loader? The .LNK file only serves to launch it, much like a shortcut launching an executable?

Yes. The LNK files (shortcuts) can use LOLBins (like RunDLL in the NOBELIUM case) to execute EXE, DLL, or run shellcode embedded & encoded in other files (documents, pictures, etc.). Doing this indirectly via LOLBins, the attack is harder to detect by AVs.

I use SRP in Windows 10 Pro to restrict all file types (DLL included) and I don't retrict .LNK file types because they are associated to shortcuts, meaning I'd have to whitelist a ton of them if I did restrict them.

The shortcuts are used in the standard locations like Desktop, Start Menu, etc. Other locations should be blocked for shortcuts (like in H_C or SWH). The problem is that most people do not know how to do it properly. The proper way requires the combination of many Disallowed and Unrestricted SRP rules ( I use 41 rules in SWH/H_C ).

 

[wat0114]

Yes.


Yes. The LNK files (shortcuts) can use LOLBins (like RunDLL in the NOBELIUM case) to execute EXE, DLL, or run shellcode embedded & encoded in other files (documents, pictures, etc.). Doing this indirectly via LOLBins, the attack is harder to detect by AVs.


The shortcuts are used in the standard locations like Desktop, Start Menu, etc. Other locations should be blocked for shortcuts (like in H_C or SWH). The problem is that most people do not know how to do it properly. The proper way requires the combination of many Disallowed and Unrestricted SRP rules ( I use 41 rules in SWH/H_C ).

Thanks Andy. I use OSArmor to restrict LOLBinis, so I think for the time being I won't worry about enforcing .LNK files.

 

[Andy Ful]

Thanks Andy. I use OSArmor to restrict LOLBinis, so I think for the time being I won't worry about enforcing .LNK files.

OSA looks like a good solution. The current version has an option to block LOLBins and sophisticated attacks. It would be interesting to test this option. You cannot block all possibilities without unpleasant consequences. But, OSA will block most attacks via LOLBins, for sure.

 

[blackice]

OSA looks like a good solution. The current version has an option to block LOLBins and sophisticated attacks. It would be interesting to test this option. You cannot block all possibilities without unpleasant consequences. But, OSA will block most attacks via LOLBins, for sure.

Yes I have seen a false positive from this that messed up an install because I forgot to disable OSA for the install. But it works

 

[wat0114]

Yes I have seen a false positive from this that messed up an install because I forgot to disable OSA for the install. But it works

Likewise, the occasional issue here, but it does seem to work well.


@Andy Ful ,

wouldn't a LOLBin have to launch a malicious file typically dropped in user space? And if this is the case, tight SRP or other anti-executable restrictions should probably stop it?

I think I verified it stops the executable in user space. I created a small batch file:

start powershell.exe Start-Process C:\users\myname\desktop\wfc6setup.exe

and just called it powershell.bat

wfc6setup.exe is just a simple firewall interface utility. SRP blocked it:

Access to C:\Users\myname\Desktop\wfc6setup.exe has been restricted by your Administrator by the default software restriction policy level.

BTW, just to get this to execute this far, I had to literally add two exclusions to OSArmor, as it's LOLBin protections wouldn't allow the batch file to launch In fact, I had to create an allow path rule in SRP in order to launch the batch file.