Eset .dll issue

[itman 1,801]

The following Win 10 Security-Mitigations Event log entry started on 6/22 and have persisted since then. Doesn't look right to me. I'm running EIS ver. 14.2.10.

Quote

Log Name:      Microsoft-Windows-Security-Mitigations/KernelMode
Source:        Microsoft-Windows-Security-Mitigations
Date:          6/22/2021 4:08:44 PM
Event ID:      12
Task Category: (6)
Level:         Warning
Keywords:      
User:          D
Computer:      D
Description:
Process '\Device\HarddiskVolume1\Windows\System32\dllhost.exe' (PID 4880) was blocked from loading the non-Microsoft-signed binary '\Program Files\ESET\ESET Security\ebehmoni.dll'.
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-Security-Mitigations" Guid="{fae10392-f0af-4ac0-b8ff-9f4d920c3cdf}" />
    <EventID>12</EventID>
    <Version>0</Version>
    <Level>3</Level>
    <Task>6</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8000000000000000</Keywords>
    <TimeCreated SystemTime="2021-06-22T20:08:44.6002925Z" />
    <EventRecordID>610</EventRecordID>
    <Correlation />
    <Execution ProcessID="4880" ThreadID="5884" />
    <Channel>Microsoft-Windows-Security-Mitigations/KernelMode</Channel>
    <Computer>D</Computer>
    <Security UserID="S-1-5-21-3446137964-4078936351-876189786-1001" />
  </System>
  <EventData>
    <Data Name="ProcessPathLength">52</Data>
    <Data Name="ProcessPath">\Device\HarddiskVolume1\Windows\System32\dllhost.exe</Data>
    <Data Name="ProcessCommandLineLength">81</Data>
    <Data Name="ProcessCommandLine">C:\WINDOWS\system32\DllHost.exe /Processid:{7966B4D8-4FDC-4126-A10B-39A3209AD251}</Data>
    <Data Name="ProcessId">4880</Data>
    <Data Name="ProcessCreateTime">2021-06-22T20:08:44.4783905Z</Data>
    <Data Name="ProcessStartKey">124130464729400539</Data>
    <Data Name="ProcessSignatureLevel">8</Data>
    <Data Name="ProcessSectionSignatureLevel">8</Data>
    <Data Name="ProcessProtection">0</Data>
    <Data Name="TargetThreadId">5884</Data>
    <Data Name="TargetThreadCreateTime">2021-06-22T20:08:44.4783937Z</Data>
    <Data Name="RequiredSignatureLevel">8</Data>
    <Data Name="SignatureLevel">4</Data>
    <Data Name="ImageNameLength">46</Data>
    <Data Name="ImageName">\Program Files\ESET\ESET Security\ebehmoni.dll</Data>
  </EventData>
</Event>

 

[itman 1,801]

Note that ebehmoni.dll is not Microsoft code signed. As such, it will be blocked from loading into a CIG process such as dllhost.exe. BTW - Eset updated ebehmoni.dll on 6/22.

The question is why is Eset injecting a .dll into WebPlatStorageBrokerServer?

Edited June 25, 2021 by itman

[shocked 60]

i have the same events listed but they start from 27/5. back then i had EIS, from 15/6 i upgraded to ESSP.

 

 

ebehmoni_dll_events.rar

[itman 1,801]

No related event log entries prior to 6/22 on my device. 

Also, these blocks occur in a series of two with the first blocked event being:

Quote

