+18
Pending Review

Code sign Connectwise Control .dll's

RobD 1 year ago updated by ITSourcePro 1 month ago 9

When a new version of the Screenconnect client is released & installed, Microsoft Defender for Endpoint - Attack Surface Reductions' rule "Block executable files from running unless they meet a prevalence, age, or trusted list criterion" denies the libraries from being used as they have no reputation.

This is expected behavior as a new version of the client being released globally is seen as "unknown" by Microsoft Security products.

The executables are not being flagged as low reputation as they are digitally signed & Microsoft have "established trust" with the code signing certificate in use.

Our request is to please sign the .dll's as well, without this digital signature, Microsoft wont "trust" the new files straight away which causes issues until enough devices globally have the client installed & Microsoft's systems learn / trust them.

It also enables us to create a trusted code signing certificate "Indicators", excluding any executable & dll from ASR rules etc, preventing these types of issues.


 https://learn.microsoft.com/en-us/microsoft-365/security/defender-endpoint/attack-surface-reduction-rules-reference?view=o365-worldwide#block-executable-files-from-running-unless-they-meet-a-prevalence-age-or-trusted-list-criterion

Image 1175

Support case reference #01401061

+3

+1 please implement! 

+1

Yes, this is required now because WDAC won't allow anything to run that is unsigned. I'm trying to find a work around and nothing at this stage seems to work. This is especially important when dealing with on-demand support instances

+1

It's 2024... No Enterprise-ready product should be shipping with unsigned DLLs.  Please?

Image 1251

The windows 11 insider builds now block even more....

In the latest Stable build 24.1.6.8875 the following DLLs are now signed:

ScreenConnect.WindowsCredentialProvider.dll and ScreenConnect.WindowsAuthenticationPackage.dll

Image 1256


Now if we could get the other 4 signed and even the installer signed, it would be great. Doing the mac installer would also help keeping the mac clients up to date.

I continue to get this error on the above build. It looks like the ScreenConnect.WindowsCredentialProvider.dl needs to be signed by Microsoft itself for this warning not to popup.

I'm having the same issue on Win 10 and Win 11 PCs

Image 1252

Image 1253

Has anyone figured out a workaround for this. I have gone in and added exceptions into the ASR policy, but nothing seems to work. 

+1

We push the following via the command option, but that is blocked on some machines as well by Windows defender (also it's a security risk):

powershell -command "Add-MpPreference -ExclusionProcess 'ScreenConnect.ClientService.exe'"
powershell -command "Add-MpPreference -ExclusionProcess 'ScreenConnect.WindowsClient.exe'"
powershell -command "Add-MpPreference -ExclusionProcess 'ScreenConnect.Windows.dll'"
powershell -command "Add-MpPreference -ExclusionProcess 'C:\WINDOWS\TEMP\ScreenConnect\*\setup.msi'"

Thank you so much. This works :)