itman

Here's a good reference on Win system process activity: https://securitybytes.io/blue-team-fundamentals-part-two-windows-processes-759fe15965e2 Wininit.exe creates services.exe and in turn creates lsass.exe and lsm.exe running as child processes to it.

Ok. This clarifies that "Self-Defense" applies to more than just Eset's own processes: https://support.eset.com/kb3755/?locale=en_US&viewlocale=en_US So at this point, you will need to determine what in your Win Server OS installation is attempting to modify lsass.exe and like critical OS processes Eset is recording Self-defense HIPS log activity for.

Out of curiousity, I enabled HIPS Log all blocked event activity option. I then rebooted. All "Self-Defense" blocked entries relate to Eset processes. It is possible Eset would use the "Self-Defense" notation for other than its own processes in EFS, but I still believe that is unlikely. -EDIT- Here's an interesting log entry. What I would like to know is what is "unknown operation" detection? Time;Application;Operation;Target;Action;Rule;Additional information 5/28/2019 11:22:09 AM;C:\Windows\System32\SecurityHealthService.exe;Unknown operation;C:\Program Files\ESET\ESET Security\SecurityProductInformation.ini;blocked;Self-Defense: Protect ESET files;

As far as I am aware of, svchost.exe should not be modifying lsass.exe. I have my own like Eset HIPS rules for lsass.exe and those have never been triggered by attempted svchost.exe modification attempt. However, I am running Win 10 on an endpoint. Things might be different for Win Server OSes predating 2016 ver..

Appears you are not running latest vers. of Win 10 since lsass.exe runs a PPL process on those. Assuming your not running Win Server 2016 or later that also runs lsass.exe as a PPL process, the Eset detections might be related to unsigned add-ons: https://docs.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection

Use the existing Win Firewall outbound rules as a guide as shown in the below screen shot. Whereas these are allow rules, I assume in your case you want to make them Eset block rules. One thing you do not want to fool around with is blocking Win 10 system packaged apps. In my opinion, it is easier and safer to just uninstall a Win 10 app you don't want. Then modify Win 10 Store settings to prevent downloading of new ones.

Look closely at the HIPS log entries. I beleive the wording given is along the lines of "partially blocked" or "partially allowed." This wording is applicable to default internal HIPS rules. When you enable the "Log all blocked activity" option is when these entries show in the HIPS log. When HIPS user rules are created, Eset's HIPS won't treat them as "absolute." That is, Eset won't allow the user to block system activity that it has predetermined to be legit and necessary activity.

Again without you posting specifics on malware being detected, no one can really help on this issue. Yes as far as I am aware of. But you would have to download and install Eset in trial mode on each device.

OK. I am getting up their in age and as such you have slow days. So let's take this "from the top" again. You stated that you are receiving malware detections from the security software loaded on the Hiren's boot CD even with your hard drive not connected. The detections are coming from the System32 directory. This can only mean that the Win PE version loaded from the Hiren's boot CD is getting infected. So let's go through the possible scenarios on how this could happen. 1. I believe the Hiren's boot CD is delivered as an .iso file and all you do is create bootable media using the .iso file. The first possible source of malware could have been on the device you created the bootable media from. For example, the software you used to create the bootable media could have contained malware and it infected one of the files needed for booting from the CD. Also the above would be applicable for the original Eset SysRescue media you created. 2. The Hiren's .iso file file you downloaded contains malware. I don't know where you downloaded it from. 3. I believe the WIN PE version used does establish a network connection. So it is possible, something was downloaded from the Internet while Win PE was running and in turn dropped malware into its System 32 directory. This would be more likely if there was malware preloaded into the .iso file that established a connection to a malicious C&C server. Or your router is compromised to the point it is allowing unsolicited inbound connections, etc. etc.. In any case at this point. all we known is that Win PE version you are running is getting infected with malware originating from the Hiren's boot CD. If you have reason to beleive that the PC you noted is getting infected, you would have to post details on what malware is being detected on that. At this point and based on the limited data provided, I would suspect your router is compromised in some way. Although you did state that your notebook is OK and I assume it is also connecting through the same router. Finally, remember this is a web site forum for Eset users and I believe you haven't purchased an Eset license yet. As such, any malware assistance will be very limited in nature.

These relate to Eset's own processes. And it is normal to see like entries in the HIPS log when you enabled the "Log all blocked processes" option. This is the reason that HIPS log option is disabled by default.

