Jump to content
RonTuijnman

Program Files\ESET\ESET NOD32 Antivirus\eamsi.dll

Recommended Posts

In my securitylogs every day some messages appear stating that 

Program Files\ESET\ESET NOD32 Antivirus\eamsi.dll

has made a false attempt to log in. How can I solve this
 Complete message:

- System
   
- Provider
      [ Name] Microsoft-Windows-Security-Auditing
      [ Guid] {54849625-5478-4994-a5ba-3e3b0328c30d}
   
  EventID 5038
   
  Version 0
   
  Level 0
   
  Task 12290
   
  Opcode 0
   
  Keywords 0x8010000000000000
   
- TimeCreated
      [ SystemTime] 2020-08-02T08:26:05.451369900Z
   
  EventRecordID 11770562
   
  Correlation
   
- Execution
      [ ProcessID] 4
      [ ThreadID] 5900
   
  Channel Security
   
  Computer xxxxxx [blanked for security reasons]
   
  Security
- EventData
    param1 \Device\HarddiskVolume3\Program Files\ESET\ESET NOD32 Antivirus\eamsi.dll

 

Share this post


Link to post
Share on other sites

The cause of the event is not known yet. Despite the event being logged, AMSI appears to work fine.

Share this post


Link to post
Share on other sites
1 hour ago, Marcos said:

The cause of the event is not known yet.

Err ...........

It's a Windows Code Integrity error. Obviously the hash is valid, so it has to be a code signing certificate issue.

Eset_code.png.543d9f39e7c0e855ee17468e92ab42f6.png

Share this post


Link to post
Share on other sites

"Time to take the bull by the horns" on this one.

First the Microsoft reference in regards to AV code signing of their amsi.dll version:

Quote

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\FeatureBits

Remarks

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 /ac switch (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 /kp option. 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.

Eset uses their driver code signing certificate to sign eamsi.dll. This cert. is not a  Authenticode + WHQL code signing certificate.

Why Eset 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.

I was going to write a POC about this a while back, but really got fed up with the excuses Eset was and continues to make on this issue.

   

 

Edited by itman

Share this post


Link to post
Share on other sites

Please provide logs collected with ESET Log Collector so that we have information about your ESET product version, the OS and most importantly the hash of eamsi.dll. Older products didn't have the dll signed with a Microsoft certificate but newer products have.

As for AMSI\FeatureBits, this setting is meant for testing and may be changed with Windows update by Microsoft. It's not something that vendors should change.

Share this post


Link to post
Share on other sites
7 hours ago, Marcos said:

your ESET product version, the OS and most importantly the hash of eamsi.dll

EIS ver. 13.2.16, Win 10 v(64) 2004

image.thumb.png.823cbd5c9f872e541397db9006861697.png

 

Edited by itman

Share this post


Link to post
Share on other sites
9 hours ago, Marcos said:

As for AMSI\FeatureBits, this setting is meant for testing and may be changed with Windows update by Microsoft. It's not something that vendors should change.

Here's the vulnerability and why very much so the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AMSI\FeatureBits value setting needs to be set to;

0x2   The check for Authenticode + WHQL signing is enabled.

In this registry key, HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AMSI\Providers, is a another registry key reference to where the AV vendor AMSI .dll is stored in clear text. All an attacker has to do is replace eamsi.dll there with his malicious .dll. This key is not write protected. 

This is the reason why Microsoft created the the check for Authenticode + WHQL signing validation. It is the only mechanism to ensure a legit AV vendor AMSI .dll is being used.

Share this post


Link to post
Share on other sites

itman I have to give you a big compliment again, you are really indispensable for the board here, you really hang in here and are really a big help!

Share this post


Link to post
Share on other sites

Comodo has a good article in layman terms on Authenticode certificate signing and validation. Of note:

Quote

An Authenticode signature is basically a complex mathematical function. First, a hash function is performed. The code itself, as well as the Microsoft Authenticode signing certificate, are concatenated (fancy word for combined) and hashed. Hashing is a cryptographic process that maps inputs of any length to a fixed length output or hash value. No two disparate inputs can create the same output.

Checksums rely on this certainty. The hash function is performed once during the signing and then again by the client when it’s first verifying the signature. When the two values match, it means the integrity of the software is intact. If not, the client issues a warning.

The hash value that’s produced during the signing is what actually gets signed. The Authenticode signing certificate’s private key signs the hash and hashes it again.

When the client receives the software, it starts by verifying the signature, repeating the second hash process and using the public key from the Authenticode signing certificate — which is also included with the software — to verify the signature. Then, the checksum is performed.

Provided everything checks out, the software is trusted and the Authenticode signature is considered verified.

https://comodosslstore.com/resources/what-is-windows-authenticode-signature/

Edited by itman

Share this post


Link to post
Share on other sites

The above is also not the only AMSI issue.

For every process where Eset's AMSI .dll is being injected into, Windows Defender's amsi.dll is also being injected as shown in the below Process Explorer screen shot. This in spite of the fact that WD is disabled and its engine process isn't even loaded. Suspect this might also be related to the Authenticode issue.

Now amsi.dll interestingly is not even signed. So I, dawning my attacker hat, will just replace amsi.dll with my malicious .dll.

Eset_AMSI.thumb.png.18ad6007aacca1894d9e11b6e65561e1.png

Share this post


Link to post
Share on other sites

Amsi.dll is a system dll whose purpose is to load AMSI providers. There is no relation between it and Windows Defender.

What we do is we register an AMSI provider and that's it. The operating system itself decides when and what processes the provider will be loaded into. Despite the eamsi.dll being signed with a MS signature, it cannot be loaded into all processes; svchost.exe seems to be one of the exceptions and the OS protects it from any 3rd party dll being loaded into it regardless of signatures.

Please do not compare Windows Defender with 3rd party AVs. Since it's a product of Microsoft, they can do virtually anything. But once they block any 3rd party dlls, other AV vendors cannot do anything about it. I will test some other AVs with AMSI providers as time allows.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...