Ver. 10 - Driver Hash Error

[itman 1,659]

Just noticed this one. Been getting it since ver. 10 was initially installed. Of note is that the associated eelam driver files are all dated 7/20. All the rest of the drivers associated files are dated 10/7.

 

Log Name:      Security
Source:        Microsoft-Windows-Security-Auditing
Date:          10/25/2016 9:59:21 AM
Event ID:      5038
Task Category: System Integrity
Level:         Information
Keywords:      Audit Failure
User:          N/A
Computer:      xxxxxx
Description:
Code integrity determined that the image hash of a file is not valid.  The file could be corrupt due to unauthorized modification or the invalid hash could indicate a potential disk device error.

File Name: \Device\HarddiskVolume3\Program Files\ESET\ESET Smart Security\Drivers\eelam\eelam.sys 
Event Xml:
<Event xmlns="hxxp://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-A5BA-3E3B0328C30D}" />
    <EventID>5038</EventID>
    <Version>0</Version>
    <Level>0</Level>
    <Task>12290</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8010000000000000</Keywords>
    <TimeCreated SystemTime="2016-10-25T13:59:21.314079200Z" />
    <EventRecordID>192162</EventRecordID>
    <Correlation />
    <Execution ProcessID="4" ThreadID="5536" />
    <Channel>Security</Channel>
    <Computer>xxxxx</Computer>
    <Security />
  </System>
  <EventData>
    <Data Name="param1">\Device\HarddiskVolume3\Program Files\ESET\ESET Smart Security\Drivers\eelam\eelam.sys</Data>
  </EventData>
</Event>

Edited October 30, 2016 by itman

[Marcos 5,070]

How often is this happening? We assume it shouldn't happen more than once during install as this driver is not used under normal circumstances. Also please provide us with a hash of the driver file so that we can check if it's not corrupted.

[itman 1,659]

MD5 hash is A6E666A2C13782E7D012202351DE0FFB. Same hash value for files in both Eset and Win10 driver directories.

 

This has been happening since I installed ver. 10 on 10/25.

 

Per below event log screen shot, it occurs 4 times during each Win 10 boot. Also I have done a repair since ver. 10 first install. So sure this activity not due to a corrupt install.

 

Also date of this driver stored in C:\Windows\System32\drivers is 6/23/2016. File details indicates its a ver. 10.0 driver.

 

Edited October 31, 2016 by itman

[itman 1,659]

Here's the reg entry for the driver. It is attempting to load first along with all the other critical Win 10 system drivers. Since it is Eset's Win 10 EAM interface driver, I would expect this to be the case. It is not currently loaded into memory per Process Explorer check. I believe Win will block loading of any drivers with a hash error? Appears something is corrupting/modifying it at boot time?

 

So the question is if Eset's ver. 10 ELAM interface working properly? 

 

 

[itman 1,659]

FYI. So much for ELAM protection as noted in the last paragraph:

 

Malware Signatures

 

The malware signature data is determined by the AM ISV, but should include, at a minimum, an approved list of driver hashes. The signature data is stored in the registry in a new “Early Launch Drivers” hive under HKLM that is loaded by Winload. Each AM driver has a unique key in which to store their signature binary large object (BLOB). The registry path and key has the format:

 

HKLM\ELAM\\<VendorName>\

 

Within the key, the vendor is free to define and use any of the values. There are three defined binary blob values that are measured by Measured Boot, and the vendor may use each:

 

•Measured
•Policy
•Config

 

The ELAM hive is unloaded after its use by Early Launch Antimalware for performance. If a user mode service wants to update the signature data, it should mount the hive file from the file location \Windows\System32\config\ELAM. The storage and retrieval format of these data BLOBs is left up to the ISV, but the signature data must be signed so that the AM driver can verify the integrity of the data.

 

Verifying Malware Signatures

 

The method for verifying the integrity of the malware signature data is left up to each AM ISV. The CNG Cryptographic Primitive Functions are available to assist in verifying digital signatures and certificates on the malware signature data.

 

Malware Signature Failure

 

If the ELAM driver checks the integrity of the signature data, and that check fails, or if there is no signature data, the initialization of the ELAM driver still succeeds. In this case, for each boot driver the ELAM driver must return “unknown” for each initialization callback. Additionally, the ELAM driver should pass this information onto the runtime AM component once it has started.

 

