ConfigureDefender utility for Windows 10/11

[In2an3_PpG]

And if so, do you know the PS commands for adding them?

This Enable ASR rules individually to protect your organization might help. Under "Use PowerShell to enable or audit Attack surface reduction rules"

 

[Andy Ful]

...
Add-MpPreference -AttackSurfaceReductionRules_Ids 9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2 -AttackSurfaceReductionRules_Actions Enabled

"Block credential stealing from the Windows local security authority subsystem (lsass.exe)"
...

Thanks, @shmu26.
The right entry is included in your post.
It seems that one of the updates made some more ASR mitigation available also in Windows 10 ver. 1709.
They will be included in the next version of ConfigureDefender tool.

 

[shmu26]

This Enable ASR rules individually to protect your organization might help. Under "Use PowerShell to enable or audit Attack surface reduction rules"

Yeah, the powershell commands work. I was kinda hoping for a tutorial that held my hand a little more tightly, but it does work.

1 You must be careful to use Add-MpPreference and not Set-MpPreference if you already have some ASR rules and you don't want to delete them

2 The command to use is Add-MpPreference -AttackSurfaceReductionRules_Ids put the rule ID here -AttackSurfaceReductionRules_Actions Enabled

The IDs for the rules are:

Block executable content from email client and webmail
BE9BA2D9-53EA-4CDC-84E5-9B1EEEE46550

Block Office applications from creating child processes
D4F940AB-401B-4EFC-AADC-AD5F3C50688A

Block Office applications from creating executable content
3B576869-A4EC-4529-8536-B80A7769E899

Block Office applications from injecting code into other processes
75668C1F-73B5-4CF0-BB93-3ECF5CB7CC84

Block JavaScript or VBScript from launching downloaded executable content
D3E037E1-3EB8-44C8-A917-57927947596D

Block execution of potentially obfuscated scripts
5BEB7EFE-FD9A-4556-801D-275E5FFC04CC

Block Win32 API calls from Office macro
92E97FA1-2EDF-4476-BDD6-9DD0B4DDDC7B

Block executable files from running unless they meet a prevalence, age, or trusted list criteria
01443614-cd74-433a-b99e-2ecdc07bfc25

Use advanced protection against ransomware
c1db55ab-c21a-4637-bb3f-a12568109d35

Block credential stealing from the Windows local security authority subsystem (lsass.exe)
9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2

Block process creations originating from PSExec and WMI commands
d1e49aac-8f56-4280-b9ba-993a6d77406c

Block untrusted and unsigned processes that run from USB
b2b3f03d-6a65-4f7b-a9c7-1c7ef74a9ba4

 

[Andy Ful]

You can also use commands for many mitigations, for example:
Enable mitigations

Set-MpPreference -AttackSurfaceReductionRules_Ids BE9BA2D9-53EA-4CDC-84E5-9B1EEEE46550,D4F940AB-401B-4EFC-AADC-AD5F3C50688A,3B576869-A4EC-4529-8536-B80A7769E899,75668C1F-73B5-4CF0-BB93-3ECF5CB7CC84,D3E037E1-3EB8-44C8-A917-57927947596D,5BEB7EFE-FD9A-4556-801D-275E5FFC04CC,92E97FA1-2EDF-4476-BDD6-9DD0B4DDDC7B -AttackSurfaceReductionRules_Actions Enabled,Enabled,Enabled,Enabled,Enabled,Enabled,Enabled

Disable mitigations

Set-MpPreference -AttackSurfaceReductionRules_Ids BE9BA2D9-53EA-4CDC-84E5-9B1EEEE46550,D4F940AB-401B-4EFC-AADC-AD5F3C50688A,3B576869-A4EC-4529-8536-B80A7769E899,75668C1F-73B5-4CF0-BB93-3ECF5CB7CC84,D3E037E1-3EB8-44C8-A917-57927947596D,5BEB7EFE-FD9A-4556-801D-275E5FFC04CC,92E97FA1-2EDF-4476-BDD6-9DD0B4DDDC7B -AttackSurfaceReductionRules_Actions Disabled,Disabled,Disabled,Disabled,Disabled,Disabled,Disabled

 

[shmu26]

Thanks. That clears up my registry question.
The remaining question is whether
5. "Block credential stealing from the Windows local security authority subsystem (lsass.exe)" (9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2)
actually does anything on win 10 pro.
Microsoft documentation says that Credential Guard is not present in the pro editions, only in Enterprise and Education. So maybe this lsass.exe rule is not really doing anything?

