Anyone Have Event 3033 Logged In Code Integrity Operational Re: antimalware_provider64.dll?
Code Integrity determined that a process (\Device\HarddiskVolume3\Windows\System32\SIHClient.exe) attempted to load \Device\HarddiskVolume3\Program Files\Bitdefender\Bitdefender Security\bdamsi\266416669197826934\antimalware_provider64.dll that did not meet the 12 signing level requirements.
Bitdefender Total Security Build 26.0.33.137
Answers
-
Hello.
You should contact Bitdefender Consumer Support by chat, telephone or e-mail:
Chat is the fastest way to get in touch with Bitdefender Consumer Support.
NOTE: Bitdefender telephone support is not toll-free!
Regards.
1 -
Hi jhawkinsvalrico,
I have. Tons of them, within seconds of each other, logged in Event Viewer>Applications and Services>Microsoft>Windows>CodeIntegrity>Operational. All since I, first upgraded from W11 22h2 to 22h2 and then clean installed W11 22H2. I have twice tried the usual: a) Completely uninstall and reinstall Bitdefender Internet Security (always last version from Bitdefender Central); and b) contacted Bitdefender Support (via email from the Support page). The first contact I received, as always a prompt response; however, they said: "The errors are part of the operating system security and are not a thing of concern. Microsoft doesn't have a correct validation for 3rd party AMSI libraries yet." Then I contacted Microsoft Windows Tech support via Chat and even let them do remote assistance on my PC and was told that Application Providers are responsible to make sure that their products meet Microsoft Windows security standards, among them: signing level requirements. I have contacted them by mail via support page and asked them for help. It seems to me that all they (Bitdefender) need to do is make sure that the "antimalware_provider64.dll" does that. I'm now waiting for a rsponse.
0 -
Generate bitdefender BDsysLog: https://www.bitdefender.com/consumer/support/answer/1922/
Generate bitdefender support tool logs: https://www.bitdefender.com/consumer/support/answer/1733/
Generate bitdefender connectivity logs: https://www.bitdefender.com/consumer/support/answer/9689/
Share the logs & your query with bitdefender support team by dropping them an email at bitsy@bitdefender.com
The support team will reply back to your query within next 24-48 hours excluding weekends.
Regards
Life happens, Coffee helps!
Show your Attitude, when you reach that Altitude!
Bitdefender Ultimate Security Plus (user)
0 -
Hi Guys, I have already done that yesterday (Ticket: 1008219482), so and I'm waiting for response still within the established answer time frame.
Thank you and regards.
0 -
@Alexandru_BD or @Mike_BD can check on the status of your support ticket.
Regards
Life happens, Coffee helps!
Show your Attitude, when you reach that Altitude!
Bitdefender Ultimate Security Plus (user)
0 -
I've figured out the problem, or at least found a post on another AV forum from someone who did. I'll just copy and paste it below (it's a different DLL but same problem).
Basically it seems like BitDefender needs to sign the DLL with a specific type of certificate that does Authenticode + WHQL, which will satisfy the more strict code integrity policy that is throwing the error. I believe that would eliminate the errors, then the user could change the registry key to also enforce it if they want.
When running signtool normally on antimalware_provider64.dll, it confirms the certificate is valid, but then I ran signtool with the /kp parameter on it and indeed it does say:
SignTool Error: A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.
I would very much appreciate if this was addressed because it would make it easier to set up Windows Defender Application Control, because right now this error is filling up my event log with a new error every second.
------------------------------ Copied post below ---------------------------------
Credit goes to the person called "itman":
First the Microsoft reference in regards to AV code signing of their amsi.dll version:
As of Windows 10, version 1903, Windows has added a way to enable Authenticode + Windows Hardware Quality Labs (WHQL) signing checks for providers. The feature is disabled by default, for both 32-bit and 64-bit processes. If you are creating a provider for test purposes, then you can enable or disable sign checks by setting the following Windows Registry value appropriately. The value is a DWORD.
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AMSI\FeatureBitsRemarks
Value Behavior
0x1 The signing check is disabled. This is the default behavior. You can also use this value, temporarily, while testing.
0x2 The check for Authenticode + WHQL signing is enabled.
Deleting the registry value altogether behaves as if the value 0x1 were present.
Note:
As a provider, you must use the
/acswitch (with the SignTool) to cross-sign with an Authenticode certificate. Once you've signed your binary, you can then verify it by using the SignTool and the/kpoption. If the SignTool returns no error, then your binary is properly signed.https://docs.microsoft.com/en-us/windows/win32/api/amsi/nn-amsi-iantimalwareprovider
Next, "translation" of the above:
Microsoft expects AV vendors to use an Authenticode + WHQL code signing certificate to sign their amsi.dll version. However, it provides a workaround to this for testing purposes only. When employed, Microsoft will throw a code integrity event because as far as they are concerned, the AV amsi.dll is not properly signed. Windows will also allow the AV vendor to inject their amsi.dll into a Win code integrity protected process.
[Company] uses their driver code signing certificate to sign eamsi.dll. This cert. is not a Authenticode + WHQL code signing certificate.
Why [Company] needs to use an Authenticode + WHQL code signing certificate to sign eamsi.dll
Once done, then this registry validation can be enabled:
0x2 The check for Authenticode + WHQL signing is enabled.
Why is this critical?
Because without the validation, it is possible for an attacker to modifiy the registry to point to his malicious .dll instead of eamsi.dll. This will allow the attacker to insert his malicious .dll into any Windows code integrity protected process.
It is also imperative if Authenticode + WHQL signing is enabled in the registry, this key,
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AMSI\FeatureBits,be protected by the AV vendor to prevent modification.1
