It's Back - Ecmds Code Integrity Error

[itman 1,659]

Win 10 x(64) 1903, EIS 12.2.30 pre-release updating enabled

There are a few strange things associated with this activity.

It started on 10/8. This is some time after I had upgraded to ver. 12.2.30.

It appears that for some reason ecmds is running once a day but at random boot intervals. In others words, it doesn't occur every boot time.

-EDIT- ecmds.exe is countersigned with a Symantec Time cert. that Windows might no longer accept.

 

Edited October 11, 2019 by itman

[Peter Randziak 1,130]

Hello @itman,

I asked our code signing guru what can be the issue, but he is currently out of office so the response might take time...

Regards, Peter

[itman 1,659]

1 hour ago, Peter Randziak said:

Hello @itman,

I asked our code signing guru what can be the issue, but he is currently out of office so the response might take time...

Regards, Peter

Appears not be an issue anymore after I found some nasty hidden pagefile malware and cleared it out of there. The Event log entry hasn't appeared since then.

The question is what the malware was trying to do with ecmds.exe?

[Peter Randziak 1,130]

Well that is a very good question.

Do you happen to have a sample of it or anything, that might help us to identify it? 

Peter

[itman 1,659]

7 minutes ago, Peter Randziak said:

Do you happen to have a sample of it or anything, that might help us to identify it? 

Being in the pagefile, its almost impossible to access.

Over the years have become fairly good at spotting pagefile malware. In this case it was fairly obvious since it increased my pagefile storage allocation 50% and kept it there. I just set the registry option to clear the pagefile at system shutdown time and the bugger was gone as evidenced by pagefile returning to normal allocation size.

[Peter Randziak 1,130]

Well that is quite strange...

Thank you for keeping us posted and I'm glad that the issue is resolved.

Peter

[itman 1,659]

3 hours ago, Peter Randziak said:

Well that is quite strange...

Here's the story. It's also the reason why I haven't complained about Eset non-detection. Call this a classic example of "shooting yourself in the foot" by someone who should have known better.

Recently I received my first every Win 10 blue screen during normal operation. Researching that it turned out one of the three HDD's in my tower case died. Luckily it wasn't the Win 10 boot drive but it was my largest, newest, and fastest SATA drive. Being extremely peeved over this, I rummaged around in my stack of old HDD's and found an old Western Digital SATA 3 GB drive that would be a suitable replacement. Couldn't remember when I last used the drive but its be years.

Still livid, swapped out failed drive for the WD drive. Upon boot into Win 10, took a look on what was on the drive. Norton Ghost backup files. This means either it was used last on XP or the early days of Win 7. Promptly did a quick reformat of the drive, All was well after that or so I thought ...........

My best guess at this point is there was some very nasty malware on the drive that activated upon install of that drive. Besides entrenching itself in the page file, it somehow found my router and reconfigured it to pass through mode to a gateway using DNS servers in Poland no less. This also explains why my IPv6 connections became borked at the same time.

Now for the "shooting in the foot part." I  should have used my SATA to USB converter to perform a full reformat of the drive via USB connection prior to installing it in the tower. This way at least Eset would have had a chance to scan the drive fully. Whether if Eset would have found MBR or rootkit malware is debatable, but it should be removed via a full reformat. Or better yet, using a solid disk wiper utility running from bootable DVD media.

[Enrico 3]

I have the same log entries, but no malware was found, ESET events log show a "Registration to windows center was not succesful" created at the same time (boot), suggestions?

Best regards.

[itman 1,659]

In my case, the ecmds.exe activity started on 10/8 and stopped on 10/10 after I discovered the malware and removed it. The activity was completely random in nature occurring once a day at random intervals with multiple attempts each interval. The activity did not occur at boot time and was not related to any Windows Security Center initialization activities.

For reference on Win 10, a code integrity violation occurs when an executable is compiled with Win 10 code integrity guard protection. This ensures that only code signed with a Microsoft code signing certificate can be injected. In my case, I believe the malware was most likely attempting to inject its malicious .dll into ecmds.exe. This would allow the malware to bypass any Eset detection since ecmds.exe is a trusted process to it. -EDIT- The preceding only applies to Windows system executables compiled with CGI protection. A code integrity violation for an app such as ecmds.exe would occur when the hash value of the .exe does not match that stored in the Eset code signing certificate associated with ecmds.exe.

