ConfigureDefender utility for Windows 10/11

[Andy Ful]

In the next integrated version, I think you mentioned somewhere that it will include Exploit protection settings for some common exploitable apps. Could you add 7-Zip to that list?

That is a plan for the future. It will require opening a new thread on MalwareTips, because such mitigations should be first tested by people with different hardware/software configurations.

 

[shmu26]

That is a plan for the future. It will require opening a new thread on MalwareTips, because such mitigations should be first tested by people with different hardware/software configurations.

Thanks.
Do you happen to know which files are the exploitable ones?
After installing the new version, I have 7zip in both program file folders, and both have 7z.exe.

 

[Andy Ful]

Thanks.
Do you happen to know which files are the exploitable ones?
After installing the new version, I have 7zip in both program file folders, and both have 7z.exe.

Do both 7ZIP installations have the same installation date/time?

 

[shmu26]

Do both 7ZIP installations have the same installation date/time?

Nope. The Program Files x86 folder was created yesterday, when I installed the new version. The other Program Files folder was created a long time ago.

 

[Andy Ful]

Nope. The Program Files x86 folder was created yesterday, when I installed the new version. The other Program Files folder was created a long time ago.

So you have your answer. The old installation was made via 32-bit 7ZIP installer a long time ago.
I had the same situation on my computer.

 

[shmu26]

So you have your answer. The old installation was made via 32-bit 7ZIP installer a long time ago.
I had the same situation on my computer.

Actually, there are a few files inside the folder, and I was wondering which one/s are the exploitable ones.
I compressed and extracted a file, by right-click, and then looked in NVT ProcLogger. It is 7zG.exe that does the work.

 

[Andy Ful]

Actually, there are a few files inside the folder, and I was wondering which one/s are the exploitable ones.
I compressed and extracted a file, by right-click, and then looked in NVT syslogger. It is 7zG.exe that does the work.

Both 7zG.exe and 7zFM are used. 7zFM is a GUI for 7zG.exe.
On the clean system, when the user wants to manage ZIP or 7-zip containers, the 7zG.exe and 7zFM are the most important.

 

[shmu26]

Both 7zG.exe and 7zFM are used. 7zFM is a GUI.

Here is someone who did already did the hard work:
7-Zip Stable Releases & Discussion

 

[Andy Ful]

Here is someone who did already did the hard work:
7-Zip Stable Releases & Discussion

My post from November 2017 for people who do not like reg tweks:
Q&A - 7Zip exploit protection settings recommendation

 

[shmu26]

My post from November 2017 for people who do not like reg tweks:
Q&A - 7Zip exploit protection settings recommendation

Thanks. It sounds like Arbitary Code Guard did not work for you. But I used the reg tweak from @WildByDesign and it is working for me.

 

[Andy Ful]

Thanks. It sounds like Arbitary Code Guard did not work for you. But I used the reg tweak from @WildByDesign and it is working for me.

That is a good improvement in the newest 7-ZIP version.

 

[shmu26]

@Andy Ful
I count 7 ASR rules in ConfigureDefender, but when I look in my registry (see screenshot) I see 8 entries.
I am wondering if the 8th one is also related to ConfigureDefender?

A little background to my question: I ran a powershell script that is claimed to enable Credential Guard on Windows 10 pro 1803

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

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

This is being hotly discussed over here:
DLL Injection Methods - Test Apps (Discussion)

Maybe my 8th registry entry is from that?
Even if it is, I still don't know if it actually works...

 

[Deleted member 65228]

@shmu26 As far as I am aware, there are only 12 Attack Surface Reduction (ASR) rules.

Spoiler

I have only started investigating it properly (I verified that the prevention of RCE for that rule does indeed work against NtAllocateVirtualMemory, I am yet to test NtWriteVirtualMemory and others).

I attached a debugger to the correct process responsible for carrying out the virtual memory operation on the target process (which should have been blocked) and set a break-point for NtAllocateVirtualMemory, then I saw the call go through and got a hit for NtAllocateVirtualMemory (NTOSKRNL) from kernel debugging. However, Attack Surface Reduction (ASR) kept its word and blocked that virtual memory operation like it was supposed to. As in, the operation was not successful. If I recall correctly, it returned an NTSTATUS code of STATUS_ACCESS_DENIED while the RCE rule was enabled only. NtAllocateVirtualMemory (NTOSKRNL) calls MiAllocateVirtualMemory (NTOSKRNL) anyway so it is likely a lot more deeper embedded.

