Hard_Configurator - Windows Hardening Configurator

F

ForgottenSeer 98186

Fun fact 3: using grandiloquent language while trying to convince (other) people that your 'best practice' is the best 'best practice', actually is not a best practice itself
I am not trying to convince anybody to do anything nor am I promoting anything. I have no incentive to convince anyone to do anything. I could care less what they do.

My replies were directed only to @Andy Ful and not anybody else.
 
F

ForgottenSeer 97327

I am not trying to convince anybody to do anything nor am I promoting anything. I have no incentive to convince anyone to do anything. I could care less what they do.

My replies were directed only to @Andy Ful and not anybody else.
Nope you replied to me in this post and only replied to fun fact 3 and ignored the two fun facts in this post

This is not the typical behavior of a compliance officer "I am not trying to convince anybody to do anything nor am I promoting anything. I have no incentive to convince anyone to do anything. I could care less what they do.", no wonder the 10.000 to hundred thousends endpoints you oversee are a mess.
 
Last edited by a moderator:
F

ForgottenSeer 98186

Nope you replied to me in this post
Nobody replied to you. It was to correct your misinformation.

This is not the typical behavior of a compliance officer "I am not trying to convince anybody to do anything nor am I promoting anything. I have no incentive to convince anyone to do anything. I could care less what they do.", no wonder the 10.000 to hundred thousends of endpoints you oversee are a mess.
You should stop getting triggered by what others say or do here at MT and focus on your data entry job.
 

Andy Ful

From Hard_Configurator Tools
Thread author
Verified
Honorary Member
Top Poster
Developer
Well-known
Dec 23, 2014
7,900
Guys, this interesting discussion becomes more and more personal. I know from experience on MT, that some posts can be interpreted differently by readers and sometimes a particular post does not exactly reflect what really the author thinks. We discussed the necessity of blocking LOLBins in H_C at home on Windows 10+. I think that all of us can agree with:
https://malwaretips.com/threads/hard_configurator-windows-hardening-configurator.66416/post-1032445

Of course, this will not remove some differences in how we think about security, but this thread is not for that.:)(y)
 
F

ForgottenSeer 97327

I had hoped, I could hangout with important piepels (dutch for people) overseeing hundred thousends of endpoints, what was I thinking? I Will do as I am told and focus on my data entry job ;)
 
Last edited by a moderator:

Andy Ful

From Hard_Configurator Tools
Thread author
Verified
Honorary Member
Top Poster
Developer
Well-known
Dec 23, 2014
7,900
What effect does configuring powershell.exe and powershell_ise.exe with Code Integrity Guard in Exploit Protection? 🤔 I believe @Max90 uses this in his config.
Code integrity guard (for powershell.exe or powershell_ise.exe) ensures that all binaries loaded or injected into a powershell.exe or powershell_ise.exe process are digitally signed by Microsoft.
This can help to mitigate some attacks, but most attacks use PowerShell in a different way.
For example, when PowerShell code runs rundll32 LOLBin to execute a DLL payload, the CIG does not check the DLL payload. It will be executed even if you protect powershell.exe via CIG. You should use CIG for rundll32.exe to block that DLL payload.
 
Last edited:

Andy Ful

From Hard_Configurator Tools
Thread author
Verified
Honorary Member
Top Poster
Developer
Well-known
Dec 23, 2014
7,900
It would be interesting to see how invasive can be the CIG mitigation for rundll32.exe and regsvr32.exe. These LOLBins are commonly used in attacks. :unsure:
The blocks can be controlled via Event Viewer (ID = 12):
Applications and Services\Microsoft\Windows\Security-Mitigations\Kernel Mode
Applications and Services\Microsoft\Windows\Security-Mitigations\User Mode
 
Last edited:
F

ForgottenSeer 97327

@Andy Ful and @oldschool

I have enabled Code Integrity Guard for

a) Important system processes also running at Medium IL
svchost.exe
explorer.exe
sihost.exe
dllhost.exe
UserOOBEBroker.exe
RuntimeBroker.exe
ApplicationFrameHost.exe

b) Powerful system processes (are blocked to run as standard user by SRP)
rundll32.exe (running DLL's)
regsvr32.exe (registering DLL's)
regini (setting/changing registry values/permission)
cacls and icacls.exe (setting file permissions)
forfiles (passing arguments/commands to files)
powershell.exe (it is the only command processor I have not disabled)

c) Processes which are nearly always running (and might be tempted to target by a sarcastic malware writer)
smartscreen.exe
SecurityHealthSystray.exe
widgets.exe

d) Windows processes easy to target, because every Windows PC has them
Write.exe
Notepad.exe
MSpaint.exe
Calc.exe