Ref.: https://msdn.microsoft.com/en-us/windows/hardware/drivers/install/elam-driver-requirements

 

 

 

Edited October 31, 2016 by itman

[itman 1,659]

Also noteworthy is this registry key, HKLM\ELAM\\<VendorName>\, from the above MS article does not exist on my Win 10 installation.

Edited October 31, 2016 by itman

[itman 1,659]

I want to disable eelam.sys till this issue is resolved. Do I have to disable Eset's self-protection to modify its reg. start key? Starting regedit as admin won't allow any mods. to this key.

[mandiato 19]

How often is this happening? We assume it shouldn't happen more than once during install as this driver is not used under normal circumstances. Also please provide us with a hash of the driver file so that we can check if it's not corrupted.

I also can confirm that.

 

On every boot on windows security log there's 4 entires with info that eelam verification failed becaus hash of file is wrong, so file was modified or corrupted. Here it is part from my log from last boot. And this is SHA256 hash for it:

 

Nazwa dziennika:Security
Źródło:        Microsoft-Windows-Security-Auditing
Data:          01.11.2016 10:39:18
Identyfikator zdarzenia:5038
Kategoria zadania:Integralność systemu
Poziom:        Informacje
Słowa kluczowe:Niepowodzenie inspekcji
Użytkownik:    Nie dotyczy
Komputer:      MonsterXXL
Opis:
Funkcja sprawdzania integralności kodu wykryła, że skrót obrazu pliku jest nieprawidłowy. Plik mógł zostać uszkodzony z powodu nieautoryzowanej modyfikacji. Nieprawidłowy skrót może wskazywać potencjalny problem z urządzeniem dyskowym.

Nazwa pliku:    \Device\HarddiskVolume9\Windows\System32\drivers\eelam.sys    
Kod XML zdarzenia:
<Event xmlns="hxxp://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-A5BA-3E3B0328C30D}" />
    <EventID>5038</EventID>
    <Version>0</Version>
    <Level>0</Level>
    <Task>12290</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8010000000000000</Keywords>
    <TimeCreated SystemTime="2016-11-01T09:39:18.931652900Z" />
    <EventRecordID>173381</EventRecordID>
    <Correlation />
    <Execution ProcessID="4" ThreadID="320" />
    <Channel>Security</Channel>
    <Computer>MonsterXXL</Computer>
    <Security />
  </System>
  <EventData>
    <Data Name="param1">\Device\HarddiskVolume9\Windows\System32\drivers\eelam.sys</Data>
  </EventData>
</Event>

Nazwa dziennika:Security
Źródło:        Microsoft-Windows-Security-Auditing
Data:          01.11.2016 10:39:18
Identyfikator zdarzenia:5038
Kategoria zadania:Integralność systemu
Poziom:        Informacje
Słowa kluczowe:Niepowodzenie inspekcji
Użytkownik:    Nie dotyczy
Komputer:      MonsterXXL
Opis:
Funkcja sprawdzania integralności kodu wykryła, że skrót obrazu pliku jest nieprawidłowy. Plik mógł zostać uszkodzony z powodu nieautoryzowanej modyfikacji. Nieprawidłowy skrót może wskazywać potencjalny problem z urządzeniem dyskowym. It says that eelam.sys integration checks failed.

Nazwa pliku:    \Device\HarddiskVolume9\Windows\System32\drivers\eelam.sys    
Kod XML zdarzenia:
<Event xmlns="hxxp://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-A5BA-3E3B0328C30D}" />
    <EventID>5038</EventID>
    <Version>0</Version>
    <Level>0</Level>
    <Task>12290</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8010000000000000</Keywords>
    <TimeCreated SystemTime="2016-11-01T09:39:18.929951300Z" />
    <EventRecordID>173380</EventRecordID>
    <Correlation />
    <Execution ProcessID="4" ThreadID="320" />
    <Channel>Security</Channel>
    <Computer>MonsterXXL</Computer>
    <Security />
  </System>
  <EventData>
    <Data Name="param1">\Device\HarddiskVolume9\Windows\System32\drivers\eelam.sys</Data>
  </EventData>
