Serious Discussion WHHLight - simplified application control for Windows Home and Pro.

[Andy Ful]

Is it possible to add autocheck and auto update functionality in the background.
For example the installer will add a script or small program that checks for updates everyday and auto downloads the new binaries.

I am not a fan of auto-updates. My applications do not require frequent updates (probably one update per year).
It is possible that in the future I will add the option to check for the update (like in Hard_Configurator).

 

[Andy Ful]

WHHLight vs. LODEINFO (spear-phishing attacks)
https://malwaretips.com/threads/lod...s-and-remote-code-tricks.128638/#post-1073323

DOWNIISSA shellcode:
https://securelist.com/apt10-tracking-down-lodeinfo-2022-part-i/107742/

According to information released by security vendors, APT campaigns using LODEINFO target Japanese media, diplomacy, public institutions, defense industries, and think tanks. It is also suggested that the infamous APT group called APT10 is involved given the similarities in their methods and malwares.

This is not a typical attack against home users, but I used it to show how the WHHLight package can help prevent/mitigate some interesting attack vectors.

Attack flow:

The attack can be stopped/mitigated by the WHHLight package on several infection stages.
The recommended way is based on hardening MS Office applications.

This can be done manually or by using the DocumentsAntiExploit tool (included in the package).
When using that tool, the VBA code is blocked and the user cannot allow it from the configuration panel of MS Office applications. The attack is prevented at the early infection stage.

In the case of allowed macros, the attack can be prevented by the FirewallHardening settings when blocking outbound connections of MS Office applications.

In this particular case, the macro injects the shellcode into the running Word process (WINWORD.exe). Next, the shellcode uses the URLDownloadToFileA() API function to download the payloads. The download will fail when outbound connections of Word are blocked.

If the shellcode is not mitigated, it decrypts the payload, drops three files in the user Temp folder, and executes one of them (as a child process of WINWORD.exe) to apply DLL Hijacking. This can be blocked if the user applies ConfigureDefender with a HIGH Protection Level (ASR rule blocks the child process).

If the user does not use DocumentsAntiExploit, FireWallHardening, or ConfigureDefender then WHHLight should be configured with SUPER_SAFE or TWO_ACCOUNTS setup. If so, then the DLL Hijacking can be blocked by WDAC.

 

[Azazel]

If I want to use WDAC and hardened it by removing recommended whitelist folders. Should I keep appdata/local/temp to avoid most false positives?

 

[Andy Ful]

If I want to use WDAC and hardened it by removing recommended whitelist folders. Should I keep appdata/local/temp to avoid most false positives?

Yes, especially false positives related to the software auto-updates.

 

[ForgottenSeer 107474]

Question to @Andy Ful

When I run standard user on Windows11 with SWH and Windows Defender on Max (with Documents Anti-Exploit and Firewall Hardening blacklisting LoLbins, Office and Adobe), with disabled CMD (with last version of SysHardener, because Win11 uses Powershell), do I miss out a lot of security features compared to WHHLight?

 

[Andy Ful]

Question to @Andy Ful

When I run standard user on Windows11 with SWH and Windows Defender on Max (with Documents Anti-Exploit and Firewall Hardening blacklisting LoLbins, Office and Adobe), with disabled CMD (with last version of SysHardener, because Win11 uses Powershell), do I miss out a lot of security features compared to WHHLight?

Not much.
The main difference is related to usability. For some users, Defender MAX settings are acceptable. Others can prefer Defender + WDAC TROUBLE-FREE setup.

 

[ForgottenSeer 107474]

Not much.
The main difference is related to usability. For some users, Defender MAX settings are acceptable. Others can prefer Defender + WDAC TROUBLE-FREE setup.

Thanks a lot or the reply. Like @oldschool I have a fairly common/vanilla software setup. Besides Windows11 and Office + Chrome no other software except my restaurant menu card maker . For security I am only using your software (and NPE + Sophos scan & clean free as secondary scanners before yearly image backup), so I have never noticed any problems using WD on Max (and standard user).

 

[Andy Ful]

Be safe.

 

[ForgottenSeer 107474]

@Andy Ful

Since you know so much about build-in Windows security, may I ask you a question about the difference between UAC and running standard user.

I started running standard user, because people who know (and Microsoft) always tell that UAC is not a real security boundary. But for a layman it is hard to understand the explanation. The reason most often provided by experts is that UAC is not a real security boundary while standard user is.