The ASR rule for lsass is now operative, in Windows 10 Pro 1803.
I already had it set to "enabled", even though it was not doing anything, but a couple days ago I started getting error messages from Windows Defender, and lots of log entries, all related to lsass.exe.
When I disabled the rule for lsass, the errors ceased.
So it works, but I don't recommend it, because it conflicts with a lot of programs, and you can't make exceptions.

 

[Andy Ful]

I am testing the new version of Configuredefender - added the ASR rules introduced in Windows 10 ver. 1803.
The below rules were confirmed to work:

• Block executable files from running unless they meet a prevalence, age, or trusted list criteria
• Block process creations originating from PSExec and WMI commands
• Block untrusted and unsigned processes that run from USB

There is no documentation for the rules, so I cannot say why the first rule blocks Configuredefender and does not block Hard_Configurator???

Some rules are hard to test, so I will test them soon:

• Use advanced protection against ransomware
• Block credential stealing from the Windows local security authority subsystem (lsass.exe)

The last two rules are completely silent on my computer.

 

[shmu26]

I am testing the new version of Configuredefender - added the ASR rules introduced in Windows 10 ver. 1803.
The below rules were confirmed to work:

• Block executable files from running unless they meet a prevalence, age, or trusted list criteria
• Block process creations originating from PSExec and WMI commands
• Block untrusted and unsigned processes that run from USB

There is no documentation for the rules, so I cannot say why the first rule blocks Configuredefender and does not block Hard_Configurator???

Some rules are hard to test, so I will test them soon:

• Use advanced protection against ransomware
• Block credential stealing from the Windows local security authority subsystem (lsass.exe)

The last two rules are completely silent on my computer.