The actual RCE IMO would be getting the memory changed (e.g. NtWriteVirtualMemory), which is why this is only partly tested. Virtual memory operations for remote memory allocation is actually an optional thing with RCE, but I wanted to start with it when I had time the other day. NtProtectVirtualMemory, NtUnmapViewOfSection and for curiosity... Reading via NtReadVirtualMemory is also on my list.

Therefore, at-least now we know that the rule for "Block Office applications from injecting code into other processes" has been partly tested, for now for remote virtual memory allocation. I'll do more testing with it when I have more time, hopefully soon.

[ This is related to 75668C1F-73B5-4CF0-BB93-3ECF5CB7CC84 ]

Anyway, based on your registry, it seems you have:
1. "Block Office applications from creating executable content" (3B576869-A4EC-4529-8536-B80A7769E899)
2. "Block execution of potentially obfuscated scripts" (5BEB7EFE-FD9A-4556-801D-275E5FFC04CC)
3. "Block Office applications from injecting code into other processes" (75668C1F-73B5-4CF0-BB93-3ECF5CB7CC84)
4. "Block Win32 API calls from Office macro" (92E97FA1-2EDF-4476-BDD6-9DD0B4DDDC7B)
5. "Block credential stealing from the Windows local security authority subsystem (lsass.exe)" (9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2)
6. "Block executable content from email client and webmail" (BE9BA2D9-53EA-4CDC-84E5-9B1EEEE46550)
7. "Block JavaScript or VBScript from launching downloaded executable content" (D3E037E1-3EB8-44C8-A917-57927947596D)
8. "Block Office applications from creating child processes" (D4F940AB-401B-4EFC-AADC-AD5F3C50688A)

The ones you do not seem to have enabled:
1. "Block executable files from running unless they meet a prevalence, age, or trusted list criteria" (01443614-cd74-433a-b99e-2ecdc07bfc25)
2. "Use advanced protection against ransomware" (c1db55ab-c21a-4637-bb3f-a12568109d35)
3. "Block process creations originating from PSExec and WMI commands" (d1e49aac-8f56-4280-b9ba-993a6d77406c)
4. "Block untrusted and unsigned processes that run from USB" (b2b3f03d-6a65-4f7b-a9c7-1c7ef74a9ba4)

Therefore, yes, it appears you do have the entry for credential theft with lsass.exe. However, the rule you were specifically interested in and posted a screenshot of is for child process creation prevention.

Source:
Use Attack surface reduction rules to prevent malware infection

 

[shmu26]

@shmu26 As far as I am aware, there are only 12 Attack Surface Reduction (ASR) rules however I have only started investigating it properly (I verified that the prevention of RCE for that rule does indeed work against NtAllocateVirtualMemory, I am yet to test NtWriteVirtualMemory (and out of curiosity, NtReadVirtualMemory, to see if it blocks read as well) - from VBA).

I attached a debugger to the correct process responsible for carrying out the virtual memory operation on the target process (which should have been blocked) and set a break-point for NtAllocateVirtualMemory, then I saw the call go through and got a hit for NtAllocateVirtualMemory (NTOSKRNL) from kernel debugging. However, Attack Surface Reduction (ASR) kept its word and blocked that virtual memory operation like it was supposed to. As in, the operation was not successful. If I recall correctly, it returned an NTSTATUS code of STATUS_ACCESS_DENIED while the RCE rule was enabled only.

Therefore, at-least now we know that the rule for "Block Office applications from injecting code into other processes" has been partly tested, for now for remote virtual memory allocation. I'll do more testing with it when I have more time, hopefully soon.

[ This is related to 75668C1F-73B5-4CF0-BB93-3ECF5CB7CC84 ]

Anyway, based on your registry, it seems you have:
1. "Block Office applications from creating executable content" (3B576869-A4EC-4529-8536-B80A7769E899)
2. "Block execution of potentially obfuscated scripts" (5BEB7EFE-FD9A-4556-801D-275E5FFC04CC)
3. "Block Office applications from injecting code into other processes" (75668C1F-73B5-4CF0-BB93-3ECF5CB7CC84)
4. "Block Win32 API calls from Office macro" (92E97FA1-2EDF-4476-BDD6-9DD0B4DDDC7B)
5. "Block credential stealing from the Windows local security authority subsystem (lsass.exe)" (9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2)
6. "Block executable content from email client and webmail" (BE9BA2D9-53EA-4CDC-84E5-9B1EEEE46550)
7. "Block JavaScript or VBScript from launching downloaded executable content" (D3E037E1-3EB8-44C8-A917-57927947596D)
8. "Block Office applications from creating child processes" (D4F940AB-401B-4EFC-AADC-AD5F3C50688A)