Do I understand correctly (in layman's terms) that "not a real/hard" boundary is because:

1. A standard user does not has the elevated rights/tokens, while an admin with UAC has those tokens assigned, but they are shielded/disabled through UAC. Not in the list is a hard boundary, while in the list, but not granted at that moment, is a soft(ware) boundary. A standard user simply does not has those rights in his/her lists, so they can't be misused.
   
   
2. Running with different user rights in same context/profile (e.g; Admin and Standard User), makes security complex (with confusing names as user rights, integrity levels, object permissions/process tokens/access control"). An example is the Creater/Owner rights of files/folders created as (elevated) admin being inherited as standard user.
   
   
3. Microsoft treats user boundary issues (e.g. Admin and Standard user) with higher priority and stricter rules than UAC issues or sometimes leaves them open by design (increasing the risk of vulnerabilities, I read something related to this about the UAC internal whitelist).

Above with the WHH light execution whitelists (for all users, even higher rights than admin) and risky file blocking (for standard users) make a two user WHH light setup so strong?

 

[Andy Ful]

@Andy Ful

Since you know so much about build-in Windows security, may I ask you a question about the difference between UAC and running standard user.

I started running standard user, because people who know (and Microsoft) always tell that UAC is not a real security boundary. But for a layman it is hard to understand the explanation. The reason most often provided by experts is that UAC is not a real security boundary while standard user is.

Do I understand correctly (in layman's terms) that "not a real/hard" boundary is because:

1. A standard user does not has the elevated rights/tokens, while an admin with UAC has those tokens assigned, but they are shielded/disabled through UAC. Not in the list is a hard boundary, while in the list, but not granted at that moment, is a soft(ware) boundary. A standard user simply does not has those rights in his/her lists, so they can't be misused.
   
   
2. Running with different user rights in same context/profile (e.g; Admin and Standard User), makes security complex (with confusing names as user rights, integrity levels, object permissions/process tokens/access control"). An example is the Creater/Owner rights of files/folders created as (elevated) admin being inherited as standard user.
   
   
3. Microsoft treats user boundary issues (e.g. Admin and Standard user) with higher priority and stricter rules than UAC issues or sometimes leaves them open by design (increasing the risk of vulnerabilities, I read something related to this about the UAC internal whitelist).

Point one is crucial.

Above with the WHH light execution whitelists (for all users, even higher rights than admin) and risky file blocking (for standard users) make a two user WHH light setup so strong?

The strength of TWO-ACCOUNTS setup follows from its post-exploitation prevention on SUA and less restrictive setup on Admin. Even if some legal application has been exploited on SUA, the post-exploitation processes cannot elevate to access the disk locations whitelisted in WDAC. So, those processes are mostly blocked.

 

[Andy Ful]

WHHLight vs. Ars Technica campaign.
https://malwaretips.com/threads/ars...r-before-seen-obfuscation.128722/post-1073729
https://arstechnica.com/security/20...-campaign-with-never-before-seen-obfuscation/

Update February 2024:

https://www.mandiant.com/resources/blog/unc4990-evolution-usb-malware

In this post, I will focus on the early stages of the infection flow (malware's new features will not be visible). The initial attack vector is very popular and the Ars Technica campaign is one of many examples.

Attack flow (initial part):
The user opens a shortcut from the infected flash drive ----> the shortcut runs a PS1 script hidden on the flash drive ----> the script decrypts and manages intermediate payloads ----> EMPTYSPACE downloader is dropped and executed

Initial Compromise: USB LNK​

In all instances of the infection which Mandiant Managed Defense responded to, the infection began with the victim double-clicking a malicious LNK shortcut file on a removable USB device. The naming convention for the LNK file typically consisted of the vendor of the USB device and the storage size in brackets, for example: KINGSTON (32GB).lnk. Mandiant also observed instances where, instead of the vendor name, the drive label was used, for example: D (32GB).lnk.

In addition to this, the icon of the LNK file was set to the Microsoft Windows default icon for drives. This was likely done to entice unsuspecting users to double click the file, ultimately triggering the functionality embedded in the LNK file.

The default SWH settings in WHHLight prevent the attack by blocking LNK shortcuts in UserSpace. Furthermore, if the shortcut was skipped in the attack, the PS1 script would be blocked anyway.
Unfortunately, I could not find the PS1 samples, so I am not sure if the Powershell Constrained Language restrictions could prevent the script from creating intermediate payloads (decryption methods are usually blocked).
Update February 2024: The recent code of explorer.ps1 can be found in the Madiant article. It uses the invocation method [System.Text.encoding]::UTF8.getstring(), which is blocked by Constrained Language mode. So, the script cannot even decode its active content and the attack fails.


Full attack flow:

 

[normalizerx]

Hello, Andy Ful, at the moment I'm using hard_configurator with configure defender set to high. How does this compare to WHHLight. If I uninstal HC and replace it with WHHLight - are there advantages to such a set-up or security-wise it will be similar?

 

[Azazel]

Does wdac block scripts?

 

[oldschool]

Does wdac block scripts?

Yes.

 

[Andy Ful]

Hello, Andy Ful, at the moment I'm using hard_configurator with configure defender set to high. How does this compare to WHHLight. If I uninstal HC and replace it with WHHLight - are there advantages to such a set-up or security-wise it will be similar?

Similar.
WHHLight is simpler, but not as configurable as H_C.

 

[Andy Ful]

Does wdac block scripts?

Yes and No.
Generally, WDAC policies can block Windows scripts (as @oldschool noticed). But in WHHLight, the WDAC policies are configured to block only Portable Executable files (EXE, SCR, COM, DLL, etc.) and MSI files, because the SWH option already blocks Windows scripts + many other file types (via Software Restriction Policies).
So, Windows scripts, scriptlets, etc. are blocked/whitelisted independently from Portable Executable files.

 

[sypqys]

Hi !


if I put recommended folder in Whitelist, Windows works fine or not ?

Can I restart my computer ?


Thanks !!

 

[sypqys]

Why H_C doesn't want to open ?

 

[sypqys]

"CHANGE and EXIT ". All is OK ?

 

[ErzCrz]

Why H_C doesn't want to open ?

You need to choose which hardening software to run H_C hardens your system like WHHL but is more advanced and more configurable. So use either WHHL or H_C but not the two together.