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

[RonTuijnman 0]

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

 

[Marcos 5,070]

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

[itman 1,659]

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.

[itman 1,659]

"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 August 2, 2020 by itman

[Marcos 5,070]

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.

[itman 1,659]

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

 

Edited August 3, 2020 by itman

[itman 1,659]

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.

[SlashRose 25]

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!

[itman 1,659]

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 August 3, 2020 by itman

[itman 1,659]

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.

[Marcos 5,070]

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.

[itman 1,659]

5 hours ago, Marcos said:

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.

Correct. It was a "brain cramp" moment. I should have left out any reference to Window Defender.

Microsoft has a graphical representation of AMSI here: https://docs.microsoft.com/en-us/windows/win32/amsi/how-amsi-helps

Appears Windows will "piggyback" loading the AV vendor amsi.dll into the few default processes Win amsi.dll is injected into. The AV vendor is free to inject its amsi.dll into any process it chooses and is not security-wise restricted from doing so; e.g. protected process - light protected. For example, Eset injects eamsi.dll into FireFox enabling it to fully scan web page JavaScripts.

However, the issue of proper signing of eamsi.dll still remains. Most of the above mentioned default processes have code integrity guard enabled.

[Marcos 5,070]

Let's stop any speculations, all AVs have this issue. The topic is subject to dispute with Microsoft.

Code Integrity determined that a process (\Device\HarddiskVolume3\Windows\System32\svchost.exe) attempted to load \Device\HarddiskVolume3\Program Files (x86)\Kaspersky Lab\Kaspersky Anti-Virus 20.0\x64\antimalware_provider.dll that did not meet the Windows signing level requirements.

 

Code Integrity determined that a process (\Device\HarddiskVolume2\Program Files\Windows Defender\MpCmdRun.exe) attempted to load \Device\HarddiskVolume2\Program Files\Avast Software\Avast\aswAMSI.dll that did not meet the Microsoft signing level requirements.

 

Windows is unable to verify the image integrity of the file \Device\HarddiskVolume2\Program Files\Trend Micro\Titanium\TmWscSvc\WSCHandler.exe because file hash could not be found on the system. A recent hardware or software change might have installed a file that is signed incorrectly or damaged, or that might be malicious software from an unknown source.

 

Code Integrity determined that a process (\Device\HarddiskVolume2\Program Files\Windows Defender\MpCmdRun.exe) attempted to load \Device\HarddiskVolume2\Program Files\DrWeb\drwamsi64.dll that did not meet the Microsoft signing level requirements.

 

 

[itman 1,659]

7 hours ago, Marcos said:

Let's stop any speculations, all AVs have this issue.

Let's rephrase this to the four AVs you tested have the issue. Appears you are the one speculating.

As such they are as vulnerable as Eset is. On the other hand, they might prevent their amsi.dll from being replaced in the registry. Also, Eset's issue as originally posted is a hash error.

 

Edited August 4, 2020 by itman

[itman 1,659]

Here's the reason why eamsi.dll is generating a hash error.

Microsoft has higher requirements when it comes to proper signing of Authenticode modules: https://docs.microsoft.com/en-us/windows-hardware/drivers/install/authenticode-signing-of-csps  . 

Of specific reference is cross-certificate signing requirements: https://docs.microsoft.com/en-us/windows-hardware/drivers/install/cross-certificates-for-kernel-mode-code-signing . Only a handful of specific CA's are authorized and only a specific certificate issued by each. Appears Eset's original SHA-1 certificate was legit since it was issued by DigiCert. The problem is SHA-1 certificates are no longer valid.. Eset's SHA-256 certificate is issued by Symantec and hence, not valid for cross-certificate signing.

 

Edited August 5, 2020 by itman

[SlashRose 25]

22 hours ago, itman said:

Let's rephrase this to the four AVs you tested have the issue. Appears you are the one speculating.

 

Must absolutely agree with iTman and that's why I've tried Marcos 1000 times to make things understandable! As always top itman