Based on what is shown here: https://www.hirensbootcd.org/download/ , what is loaded on the Hirens Boot CD are old versions of MalwareBytes and Eset's on-line scanner. The current ver. of Eset's on-line scanner is 3.0.17.0. For MalwareBytes, the current ver. is 3.7.1.2839. As such, I would be skeptical of any detections by either.

Still no fix. Believe its time Eset find a new backend provider.

What AV do you have loaded on the Hiren's boot CD? It could very well be giving you a false positive detection. It also appears that it is incapable of removing whatever it is detecting; most likely since it is in the System32 directory. Do this. Note the name of the file the AV is detecting in the System32 directory. Boot into Windows. Then submit that file to VirusTotal here: https://www.virustotal.com/#/home/upload for a scan by the various AV engines it uses. If none or only one or two of the engines flag the file as malware, assume the Hiren's boot CD AV detection is a false positive.

Now that it has been established that access denied popup should also be appearing in Win 7, it appears that the OP's Win 7 service permissions are corrupted. Refer to the below screen shot. Ekrn.exe service permission is Read only. If OP's service permissions on Win 7 are corrupted, this is a major security issue for him since other Win 7 services might be affected which obviously don't employ self-protection mechanisms such as Eset has.

As I just posted, upgrade to Win 10 and you will receive the access denied message. Win 7 does not support/provide protected process protection.

Do this. Terminate ekrn.exe in Task Manager. Close Task Manager. Reopen Task Manager and see if ekrn.exe is now running which I suspect it is. What I suspect is the issue is Win 7 Task Manager. It appears to terminate ekrn.exe where in fact it does not. In other words, the attempted ekrn.exe termination silently fails. In Win 10, ekrn.exe runs as a protected process - antimalware; i.e. PPL. This is what causes the access denied popup to appear and prevents Task Manager from attempting to terminate ekrn.exe.

Eset firewall automatic mode does not imply that user firewall rules cannot be created. Just create a rule to block the specific app.. That said, note that Win 10 app names change each time they are updated. This means that your existing rule is not longer applicable and a new Eset firewall rule needs to be created. Note that Win 10 auto updates its own firewall rules to accommodate like activity. Such is not the case with the Eset firewall. Finally note that Eset's Network Protection Application Control only works when the firewall is set to Interactive mode. As such, you will not receive any alerts about existing firewall monitored app update activity.

Appears to have started recently. It was OK earlier this morning.

Perform an Eset "Repair" installation via Control Panel -> Programs -> Programs & Features -> Uninstall a program. Select your currently installed Eset installation. You will be asked whether you want to "Uninstall" or "Repair." Select "Repair." An Eset repair install has fixed most of my past problems with Eset.

I am trying to figure about how you could install Kaspersky Endpoint on a Win Server OS? If that was indeed possible, it can be assumed: 1. The Kaspersky installation is "borking" Win Server OS components. 2. Kaspersky in all likelihood never uninstalled cleanly.

For reference, SANS has an article on a malware sample using the NSIS installer here: https://isc.sans.edu/forums/diary/Quick+analysis+of+malware+created+with+NSIS/23703/ . I believe this particular coinminer malware was deployed via a self-executing SFX archive using something along this line: https://gist.github.com/xymopen/951ef3d5301af55efd82eb67af129066 . Make sure Eset's PUA protection is always enabled and don't ignore the warnings generated from it. It is far easier to prevent malware/nuisance-ware from being installed than trying to remove it later.

Do you have Eset Smart Security installed? This is the only version that offers the password manager feature.

I am not sure what Eset published is 100% correct. Dell has a good article on OS downgrading rights here: https://www.dell.com/support/article/us/en/04/sln294589/an-understanding-of-both-your-microsoft-windows-downgrade-rights-and-downgrading-from-windows-8-8-1-and-10?lang=en . The "gotcha" is only non-Home versions were offered downgrading rights which would have extended their end-of-support date to the like date from the product they downgraded from. This means that the Vista business versions, if they were downgraded from a like Win 7 version, are still supported until the Win 7 end-of-life date in Jan., 2020. This would imply that the patch was also offered to these Vista versions.

TrendMicro has an article on how to permanently remove this coinminer here: https://www.trendmicro.com/vinfo/us/threat-encyclopedia/malware/worm_coinminer.inj . It does require some manual cleaning activities. Click on the "Solution" section. Substitute the "scan with TrendMicro" with a full in-depth scan using Eset Smart Security. If the above is too technically advanced for you, contract your regional Eset support concern for assistance: https://www.eset.com/int/

Eset now has a security blog article on this vulnerability: https://www.welivesecurity.com/2019/05/22/patch-now-bluekeep-vulnerability/ . Of note is Microsoft issued no patch to Vista for this.