Log Name:      Microsoft-Windows-Security-Mitigations/KernelMode
Source:        Microsoft-Windows-Security-Mitigations
Date:          6/24/2021 6:45:47 PM
Event ID:      2
Task Category: (1)
Level:         Warning
Keywords:      
User:          D
Computer:      D
Description:
Process '\Device\HarddiskVolume1\Windows\System32\dllhost.exe' (PID 2540) was blocked from generating dynamic code.
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-Security-Mitigations" Guid="{fae10392-f0af-4ac0-b8ff-9f4d920c3cdf}" />
    <EventID>2</EventID>
    <Version>0</Version>
    <Level>3</Level>
    <Task>1</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8000000000000000</Keywords>
    <TimeCreated SystemTime="2021-06-24T22:45:47.3771473Z" />
    <EventRecordID>644</EventRecordID>
    <Correlation />
    <Execution ProcessID="2540" ThreadID="5836" />
    <Channel>Microsoft-Windows-Security-Mitigations/KernelMode</Channel>
    <Computer>D</Computer>
    <Security UserID="S-1-5-21-3446137964-4078936351-876189786-1001" />
  </System>
  <EventData>
    <Data Name="ProcessPathLength">52</Data>
    <Data Name="ProcessPath">\Device\HarddiskVolume1\Windows\System32\dllhost.exe</Data>
    <Data Name="ProcessCommandLineLength">81</Data>
    <Data Name="ProcessCommandLine">C:\WINDOWS\system32\DllHost.exe /Processid:{973D20D7-562D-44B9-B70B-5A0F49CCDF3F}</Data>
    <Data Name="CallingProcessId">2540</Data>
    <Data Name="CallingProcessCreateTime">2021-06-24T22:45:47.3208942Z</Data>
    <Data Name="CallingProcessStartKey">125537839612952735</Data>
    <Data Name="CallingProcessSignatureLevel">8</Data>
    <Data Name="CallingProcessSectionSignatureLevel">8</Data>
    <Data Name="CallingProcessProtection">0</Data>
    <Data Name="CallingThreadId">5836</Data>
    <Data Name="CallingThreadCreateTime">2021-06-24T22:45:47.3208972Z</Data>
  </EventData>
</Event>

 

Edited June 25, 2021 by itman

[itman 1,801]

Looks like Eset is trying to monitor Web Storage Server COM object. Good luck on that one.

[itman 1,801]

Well, in spite of the Event log entries, the Eset DBI .dll injection appears to be working:

The question is if it is always working? I checked for this dllhost.exe instance yesterday and it wasn't running.

Edited June 26, 2021 by itman

[itman 1,801]

Know what's is going on.

This COM process can be used by malware: C:\WINDOWS\system32\DllHost.exe /Processid:{973D20D7-562D-44B9-B70B-5A0F49CCDF3F} . When Eset sees it starting up, it injects its DBI .dll to monitor it.

It is a bit co-incidental that this Eset .dll injection started when the DBI .dll was updated. I suspect that's due to a change in Eset's DBI processing; perhaps to specifically monitor suspicious COM processes?

BTW - I saw web postings dating back to Win 1809 where folks were complaining that anything that uses the Start menu search was triggering this COM process to start running. Then it was due to a borked Win update.

Edited June 26, 2021 by itman

[itman 1,801]

The "mystery deepens." I temporarily disabled DCOM and no longer see these dllhost.exe  processes starting at system startup time. However, they will start about 10 mins. later.

@Marcos need an Eset clarification on DBI triggering here.

Is it because Win 10 is first blocking dynamic code execution and this is what is triggering the DBI .dll injection? Or is it the DBI .dll injection attempt that is triggering the dynamic code execution detection by Win 10? The later is of no concern. The former would be indicative of malware activity.

Edited June 27, 2021 by itman

[itman 1,801]

One other important detail on this activity I forgot to mention. These dllhost.exe process startup instances always occur in pairs.

The first attempted startup relates to Win registry parameters stored in keys referenced by 7966B4D8-4FDC-4126-A10B-39A3209AD251. This instance is never running. It either immediately terminates or abends upon startup. Only the dllhost.exe instance that relates to Win registry parameters stored in keys referenced by 973D20D7-562D-44B9-B70B-5A0F49CCDF3F successfully runs.

Of note:

Quote

T1122 Component Object Model (COM) Hijacking

Note: This involves replacing legitimate components with malicious ones, and as such the legitimate components will likely no longer function. If you have a detection based on DLLHost.exe with /Processid:{xyz}, you can match xyz with the CLSID (COM Class Object) or AppID mentioned below to check for any malicious EXE or DLL.

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\WOW6432Node\CLSID\{abc} /v AppID /t REG_SZ /d {xyz}
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{abc} /v AppID /t REG_SZ /d {xyz}
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AppID\{xyz}
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\WOW6432Node\AppID\{xyz}
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Classes\AppID\{xyz}

Example analysis:

reg query "HKLM\SOFTWARE\Classes\WOW6432Node\CLSID" /s /f "{973D20D7-562D-44B9-B70B-5A0F49CCDF3F}"
reg query "HKLM\SOFTWARE\Classes\WOW6432Node\CLSID\{178167bc-4ee3-403e-8430-a6434162db17}" /s
reg query "HKLM\SOFTWARE\Classes\AppID\{973D20D7-562D-44B9-B70B-5A0F49CCDF3F}"