[RonTuijnman 0]

Thanx everybody for your replies! I know now it's a common problem with ESET, so it's safe to ignore these errors.

 

[Marcos 5,070]

4 minutes ago, RonTuijnman said:

Thanx everybody for your replies! I know now it's a common problem with ESET, so it's safe to ignore these errors.

As you can see above, every AV except Defender which is a part of the OS has this problem simply because MS as a maker of Windows allows only MS dlls to be injected into processes without restrictions.

[itman 1,659]

I am going to get right to the point on this.

The eamsi.dll hash code integrity errors are being generated because Eset is trying to inject the .dll into Protected Process - Light (PPL) processes. I might be missing something in this Google Project Zero article which BTW is about bypassing PPL protection: https://googleprojectzero.blogspot.com/2018/10/injecting-code-into-windows-protected.html  . However if Eset used it's anti-malware vendor cert; the one used to sign its ELAM driver, to also sign eamsi.dll, this should allow for eamsi.dll to be injected into a PPL process.

@Marcos , something for Eset to checkout.

Edited August 20, 2020 by itman

[Marcos 5,070]

Neither ESET nor other AVs inject an AMSI provider dll (e.g. eamsi.dll, antimalware_provider.dll, aswAMSI.dll, etc.) into protected processes. Loading the AMSI provider dll is performed by the process itself. Regarding PPL, it is just one of protected processes levels.

How eamsi.dll is signed can be verified yourself. However, there are protected processes that allow to load only dlls that are part of the OS and are signed by MS. That said, dlls of any other 3rd party vendors will not load as long as Microsoft has this restriction for special protected processes and no vendor can do anything about it. As I have stated before, this is being discussed with Microsoft. Until they make a statement on this, anything else are just misleading speculations.

[itman 1,659]

1 hour ago, Marcos said:

 However, there are protected processes that allow to load only dlls that are part of the OS and are signed by MS.

Correct. These are process signed with the TCB component specification as shown in the linked Google article:

However, this is not an issue with eamsi.dll code integrity errors since the processes being injected are not TCB protected:

Quote

Windows is unable to verify the image integrity of the file \Device\HarddiskVolume1\Program Files\ESET\ESET Security\eamsi.dll because file hash could not be found on the system. A recent hardware or software change might have installed a file that is signed incorrectly or damaged, or that might be malicious software from an unknown source.
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-CodeIntegrity" Guid="{4ee76bd8-3cf4-44a0-a0ac-3937643e37a3}" />
    <EventID>3004</EventID>
    <Version>1</Version>
    <Level>2</Level>
    <Task>1</Task>
    <Opcode>104</Opcode>
    <Keywords>0x8000000000000000</Keywords>
    <TimeCreated SystemTime="2020-08-21T12:52:32.3899482Z" />
    <EventRecordID>2057</EventRecordID>
    <Correlation ActivityID="{3e8e9693-770a-0001-8e00-8f3e0a77d601}" />
    <Execution ProcessID="2348" ThreadID="6840" />
    <Channel>Microsoft-Windows-CodeIntegrity/Operational</Channel>
    <Computer>
    <Security UserID="S-1-5-18" />
  </System>
  <EventData>
    <Data Name="FileNameLength">66</Data>
    <Data Name="FileNameBuffer">\Device\HarddiskVolume1\Program Files\ESET\ESET Security\eamsi.dll</Data>
    <Data Name="SecureRequired">0x80000000</Data>
    <Data Name="RequestedSigningLevel">12</Data>
    <Data Name="ProcessNameLength">54</Data>
    <Data Name="ProcessNameBuffer">\Device\HarddiskVolume1\Windows\System32\SIHClient.exe</Data>
  </EventData>
</Event>

Note that SIHClient.exe does not have the Windows TCB Component specification associated with it:

I really can't see what Eset has to lose by testing what I proposed. Eset being a large organization appears to be struck in bureaucratic inertia when it comes to "thinking outside of the security box" in regards to new ideas.

Edited August 21, 2020 by itman