Eset incompatible with CIG Mitigations + CMD.exe

[Tzatz 0]

I was ahead of Eset for months, no problems like this, and recent updates to ESET,  eset caught up with me, except their protection causes errors when loading CMD; if CIG is enabled on cmd.exe.  This can be very annoying to the point I was forced to compromize my security and allow eset to inject dlls into cmd to look out for, I presume, known viruses. While my setting blocked all viruses,  that perhaps were not already injected into microsoft signed processes.

This can be annoying, leaving the computer over night, background processes & scheduled tasks that initiate CMD.exe require clicking off the error message you see above, in the morning, they can pile up. And you cannot open an command prompt without this error appearing.

Any way to regain lost security here and avoid these errors? An option in ESET advanced settings to prevent injecting into cmd.exe would be nice.

 

Edited July 2, 2021 by Tzatz

[Marcos 5,074]

This is by design and expected:

Enabling CIG for cmd exe will prevent ESET from injecting into cmd.exe process to monitor executions which triggers the notification.

You should disable CIG for cmd.exe as well as processes that ESET monitors.
As for cmd.exe, we started to monitor it in April 2021 when the HIPS module 1412. 2 was released.

While we will stop attempting to inject into processes with CIG enabled, this may be quite dangerous since it would enable even malicious scripts to run undetected if you enable CIG for processes that should be monitored by ESET.

[itman 1,659]

4 hours ago, Marcos said:

As for cmd.exe, we started to monitor it in April 2021 when the HIPS module 1412. 2 was released.

What's the criteria for monitoring?

If I open cmd.exe, I see no Eset .dll injection when using Process Explorer. Does Eset only monitor cmd.exe if spawned from another process other than explorer.exe?

-EDIT- Appears Eset .dll injection is triggering off of .bat use by cmd.exe?

Now the question is if it would do so when running a .bat script via PowerShell: https://www.jamsscheduler.com/blog/how-to-execute-a-bat-file-within-a-powershell-job/ ?

Edited July 2, 2021 by itman

[Marcos 5,074]

2 hours ago, itman said:

What's the criteria for monitoring?

To my best knowledge it's the application class.

No problems with injection after running cmd.exe:

[itman 1,659]

2 hours ago, Marcos said:

No problems with injection after running cmd.exe:

It doesn't inject DBI .dll on my EIS 14.2.19 installation on Win 10 21H1 x(64).

I created a .cmd script containing only pause command in it.

I ran it via Start -> Run -> cmd.exe C:\Users\xxxxx\Downloads\pause.cmd.

Opened cmd.exe running under explorer.exe using Process Explorer and no Eset .dll injected.

Ditto for executing pause.bat by double mouse clicking on it.

Of note is a conhost.exe instance always opens as a child process under cmd.exe.

-EDIT- I also added some code in the script prior to the pause command and still no .dll injection by Eset.

Edited July 2, 2021 by itman

[itman 1,659]

I might be "barking up the wrong tree" here.

Eset scans command scripts at execution via its AMSI scanner. I assume at that point if and only if it detects something suspicious, Eset will inject the DBI monitoring .dll into cmd.exe. Otherwise, the .dll will not be injected.

Is this correct?

[Tzatz 0]

Yeah, automatically detecting, then not injecting if CIG is enabled sounds useful. I am unsure which security trade off is the lesser of two evils. ESET It injects cmd.exe directly with ebehmoni.dll, whether its loaded from start menu, command prompt, or the system itself.

Here is a video I made

https://vimeo.com/570732977

 

Edited July 3, 2021 by Tzatz

[Tzatz 0]

I have only seen this window arise in windows loading CMD.exe, it might be best to only stop injecting into CMD if detected, at least the user will still have events that allow the user to know he has some options.

Edited July 3, 2021 by Tzatz

[itman 1,659]

1 hour ago, Tzatz said:

I have only seen this window arise in windows loading CMD.exe,

It must have something to do with the .bat scripts you are running. As posted, I experimented with a few .bat scripts I have and never saw the DBI monitoring .dll injected into cmd.exe,

[Tzatz 0]

On 7/3/2021 at 3:58 PM, itman said:

It must have something to do with the .bat scripts you are running. As posted, I experimented with a few .bat scripts I have and never saw the DBI monitoring .dll injected into cmd.exe

I never saw DBI monitoring .dll either, what is being blocked is, ebehmoni.dll, as shown in the video above. You will see, with CIG protections enabled, this happens to CMD no matter where it is loaded.

[itman 1,659]

15 hours ago, Tzatz said:

I never saw DBI monitoring .dll either, what is being blocked is, ebehmoni.dll, as shown in the video above. You will see, with CIG protections enabled, this happens to CMD no matter where it is loaded.

It turns out, I had a corrupted Eset installation which in itself is scary as hell since there was no indication from EIS this was the case.