Also for me, the ransomware rule is silent.
But the lsass rule caused Windows error messages from VMware. When I opened Windows Event Viewer, I saw block entries also for Macrium Reflect and for Norton Family. (I don't have Norton AV, only the standalone Family web filter).

Here is an example of a block entry:

Windows Defender Antivirus has blocked an operation that is not allowed by your IT administrator.
For more information please contact your IT administrator.
ID: 9E6C4E1F-7D60-472F-BA1A-A39EF669E4B2
Detection time: 2018-05-21T15:27:25.803Z
User: NT AUTHORITY\SYSTEM
Path: C:\Windows\System32\lsass.exe
Process Name: C:\Program Files\Macrium\Common\MacriumService.exe
Signature Version: 1.267.1712.0
Engine Version: 1.1.14901.4
Product Version: 4.16.17656.18051

 

[Andy Ful]

I also tested Network Protection feature in ConfigureDefender using FireFox Portable against URL:
SmartScreen Test
This also works well now (there were problems some months ago).
.
Microsoft improved the ASR Rule:
Impede JavaScript and VBScript to launch executables: D3E037E1-3EB8-44C8-A917-57927947596D
Now it can also block the script that has downloaded the executable from the Internet and tries running the executable via WMI and MMC.

 

[Andy Ful]

My system is configured for testing all ASR rules set to ON. Furthermore, I am trying to understand how works the ASR rule:
"Block executable files from running unless they meet a prevalence, age, or trusted list criteria".
Here are my findings:

1. The rule supports exclusions, but that worked well for me only after some reboots. I excluded C:\Windows and C:\Program Files ...
2. All my already installed applications (in C:\Program Files...) and portable programs on the second disc could be executed without a problem, also the legal programs downloaded from the Internet.
3. The fresh compilation of ConfigureDefender could be run from the excluded folder, but was blocked in other locations (A, B, ...).
4. When I turned OFF the ASR rule temporarily and run the fresh compilation of ConfigureDefender in the location A, it was checked in Defender cloud and after several seconds Defender allowed it to run. Next, after I turned the ASR rule ON again, the fresh compilation of ConfigureDefender in the location A was NOT BLOCKED anymore. But, this was not true for the same file in another location B. So, this ASR rule could get the information from the Defender local AI about the previous file execution history.

I am curious, how long this ASR rule will block the fresh compilation of ConfigureDefender in the location B. I am waiting for the Microsoft article on how this rule can be managed.

 

[shmu26]

My system is configured for testing all ASR rules set to ON. Furthermore, I am trying to understand how works the ASR rule:
"Block executable files from running unless they meet a prevalence, age, or trusted list criteria".
Here are my findings:

1. The rule supports exclusions, but that worked well for me only after some reboots. I excluded C:\Windows and C:\Program Files ...
2. All my already installed applications (in C:\Program Files...) and portable programs on the second disc could be executed without a problem, also the legal programs downloaded from the Internet.
3. The fresh compilation of ConfigureDefender could be run from the excluded folder, but was blocked in other locations (A, B, ...).
4. When I turned OFF the ASR rule temporarily and run the fresh compilation of ConfigureDefender in the location A, it was checked in Defender cloud and after several seconds Defender allowed it to run. Next, after I turned the ASR rule ON again, the fresh compilation of ConfigureDefender in the location A was NOT BLOCKED anymore. But, this was not true for the same file in another location B. So, this ASR rule could get the information from the Defender local AI about the previous file execution history.

I am curious, how long this ASR rule will block the fresh compilation of ConfigureDefender in the location B. I am waiting for the Microsoft article on how this rule can be managed.

This rule does not seem so useful in a default/deny setup. But in default/allow, I can see that it might be useful.
It reminds me a little of the autocontainment rule for Comodo, specifically in the Firewall Configuration, where by default it allows all files that are older than a few days.

 

[Andy Ful]

It would be interesting to test against the real malware the ASR rule:
"Block executable files from running unless they meet a prevalence, age, or trusted list criteria".
The above rule is a kind of reputation rule based on a prevalence, age, or trusted list criteria.
That would be the cover for SmartScreen, because the EXE or DLL malware files downloaded and ran by scripts are usually ignored by SmartScreen. If the user activated Defender Network Protection, then a connection to the malicious website can be blocked (if the website is known as malicious).
In theory, this rule can be also useful in Defender + Hard_Configurator set to allow EXE & DLL files. That would be a similar idea as Avast Hardened Aggressive mode with blocked/restricted scripts or Comodo Firewall with Sandbox set to block.
The rule is supposed to block also PowerShell and WSH scripts, but I prepared a simple trojan downloader that bypassed all ASR rules (script downloaded and ran the EXE payload). So, blocking scripts by this rule is not so strong. Anyway, if the payload was malicious then it should be stopped by "Block executable files from running unless they meet a prevalence, age, or trusted list criteria".

 

[Andy Ful]

Finally, I managed to confirm that the ASR rule:
Block credential stealing from the Windows local security authority subsystem (lsass.exe)
works on my computer. This rule was totally silent until today, when I noticed that it blocked
C:\Windows\System32\taskhostw.exe from accessing lsass.exe.
Next, I downloaded the tool Remote DLL : Simple & Free Tool to Inject or Remove DLL from Remote Process | www.SecurityXploded.com and ran it with admin rights. When I tried to choose the target process for injection, Windows showed the blocking alert, and I could see that lsass.exe is missing on the list of available target processes.
In the Event Viewer (Event Id 1121) I could check that C:\Program Files (x86)\SecurityXploded\Remote DLL\RemoteDll64.exe could not access lsass.exe.
As in the case of some other ASR rules, this rule woke up after some reboots. I tested it before with RemoteDll and there was not any blocking alert.

 

[shmu26]

Finally, I managed to confirm that the ASR rule:
Block credential stealing from the Windows local security authority subsystem (lsass.exe)
works on my computer. This rule was totally silent until today, when I noticed that it blocked
C:\Windows\System32\taskhostw.exe from accessing lsass.exe.
Next, I downloaded the tool Remote DLL : Simple & Free Tool to Inject or Remove DLL from Remote Process | www.SecurityXploded.com and ran it with admin rights. When I tried to choose the target process for injection, Windows showed the blocking alert, and I could see that lsass.exe is missing on the list of available target processes.
In the Event Viewer (Event Id 1121) I could check that C:\Program Files (x86)\SecurityXploded\Remote DLL\RemoteDll64.exe could not access lsass.exe.
As in the case of some other ASR rules, this rule woke up after some reboots. I tested it before with RemoteDll and there was not any blocking alert.

Thanks for the report.

I am hoping to hear more about smart ways to implement the rule for "Block executable files from running unless they meet a prevalence, age, or trusted list criteria". It sounds like it might be a good protection.

 

[shmu26]

Can you export ASR rules as a reg file from Regedit, and then import them on a different computer?

 

[Andy Ful]

Can you export ASR rules as a reg file from Regedit, and then import them on a different computer?

You can do it for ASR rules applied via Windows Policies (as administrator).
The ASR rules applied via ConfigureDefender or PowerShell cmdlets require higher rights (System, WinDefend, TrustedInstaller).
Anyway, there is a simple way to transfer the rules made by ConfigureDefender (PowerShell cmdlets) to another computer (Windows Policies). One should export the rules (all ON in the below example):
.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Defender\Windows Defender Exploit Guard\ASR]

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Defender\Windows Defender Exploit Guard\ASR\ASROnlyExclusions]
"C:\\Windows"=dword:00000000
"C:\\Program Files"=dword:00000000
"C:\\Program Files (x86)"=dword:00000000
"C:\\ProgramData\\Microsoft\\Windows Defender"=dword:00000000

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Defender\Windows Defender Exploit Guard\ASR\Rules]
"BE9BA2D9-53EA-4CDC-84E5-9B1EEEE46550"=dword:00000001
"D4F940AB-401B-4EFC-AADC-AD5F3C50688A"=dword:00000001
"3B576869-A4EC-4529-8536-B80A7769E899"=dword:00000001
"75668C1F-73B5-4CF0-BB93-3ECF5CB7CC84"=dword:00000001
"D3E037E1-3EB8-44C8-A917-57927947596D"=dword:00000001
"5BEB7EFE-FD9A-4556-801D-275E5FFC04CC"=dword:00000001
"92E97FA1-2EDF-4476-BDD6-9DD0B4DDDC7B"=dword:00000001
"01443614-cd74-433a-b99e-2ecdc07bfc25"=dword:00000001
"9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2"=dword:00000001
"d1e49aac-8f56-4280-b9ba-993a6d77406c"=dword:00000001
"b2b3f03d-6a65-4f7b-a9c7-1c7ef74a9ba4"=dword:00000001
"c1db55ab-c21a-4637-bb3f-a12568109d35"=dword:00000001