e) Microsoft Office programs and Edge broker process (renderer has SIG enabled by default) for same reason (most of corporate PC's have them)

This is only possible when you use Microsoft Defender as Antivirus, because many 3p Antivirus inject DLL's in vulnarable processes.

This is based on information I found on a website for admins (I forgot which) where admins shared info on which processes could be added to Code Integrity without running into performance or compatibilty problems. When I recall correctly they used three two for selecting the processes
1. System processes to important not to run in a pristine state (only running Microsoft signed or co-signed stuff) = (my a and b)
2. Processes nearly always running in medium IL (= my c) or installed (my d and e) these are the often attacked because malware writers know they are on a PC.

They considered the best prestine state as running virtualized, the second as Protected Process and third with Code Integrity Guard
 
Last edited by a moderator:

Andy Ful

From Hard_Configurator Tools
Thread author
Verified
Honorary Member
Top Poster
Developer
Well-known
Dec 23, 2014
7,900
@Andy Ful and @oldschool

I have enabled Code Integrity Guard for

a) Important system processes also running at Medium IL
svchost.exe
explorer.exe
sihost.exe
dllhost.exe
UserOOBEBroker.exe
RuntimeBroker.exe
ApplicationFrameHost.exe

b) Powerful system processes
rundll32.exe
regsvr32.exe
powershell.exe (it is the only scriptor I allowed elevated, as standard user it is blocked by SRP)

c) Processes which are nearly always running (and might be tempted to target by a sarcastic malware writer)
smartscreen.exe
SecurityHealthSystray.exe
widgets.exe

d) Windows processes easy to target
Write.exe
Notepad.exe
MSpaint.exe
Calc.exe

e) Microsoft Office programs and Edge broker process (renderer has SIG enabled by default)

This is only possible when you use Microsoft Defender as Antivirus, because many 3p Antivirus inject DLL's in vulnarable processes

Do you control the possible silent blocks via Event Viewer?
 
  • Like
Reactions: Trident
F

ForgottenSeer 97327

Do you control the possible silent blocks via Event Viewer?
No, but I am running a nearly Microsoft only setup (only using Macrium and Syncback as other software), so never ran into problems (since 2019). Because I get bored with the same setup, I probably implement some corner case hardening practices. The reasons of the people on that admin website made sense to me (protecting the pristine state of important and powerful processes and raising the bar for easy to target always running or installed processes to lower the predictable succes of intrusions). I think the website was called the lazy admin or something like that).
 
Last edited by a moderator:

Andy Ful

From Hard_Configurator Tools
Thread author
Verified
Honorary Member
Top Poster
Developer
Well-known
Dec 23, 2014
7,900
F

ForgottenSeer 97327

@Andy Ful Restarted my PC and ran all programs, only seeing Information events, so nothing is blocked or goes wrong :) (for these critical processes besides the defaults I have enabled: block remote images, enable CIG, block, disable extension points and validate image dependency).
1679924458644.png
 
Last edited by a moderator:
  • Like
Reactions: Andy Ful
F

ForgottenSeer 98186

Code integrity guard (for powershell.exe or powershell_ise.exe) ensures that all binaries loaded or injected into a powershell.exe or powershell_ise.exe process are digitally signed by Microsoft.
This can help to mitigate some attacks, but most attacks use PowerShell in a different way.
For example, when PowerShell code runs rundll32 LOLBin to execute a DLL payload, the CIG does not check the DLL payload. It will be executed even if you protect powershell.exe via CIG. You should use CIG for rundll32.exe to block that DLL payload.
DLL injection into the list of processes given would be a very uncommon attack method. The configuration of Code Integrity Guard for them is basically just PoC based upon speculation that it can happen. Morphisec discovered a bypass of CIG in 2018 but it was never any kind of threat. It is an interesting discussion topic though.
 

Andy Ful

From Hard_Configurator Tools
Thread author
Verified
Honorary Member
Top Poster
Developer
Well-known
Dec 23, 2014
7,900
@Andy Ful Restarted my PC and ran all programs, only seeing Information events, so nothing is blocked or goes wrong :) (for these critical processes besides the defaults I have enabled: block remote images, enable CIG, block, disable extension points and validate image dependency).
View attachment 273908
I also cannot see any blocks on my computer. There are several scheduled tasks that use rundll32, but they use Microsoft-signed DLLs (signed by catalog). If I correctly remember some web browser extensions can use rundll32 to run. There are probably some applications that can use rundll32 to run DLLs.
 
F

ForgottenSeer 98186

If I correctly remember some web browser extensions can use rundll32 to run. There are probably some applications that can use rundll32 to run DLLs.
This is correct. Internet Explorer. Not only that, but also IE used rundll32 to perform network checks.
 
  • Like
Reactions: Andy Ful

Andy Ful