After a ver. 14.2.19 reinstall, I now see ebehmoni.dll injected into cmd.exe upon its startup.

Edited July 7, 2021 by itman

[boatvid 0]

I am unsure which security trade off is the lesser of two evils. 

[Marcos 5,074]

In the video Arbitrary Code Guard was disabled for cmd.exe. This is the worst combination since CIG prevents ESET from monitoring the process and at the same shellcode protection (ACG) by Windows is disabled.

We either recommend enabling ACG+CIG to get protected by Windows or disable both for ESET to fully protect cmd instances.

[itman 1,659]

4 hours ago, Marcos said:

In the video Arbitrary Code Guard was disabled for cmd.exe.

I will also add that ACG is a system wide Win 10 exploit protection and Microsoft did this for a reason; to stop dynamic code execution from any process.

[Tzatz 0]

WOW. WOW WOW! Thank you for the tips! I wish this were more public information. I will keep this noted. One little mess up and your whole security may be crippled.

I just came across this also, so if there is a means to bypass CIG enforcement, such as CIGslip this is where antivirus systems could be very useful

 

Quote

The biggest implication, according to Morphisec, is attackers could use CIGslip to inject browser malware or adware. However, there is also potential for vendors to manipulate this method. CIG makes it harder for third-party security vendors to protect Edge because they need a DLL signed by Microsoft for each protective process. Some might inject protective code outside Microsoft's signing process.

https://beta.darkreading.com/vulnerabilities-threats/cigslip-lets-attackers-bypass-microsoft-code-integrity-guard?web_view=true

[Tzatz 0]

IWOW. WOW WOW! Thank you for the tips! I wish this were more public information. I will keep this noted. One little mess up and your whole security may be crippled.

I just came across this also, so if there is a means to bypass CIG enforcement, such as CIGslip this is where antivirus systems could be very useful

 

Quote

The biggest implication, according to Morphisec, is attackers could use CIGslip to inject browser malware or adware. However, there is also potential for vendors to manipulate this method. CIG makes it harder for third-party security vendors to protect Edge because they need a DLL signed by Microsoft for each protective process. Some might inject protective code outside Microsoft's signing process.

https://beta.darkreading.com/vulnerabilities-threats/cigslip-lets-attackers-bypass-microsoft-code-integrity-guard?web_view=true

I have noticed previously that forcing ACG on programs caused issues; such as Firefox not loading, so perhaps it is enforced by default conditionally or system files only.

Edited July 17, 2021 by Tzatz

[Tzatz 0]

On 7/14/2021 at 3:08 AM, Marcos said:

We either recommend enabling ACG+CIG to get protected by Windows or disable both for ESET to fully protect cmd instances.

Is this combination recommended only for software for commandline capable software, (like powershell, WMIC, etc) do you have a different recommendation for different software, or is this a universal recommendation?

Edited July 17, 2021 by Tzatz

[itman 1,659]

6 hours ago, Tzatz said:

Is this combination recommended only for software for commandline capable software, (like powershell,

You shouldn't be fooling around with Win 10 exploit protection settings period. No one recommends "tweaking" process settings there anymore. Win 10 will allocate and set exploit protection settings as needed.

As far as setting CIG protection on script based processes like PowerShell, its already enabled by default. Also, it appears Eset is deploying the equivalent to this "CIGslip" processing you quoted since it can indeed inject its amsi.dll into select script processes. However, this is not undetected by the OS and the Win Security Mitigations Event log records entries for this activity.

Edited July 17, 2021 by itman

[Tzatz 0]

On 7/17/2021 at 6:22 AM, itman said:

You shouldn't be fooling around with Win 10 exploit protection settings period. No one recommends "tweaking" process settings there anymore. Win 10 will allocate and set exploit protection settings as needed.

As far as setting CIG protection on script based processes like PowerShell, its already enabled by default. Also, it appears Eset is deploying the equivalent to this "CIGslip" processing you quoted since it can indeed inject its amsi.dll into select script processes. However, this is not undetected by the OS and the Win Security Mitigations Event log records entries for this activity.

So Microsoft automatically detects if any code loading is compatible with certain mitigations?

While I do not know about the rest, there are some things I would recommend however, like not allowing child processes or remote images on wmic, and WmiPrvSE.exe

[itman 1,659]

6 hours ago, Tzatz said:

So Microsoft automatically detects if any code loading is compatible with certain mitigations?

Yes and no.

Win 10 monitors known vulnerable processes such as spoolsv.exe for dynamic code injection. You might have seen Win Security Mitigation Event log entries to this effect.

As far as .dll side loading and direct injection attacks, Win 10 pretty much relies on process CIG protection. That is only Micsosoft code signed .dlls can be used by a process. "The rub" is the process must be compiled with the CIG protection specified.