Has anyone come across Microsoft Defender for Endpoint and using ASR rules whereby its picking up the SyncroLive.Agent.Runner.exe service for this rule:
Rule: Block abuse of in-the-wild exploited vulnerable signed driver?
I have included a screenshot below.
We would prefer not to exclude this software if it in fact abusing the rule, however has anyone else seen this and what was the fix?
Im guessing one of the fixes will be for Syncro \ RepairTech to update the OpenHardwareMonidorLib.sys file in the software package.
I have had the same issue with both the SyncroLive.Agent.Renner.exe and the Choco.exe file. It is definitely concerning because it did not flag those 2 files in the past. Curious if there is any explanation from Syncro on this because if there is any validity to their 2 main files being a threat…needs to be addressed ASAP.
Hello. This is what I was told when I reached out to Syncro on this issue. Hope this helps, according to Syncro nothing to worry about. I assume the error comes because of the depth of functionality Syncro operates with.
From Syncro:
These happen every once in a while with all RMM agents.
Going to pass this on so we can reach out to them.
I’ve logged a ticket with both Microsoft and Synco regarding this. Microsoft actually did a really deep dive on it - which I found rather impressive for them.
Here is Microsoft’s response:
We have re-verified the shared Submission ID : (blah-blah-blah) and observed that someone altered the code from original winring0 and removed almost all the vulnerable pieces. However, there is still an arbitrary readmsr which can be used for infoleak. So, we confirm that the driver meets our criteria for being blocked by ASR.
If you want to allow the file, please consider deploying file path-based exclusion or Cert IoC based exclusion for the same.
Microsoft also added how to exclude it if I wanted to.
Syncro’s response was along the lines of: we plan on replacing this soon, but with no current ETA.
I’ve confirmed that it is in our development team’s plans to ultimately remove the dependency altogether to help resolve some of these issues. While I’m not privy to the ETA or timeline of this, it is actively being addressed and you may see it come to fruition soon.
It’s also worth mentioning in the meantime that this is largely a post-exploitation vulnerability. The security team would like to place emphasis on the fact that the driver would require administrative permissions to exploit, which in turn means that the system itself would need to already be significantly compromised; therefore shouldn’t be considered to be exceedingly severe in most circumstances
So, is the file technically have vulnerabilities in it: Yes, according to Microsoft.
What did we do? Nothing. We did NOT add it to any exclusion list, and Syncro still seems to work fine. If we’re missing some sort of functionality, I’m not sure what it is. Would be kind of interested to know though