</Event>

Nazwa dziennika:Security
Źródło:        Microsoft-Windows-Security-Auditing
Data:          01.11.2016 10:39:18
Identyfikator zdarzenia:5038
Kategoria zadania:Integralność systemu
Poziom:        Informacje
Słowa kluczowe:Niepowodzenie inspekcji
Użytkownik:    Nie dotyczy
Komputer:      MonsterXXL
Opis:
Funkcja sprawdzania integralności kodu wykryła, że skrót obrazu pliku jest nieprawidłowy. Plik mógł zostać uszkodzony z powodu nieautoryzowanej modyfikacji. Nieprawidłowy skrót może wskazywać potencjalny problem z urządzeniem dyskowym.

Nazwa pliku:    \Device\HarddiskVolume9\Program Files\ESET\ESET Smart Security Premium\Drivers\eelam\eelam.sys    
Kod XML zdarzenia:
<Event xmlns="hxxp://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-A5BA-3E3B0328C30D}" />
    <EventID>5038</EventID>
    <Version>0</Version>
    <Level>0</Level>
    <Task>12290</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8010000000000000</Keywords>
    <TimeCreated SystemTime="2016-11-01T09:39:18.928035800Z" />
    <EventRecordID>173379</EventRecordID>
    <Correlation />
    <Execution ProcessID="4" ThreadID="320" />
    <Channel>Security</Channel>
    <Computer>MonsterXXL</Computer>
    <Security />
  </System>
  <EventData>
    <Data Name="param1">\Device\HarddiskVolume9\Program Files\ESET\ESET Smart Security Premium\Drivers\eelam\eelam.sys</Data>
  </EventData>
</Event>

Nazwa dziennika:Security
Źródło:        Microsoft-Windows-Security-Auditing
Data:          01.11.2016 10:39:18
Identyfikator zdarzenia:5038
Kategoria zadania:Integralność systemu
Poziom:        Informacje
Słowa kluczowe:Niepowodzenie inspekcji
Użytkownik:    Nie dotyczy
Komputer:      MonsterXXL
Opis:
Funkcja sprawdzania integralności kodu wykryła, że skrót obrazu pliku jest nieprawidłowy. Plik mógł zostać uszkodzony z powodu nieautoryzowanej modyfikacji. Nieprawidłowy skrót może wskazywać potencjalny problem z urządzeniem dyskowym.

Nazwa pliku:    \Device\HarddiskVolume9\Program Files\ESET\ESET Smart Security Premium\Drivers\eelam\eelam.sys    
Kod XML zdarzenia:
<Event xmlns="hxxp://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-A5BA-3E3B0328C30D}" />
    <EventID>5038</EventID>
    <Version>0</Version>
    <Level>0</Level>
    <Task>12290</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8010000000000000</Keywords>
    <TimeCreated SystemTime="2016-11-01T09:39:18.913446400Z" />
    <EventRecordID>173378</EventRecordID>
    <Correlation />
    <Execution ProcessID="4" ThreadID="320" />
    <Channel>Security</Channel>
    <Computer>MonsterXXL</Computer>
    <Security />
  </System>
  <EventData>
    <Data Name="param1">\Device\HarddiskVolume9\Program Files\ESET\ESET Smart Security Premium\Drivers\eelam\eelam.sys</Data>
  </EventData>
</Event>

Edited November 1, 2016 by mandiato

[Marcos 5,070]

According to the hash the file is ok and not corrupted. The same is happening on one of dev's computer with Windows 10 but not on Win10 x64 1607 Enterprise. At the moment we don't know what could be causing these errors. We don't recommend disabling that driver or ekrn will not run as a protected service.

[itman 1,659]

I am running Win 10 Home x64 1607.

 

I am also getting slow initialization of Eset after boot with the GUI not appearing on the task bar for 2 mins. or so with updating staring after that. Whereas in the past, the Eset GUI was present when the desktop was initialized.

[itman 1,659]

Thinking about this a bit more, I have had past hash errors with Emsisoft drivers and I was running Win 7 at the time. Win 7 does not employ ELAM. So I don't now believe ELAM is the issue here.

 

Will have to do more research on what can cause those hash errors.

[itman 1,659]

I think the problem is the ELAM certificate the driver is using. No problem with the cert. per se. However, I noticed that when trying to view cert. details, got a firewall alert for outbound connection to MS cert. server.

Does that ELAM cert. have to be installed in the local CA store?

[itman 1,659]

Well, I thought I had the problem resolved. Guess not .............

The 2014 MS intermediate CA cert that the eelam driver uses was not installed in the Win 10 intermediate CA store. Installed that and did a cold boot. Hash problem persists. At least my boot times are back to normal w/Eset GUI displayed at desktop initialization.

As the event log entry @ mandiato posted shows, the eelam driver is failing the hash check from both the Eset and Win driver directories. Appears to me the hash value stored in the ELAM registry area hive area is incorrect. That is as stated previously, the hive area exists in Win 10 home? Again this reg. key, HKLM\ELAM\\<VendorName>\, does not exist in my Win 10 registry.

Edited November 1, 2016 by itman

[itman 1,659]

Think I got this figured out.

 

First a bit about ELAM from this bleepingcomputer.com article:

 

Configuring Early Launch Anti-Malware Protection via the Registry

 

If you are not using Windows 8 Professional or Enterprise you will not have access to the Group Policy Editor. Instead you will need to enable this setting through the Windows Registry. This setting can be enabled by creating a REG_DWORD value named DriverLoadPolicy under the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Policies\EarlyLaunch Registry key.

You would then have to assign one of 4 data values to the DriveLoadPolicy value to configure a particular classification. The decimal values that you can choose to assign to the DriverLoadPolicy value are:

 

 

Classification

DWORD Data Value

Good Only

8

Good and unknown

1

Good, unknown, bad but critical

3

All

7

 

 

And you guessed it folks, this key, HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Policies\EarlyLaunch  doesn't exist on my Win 10 x64 Home build. Safe to say ELAM is only available on the Pro and Enterprise vers..

 

Appears Eset is using the ELAM API's to load eelam.sys, if its actually loading, early in the boot process. Problem is the OS doesn't like it doing so and is throwing a "hash" error on the driver.

 

-EDIT-

 

Just created a ntbootlog. Eelam.sys is loading and is loading early. So it appears to be working.

Edited November 1, 2016 by itman

[mandiato 19]

 

And you guessed it folks, this key, HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Policies\EarlyLaunch  doesn't exist on my Win 10 x64 Home build. Safe to say ELAM is only available on the Pro and Enterprise vers..

 

But on my Windows 1607 x64 those registry entry also is not available, so this is no Home version problem only.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Policies]

This is registry hive dump from my machine, and as you see there's no EarlyLaunch policy at all.

[itman 1,659]

 

 

And you guessed it folks, this key, HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Policies\EarlyLaunch  doesn't exist on my Win 10 x64 Home build. Safe to say ELAM is only available on the Pro and Enterprise vers..

 

But on my Windows 1607 x64 those registry entry also is not available, so this is no Home version problem only.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Policies]

This is registry hive dump from my machine, and as you see there's no EarlyLaunch policy at all.

 

Are you running Win 10 Pro or Enterprise ver.? Build 1607 is just the release ver..

Edited November 1, 2016 by itman

[mandiato 19]

Are you running Win 10 Pro or Enterprise ver.? Build 1607 is just the release ver..

 

I'm using Pro version, and in work I can check default settings under Enterprise, but this place is by default empty and Policy hive is for changed policies from default settings, so by default and by design this one is empty.

[itman 1,659]

Think I can demystify this a bit. Read this article for further details: hxxp://deploymentresearch.com/Research/Post/514/List-of-Windows-10-features-that-requires-UEFI

 

1. The Secure Boot feature is only available for motherboards that use UEFI firmware. Older BIOS firmware doesn't support the feature.

2. ELAM along with other additional security options are loaded by Secure Boot processing.

 

The question to Eset is that the ELAM option is set on by default in ver. 10. Should the ELAM option be disabled in ver. 10 for all Win 10 PC's that don't use UEFI?

 

-EDIT-

 

Forgot to mention that the ELAM driver can be loaded twice. Once as part of the above secure boot process to monitor low-level loading system processes and later during the normal driver and system processes boot loafing procedure.

 

Since Eset's ELAM driver is throwing a hash error upon loading, it indicates to me some type of corruption is occurring during that process. So I am going to disable the ver. 10 ELAM driver use option in ver. 10 until this matter is resolved.

 

Marcos, please let me know when a resolution has been deployed.

 

-EDIT 2 -

 

I give up. The ver. 10 ELAM setting doesn't prevent the driver from loading and throwing resultant hash errors.

Edited November 2, 2016 by itman

[itman 1,659]

Believe this is what is causing the hash error. Noticed this previously but forgot to mention it. 

 

The eelam.sys driver is the only Eset driver that is missing Eset SHA1 and SHA256 certs. Believe those certs. are used to validate hash values? Just include those certs. and issue a driver update and hopefully, we can put this issue to bed.

[Marcos 5,070]

Everything works as expected, it's just that the errors are logged for some reason. We continue investigating it.

 

If there were issues with the elam driver, ekrn.exe would not run as protected service. To verify if ekrn is running as protected service, launch Process Explorer, double click ekrn and on the Security tab check if "Protected service" reads "No" or the following which appears if everything is ok with the elam driver:

 

[Peter Randziak 1,130]

Regarding eelam.sys driver signature: "Each driver .sys file must be code signed by Microsoft, using a special certificate indicating that it is an Early Launch AM Driver." as stated in ELAM Prerequisites by MS. So the signature is correct. As Marcos said we are looking into it and we will post here the solution, once we have one available.

[itman 1,659]

There also might be a bug in Win 10 in regards to the loading of the ELAM driver.

 

In Vista days, there was an issue on x64 OS's when a driver is loaded in user mode as noted below. Could be this has resurfaced in Win 10 in regards to the ELAM driver loading? 

 

Based on my research, first please understand that signature verification is enforced on tcpip.sys by code integrity. These spurious entries in the event log stem from the assumption that tcpip.sys is loaded only into the kernel. When tcpip.sys is verified in the kernel load path, the signature is successfully verified using a file hash as tcpip.sys is loaded and verified in entirety. However, when tcpip.sys is loaded in user mode, it is loaded in a page-by-page basis. As page hashes are not present in tcpip.sys signature, CI (Code integrity) logs an error even though the file is "correctly" signed.

 

The mandatory kernel enforcement on x64 still enforces signature validation on tcpip.sys. On x86, if the signature is invalid in the kernel path, depending on how the file was tampered either tcpip.sys will not load, or certain tcpip.sys functionality is disabled. It appears that the issue is confined to misleading text in the event log.

 

Unfortunately there are no easy workaround to disable these log entries from being created. Actually this has been reported as a bug and will be resolved in the next OS version. The reason tcpip.sys is getting loaded in user mode is so that someone can check the version information on the driver binary. In spite of the eventlog messages, we know the version information is valid because if some malicious agent had modified it, tcpip.sys would fail its kernel-mode integrity check at boot time. So, there is no danger that ignoring the user-mode messages in the event log would make anyone vulnerable to a driver modification attack.

[Marcos 5,070]

This error seems to be by design of ELAM and how protected services work. It has no effect of functionality whatsoever. We'll try to find a workaround that should completely or substantially reduce these errors.

[itman 1,659]

Problem might not be the eelam.sys ELAM driver but with ekrn.exe:

 

Anti-malware service signing requirements

 

The user-mode service that needs to be launched as protected must be signed with valid certificates. The service EXE must be page hash signed, and any non-Windows DLLs that get loaded into the service must be also signed with the same certificates. The hash of these certificates must be added into the resource file, which will be linked into the ELAM driver.

 

Note  SHA256 file/page hashes must be used, though certificates may continue to be SHA1.

 

Ref.: https://msdn.microsoft.com/en-us/library/windows/desktop/dn313124(v=vs.85).aspx

Edited November 4, 2016 by itman

[Marcos 5,070]

The user-mode service that needs to be launched as protected must be signed with valid certificates. The service EXE must be page hash signed, and any non-Windows DLLs that get loaded into the service must be also signed with the same certificates. The hash of these certificates must be added into the resource file, which will be linked into the ELAM driver.

 

It is. As I wrote, we have figured out what is causing the issue and will prepare a workaround for this.