Jump to content

Eset incompatible with CIG Mitigations + CMD.exe


Recommended Posts

Posted (edited)

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.

 

Eset.thumb.png.e9be2929a7f3359009dd0edd6750db32.png

Edited by Tzatz
Link to comment
Share on other sites

  • Tzatz changed the title to Eset incompatible with CIG Mitigations + CMD.exe
  • Administrators

This is by design and expected:

image.png

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.

Link to comment
Share on other sites

Posted (edited)
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 by itman
Link to comment
Share on other sites

  • Administrators
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:

image.png

Link to comment
Share on other sites

Posted (edited)
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 by itman
Link to comment
Share on other sites

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?

Link to comment
Share on other sites

Posted (edited)

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 by Tzatz
Link to comment
Share on other sites

Posted (edited)

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 by Tzatz
Link to comment
Share on other sites

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,

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Posted (edited)
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 by itman
Link to comment
Share on other sites

  • Administrators

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

Posted (edited)

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 by Tzatz
Link to comment
Share on other sites

Posted (edited)
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 by Tzatz
Link to comment
Share on other sites

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 by itman
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...