itman

You should be able to access files in the directory via Mac Safe mode: https://support.apple.com/guide/mac-help/start-up-your-mac-in-safe-mode-mh21245/mac .

Following up on @Peter Randziak above posting, VT analysis shows the .exe was signed using a stolen Micro-Star root certificate that had been subsequently revoked; Assumed is the Digicert cert. assigned to the .exe was an EV one. Appears Eset Reputation scanning, like Win SmartScreen, will auto trust an executable signed with an EV cert.. However, SmartScreen does validate the cert. chain path. SmartScreen will also block the process from executing in the instance of cert. chain validation failure. I have not seen Eset Reputation scanning having like capability. Finally with Eset HTTP/HTTPS scanning enabled, Eset fails the EV cert. validation test at badssl.com; The Eset Reputation issue aside, it does not explain why Eset could not detect this malware when 40+ vendors at VT did. It appears most of the detection's at VT were behavior based. One malicious behavior observed was an AMSI bypass deployed by this malware. It has been repeated stated in the forum that a process's signing status does not factor into Eset's scanning "at-first-sight" upon creation/startup/etc.. It would be "revealing" if this is not done for EV signed processes.

Just delete the 1 byte file in the quarantine directory.

It appears Eset has tightened its license validation processing and now performing locality checks on previously installed installations.

What occurred just prior to this activity? Was a Win OS or Office update running?

The ranking color is based on prior Eset "first sight" status of the .exe. For example after a Win OS cumulative update resulting in many OS files being changed, LiveGrid will show many of these files with a yellow color; i.e. low reputation. You will observe that as time elapses, the color of these files will change to green. Likewise, a red color would be indicative of an unknown process; i.e. never seen by Eset previously. I will also add that the above Reputation description is deceptive in that it means a cumulative ranking of the number of times the process has been scanned on devices with Eset installed. Again, LiveGrid does not perform any cloud malware scanning other than for blacklist status.

Using a password to access Eset GUI settings is an optional setting and is not enabled by default. Therefore it is assumed you manually set password use. Using a password to access Eset GUI settings makes the product cumbersome to use where a feature such as Interactive firewall requires frequent access to the GUI. It is your choice here as to whether password use should be disabled or not.

This comment applies to https://infinitymagazine.co.uk.

All that LiveGrid Reputation status display indicates is how many Eset installations the .exe has been installed on. Reputation status has nothing to do with whether the process has been white/blacklisted or the like. As such, I have always viewed LiveGrid Reputation display status as a useless feature.

As far as the AV-C Malware Protection test series goes, the only thing I pay attention to is the On-line versus Off-Line detection scores. It is not uncommon for malware to tamper with or disable a device's network connection. Hence, a high score in Off-line detection capability is a must.

In an AV lab test where all but three vendor products scored 99.9% or above, one needs to ask themselves if such a test reflects current real world malware detection capability.

Still a no-go. All three tests show ECH not enabled. If I disable Eset HTTPS scanning, all three tests show ECH enabled. -EDIT- According to Mozilla, ECH in Firefox 118+ is based on existing DoH; DNS over HTTPS, processing. So assume Eset HTTPS scanning is also busting that.

I will also add that I am no fan of anything Cloudfare based; especially their DNS servers. DNS security tests I have run show my ISP(AT&T) DNS servers are far superior to Cloudfare's. As such, I could care less about this Firefox feature.

Max Protection in Firefox doesn't appear to work. First, verified that Cloudflare DNS servers were being used; However, above ECH test sites all show it is not enabled. So @SeriousHoax is correct; Eset's SSL/TLS protocol scanning busts it.

That explains why ISP address was being displayed in Eset log entries. Also, he must be using a cable-based ISP since they usually only issue modems versus modem/router combo units issued by DSL/fiber providers.

Assuming that Eset Smart Security 10.1.245.0 is being referenced, Eset has terminated all support for it. That means also signature updating of it; https://support-eol.eset.com/en/policy_home/product_tables.html

The default cleaning mode for the Smart scan option is shown in the below screen shot. You can change it to whatever you wish;

Only applicable to ESSP since it is the only consumer version that has LiveGuard. Did you mean LiveGrid instead?

Eset recommends once a month in-depth scan at the minimum. A weekly default Smart scan otherwise should be sufficient; https://help.eset.com/ees/10.1/en-US/?idh_page_scan.html The above stated, Eset's real-time scanning will detect the vast majority of malware upon creation on the local device. Also of note is Eset performs default scheduled scans of known system areas where malware resides at system startup and after Eset update activities.

It appears the Eset scan cache was not cleared when the second on-demand scan was run. This resulted in results from the first scan influencing the detection's from the second scan. Running back to back full on-demand scans is not expected normal scan behavior. This option detects exactly as stated. These apps are not malware per se, but exhibit undesirable behavior such as scams to purchase unneeded services and the like. Due to the fact users might be using such apps as you are, the option is not enabled by default at installation time.

This posting about Facebook use in Vietnam is informative: https://www.washingtonpost.com/world/2023/06/19/facebook-meta-vietnam-government-censorship/ . It also might explain the different home web page. Also, assume Internet communication is being actively being monitored there. Since Eset appears to function properly in browsers with a Private mode, that is the mode that should be used for social media access.

I noticed something. The Facebook home page the OP is being directed to does not appear to be the same one I am directed to. I suspect some type of redirection is occurring here;

Looks like you're using Edge as your browser. ESSP blocked facebook.com in Edge both in normal and InPrivate mode on my Win 10 22H2 Pro installation.

It works on ESSP when I add *.facebook.com/* to Eset existing "List of existing blocked address" list;

Have them check if the ISP router has a firewall and its enabled. Most ISP provided routers these days have a NAT firewall. Also, they are stateful. This means they won't allow unsolicited inbound TCP traffic; i.e. inbound traffic not in response to a prior outbound request, . If all the above apply, I would stand by my previous statement that un-patched vulnerable OS or app software exits on the device and an external hacker is trying to exploit it. Also per Eset posted log entries, the target IP address is 140.186.96.15 which is associated with Midcontinent Communications in Fargo, ND. That is a public IP address and not a private IP address which should be associated with the device. As such, something is definitely not right here. -EDIT- Let's say Midcontinent Communications; i.e. Midco, is the user's ISP. He requested and received a static IP address from them; i.e.140.186.96.15. Note the security issue with static IP assignment; https://www.techtarget.com/whatis/definition/static-IP-address