Jump to content
itman

Eset AMSI DLL Issue on Win 10 x(64) 1903

Recommended Posts

EIS ver. 12.1.64

Eset_AMSI.thumb.png.45d7a6538b3c963d9233f83bd180f7dd.png

Share this post


Link to post
Share on other sites

I have the same but it just seems to be an informative alert rather than a genuine fault.

Share this post


Link to post
Share on other sites
Posted (edited)
59 minutes ago, cyberhash said:

I have the same but it just seems to be an informative alert rather than a genuine fault.

Not quite.

Each one of the errors indicates a process where Eset's AMSI .dll was blocked from loading. Most of the alerts relate to SIHClient.exe; i.e. service-initiated healing:

This daily task launches the SIH client (server-initiated healing) to detect and fix system components that are vital to automatic updating of Windows and Microsoft software installed on the machine. This task can go online, evaluate applicability of healing actions, download necessary payloads to execute the actions, and execute healing actions.

I am not too concerned about this one.

However, there are errors associated with svchost.exe with no detain given of associated service. These are the ones I am concerned about. As it presently stands, Eset AMSI .dll is only injected into two svchost.exe service associated processes.

Edited by itman

Share this post


Link to post
Share on other sites

As of v12.2, eamsi.dll is signed by Microsoft, hence the error should not be logged any more. Anyways, it doesn't affect protection whatsoever and script scanning via AMSI worked in older versions without issues.

Share this post


Link to post
Share on other sites
Posted (edited)

I was able to identify one of the svchost.exe services where eamsi.dll was blocked and it is Windows Security Center. So the sooner ver 12.2 is implemented, the better.

BTW - Win 10 1903 was released in May ........................

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://docs.microsoft.com/en-us/windows/win32/amsi/antimalware-scan-interface-portal

Edited by itman

Share this post


Link to post
Share on other sites

Just upgraded to ver. 12.2.23.

Appears all is fixed except injection into Windows Security Center service; i.e. wscsvc. Possibly because it is running as PPL process.

Share this post


Link to post
Share on other sites
Posted (edited)

Also should not this registry key now be set to 0x2 since Eset's .dll is Microsoft Authenticode signed? It is still set to 0x1 on my ver. 12.2. 23 device:

Quote

As of Windows 10, version 1903, Windows has added a way to enable Authenticode 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

Value Behavior
0x1 The Authenticode-signed check is disabled. This is the default behavior. You can also use this value, temporarily, while testing.
0x2 The Authenticode-signed check is enabled.

 

Edited by itman

Share this post


Link to post
Share on other sites
Posted (edited)

Figured out why Eset attempts to inject its AMSI .dl into svchost.exe PPL instances is failing. Had to dive into my reference materials.

To inject code into a PPL process, the code must be signed at WindowsTCB authentication level. This is the highest signing level available. Eset signed the eamsi.dll with its regular driver certificate which is authorized for PP - Authenticode level only. Microsoft only issues one type of WindowsTCB level certificate. That is the certificate Eset used to sign its ELAM driver. Therefore it appears to me, Eset needs to sign the eamsi.dll with this certificate:

Eset_ELAM.png.5ddeac460303e698b06021d20a375b5f.png

 

 

 

Edited by itman

Share this post


Link to post
Share on other sites
Quote

Also should not this registry key now be set to 0x2 since Eset's .dll is Microsoft Authenticode signed?

This value is set by the operating system and 3rd party vendors have no reason to change OS settings that are controlled by the OS itself. By default, the value FeatureBits doesn't exist.

Quote

Figured out why Eset attempts to inject its AMSI .dl into svchost.exe PPL instances is failing.

We do not inject eamsi.dll whatsoever. If a particular process utilizes AMSI, the OS is responsible for loading the said dll into it.

Quote

Therefore it appears to me, Eset needs to sign the eamsi.dll with this certificate

No. The said certificate is intended to sign ELAM drivers only. Microsoft doesn't sign 3rd party dlls.

Share this post


Link to post
Share on other sites
Posted (edited)
6 hours ago, Marcos said:

We do not inject eamsi.dll whatsoever. If a particular process utilizes AMSI, the OS is responsible for loading the said dll into it.

OK. Let's assume eamsi.dll has been added to the list of knowndlls, etc.. In any case, it will not be loaded into any PPL process because it is not properly signed to do so. Since Microsoft is increasingly using PPL to protect its processes, Eset's monitoring capability is increasingly being diminished.

As any pen-tester "worth his salt" will attest, PPL is somewhat of a joke and multiple bypass POCs exist showing this.

Eset_AMSI.png.88193c022ec701ecedcd9feae0da0d7b.png

 

 

Edited by itman

Share this post


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

No. The said certificate is intended to sign ELAM drivers only. Microsoft doesn't sign 3rd party dlls.

My take on this is this cert. can be used to sign .dlls. As you noted previously, Windows is attempting to load the AV amsi.dll into a PPL process. It wouldn't  attempt it unless it assumed the .dll was properly signed.

Quote

Signing levels allow Microsoft to open up protected processes to third-parties, although at the current time the only type of protected process that a third party can create is an Anti-Malware PPL. The Anti-Malware level is special as it allows the third party to add additional permitted signing keys by registering an Early Launch Anti-Malware (ELAM) certificate.

https://googleprojectzero.blogspot.com/2018/10/injecting-code-into-windows-protected.html

Or alternatively, just use one of the PPL bypasses noted in the article.🙄

Share this post


Link to post
Share on other sites
Quote

My take on this is this cert. can be used to sign .dlls. As you noted previously, Windows is attempting to load the AV amsi.dll into a PPL process. It wouldn't  attempt it unless it assumed the .dll was properly signed.

I would say that developers and Microsoft know best so... I only quoted them and passed the information here to stop speculations.

Also eamsi.dll is properly signed.

 

 

Share this post


Link to post
Share on other sites
Posted (edited)
6 minutes ago, Marcos said:

I would say that developers and Microsoft know best so... I only quoted them and passed the information here to stop speculations.

Actually I misstated in use of Eset's ELAM cert. per se. Eset's needs to add the special PPL keys provided within the ELAM cert. to its existing driver authenticode cert..

Edited by itman

Share this post


Link to post
Share on other sites

Ok, there was a misunderstanding. As of v12.2, eamsi.dll is signed by Microsoft so that processes that utilize AMSI can load eamsi.dll without issues.

What developers meant was that Microsoft would not sign the dll using the ELAM certificate.

Share this post


Link to post
Share on other sites
Posted (edited)
1 hour ago, Marcos said:

Ok, there was a misunderstanding. As of v12.2, eamsi.dll is signed by Microsoft so that processes that utilize AMSI can load eamsi.dll without issues.

I checked the code signing specification on both the Microsoft ELAM and AMSI certificates used in both Eset corresponding entities and they are identical; i.e. 1.3.6.1.5.5.7.3.3. So at this point, I am at a loss as to why Win 10 1903 is blocking loading of the Eset AMSI .dll into PPL processes.

What I do know is these code integrity errors for PPL processes were not occurring on Win 10 1809. I "religiously" check that event log for errors.  I suggest Eset developers get together with Microsoft as to cause and resolution.

-EDIT- One possibility is the Microsoft driver certificate Eset is using to sign its AMSI .dll must be EV status as the corresponding ELAM certificate is.

Edited by itman

Share this post


Link to post
Share on other sites

@Marcos, Eset AMSI doesn't detect this Powershell malware script; i.e. Win32/Mptest!amsi, that Microsoft developed to test AMSI functionality as noted below:

AMSI_Test.png.9ff926a451a1515d70b6f3afa75fa78b.png

Ref.: https://docs.microsoft.com/en-us/windows/win32/amsi/how-amsi-helps

I assume and hope this is because Eset doesn't have a like sig. detection for this. Please add a sig. for this. Let me know when this is done so I can retest.

Note: LiveGrid uploaded something when I was testing so the servers might already have code.

Share this post


Link to post
Share on other sites

There's nothing to detect since the script merely prints "'AMSI Test Sample: 7e72c3ce-861b-4339-8740-0ac1484c1386'". It doesn't do anything else. As you understand, this is not harmful and thus the script is not subject to detection.

Share this post


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

There's nothing to detect since the script merely prints "'AMSI Test Sample: 7e72c3ce-861b-4339-8740-0ac1484c1386'". It doesn't do anything else.

Wrong. Refer to the Microsoft article for output displayed from Powershell when detected.

Share this post


Link to post
Share on other sites

What code are you referring to? I was referring to this one:

Quote

$base64 = "FHJ+YHoTZ1ZARxNgUl5DX1YJEwRWBAFQAFBWHgsFAlEeBwAACh4LBAcDHgNSUAIHCwdQAgALBRQ="
$bytes = [Convert]::FromBase64String($base64)
$string = -join ($bytes | % { [char] ($_ -bxor 0x33) })
iex $string

 

Share this post


Link to post
Share on other sites

Here's what is displayed upon detection:

image.png.d9d54aa3808c7feff9f04156109dc906.png

Share this post


Link to post
Share on other sites

As I wrote, the script merely downloads an encrypted string, decrypts it and displays it (" 'AMSI Test Sample: 7e72c3ce-861b-4339-8740-0ac1484c1386'").

You can also see in the url in the screen shot that Defender detects it as a test file  Win32/Mptest!ams.

Normally it would be a false positive triggered on an innocuous script but since it's recognized by Defender as a test file, I'm ok with the detection as they make it clear to users, however, it may not be obvious at the first glance.

Share this post


Link to post
Share on other sites

I just asked for a sig. to be added to verify Eset's AMSI  detection functionality. No different in concept to existing AMTSO tests.

Forget I asked.

Share this post


Link to post
Share on other sites
9 minutes ago, itman said:

I just asked for a sig. to be added to verify Eset's AMSI  detection functionality. No different in concept to existing AMTSO tests.

Forget I asked.

I see now. I overlooked that and thought you wanted to report it as missed malware or whatever. I'll reach out to a colleague who is in touch with people from AMTSO to find out if other AV vendors would agree with using the script for testing AMSI functionality. A detection should be agreed by all AV vendors like it's with eicar and other test files.

As far as I know, even test files are protected with copyright and the maker of them must give permissions for detection or putting the test files on other websites that are not owned by the maker.

Share this post


Link to post
Share on other sites

Also to clarify, I expect to see Eset alert displayed, entry created in Detection log showing AMSI detection, and script quarantined.

Obviously since the script was never executed, PowerShell output display would not show what if given for the WD detection.

Also rather going the AMTSO committee route, Eset could just create like test AMSI PowerShell malware .php script?  Since it would only be detected by Eset, the "obsessive" FP concern would be eliminated.

Share this post


Link to post
Share on other sites

We will definitely discuss it, however, the test script should be widely accepted by other AVs as a test script. Otherwise it could happen that if such test file gets into test sets, especially in amateurish tests vendors would have no chance to raise objections if they missed it.

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.


  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...