itman

Yes, a update server was hacked. And since multiple vendors were compromised, it is hoped the ongoing investigation will uncover how it was done. In the CCleaner incident, the breach occurred during the transition period after the Piriform to Avast merger. At least this was a plausible explanation as to how such a security breach could have occurred. This incident appears different and more serious.

I forgot to post the following extract from the Kaspersky blog article. It is not only Asus affected by this issue:

Per Kaspersky and noted below, just because you have a vulnerable device doesn't mean your infected. It appears this has been a targeted attack. Also Kaspersky has a utility to check if your device is one affected by this vulnerability: https://www.kaspersky.com/blog/shadow-hammer-teaser/26149/

Yeah, that's the thread. To begin with, LiveGrid uploads detections and suspicious processes via the FNDx.NFI mechanism. Once these have been analyzed, LiveGrid then instructs the origin local Eset installation to delete those files. For the majority of the time, this works without issue. It appears to me Eset has an "attack mode" sensor which is triggered when it encounters a multitude of malware attacks within a short duration. This triggers LiveGrid to be put in a constant connect mode to the Eset servers. Hence, the observable upload transmission loop. All this is fine except that the upload loop never ceases based on my prior observation. In other words, it will continue even after the next day's cold boot. It appears there is a lost status condition occurring between the local Eset installation and Eset servers. Finally, the Customer Experience option is somehow a factor in the above. Note that it was enabled by default in the 12.1.31 upgrade. When I disable that, the transmission looping activity never reappears.

Since there are two separate threads on going about this issue, one might try on a temporary basis what @Peter Randziak suggested in this posting: https://forum.eset.com/topic/19007-main-you-are-protected-screen-keeps-popping-up-every-few-minutes/?do=findComment&comment=92860 . If something gets "borked" in the Eset GUI, just rename the .dll back to its original name. Note: this has to be done in Safe mode since that Eset directory is protected by Eset from modification. After the change was made, reboot the PC and monitor for the abnormal Eset GUI startup behavior. Also if this stops the behavior, please post back since no one to date has done so in the other thread.

One possibility here is the OP is stuck in the dreaded "LiveGrid never ending submission loop." I posted a long thread about this a couple of years ago. Can't find it for reference; probably archived. Shortly after I installed ver. 12.1.31, I did some penetration testing against it. I hit it with a dozen or so test malware in rapid succession. This was enough to start the never ending multiple port opening submissions to LiveGrid servers in rapid succession. It appears like behavior is what triggers the problem. Let this go on for a while to see if it would stop on its own. It didn't. So I employed the resolution that worked previously; boot into safe mode and delete every FNDx.NFI file present in C:\ProgramData\ESET\ESET Security\Charon directory. Note: I am not recommending this; only stating what worked for me. Was going to create a forum posting about it, but decided it wasn't worth the effort since the issue was never resolved two years ago. -EDIT- Forgot this. I also disabled the Customer Experience option which as I recollect, was also a factor in the behavior two years ago.

Also and rephrased, I am referring to detection of Python engine components within an executable. A recent such malware example is XBash: https://unit42.paloaltonetworks.com/unit42-xbash-combines-botnet-ransomware-coinmining-worm-targets-linux-windows/ . At the time of its initial discovery, only 1/57 at Virus Total detected it.

If you're concerned about this, you can control what Eset collects as shown in the below screen shot:

If you're referring to eOppFrame.exe constantly running, that is expected behavior ever since B&PP has existed in Eset. Once it loads, it will remain running till system shutdown time. Personally, I was never concerned about it since it only uses 16K of memory.

-EDIT- Having a bad day today. Also I misstated previously, You can create a .exe using PyBuilder. PyInstaller and a few others are alternative methods to do so. PyBuilder only allows you to create a self-executing Python .py script. To create an executable, you need to use PyInstaller to create an .exe encapsulating the script: http://www.primalsecurity.net/0xc-python-tutorial-python-malware/

Advisable since there are ransomware strains that do employ "sleeper" Python scripts. Hence my recommendation that an .exe with the Python engine code imbedded be flagged as a PUA. This is not normal activity as should be flagged as suspicious. Perhaps included in the new Deep Behavior Inspection detection.

Can Eset actually detect a Python script pre-execution if its packed and encrypted? Note that Win 10 AMSI does not scan Python scripts. -EDIT- also Python scripts "are famous" for running "sleeper" code designed to "wait out" heuristic scanning methods.

Although this article notes error code, 0x847695d0, I suspect it still applies in this case: https://support.eset.com/kb6408/?locale=en_US&viewlocale=en_US

Does Eset detect an executable created via PyBuilder in which the Python engine along with a script is bundled as a PUA? If not, it should.

It appears to me Eset is detecting something on the captcha web page and blocking it. My experience with such an occurrence is there might be other malware attempting to be served up from such a web page. So proceeding to enter data, etc. on that web page is done at your own peril. What you can try is suspending uBlock for that web page and observing what Eset detects on the web page.

Err …….. what? Why didn't you simply ask him for the taxi service phone number, you make the connection yourself, and handed the phone to him? Or better yet, you personally made the call to the taxi service. Lucky he just didn't run off with your phone. Although you changed your password, you also need to change your logon id since he also knows that. If that isn't possible, at least make sure your password is very long in length and securely created; numeric, alpha, upper and lower case, plus a few special characters.

What program are you referring to? Is it Eset Internet Security and you wish to uninstall it?

Open Eset Gui. Select Tools -> More Tools. Select Log Files. In the window shown, click on the down arrow and select Computer scan. Scroll down to the log entry line than relates to the scan you ran. Double click on the line item and the entire log will be displayed. Scroll down to the bottom log and it will show all malware detections and what their remediation status is. In most cases, Eset will automatically remove the malware. In some cases that cannot be done unless a system restart is performed, or if the malware resides in a critical system file. In any case, post a screen of what is shown in this regard.

When one startups the Eset Gui via desktop, ekrn.exe appears to dynamically create a equi.exe child process to do so. It appears eguiProxy.exe sole function to terminate equi.exe after a short time interval. I have observed that egui.exe does not immediately terminate after the Eset Gui is closed on the desktop. Appears something in the above is out of sync in a few isolated install instances. My money at this point is something is amiss with perhaps the Windows installation. Note that normally the parent process terminates the child process which is not the case here.

I will also add that corp. level network apps that have application control still don't have the capability the OP wants: https://campus.barracuda.com/product/nextgenfirewallx/doc/41093369/how-to-introduce-application-control-to-your-network/ As shown above, the capability really isn't more encompassing that what Eset already offers. Bottom line - the capability doesn't exist at the firewall level and never will.

Thanks. Good find. Have you considered using idle-time scanning as a solution to your daily scanning issues?

There are third party apps that have this capability. The installed version of Adguard: https://adguard.com/en/welcome.html for example will not only monitor the browser for like activity, but any other app you wish.

Until Eset figures out why this happens, one might try what this poster did in another thread: https://forum.eset.com/topic/19007-main-you-are-protected-screen-keeps-popping-up-every-few-minutes/?do=findComment&comment=92783 . It makes no sense to me and I assume others, why opening Win Task Manager would stop the popping up of the Eset GUI home page. But if it stops the behavior, at least for the duration of the current logon session, it would be worthwhile.

Not possible. Assumed is if one wants to block a domain/URL, they want to block all attempted accesses to it.

The URL block list has wildcard capability. For example, coding, *.domain.com/*, will block all URLs associated with domain.com. As far as URL blocking via firewall rule, doubtful that will ever be implemented since most firewalls don't have such capability.