Queries:

reg query HKLM\SOFTWARE\Classes\CLSID\ /s /f ".dll"
reg query HKLM\SOFTWARE\Classes\CLSID\ /s /f ".exe"
reg query HKLM\SOFTWARE\Classes\AppID\ /s /f DllSurrogate
gci -path REGISTRY::HKLM\SOFTWARE\Classes\*\shell\open\command 
reg query HKU\{SID}\SOFTWARE\Classes\CLSID\ /s /f ".dll"
reg query HKU\{SID}\SOFTWARE\Classes\CLSID\ /s /f ".exe"
gci 'REGISTRY::HKU\*\Software\Classes\CLSID\*\TreatAs'
gci 'REGISTRY::HKU\*\Software\Classes\Scripting.Dictionary'
gci "REGISTRY::HKU\*\SOFTWARE\Classes\CLSID\*\LocalServer32" -ea 0
gci "REGISTRY::HKU\*\SOFTWARE\Classes\CLSID\*\InprocServer32" -ea 0
gci "REGISTRY::HKU\*\SOFTWARE\Classes\CLSID\*\InprocHandler*" -ea 0
gci "REGISTRY::HKU\*\SOFTWARE\Classes\CLSID\*\*Server32" -ea 0
gci "REGISTRY::HKU\*\SOFTWARE\Classes\CLSID\*\ScriptletURL" -ea 0
reg query HKU\{SID}\SOFTWARE\Classes\CLSID\ /s /f "ScriptletURL"

 

https://tajdini.net/blog/forensics-and-security/digital-forensics-and-incident-response/

Edited June 27, 2021 by itman

[itman 1,801]

It gets "wilder" by the day folks.

After re-enabling DCOM and rebooting, the two dllhost.exe instances mentioned are no longer running or attempting to run. As such, no further Eset DBI .dll injection attempts being observed. Really looks like some COM hijacking activities were going on here.

Also of note is I now see spoolsv.exe running which was not happening when this dllhost.exe activity was happening. And, Win 10 dynamic code execution; i.e. DEP, detection being triggered, when spoolsv.exe starts up which I have observed on numerous previous occasions. Makes me believe that spoolsv.exe is related to this instance. Also and significant is no Eset DBI triggering when the WIN DEP activity detection occurs against spoolsv.exe.

-EDIT- Spoke to soon. Dllhost.exe activity returned.

Edited June 28, 2021 by itman

[itman 1,801]

I am fairly confident I have found the source of this dllhost.exe activity.

To begin, this dllhost.exe acitvity doesn't always manifest at system logon time. For example, a system sign-off and subsequent entry into standby mode messes with its startup at next system logon time. In this instance, shortly after logon time, a suspended backgroundTaskHost.exe will appear with startup of the dllhost.exe instance shortly thereafter. It the appearance of a suspended process on startup occurring wasn't suspicious enough, when I try to access backgroundTaskHost.exe process details via Process Explorer the task terminates. So I can see how Eset sees his activity suspicious enough to trigger constant DBI monitoring.

Anyway, the backgroundTaskHost.exe use pointed me to search for recent Win store app updates. Sure enough, I received a MS Home and Office 2019 update on 6/22 at 3:22PM EST. The dllhost.exe activity started almost immediately after this update. Who knows? Maybe we have a Microsoft supply chain compromise here ..........

-EDIT- When I opened Office Word and forced an update check from there, DllHost.exe /Processid:{973D20D7-562D-44B9-B70B-5A0F49CCDF3F} started up. So it appears safe to ignore this activity.

BTW - The suspended backgroundTaskHost.exe startup is associated with NcsiUwpApp Win system app. So, safe to ignore it.

The only remaining troubling behavior while monitoring this activity was SmartScreen twice terminating for no known reason. Whereas it did restart itself, does draw into question its protection effectiveness.

Edited June 29, 2021 by itman

[itman 1,801]

An update on this Eset .dll DBI injection.

I cleared my Win page file via registry option at shutdown late in the day on 6/28. Upon system startup on 6/29 and thereafter. no .dll DBI injection is occurring in the dllhost.exe process in question. Either Eset updated a DBI triggering rule which is doubtful, or whatever Eset DBI was triggering on was in the page file.  

[SlashRose 25]

Why doesn't anyone at Eset say anything about it?