and next edit the registry path (adding Policies):

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows Defender\Windows Defender Exploit Guard\ASR]

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows Defender\Windows Defender Exploit Guard\ASR\ASROnlyExclusions]
"C:\\Windows"=dword:00000000
"C:\\Program Files"=dword:00000000
"C:\\Program Files (x86)"=dword:00000000
"C:\\ProgramData\\Microsoft\\Windows Defender"=dword:00000000

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows Defender\Windows Defender Exploit Guard\ASR\Rules]
"BE9BA2D9-53EA-4CDC-84E5-9B1EEEE46550"=dword:00000001
"D4F940AB-401B-4EFC-AADC-AD5F3C50688A"=dword:00000001
"3B576869-A4EC-4529-8536-B80A7769E899"=dword:00000001
"75668C1F-73B5-4CF0-BB93-3ECF5CB7CC84"=dword:00000001
"D3E037E1-3EB8-44C8-A917-57927947596D"=dword:00000001
"5BEB7EFE-FD9A-4556-801D-275E5FFC04CC"=dword:00000001
"92E97FA1-2EDF-4476-BDD6-9DD0B4DDDC7B"=dword:00000001
"01443614-cd74-433a-b99e-2ecdc07bfc25"=dword:00000001
"9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2"=dword:00000001
"d1e49aac-8f56-4280-b9ba-993a6d77406c"=dword:00000001
"b2b3f03d-6a65-4f7b-a9c7-1c7ef74a9ba4"=dword:00000001
"c1db55ab-c21a-4637-bb3f-a12568109d35"=dword:00000001

That is all.

 

[shmu26]

You can do it for ASR rules applied via Windows Policies (as administrator).
The ASR rules applied via ConfigureDefender or PowerShell cmdlets require higher rights (System, WinDefend, TrustedInstaller).
Anyway, there is a simple way to transfer the rules made by ConfigureDefender (PowerShell cmdlets) to another computer (Windows Policies). One should export the rules (all ON in the below example):
.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Defender\Windows Defender Exploit Guard\ASR]

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Defender\Windows Defender Exploit Guard\ASR\ASROnlyExclusions]
"C:\\Windows"=dword:00000000
"C:\\Program Files"=dword:00000000
"C:\\Program Files (x86)"=dword:00000000

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Defender\Windows Defender Exploit Guard\ASR\Rules]
"BE9BA2D9-53EA-4CDC-84E5-9B1EEEE46550"=dword:00000001
"D4F940AB-401B-4EFC-AADC-AD5F3C50688A"=dword:00000001
"3B576869-A4EC-4529-8536-B80A7769E899"=dword:00000001
"75668C1F-73B5-4CF0-BB93-3ECF5CB7CC84"=dword:00000001
"D3E037E1-3EB8-44C8-A917-57927947596D"=dword:00000001
"5BEB7EFE-FD9A-4556-801D-275E5FFC04CC"=dword:00000001
"92E97FA1-2EDF-4476-BDD6-9DD0B4DDDC7B"=dword:00000001
"01443614-cd74-433a-b99e-2ecdc07bfc25"=dword:00000001
"9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2"=dword:00000001
"d1e49aac-8f56-4280-b9ba-993a6d77406c"=dword:00000001
"b2b3f03d-6a65-4f7b-a9c7-1c7ef74a9ba4"=dword:00000001
"c1db55ab-c21a-4637-bb3f-a12568109d35"=dword:00000001

