itman

Well, I tried to download IEInspector. The download is zipped. You can't extract it since the only .exe in archive, HttpAnalyzerStd_V7.6.4.exe, is password protected. I assume this is the installer.

Appears Avast was detecting it last month. Microsoft site is in Chinese. Below is a link to the English translation: Suspicious file botupdate.exe in Windows\SysWOW64\Microsoft\Protect https://translate.google.com/translate?hl=en&sl=zh-TW&u=https://answers.microsoft.com/zh-hant/windows/forum/windows_10-security/windowssyswow64microsoftprotect%E4%B8%AD%E6%9C%89/cb9d2357-3689-447c-9877-d0d933935f59&prev=search Also appears Microsoft wasn't interested in it in the least. To bad for folks infected by this. Also as far as I am aware of IEInspector is legit software: https://www.ieinspector.com/httpanalyzer/index.html Also it does not integrate with Chrome so that aspect is still a mystery. Suspect this bugger is a hacked ver. of IEInspector since the legit version is paid software. BTW - IEInspector does have a silent install option: https://www.ieinspector.com/httpanalyzer/manual/index.html

Also of note is this use of this SID "S-1-96-82." Here's a reference to well know system SID's: https://docs.microsoft.com/en-us/windows/desktop/secauthz/well-known-sids When I refer to legit SID based directories listed under C:\Windows\System32\Microsoft\Protect\, they all begin with S-1-5. Also, the only thing that exits in those directories are registry key references. -EDIT- Kaspersky recent published an article in regards to a RID vulnerability that exists on all Win versions here: https://threatpost.com/trivial-post-intrusion-attack-exploits-windows-rid/138448/ with specific attack details here: http://csl.com.co/rid-hijacking/ . This attack would allow for system changes to be made such as what is currently being evidenced in this thread.

To begin with, Eset's firewall evaluates rule from top to bottom order. Unless the user rules you added were placed at the top of the existing rule set, it can be assumed that existing Eset default firewall rules are overriding your custom rules. Appears you are trying to use RPC for your remote connection activity? Eset already has default rules for that. However, the default rules only allow inbound RPC activity for IP addresses listed in the "Trusted" zone. You should review the existing Eset default rules in regards to "Trusted" zone activity. If those meet your security policy criteria, the simple solution is to add the local network IP address shown in your screen shot to the "Trusted" zone.

It does make one wonder if this was a result of either a rogue install or update of iTunes, QuickTime, etc.? Do any of the affected parties have Apple app software installed on their PCs?

Appears Fujitsu does indeed have a hard drive diagnostic utility. You can read about it here: https://www.lifewire.com/fujitsu-diagnostic-tool-review-2624559 Download is here: https://www.majorgeeks.com/mg/getmirror/fujitsu_diagnostic_(ide),1.html . The MajorGeeks download writeup does state this utility is for Toshiba branded Fujitsu drives. Hopefully the documentation is included in the download. Run the quick test first. If no errors shown, then run the extended test.* * Careful with the extended test and verify it does not perform any file destructive activities. If this utility doesn't work on your drive, I am done with suggestions in this area and you're on your own. Also regardless of drive condition, this is a slow drive as noted here: https://hdd.userbenchmark.com/SpeedTest/2698/TOSHIBA-MK2555GSX. Slow drives equate to below par overall system performance.

Great analysis! I suspected that using MBAM which killed the scheduled task really didn't remove the malware. This only prevented its outbound connection processing to a site that Eset had blacklisted. I also suspect whatever installed this malware/coin miner also used icacls to change the C:\Windows\SysWOW64\Microsoft\Protect\[SYSTEMSID] registry key permissions. This would have required at least admin privileges to do so. I will say this in this regard. I know of at least one popular free third party security software that uses icacls via its installer to change registry permissions. And it gets worse in that when the software is uninstalled, those registry permissions are not returned to their default values. There is still however one major issue. This directory, C:\Windows\SysWOW64\Microsoft, does not exist on my Win 10 x(64) 1803 build. Others will have to verify the same is true on Win 7/8 x(64). So the simple and desired solution may be to delete the C:\Windows\SysWOW64\Microsoft directory after using icacls or manually to change its permissions to allow this to be done. Also and very important to create the C:\Windows\SysWOW64\Microsoft directory, it appears that C:\Windows\SysWOW64 directory permissions may have been modified. Have you in anyway modified the contents of the C:\Windows\SysWOW64\Microsoft directory other than changing permissions? If not, I would create a zipped version of the directory and post it for @Marcos to forward to Eset malware researchers.

If you want to block access to domain names, the best way to do that is to use the existing URL block list in the Web Access section of Internet Protection. Wildcard capability exists there to allow you flexibility in specifying a broad range of generalized domain coverage. Note that Eset's Web Access protection now monitors all process Internet communication whereas in past versions only browser communication was monitored.

All that is shown in your screen shot is that Eset cannot scan those file because they are locked by the Windows OS. See this thread for further reference: https://forum.eset.com/topic/17195-unable-to-open-files-on-a-lot-of-files-when-scanning/

The below elaborates on why FQDN should not be used in firewall rules: To use a FQDN your security system either needs to perform a reverse DNS lookup whenever traffic containing a new and unknown ip-address arrives to determine if that particular ip-address resolves to a white-listed FQDN. The problem with that, in addition to the fact that it can be slow, is that the owner of an ip-address can set any hostname name they want on a reverse DNS record, including one from domains that they don't own such as your white-listed domain... So that is both slow, unreliable and insecure. Alternatively systems could translate the FQDN to an ip-address in the background and effectively apply your policies to the ip-addresses the FQDN's resolve to, which will prevent the slow, unreliable and insecure reverse lookups, but that results in a different set of problems: the ip-address associated with a FQDN can be changed at any time by the owner of the domain, and how and when will the new IP-address replace the old one in your policies? a FQDN can even resolve to multiple ip-addresses... depending on your own ip-address, a FQDN may resolve to different (ranges of) IP-addresses so a policy based on the FQDN can't possibly match all actual ip-addresses... https://serverfault.com/questions/874525/how-to-permit-deny-traffic-based-on-domain-name-fqdn-rather-than-ip-address-in

Actually Eset's IDS protection is a hybrid IDS/IPS in that besides blocking the activity, it gives you the option to be informed about the activity:

This is something that is not advisable: https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClHJCA0 In any case, it is not a feature that would be applicable to consumer based firewall solutions.

You can take a screen shot of the alert by pressing the keyboard Shift + Print Scrn keys. You can then open something like MS Paint and paste the screen shot into it. Additionally, you can crop the image to only show the alert. Then either print out the alert image or save it to the location of your choice.

I live in the U.S.. Just checked Eset download servers for Internet Security and the latest ver. is 11.2.63.

As originally posted below, the OP specifically stated the Eset detections where from NOD32; Further justification given below: Therefore @Shoaib Maqsood, you need to post ELC logs from the device with NOD32 installed where the above log detections originated.