From Hard_Configurator Tools
Thread author
Verified
Honorary Member
Top Poster
Developer
Well-known
Dec 23, 2014
7,900
DLL injection into the list of processes given would be a very uncommon attack method. The configuration of Code Integrity Guard for them is basically just PoC based upon speculation that it can happen. Morphisec discovered a bypass of CIG in 2018 but it was never any kind of threat. It is an interesting discussion topic though.
If I correctly remember, PowerSploit uses PowerShell code to inject EXE/DLL into powershell.exe (Invoke-ReflectivePEInjection). But it uses in-memory injection which probably can bypass CIG.
Anyway, there were several examples in the wild when DLLs were injected into rundll32, dllhost, svchost, Explorer, etc. But in fact, the attacker can use any process which is commonly used on users' computers.

Edit.
It seems that lsass, svchost, and taskhost are the most popular targets.
 
Last edited:
F

ForgottenSeer 97327

If I correctly remember, PowerSploit uses PowerShell code to inject EXE/DLL into powershell.exe (Invoke-ReflectivePEInjection). But it uses in-memory injection which probably can bypass CIG.
Anyway, there were several examples in the wild when DLLs were injected into rundll32, dllhost, svchost, Explorer, etc. But in fact, the attacker can use any process which is commonly used on users' computers.

Edit.
It seems that lsass, svchost, and taskhost are the most popular targets.
I have SIG enabled for all medium IL processes (so also TaskHost). I have not enabled SIG on lsass because it runs as ProtectedProcess (forgot what I had to enable on Windows 10).

Because the hacker can inject a DLL i any process, but also wants his/her intrusion to be succesful on many Windows PC's they probably focussed on the most common ones. That is why those admins also advised enabled SIG for popular processes which were always running/installed.
 
F

ForgottenSeer 98186

If I correctly remember, PowerSploit uses PowerShell code to inject EXE/DLL into powershell.exe (Invoke-ReflectivePEInjection).
Yes, IIRC the attack requires a reverse shell (e.g. via a weaponized document or an agent). That type of attack is thwarted easily by using SWH. Not really a threat to a home user - unless that home user is a member of National Security Bureau (Polish: Biuro Bezpieczeństwa Narodowego, BBN) with data on their system that a nation state adversary wants.

But it uses in-memory injection which probably can bypass CIG.
IIRC this was how Morphisec bypassed CIG.

Anyway, there were several examples in the wild when DLLs were injected into rundll32, dllhost, svchost, Explorer, etc. But in fact, the attacker can use any process which is commonly used on users' computers.
The injection can be easily thwarted again by preventing execution of common file types. SWH is going to prevent these sorts of attacks. I'm sure there are corner cases where such an attack could succeed, but realistically they are not much of a threat. So hardening the system against them is overkill for the unlikely instance of a system exploit or other clever attack.

Adding a bunch of processes to CIG is the exploit protection equivalent of adding 250 LOLBins to a block list. While both can be done at the home user level, it just is not necessary for a home user except in extreme circumstances (e.g. a home user lives in a nation that oppresses dissidents and they are being targeted by the government; think FinSpy).

It is always good infos to know, just-in-case. Overall though, as you've previously stated, these sorts of configurations provide little additional protection.

Edit.
It seems that lsass, svchost, and taskhost are the most popular targets.
My data collected from the field shows: svchost, explorer, taskhost and lsass (less commonly targeted now due to Microsoft's increased lsass memory protections).
 
  • Like
Reactions: SirJon and Andy Ful

Andy Ful

From Hard_Configurator Tools
Thread author
Verified
Honorary Member
Top Poster
Developer
Well-known
Dec 23, 2014
7,900
I have SIG enabled for all medium IL processes (so also TaskHost). I have not enabled SIG on lsass because it runs as ProtectedProcess (forgot what I had to enable on Windows 10).

Because the hacker can inject a DLL i any process, but also wants his/her intrusion to be succesful on many Windows PC's they probably focussed on the most common ones. That is why those admins also advised enabled SIG for popular processes which were always running/installed.
SIG or CIG? :)
Process injections are used late in the infection chain. That is why I am interested in CIG mitigation for rundll32 and regsvr32 (DLL is loaded by these LOLBins) which are commonly used at the early stage. Such mitigations could be interesting when using only ConfigureDefender on Windows 10+. This possibility must be tested because the ASR prevalence rule may check DLLs when executed via rundll32 or regsvr32 (I am not sure).
 
Last edited:

About us

  • MalwareTips is a community-driven platform providing the latest information and resources on malware and cyber threats. Our team of experienced professionals and passionate volunteers work to keep the internet safe and secure. We provide accurate, up-to-date information and strive to build a strong and supportive community dedicated to cybersecurity.

User Menu

Follow us

Follow us on Facebook or Twitter to know first about the latest cybersecurity incidents and malware threats.

Top