and next edit the registry path (adding Policies):

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Defender\Windows Defender Exploit Guard\ASR]

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Defender\Windows Defender Exploit Guard\ASR\ASROnlyExclusions]
"C:\\Windows"=dword:00000000
"C:\\Program Files"=dword:00000000
"C:\\Program Files (x86)"=dword:00000000

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows Defender\Windows Defender Exploit Guard\ASR\Rules]
"BE9BA2D9-53EA-4CDC-84E5-9B1EEEE46550"=dword:00000001
"D4F940AB-401B-4EFC-AADC-AD5F3C50688A"=dword:00000001
"3B576869-A4EC-4529-8536-B80A7769E899"=dword:00000001
"75668C1F-73B5-4CF0-BB93-3ECF5CB7CC84"=dword:00000001
"D3E037E1-3EB8-44C8-A917-57927947596D"=dword:00000001
"5BEB7EFE-FD9A-4556-801D-275E5FFC04CC"=dword:00000001
"92E97FA1-2EDF-4476-BDD6-9DD0B4DDDC7B"=dword:00000001
"01443614-cd74-433a-b99e-2ecdc07bfc25"=dword:00000001
"9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2"=dword:00000001
"d1e49aac-8f56-4280-b9ba-993a6d77406c"=dword:00000001
"b2b3f03d-6a65-4f7b-a9c7-1c7ef74a9ba4"=dword:00000001
"c1db55ab-c21a-4637-bb3f-a12568109d35"=dword:00000001

That is all.

That's a nice hack. I will try that.

 

[Andy Ful]

The new ConfigureDefender ver. 1.0.1.0 is available for testing:

• for Windows 64-bit: AndyFul/ConfigureDefender
• for Windows 32-bit: AndyFul/ConfigureDefender

Added ASR mitigations introduced in Windows ver. 1803 (they should work also on updated ver. 1709).
In the "Child Protection", all ASR mitigations are enabled, with some folder exclusions:
Windows, Program Files ..., ProgramData\Microsoft\Windows Defender.
.
I noticed that mitigation: "Block executable files from running unless they meet a prevalence, age, or trusted list criteria" is more restrictive than Defender 'Cloud Protection Level' set to Block. Furthermore, most executables blocked by this mitigation (but not all) can be run after one day.
.
The mitigation "Block credential stealing from the Windows local security authority subsystem (lsass.exe)" can block some schtaks.exe processes and also processes started by Windows Defender in the folder: ProgramData\Microsoft\Windows Defender.

Post edited.
The Lsass rule, does not support exclusions.

 

[shmu26]

Thanks Andy, I will check out the new version

 

[shmu26]

.
The mitigation "Block credential stealing from the Windows local security authority subsystem (lsass.exe)" can block some schtaks.exe processes and also processes started by Windows Defender in the folder: ProgramData\Microsoft\Windows Defender (both folders are excluded).

How did you make those folder exclusions?
Ah, I get it now. The folder exclusions apply to all ASR rules, not just to lsass.
Do you think that these folder exclusions might weaken the other ASR rules? The lsass rule is probably not so important for home users, so maybe it is better to disable that particular rule, and then delete the folder exclusions?

 

[Andy Ful]

How did you make those folder exclusions?
Ah, I get it now. The folder exclusions apply to all ASR rules, not just to lsass.
Do you think that these folder exclusions might weaken the other ASR rules? The lsass rule is probably not so important for home users, so maybe it is better to disable that particular rule, and then delete the folder exclusions?

If I correctly remember the passwords to Microsoft account, Outlook and OneDrive are also stored in Lsass. Anyway, the "Lsass" rule does not support exclusions (it is marked by !! ), so they are for :
"Block executable files from running unless they meet a prevalence, age, or trusted list criteria".
(I noticed a mistake in the code that adds exclusions also for Lsass rule). The excluded folders were suited to Hard_Configurator (whitelisted by SRP).
Only "Child Protection" and two ASR rules automatically trigger folder exclusions (one by mistake). If you will apply "Defender high settings" or "Defender Default settings", then all exclusions are removed.