Reldel1

Level 1
They probably forgot to whitelist the new Edge build and update the ASR module.
You can add an exclusion (file path) to ASR rules from ConfigureDefender. Although this exclusion will be applied for most ASR rules too, the blocked executable is in a not-writable folder, and excluding Edge should not lower ASR protection.
You can also disable this ASR rule temporarily, restart Windows, next update & run Edge Dev, and finally Enable ASR rule again.
Generally, this ASR rule can produce false positives during software updates. That is why it is disabled in ConfigureDefender HIGH Protection level.
Thanks Andy, I find your effort, product and support to be impeccable. I knew it was "them", :devil:.
 

oldschool

Level 35
Verified
@Reldel1 @Andy Ful Yes, I checked and found Edge Dev Upda was also blocked here by this rule.

Also, I looked through WSC Protection History and see it keeps the log quite a long time. I found some older blocks which required exclusions so no problem there. I would advise users to check not only ConfigureDefender logs but also Protection History in WSC to check for blocks which won't receive WD notifications. I think I needed 3 ASR exclusions after checking.

And finally, I see that WD scans have all been optimized with this last update. Have others noticed this?
 

Reldel1

Level 1
Thanks. I did not know the word impeccable. I learned something. :giggle:
It appears Microsoft found their problem and have provided and update, below is from their Edge Insider notes:


Hi everyone, just a quick note to say that we deployed a new build 78.0.268.3 to the Dev channel today for Windows only. This corrects an issue with our digital signature that prevented Microsoft Edge from working on Windows 10 S and caused some people to see an "unverified publisher" or similar message. There are no other changes in this update.
 

Andy Ful

Level 48
Verified
Trusted
Content Creator
Why am I seeing this in my logs? Running on high protection, and as far as I remember I did nothing to WD on the date shown. Thanks.
...
Something disabled WD.
There are a few events Id=5010 on my computer, but they are correlated with moments when I disabled WD via Defender Control tool (confirmed a few minutes ago).
I think that it can be also related to updating WD engines (not signatures).(y)
It would be interesting to know how many ConfigureDefender users have this event in the Log.
 

Reldel1

Level 1
Something disabled WD.
There are a few events Id=5010 on my computer, but they are correlated with moments when I disabled WD via Defender Control tool (confirmed a few minutes ago).
I think that it can be also related to updating WD engines (not signatures).(y)
It would be interesting to know how many ConfigureDefender users have this event in the Log.
No 5010 events in my log.
 

blackice

Level 10
Verified
Something disabled WD.
There are a few events Id=5010 on my computer, but they are correlated with moments when I disabled WD via Defender Control tool (confirmed a few minutes ago).
I think that it can be also related to updating WD engines (not signatures).(y)
It would be interesting to know how many ConfigureDefender users have this event in the Log.
I just got an engine update when I switched back to Defender. I will check the event log later when I’m at my computer to see if it’s in there.
 

simmerskool

Level 7
Verified
Malware Tester
The new Edge Development version, Version 78.0.268.1 (Official build) dev (64-bit), failed the update re-start process because the Configure Defender exploit guard setting "Block executable files from running unless they meet a prevalence, age or trusted list criteria" prevented the update restart. For whatever reason the "ON" setting had to be disabled in Configure Defender in order to complete the update AND then to allow Version 78.0.268.1 desktop link to open Development Edge. I am now running with the "Block executable files" setting disabled and Edge updates and opens correctly.
something was amiss with the msedge update to v78, give me BSOD :emoji_grimacing:
 

Andy Ful

Level 48
Verified
Trusted
Content Creator
ConfigureDefender and the fileless malware.

I would like to share some information about WD ASR rules in the context of fileless attacks. Fileless attack (common definition) is an attack during which no portable executable (PE) file is written to and executed from disk.

The below ASR rules are strictly related to the protection of MS software:
  • Block executable content from email client and webmail (Outlook or Outlook.com).
    It blocks the following file types: EXE, SCR, DLL, PS, JS, VBS, etc. when these files are launched from Outlook or Outlook.com (and probably some other popular webmail providers).
  • Block Office applications from creating child processes - blocks also the execution of script engines and other LOLBins by Office exploits.
  • Block Office applications from injecting into other processes - prevents the Office exploits to inject the malicious code into other processes.
  • Block Win32 imports from Macro code in Office - restricts VBA macros when they try to use Win32 API calls.
  • Block only Office communication applications from creating child processes - prevents Outlook exploits from creating child processes, also script engines and other LOLBins.
The below ASR rules can generally protect the system:
  • Use advanced protection against ransomware - includes also remediation of PowerShell trojan-downloaders.
  • Impede JavaScript and VBScript to launch executables - blocks common JavaScript and VBScript trojan-downloaders.
  • Block credential stealing from the Windows local security authority subsystem (lsass.exe) - protects passwords and credentials.
  • Block process creations originating from PSExec and WMI commands - prevents spying, blocks wmic.exe, prevents remote code execution.
  • Block Adobe Reader from creating child processes - blocks also the execution of script engines, Office applications, and other LOLBins by Adobe Reader exploits.
  • Block execution of potentially obfuscated scripts - blocks some obfuscated JS, VBS, PS, VBA code.
  • Block persistence through WMI event subscription - prevents the threats that abuse WMI to persist and stay hidden in WMI repository.
See also:

As can be seen from the above points, WD ASR rules do not prevent the attacks performed via Python scripts or Java files ( .jar files), which are sometimes used by malc0ders too. But, such attacks require installing Python or Java engines.
 
Last edited: