New Update Simple Windows Hardening

[Andy Ful]

@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?

It is hard to bypass SRP + OSA (properly configured). SRP cannot block .NET DLLs, and probably OSA too. But, executing .NET DLLs via LOLBins usually requires PowerShell or Windows Script Host. PowerShell is already highly restricted to Constrained Language Mode when SRP Default Security Level is set to Disallowed - this can prevent Powershell to load .NET DLLs. Also, other scripting engines can be restricted by SRP/OSA.
The same is true for running the shellcode encoded in documents, pictures, etc. But SRP + OSA requires more attention and maintenance compared to SRP with properly blocked shortcuts (like in H_C). Many things are doubly blocked by SRP and OSA. Sometimes, it is really hard to find out how to whitelist applications in the User Space, especially when DLLs are blocked. There can be also problems with Windows Updates and software updates.
Your SRP + OSA protection model is rather designed for businesses (possible attacks from the Local Network).
Anyway, you seem to like it. So, you can probably live with it.

 

[wat0114]

Anyway, you seem to like it. So, you can probably live with it.

You are absolutely right Thanks!

 

[wat0114]

Sometimes, it is really hard to find out how to whitelist applications in the User Space, especially when DLLs are blocked. There can be also problems with Windows Updates and software updates.

I forgot to respond to this earlier. No doubt you know about this already, there is a way to enable Advanced logging - for blocked DLL's especially - in SRP, which I have found invaluable for identifying blocked DLL's and even some executables, though the latter I typically find in Event Viewer:

https://www.itprotoday.com/security/q-how-can-we-verify-software-restriction-policy-srp-rule-we-defined-one-our-applications

 

[Andy Ful]

I forgot to respond to this earlier. No doubt you know about this already, there is a way to enable Advanced logging - for blocked DLL's especially - in SRP, which I have found invaluable for identifying blocked DLL's and even some executables, though the latter I typically find in Event Viewer:

https://www.itprotoday.com/security/q-how-can-we-verify-software-restriction-policy-srp-rule-we-defined-one-our-applications

Yes. In H_C one can still use Advanced logging. I left this option for users who would like to block also DLLs by SRP via the reg tweak. The H_C Log can also filter the logged DLLs to show only DLLs blocked by SRP in the User Space (many system DLLs are skipped for clarity).
Anyway, in the Home environment, I prefer the security model which can efficiently block the malware before it could load/run malicious DLLs or use LOLBins. It is much easier (and more efficient) to block malware in the early infection stage. Furthermore, such protection is simpler and easier to understand.

Edit
This idea is also true for SWH, except that EXE and MSI files must be efficiently protected by the AV, SmartScreen, or a kind of file reputation service in the cloud. The cautious users can be simply cautious with EXE or MSI files.

 

[Andy Ful]

Simple Windows Hardening vs. advanced attacks.

In another thread, I posted the article about testing EDRs. The attack vectors were as follows:

The attack method in the article starts with some spear-phishing emails that try to lure the target user into opening a file or follow a link that will be used to compromise the victim’s host. The authors crafted some emails with links to cloud providers that lead to some custom malware. The malicious files were CPL, HTA, and EXE files, plus DLL file (side loading attack).

Although such attacks are prevented by H_C in the Recommended Settings, the SWH alone can block only some of them. The malicious CPL and HTA files will be blocked by SWH. But EXE and DLL files will be blocked only when the user would try to open the file from an email client or archiving application (supported by SWH).

Anyway, in the Home environment, the execution of EXE files will be detected/blocked in most cases by the AV because never seen malware is rarely used in widespread attacks. Even if the malware will be never-seen one, then it will be often blocked by SmartScreen Application Reputation (files downloaded from the Internet).
If one uses Defender with ConfigureDefender settings, then the EXE malware will be also prvented while using USB drives. With ConfigureDefender MAX settings the EXE file (malicious) will be blocked by the ASR prevalence rule.

The only problem can be with the attack based on the legal EXE file vulnerable to DLL side loading. This attack can be prevented only when running suspicious EXE files by using RunBySmartScreen (as suggested in the SWH manual). Unfortunately, the standard AVs will often allow such an attack. Fortunately, this attack vector is rare (so far) in widespread attacks.

 

[Andy Ful]

The way you configure SRP has everything to do how effective it is. Even though SRP has been deprecated by Microsoft so it remains a great part of Windows Security. Cool.

There are good reasons for Microsoft to stop developing SRP, but still keep it alive. One of them is backward compatibility. Many people still use SRP alone or to support Applocker. Some Applocker bypasses can be prevented by properly configured SRP. That is why SRP survived also in Windows 11.

 

[Andy Ful]

Very interesting, thank you for letting me know! I researched SRP extensively a few months ago and Microsoft built SRP in stages. SRP is SRP version 1, Applocker is SRP version 2 and WDAC is SRP version 3. Microsoft will continue to refine and include SRP in future generations of Windows because enterprises use it.

There is continuity on the idea level, but the technical implementation of WDAC is very different. From the viewpoint of Home users, WDAC is the most problematic/inconvenient solution (for now).

 

[Andy Ful]

Simple Windows Hardening vs. advanced attacks.
Microsoft Office exploit CVE-2021-40444

This exploit can be seen as an evolution of the MS Office exploitation via abusing OLE/ActiveX. The old attack was based on a payload (CPL file, script, etc.) embedded in the MS Office document. The user was convinced by the attacker to click the icon in the document. This caused to drop of the embedded file (payload) to the user Temp folder and Word requested opening the payload by the OS. For example, the file association for CPL file is defined in the Windows Registry:

At this moment the SRP (used in SWH to block files like CPL, INF, etc.) checks the file path and blocks the file execution.

The new exploit does not use the payload embedded in the document body, but uses MSHTML to update the document. Microsoft Word must download a web page, from the URL referenced into the document. The web content uses JavaScript code executed into MSHTML ActiveX component of Microsoft Word - the payloads are dropped/extracted to disk. There is no payload in the document, but still Word requests opening the payload by the OS, so SRP can block it.

The infection chain on the chart is for the version which downloads the payloads from the Internet, but it can be modified to do its work locally.
The JavaScript code applies the value « .cpl:123 » to the « document.URL » parameter. This allows opening the file with any extension (the INF extension was chosen in the wild) as a CPL file.

CVE-2021-40444 vulnerability: the response of Stormshield products

Stormshield's protection against a new Zero-Day. A critical vulnerability in Internet Explorer, analysed with Stormshield Customer Security Lab.

www.stormshield.com

Analyzing attacks that exploit the CVE-2021-40444 MSHTML vulnerability | Microsoft Security Blog

This blog details our in-depth analysis of the attacks that used the CVE-2021-40444, provides detection details and investigation guidance for Microsoft 365 Defender customers, and lists mitigation steps for hardening networks against this and similar attacks.

www.microsoft.com

Edit
On September 2021 Patch Tuesday, Microsoft has fixed this exploit.

 

[Andy Ful]

I was rather surprised that SRP and Windows Policies configured by SWH could mitigate some MS Office MSHTML exploits. Generally, such exploits have to be patched by Microsoft.
I spent a lot of time when trying to bypass SRP via this exploit. Finally, I found out how to do it.
After modifications, the exploit could bypass SRP protection for CPL files but still, SRP blocked it for Windows scripts (JScript, VBScript, etc.).
Next, I updated Windows (Microsoft patch was installed) and Windows blocked the old and modified exploits without the help from SWH.

 

[Digmor Crusher]

I use Sumo to check for program updates, today it shows an update for SWH, version 6.0.0.0, I'm thinking this is wrong. Does this update exist Andy? thanks.

 

[JasonUK]

I use Sumo to check for program updates, today it shows an update for SWH, version 6.0.0.0, I'm thinking this is wrong. Does this update exist Andy? thanks.

Maybe they updated it as I have the same combination (SUMO/SWH) but no update shown for v1.0.0.2 in Sumo

 

[Andy Ful]

I use Sumo to check for program updates, today it shows an update for SWH, version 6.0.0.0, I'm thinking this is wrong. Does this update exist Andy? thanks.

I did not publish any update of SWH - version 6.0.0.0 can be probably related (by mistake) to H_C.
In October I will publish SWH beta 1.01.0 (with Windows 11 support).

 

[Digmor Crusher]

Not showing it today, maybe I was hallucinating.

 

[SeriousHoax]

Hard_Configurator's files are stored in "C:\Windows" but it's not the same for Simple Windows Hardening. It doesn't seem to store any files anywhere. Is that correct?

 

[Andy Ful]

Hard_Configurator's files are stored in "C:\Windows" but it's not the same for Simple Windows Hardening. It doesn't seem to store any files anywhere. Is that correct?

SWH is a portable application, so it does not store files on the disk. The settings (SRP &Windows Policies) are stored in the Windows Registry.

 

[Andy Ful]

Not showing it today, maybe I was hallucinating.

I refrained myself on time from choosing the "like" option.

 

[SeriousHoax]

SWH is a portable application, so it does not store files on the disk. The settings (SRP &Windows Policies) are stored in the Windows Registry.

Ok I see. BTW, I was wondering why the logging feature of HC and SWH is different. I mean HC contains all logs in a single file while SWH has separate logs for SRP, Powershell and Admin WSH. Is there any special reason, or just a design choice that you made?

 

[Andy Ful]

Ok I see. BTW, I was wondering why the logging feature of HC and SWH is different. I mean HC contains all logs in a single file while SWH has separate logs for SRP, Powershell and Admin WSH. Is there any special reason, or just a design choice that you made?

H_C uses an external application (FullEvntLog) to display the events.

SWH is a portable application, so I skipped FullEventLog tool and started using Windows built-in tool (wevtutil) + my filtering function to display the events.

wevtutil

Reference article for wevtutil, which lets you retrieve information about event logs and publishers.

docs.microsoft.com

Wevtutil creates different outputs for SRP, PowerShell, and Windows Script Host events. With some effort, I could gather different outputs into one file, but I am not sure if this would be a better idea. The most troublesome are usually SRP blocks so making a separate output for them seems to be reasonable.

I am thinking about skipping FullEventLog in H_C, and using the idea of separate logs for SRP, PowerShell, Defender, and FirewallHardening. In most cases, the advanced users can recognize what sort of block has happened and can choose the right log to see the details. Next, it is easier to inspect the log witch is focused on the specific class of events. Only rarely, the user will be forced to use two or more logs to solve the problem with blocked processes.

 

[Digmor Crusher]

I refrained myself on time from choosing the "like" option.

Aw come on, you could have liked it.

 

[Gandalf_The_Grey]

You have integrated all those help files and no one bothers to read them. It is just easier to come here and ask you. Typical behavior.

That is actually quite sad, the attention to detail with the helpfiles is amazing.
@Andy Ful does such a great job with his programs and the support he provides here