NoVirusThanks OSArmor: An Additional Layer of Defense

This reg.hack does nothing on my 1809 enterprise machine. There is no switch in the UI.
I have the mitigations set by powershell, and confirmed that they work

 

That makes sense since it appears this reg. switch only applies to Win 10 Home.

Also another possibility is the reg. switch will cause upon reboot, the mitigations to be added to the registry via WDEG Powershell interface. Now that would be interesting; especially if the switch did the same on 1803.

 

I will find out ̶t̶̶o̶̶m̶̶o̶̶r̶̶r̶̶o̶̶w̶, when I have access to WIN 10-home.

edit: asap

 

Thanks for the reference link to TenForums-Been xtremely useful Forums for 8.1 too.

 

Found another article in regards to EnableASRConsumers option: http://www.fileinspect.com/blog/new-block-suspicious-behaviors-windows-10/

This has more detail and somewhat confirms my suspicions that all the switch is doing is automating the creation of the WDEG ASR rules. Turning it off, deletes those rules in the registry. So we need someone to confirm this and also see if it works on 1803. @Sampei Nihira are you game?

 

IF, and I mean this literally, IF after making modifications to that registry setting since it involves specialty Permissions, and some of my own experience on file permissions with Windows 10 has caused issues before. Just don't panic if it gets whacked. Use Tweaking.com's Windows Repair and it will ACCURATELY-SAFELY reset & restore them back again to prevent further weirdness. Just a precaution that might prove helpful to experimenters.

 

Anyways, these features sometimes change before they reach the release version, so when it comes out, WYSIWYG.

 

I believe the ASR rules shown in your screen shot are those that you manually created via Powershell or possibly created when WD is running in realtime mode.

I use a third party AV and have not created any manual ASR rules. No rules exist in my registry in that area for 1803 ver..

 

Ok. That answers the question in that the ASR consumer rules are loaded by default and use of them controlled by the EnableASRConsumers reg. setting.

 

Thanks for the reports!

 

There is also the question if these new consumer protection ASR rules will function properly if WD realtime scanning is not enabled. This could be one explanation for why the option is missing in the 1809 Security Center GUI?

Microsoft up to 1809 has been quite specific that WD enabling was a requirement for these mitigations: https://github.com/MicrosoftDocs/windows-itpro-docs/issues/1164

Also: https://github.com/MicrosoftDocs/wi...loit-guard/enable-attack-surface-reduction.md

 

Awesome. Thanks for fishing these out for us.

 

I have WD with active realtime scanning enabled, on 1809 pro, but I don't have the option in the Security Center GUI. You know how MS is with new features that they promise. Sometimes they make good on promises, but...

 

It works

 

Scroll down so you can see the lower right of the screenshot, you will see the pop-up.
It might be hard to see on this screenshot, but Appguard is disabled. The pop-up is clearly from Windows, not from a 3rd party app.

 

I think I have an idea on what is going on in 1809 in regards to these new ASR mitigations.

In the link I posted previously, the OP commented that these ASR mitigations worked on 1803 Pro despite MS statements that only so on the Enterprise vers.. Appears to me MS intentionally left out the Security Center GUI enable/disable option on the non-Home 1809 vers. since they can be controlled via Group Policy.

Now for the really big question. Will these new ASR mitigations work if one is using a third party AV? My gut is telling me that is so if one enables the EnableASRConsumers reg. setting hack. Obviously, there will be no WD alert if one is triggered but the action will be recorded in the Security-Mitigations event log.

 

You can also configure and test rules with a Microsoft tool:

Windows Defender Exploit Guard evaluation package:
http://download.microsoft.com/download/8/9/3/89365A76-6586-40CB-964A-6FBD0DAA0A6D/Windows Defender Exploit Guard evaluation package.zip?ocid=cx-dlc-evaluatewdeg

 

when installing kaspersky cloud free I got this warning:
Process: [6580]C:\Windows\System32\regsvr32.exe
Process MD5 Hash: 59BCE9F07985F8A4204F4D6554CFF708
Parent: [6036]C:\Windows\SysWOW64\regsvr32.exe
Rule: PreventRegsvr32LoadingDLLs
Rule Name: Prevent regsvr32.exe from loading .DLLs
Command Line: /s "C:\ProgramData\Kaspersky Lab\AVP19.0.0\Bases\klsihk64.dll"
Signer:
Parent Signer:
User/Domain: SYSTEM/NT AUTHORITY
System File: True
Parent System File: True
Integrity Level: System
Parent Integrity Level: System

wondering if its ok.

 

This article excerpt is for 1803 and confirms that ASR mitigations require WD to be set to realtime mode; i.e. it is the primary AV. I see no reason why this would change in 1809:

https://argonsys.com/learn-microsof...tack-surface-against-next-generation-malware/

In 1809, you might be able to use ASR if your third party AV does not use the Win 10 ELAM driver to load its kernel process as PPL - antivirus. In this case, WD will automatically set itself to the primary AV realtime solution.

 

The download from here is: http://download.microsoft.com/download/8/9/3/89365A76-6586-40CB-964A-6FBD0DAA0A6D/Windows Defender Exploit Guard evaluation package.zip?ocid=cx-dlc-evaluatewdeg ; both the x(86) and x(64) .exe's are Microsoft signed.

 

Yikes! The below screen shot is self-explanatory. Install the Microsoft Testing Root Certificate in the Win root trusted CA store and you won't get any more chaining errors.

Assumed is that root CA store certificate is only installed and manually so in development envionments.

 

I thought this thread was about OSA.

 

Move to another thread, quit clogging up OSA!
There is enough to read through.

 

+1