itman 1,740 Posted June 25, 2021 Share Posted June 25, 2021 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> Link to comment Share on other sites More sharing options...
itman 1,740 Posted June 25, 2021 Author Share Posted June 25, 2021 (edited) 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 Link to comment Share on other sites More sharing options...
Most Valued Members shocked 60 Posted June 25, 2021 Most Valued Members Share Posted June 25, 2021 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 Link to comment Share on other sites More sharing options...
itman 1,740 Posted June 25, 2021 Author Share Posted June 25, 2021 (edited) 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 Link to comment Share on other sites More sharing options...
itman 1,740 Posted June 25, 2021 Author Share Posted June 25, 2021 Looks like Eset is trying to monitor Web Storage Server COM object. Good luck on that one. Link to comment Share on other sites More sharing options...
itman 1,740 Posted June 26, 2021 Author Share Posted June 26, 2021 (edited) 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 Link to comment Share on other sites More sharing options...
itman 1,740 Posted June 26, 2021 Author Share Posted June 26, 2021 (edited) 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 Link to comment Share on other sites More sharing options...
itman 1,740 Posted June 27, 2021 Author Share Posted June 27, 2021 (edited) 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 Link to comment Share on other sites More sharing options...
itman 1,740 Posted June 27, 2021 Author Share Posted June 27, 2021 (edited) 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 Link to comment Share on other sites More sharing options...
itman 1,740 Posted June 28, 2021 Author Share Posted June 28, 2021 (edited) 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 Link to comment Share on other sites More sharing options...
Solution itman 1,740 Posted June 29, 2021 Author Solution Share Posted June 29, 2021 (edited) 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 Link to comment Share on other sites More sharing options...
itman 1,740 Posted July 1, 2021 Author Share Posted July 1, 2021 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. Link to comment Share on other sites More sharing options...
ESET Insiders SlashRose 25 Posted July 2, 2021 ESET Insiders Share Posted July 2, 2021 Why doesn't anyone at Eset say anything about it? Link to comment Share on other sites More sharing options...
Recommended Posts