Pavol Cerven 0 Posted July 20, 2023 Share Posted July 20, 2023 Hello, during testing our program we found out your dll file eamsi.dll inject into our process. Because this file is signed with Microsoft's certificate it will be no problem. File has 3 signatures: ESET, spol. s r.o. -> it's ok Microsoft Windows Hardware Compatibility Publisher -> it's ok ESET, spol. s r.o. -> If you open "view certificate" then you will see: "This certificate cannot be verified up to a trusted certification authority" and if you open "Certification Path" then you will see "This CA Root certificate is not trusted because it is not in the Trusted Root Certification Authorities store." I did a quick check and think many other files have the same problem (dmon.dll). Can you please update your certificates or maybe inject your files more hidden way? Link to comment Share on other sites More sharing options...
Administrators Marcos 5,231 Posted July 21, 2023 Administrators Share Posted July 21, 2023 ESET does not inject eamsi.dll anywhere. It's other process that load registered AMSI provider dlls themselves. The signatures are correct, not sure what you mean that dmon.dll has the same problem. What problem? Link to comment Share on other sites More sharing options...
itman 1,740 Posted July 21, 2023 Share Posted July 21, 2023 12 hours ago, Marcos said: The signatures are correct Windows doesn't think they are; And my Win Code Integrity Event log is full of errors because of this; Link to comment Share on other sites More sharing options...
itman 1,740 Posted July 21, 2023 Share Posted July 21, 2023 As far as what the OP is referring to, it appears Eset's cert. has expired; Link to comment Share on other sites More sharing options...
Administrators Marcos 5,231 Posted July 21, 2023 Administrators Share Posted July 21, 2023 What matters is the countercertificate. Moreover, the above cert. is a self-signed certificate which is validated internally regardless of the expiration date. Link to comment Share on other sites More sharing options...
Pavol Cerven 0 Posted July 21, 2023 Author Share Posted July 21, 2023 (edited) Marcos if you think your certificates are correct, then you try to call WinVerifyTrust function. For eamsi.dll it returns error code 0x800B0109 which is CERT_E_UNTRUSTEDROOT. Before you reply try opening (ALT+ENTER) eamsi.dll in Windows and check what Windows display for your certificates. It doesn't look correct. I am sorry. I have 3 licenses of ESET Internet Security and it's the same at Win11, Win10, and Win7. Edited July 21, 2023 by Pavol Cerven Link to comment Share on other sites More sharing options...
Administrators Marcos 5,231 Posted July 21, 2023 Administrators Share Posted July 21, 2023 The above signature is irrelevant. It's signed by a self-signed ESET certificate which doesn't need to be trusted by WIndows but it's trusted by ekrn.exe and that's the point. Link to comment Share on other sites More sharing options...
itman 1,740 Posted July 21, 2023 Share Posted July 21, 2023 (edited) 22 hours ago, Pavol Cerven said: during testing our program we found out your dll file eamsi.dll inject into our process. Because this file is signed with Microsoft's certificate it will be no problem. You need to further define what the problem is. Did you setup this program to only accept valid code signed .dlls? Is eamsi.dll loading into this program failing for that reason? As best as I can determine, loading of eamsi.dll into a process will occur regardless of the code integrity error; Edited July 21, 2023 by itman Link to comment Share on other sites More sharing options...
Pavol Cerven 0 Posted July 22, 2023 Author Share Posted July 22, 2023 Our protection solution accepts in process only dlls with known certificates and valid signed dlls . I can add Eset's certificate as a known certificate. It is not the problem. The problem is a return value from WinVerifyTrust function. All correctly signed files normally return ERROR_SUCCESS. But eamsi.dll returns CERT_E_UNTRUSTEDROOT. Link to comment Share on other sites More sharing options...
itman 1,740 Posted July 22, 2023 Share Posted July 22, 2023 (edited) 10 hours ago, Pavol Cerven said: Our protection solution accepts in process only dlls with known certificates and valid signed dlls . I can add Eset's certificate as a known certificate. It is not the problem. The problem is a return value from WinVerifyTrust function. All correctly signed files normally return ERROR_SUCCESS. But eamsi.dll returns CERT_E_UNTRUSTEDROOT. As @Marcos explained previously, your protection solution shouldn't be performing WinVerifyTrust activities for self-signed certs.. I would contact the protection solution vendor about the issue. -EDIT- As I see it, your protection solution should be first performing; Quote The WTHelperCertIsSelfSigned function checks whether a certificate is self-signed. This function has no associated import library. You must use the LoadLibrary and GetProcAddress functions to dynamically link to Wintrust.dll. https://learn.microsoft.com/en-us/windows/win32/api/wintrust/nf-wintrust-wthelpercertisselfsigned Then bypassing the WinVerifyTrust function if the cert. is self-signed. Edited July 22, 2023 by itman Link to comment Share on other sites More sharing options...
Pavol Cerven 0 Posted July 22, 2023 Author Share Posted July 22, 2023 (edited) itman: Thank you for your answers, they are very helpful. But one thing I don't understand. You will add Eset's certificate to the whitelist of allowed certs. Then the security solution will check if it is the same cert. At this point everything is fine. Then you will call WTHelperCertIsSelfSigned function. It will return "it is self-signed cert". And then what? You can't call WinVerifyTrust because it will return CERT_E_UNTRUSTEDROOT. But how you will check if certs are ok and nobody changed the file? Then anybody can use a self-signed cert for another file or change eamsi.dll and you will allow it? This is what I don't understand. And I appreciate your opinion because your answers make sense. Btw: I looking for answers for others, because we have our's cert handling, checking, etc. You give me the correct way how we will do it for problematic certs like this (we will see if we can really do it in the correct way). Edited July 22, 2023 by Pavol Cerven Link to comment Share on other sites More sharing options...
itman 1,740 Posted July 23, 2023 Share Posted July 23, 2023 Since your concern seems to be with eamsi.dll not be validily signed, note the following; Quote Starting in Windows 10, version 1903, if your AMSI provider DLL is not Authenticode-signed, then it may not be loaded (depending on how the host machine is configured). For full details, see IAntimalwareProvider interface. https://learn.microsoft.com/en-us/windows/win32/amsi/antimalware-scan-interface-portal . Link to comment Share on other sites More sharing options...
Recommended Posts