itman

Yesterday I was doing some system testing that caused hundreds of Eset desktop notifications. In my haste to stop those, I inadvertently and mistakenly turned off desktop notifications. No problem. Went into Eset GUI and re-enabled it. Now here is where it gets very strange. Afterwards all my Eset HIPS ask rules were suddenly auto allowing the activity. Additionally, I was no longer receiving any Eset confirmation for GUI setting changes. A system reboot returned everything back to normal. However, this behavior was a bit disturbing.

https://www.eset.com/us/home/multi-device-security/

It would also mean that OP was the first Eset user to have the file exist on his device. The odds of that for ntoskrnl.exe is many zillions to one.

There have been issues with FF 73 posted at wilderssecurity.com for example, noting that users who have employed OS patches from the 0patch product are have major problems with FF 73.

Since your in the U.S. and assuming you purchased from the Eset web site, the price for Internet Security for a 2 device license is $59.99. On the other hand, a single device license for Smart Security also costs $59.99. Note: you should have received a confirmation e-mail from Eset with your license key. In that e-mail should state the number of devices for the license.

I am running Win 10 x(64) 1909 and I just upgraded to FF 73 a few hours ago. No problem here. Might be a Win 7 issue.

If this is indeed the case and the "1" on the right side of the icon indicates number of users, then the OP has an issue. The "System" process; i.e. ntoskrnl.exe should definitely not be shown as such. I do hope @Purpleroses did not unblock that process.

I would be careful using this tool. Appears results are a bit ambiguous and can be misinterpreted: For example: Developer's response:

According to the following, it appears the .msi installer name specified is wrong: https://help.eset.com/era/53/en-US/idh_ra_remoteinst_commandline.html It appears that XXX in eea_nt64_XXX.msi installation package name specifies the three character language code abbreviation.

I assume its related to process reputation status. Make sure the process referenced is ntoskrnl.exe. However, I am not sure Eset references "System" as such.

See the below screen. Note that I have the alert disabled.

Hum ......... Also ever seen that before either. Click on "Details" and see that sheds some light on what it might be.

Another thing worth a try, until the fix is pushed, is to disable the license expiration alert.

Actually, Eset also has one which I would trust as more reliable: https://help.eset.com/eset_tools/ESETEternalBlueChecker.exe Ref.: https://www.eset.com/us/about/newsroom/press-releases/eset-releases-eternalblue-vulnerability-checker-to-help-combat-wannacry-ransomware/

Make that PC and anything else on your network has been patched against the SMBv1 protocol vulnerability: https://docs.microsoft.com/en-us/security-updates/securitybulletins/2017/ms17-010 Ref.: https://blog.malwarebytes.com/101/2018/12/how-threat-actors-are-using-smb-vulnerabilities/

For those wondering how the attackers could get around driver signature enforcement protection that has existed since Win 7: https://news.sophos.com/en-us/2020/02/06/living-off-another-land-ransomware-borrows-vulnerable-driver-to-remove-security-software/ Note that this can also be classified as a Win kernel patch protection bypass.

This file must only exist in the Endpoint vers.. As such, I can't view what permissions are assigned to it. Did you try to temporarily assign yourself with full admin privileges to the file?

As far as the above noted Robbinhood ransomware portion of the attack; https://www.bleepingcomputer.com/news/security/a-closer-look-at-the-robbinhood-ransomware/ Oh, my ..................... 😭

Appears latest ver. of VUBRUTE can be downloaded here: https://hackforums.net/showthread.php?tid=5821898 . Of course, you will have to join the forum first ............. 😰

To begin with: The Win firewall will be auto enabled. So there will always be some firewall active.

Another solution to this issue that would eliminate the Eset detection entirely is to use a good ad blocker such as uBlock Origin in Chrome:

This is a nasty one. Gigabyte never patched the vulnerability in the gdrv.sys driver stating it wasn't vulnerable. That is not surprising for those familiar w/Gigabyte. This malware will exploit that vulnerability and then load the exploited driver on the targeted device. They then use the exploited loaded driver to load their malicious driver to kill off AV processes. Note that Win 10 ELAM driver feature that Eset and many AV vendors use to load their anti-malware drivers, only loads this driver prior to any other app based drivers. Kernel mode device drivers load prior to any app based drivers which would allow malicious ones to intercept any activities from any app drivers.

Another kernel mode driver issue. Ransomware Exploits GIGABYTE Driver to Kill AV Processes https://www.bleepingcomputer.com/news/security/ransomware-exploits-gigabyte-driver-to-kill-av-processes/ -EDIT- Attention Eset. No detection for the following at VT: https://news.sophos.com/en-us/2020/02/06/living-off-another-land-ransomware-borrows-vulnerable-driver-to-remove-security-software/

Related brute force hack tools: https://sidechannel.tempestsi.com/hydrapos-operation-of-brazilian-fraudsters-has-accumulated-at-least-1-4-million-card-data-b05d88ad3be0

It's been around for a while: https://www.hack2world.com/2015/12/vubrute-for-windows-tested.html https://rstforums.com/forum/topic/101338-vubrute-10/