The ones you do not have enabled:
1. "Block executable files from running unless they meet a prevalence, age, or trusted list criteria" (01443614-cd74-433a-b99e-2ecdc07bfc25)
2. "Use advanced protection against ransomware" (c1db55ab-c21a-4637-bb3f-a12568109d35)
3. "Block process creations originating from PSExec and WMI commands" (d1e49aac-8f56-4280-b9ba-993a6d77406c)
4. "Block untrusted and unsigned processes that run from USB" (b2b3f03d-6a65-4f7b-a9c7-1c7ef74a9ba4)

Therefore, yes, you do have the entry for credential theft with lsass.exe. However, the rule you were specifically interested in and posted a screenshot of is for child process creation prevention.

Source:
Use Attack surface reduction rules to prevent malware infection

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?

 

[Deleted member 65228]

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?

It's been awhile since I looked into the credential theft via LSASS since it tends to be the same thing from another attack, however I recall it was to do with virtual memory operations after opening a handle to lsass.exe. At-least this is what I recall because I remember chopping off the ability to do that being sufficient against Mimikatz (user-mode) at the time unless it has changed a lot since.

If you have any other information about this feature, or recent credential theft attacks leveraging lsass.exe which work differently to as described above which I may be unaware of, then please do let me know of those as well. Do you have any examples of what Microsoft may have been looking at when designing and developing that rule feature, in terms of article/write-ups?

If this is what that Attack Surface Reduction (ASR) feature is meant to prevent though then I should be able to test that for you on a real Windows 10 Professional 64-bit environment, hopefully soon.

Note: There's also a registry modification you can make to cause lsass.exe to become a protected process. Source: Configuring Additional LSA Protection

 

[shmu26]

@shmu26 As far as I am aware, there are only 12 Attack Surface Reduction (ASR) rules.

Spoiler

I have only started investigating it properly (I verified that the prevention of RCE for that rule does indeed work against NtAllocateVirtualMemory, I am yet to test NtWriteVirtualMemory and others).

I attached a debugger to the correct process responsible for carrying out the virtual memory operation on the target process (which should have been blocked) and set a break-point for NtAllocateVirtualMemory, then I saw the call go through and got a hit for NtAllocateVirtualMemory (NTOSKRNL) from kernel debugging. However, Attack Surface Reduction (ASR) kept its word and blocked that virtual memory operation like it was supposed to. As in, the operation was not successful. If I recall correctly, it returned an NTSTATUS code of STATUS_ACCESS_DENIED while the RCE rule was enabled only. NtAllocateVirtualMemory (NTOSKRNL) calls MiAllocateVirtualMemory (NTOSKRNL) anyway so it is likely a lot more deeper embedded.

The actual RCE IMO would be getting the memory changed (e.g. NtWriteVirtualMemory), which is why this is only partly tested. Virtual memory operations for remote memory allocation is actually an optional thing with RCE, but I wanted to start with it when I had time the other day. NtProtectVirtualMemory, NtUnmapViewOfSection and for curiosity... Reading via NtReadVirtualMemory is also on my list.

Therefore, at-least now we know that the rule for "Block Office applications from injecting code into other processes" has been partly tested, for now for remote virtual memory allocation. I'll do more testing with it when I have more time, hopefully soon.

[ This is related to 75668C1F-73B5-4CF0-BB93-3ECF5CB7CC84 ]

Anyway, based on your registry, it seems you have:
1. "Block Office applications from creating executable content" (3B576869-A4EC-4529-8536-B80A7769E899)
2. "Block execution of potentially obfuscated scripts" (5BEB7EFE-FD9A-4556-801D-275E5FFC04CC)
3. "Block Office applications from injecting code into other processes" (75668C1F-73B5-4CF0-BB93-3ECF5CB7CC84)
4. "Block Win32 API calls from Office macro" (92E97FA1-2EDF-4476-BDD6-9DD0B4DDDC7B)
5. "Block credential stealing from the Windows local security authority subsystem (lsass.exe)" (9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2)
6. "Block executable content from email client and webmail" (BE9BA2D9-53EA-4CDC-84E5-9B1EEEE46550)
7. "Block JavaScript or VBScript from launching downloaded executable content" (D3E037E1-3EB8-44C8-A917-57927947596D)
8. "Block Office applications from creating child processes" (D4F940AB-401B-4EFC-AADC-AD5F3C50688A)

The ones you do not seem to have enabled:
1. "Block executable files from running unless they meet a prevalence, age, or trusted list criteria" (01443614-cd74-433a-b99e-2ecdc07bfc25)
2. "Use advanced protection against ransomware" (c1db55ab-c21a-4637-bb3f-a12568109d35)
3. "Block process creations originating from PSExec and WMI commands" (d1e49aac-8f56-4280-b9ba-993a6d77406c)
4. "Block untrusted and unsigned processes that run from USB" (b2b3f03d-6a65-4f7b-a9c7-1c7ef74a9ba4)