One possibility is in my case, the initial malware set a backdoor on my Win 10 installation. Whatever the malware was, it had to be quite old. Suspect all the backdoor did was periodically ping the attacker's C&C server to let it know the backdoor was alive and well. Also believe backdoor statuses are sold on the Dark web and automation is employed to periodically check their statuses. The one on my device suddenly "came alive" and was sold to the highest bidder. 

This does raise the question of if ecmds.exe is monitored by Eset's self-protection mechanism? It appears it is not. Of note is CGI bypasses have been demonstrated in the past.

Edited October 18, 2019 by itman

[itman 1,659]

One other important part about ecmds.exe.

It only runs at system startup time via a registry run key. Its sole purpose is to start the desktop toolbar icon Eset GUI and Windows Security Center processes. If it runs at any other time, it is most likely malware related. It would be an ideal malware target since it can run hidden.

Edited October 17, 2019 by itman

[Peter Randziak 1,130]

Hello @Enrico  / @itman, if you are able to reproduce it.

can you please provide us with:

1. Processmonitor log (saved in native .PML format) with Advanced output enabled from the boot-time, from a boot where the error is being logged

2. output from ESET Log Collector utility? 

 

Please compress those two to an archive, upload them to a safe location and send me the download details via private message with a reference to this thread

Regards, Peter

[itman 1,659]

1 hour ago, Peter Randziak said:

if you are able to reproduce it.

Like I posted, it hasn't occurred again. Also, it was random in nature in my case. So Process Monitor use is not applicable; the log would be enormous. 

In my case, I strongly suspect something like a process hollow attempt was made against ecmds.exe to modify it. Upon process startup, Eset's code signing certificate hash for ecmds.exe didn't match its modified size.

[Enrico 3]

Here they come.

Win 10 Audit Failure events started after 12.2.30 was installed, they're still happening with the latest version. Note: during boot and shutdown the access point is kept offline.

Also the "stealing focus" problem was back with 12.2.30 (had no time to check if persist in 13.0, eventually I will open a new topic).

sec_log.zip Bootlog-2.zip Bootlog-1.zip Bootlog.zip eis_logs.zip

Edited October 22, 2019 by Enrico

[am_dew 3]

To add to this thread, I noticed today in my Windows Event Viewer that I am getting code integrity errors.  I am on x64 Windows 10 v1903 and ESET Internet Security 13.0.22.0.  I have scanned my entire PC for malware with nothing detected.  This started on Oct. 3.  ESET seems to be running fine.

EDIT:  I just checked another PC of mine, same specs as above, and it also is showing this in the WIndows Event Viewer.

Any suggestions/comments?

Edited November 8, 2019 by am_dew
Additional info

[itman 1,659]

2 hours ago, am_dew said:

I just checked another PC of mine, same specs as above, and it also is showing this in the WIndows Event Viewer

Verify that the code integrity log entries are for ecmds.exe and not eamsi.dll.

[am_dew 3]

21 minutes ago, itman said:

Verify that the code integrity log entries are for ecmds.exe and not eamsi.dll.

All of the log entries seem to be from eamsi.dll

[itman 1,659]

1 hour ago, am_dew said:

All of the log entries seem to be from eamsi.dll

Eset's .dll for Win 10 AMSI is not properly code signed although Eset states otherwise. This is why those errors are occurring. As best as I can determine, eamsi.dll is being injected eventually into some but not all of the processes where the code integrity error occurs.

[am_dew 3]

2 hours ago, itman said:

Eset's .dll for Win 10 AMSI is not properly code signed although Eset states otherwise. This is why those errors are occurring. As best as I can determine, eamsi.dll is being injected eventually into some but not all of the processes where the code integrity error occurs.

So for all practical purposes, this error can be ignored and is not noticeably affecting performance?

[itman 1,659]

19 minutes ago, am_dew said:

So for all practical purposes, this error can be ignored and is not noticeably affecting performance?

Correct. However, there are issues with this current situation but the forum is not the place to discuss them.