Therefore, yes, it appears you do have the entry for credential theft with lsass.exe. However, the rule you were specifically interested in and posted a screenshot of is for child process creation prevention.

Source:
Use Attack surface reduction rules to prevent malware infection

By the way, would you recommend enabling

2. "Use advanced protection against ransomware" (c1db55ab-c21a-4637-bb3f-a12568109d35)
3. "Block process creations originating from PSExec and WMI commands" (d1e49aac-8f56-4280-b9ba-993a6d77406c)

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

 

[Deleted member 65228]

@shmu26 Yes, I do recommend enabling both of those. I think it would be a wise decision. However, make sure for all the rules you enable that can be applied without breaking any functionality you require. It wouldn't be a bad idea either to want more insight into how the rules work for the future in-case an issue ever occurs.

By the way, the official documentation states the following.

Windows 10, version 1803 has five new Attack surface reduction rules:

Therefore, any environment on Windows 10 which is not on that build or higher, will not have access to the following rules.

• Block executable files from running unless they meet a prevalence, age, or trusted list criteria
• Use advanced protection against ransomware
• Block credential stealing from the Windows local security authority subsystem (lsass.exe)
• Block process creations originating from PSExec and WMI commands
• Block untrusted and unsigned processes that run from USB

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

From what I understand of the naming for the rule, it will block all process creation originating from PSExec (from SysInternals) or WMI usage, regardless of how it is being performed by PSExec/WMI usage.

However, I believe PSExec became a target by Microsoft for the ASR rules due to the abuse it has within malware attacks from the past (and likely still current). Not to mention that PSExec will be more than happy to spawn any target process under NT Authority Account (SYSTEM) when using the "-s" argument correctly (which is what that argument is for).

The note from the official Microsoft documentation is as follows.

This rule blocks processes through PsExec and WMI commands from running, to prevent remote code execution that can spread malware attacks.

That appears to be all they provide about it, apart from a brief disclaimer afterwards about functionality of something else.

 

[shmu26]

It's been awhile since I looked into the credential theft via LSASS since it tends to be the same thing from another attack, however I recall it was to do with virtual memory operations after opening a handle to lsass.exe. At-least this is what I recall because I remember chopping off the ability to do that being sufficient against Mimikatz (user-mode) at the time unless it has changed a lot since.

If you have any other information about this feature, or recent credential theft attacks leveraging lsass.exe which work differently to as described above which I may be unaware of, then please do let me know of those as well. Do you have any examples of what Microsoft may have been looking at when designing and developing that rule feature, in terms of article/write-ups?

If this is what that Attack Surface Reduction (ASR) feature is meant to prevent though then I should be able to test that for you on a real Windows 10 Professional 64-bit environment, hopefully soon.

Note: There's also a registry modification you can make to cause lsass.exe to become a protected process. Source: Configuring Additional LSA Protection

Somebody just posted on the other forum that Microsoft recently clarified that the ASR rule for lsass was published by mistake, because it will not go live until the fall, with the next version of Windows. It is independent of Credential Guard, and is intended for cases whether Credential Guard cannot be used.
The post is here:
DLL Injection Methods - Test Apps (Discussion)

 

[Deleted member 65228]

It is independent of Credential Guard, and is intended for cases whether Credential Guard cannot be used.

Interesting.

I stopped writing earlier when replying and thought, "Wait, I misread... Credential Guard?" and then wondered if it was actually related at all to ASR, because I doubted it was. I wouldn't have been surprised if it was either though.

As for the credential theft rule for ASR, I recon it will work how I mentioned earlier (e.g. either blocking Office applications from opening a handle to lsass.exe altogether or allowing the handle but preventing RCE with it), since I don't recall there being credential theft techniques (which are at-least known) which depend precisely on lsass.exe and do not involve RCE. However, if I have missed news/this is incorrect, please correct me as and when.

 

[shmu26]

Interesting.

I stopped writing earlier when replying and thought, "Wait, I misread... Credential Guard?" and then wondered if it was actually related at all to ASR, because I doubted it was. I wouldn't have been surprised if it was either though.

As for the credential theft rule for ASR, I recon it will work how I mentioned earlier (e.g. either blocking Office applications from opening a handle to lsass.exe altogether or allowing the handle but preventing RCE with it), since I don't recall there being credential theft techniques (which are at-least known) which depend precisely on lsass.exe and do not involve RCE. However, if I have missed news/this is incorrect, please correct me as and when.

Thanks.
I don't know more about the subject.