itman

Did more testing with the TLD https://crackingpatching.com/ The problem is with DoH enabled in Firefox. With DoH disabled, Eset will alert and block access every time. When any of the DoH settings are enabled, Eset might block it once after setting change but not thereafter. Doesn't matter what DoH option is selected or DoH provider selected. I am keeping DoH disabled until this is resolved. Glad you found this problem.

Found the problem, I believe. Eset Filtered Web Site log shows it blocked access; Time;URL;Status;Detection;Application;User;IP address;Hash 3/9/2024 11:43:27 AM;https://crackingpatching.com;Blocked;Internal blacklist;C:\Program Files\Mozilla Firefox\firefox.exe;xxxxx;104.21.43.46;F736FE1F2C3ACB8E53F9E22EFE632D18B65DECCB Time;URL;Status;Detection;Application;User;IP address;Hash 3/9/2024 11:43:28 AM;https://accounts.google.com/o/oauth2/postmessageRelay?parent=https://crackingpatching.com&jsh=m;/_/scs/abc-static/_/js/k=gapi.lb.en.8uXxGUoumbY.O/d=1/rs=AHpOoo96qx3mL4tzGUOa-0q0udyPRqEAoA/m=__features__;Blocked;Internal blacklist;C:\Program Files\Mozilla Firefox\firefox.exe;xxxxx;2607:f8b0:4023:140d::54;F736FE1F2C3ACB8E53F9E22EFE632D18B65DECCB But web site access is not blocked. Notice the redirect to Google. Looks like someone has figured out how to bypass Eset Web Filtering on Firefox.

I have Firefox DNS over HTTPS set to Default level w/CloudFlare as DNS provider. I am also using CloudFlare as my Win 10 DNS provider. When I try to access the malicious URL in question, I can access the web site and even download the malicious crack. Same here. I am wondering if this is a FireFox problem since Eset blocks the URL on Chrome? -EDIT- I set Firefox DNS over HTTPS to Increased Protection using CloudFlare as DNS provider, Eset alert now displayed on attempted web page access. However, w/ DNS over HTTPS set to Maximum protection, no web site blocking occurs. Also when setting back to Increased Protection, no Eset alert. Clearing all browser cache settings, restarting Firefox, setting to Default protection, Eset now alerts. Repeat test at Default protection, Eset still alerts. I would say this is indeed a Firefox bug.

https://help.eset.com/glossary/en-US/canary_file.html Assumed here is these are "bait" files which are commonly used in anti-ransomware apps to detect ransomware encryption activities.

He's referring to Node.js based malware; example here: https://any.run/cybersecurity-blog/lu0bot-analysis/ .

I will also add that Eset doesn't perform SSL/TLS scanning on every HTTPS web site. Select trusted sites known to Eset are excluded.

You can no longer rename or modify any network connection Eset creates other than change its profile type. You can however create a new network connection which Eset now calls a Profile.

True. But this extension will not show when searching Chrome Store Extensions under "Eset" criteria. You can try it in Brave and see if it installs. If it does install, my guess is it won't work.

Not possible. Brave uses extensions from the Chrome Store. The only Eset extension available there is for Eset Password Manager.

As far as Eset previous detections of this malware, refer to this thread: https://forum.eset.com/topic/36848-jsspybankerkn/ .

The malware is still detected on the web site;

It does not support Brave; https://help.eset.com/essp/17/en-US/banking_and_payment_protection.html?idh_config_bps.html

Yes. However, you are using Brave browser. Brave is not a Secured Browser protection supported browser. This leaves you vulnerable to browser memory based code injection attacks, keyloggers, etc.

There's an older thread in the forum on a similar PowerShell malware. In this case, a rogue sub-directory was created in C:\Windows\System32: https://forum.eset.com/topic/32653-annoying-powershellagentaew-on-each-start-need-assitence/#elControls_152733_menu . In any case, diagnosis will be a bit involved.

Did you enable the HIPS setting shown in the below screen shot? On the other hand, I don't know why Eset HIPS would be blocking that many transactions to create a log of this size.

First, what is msrdc.exe; https://spyshelter.com/exe/microsoft-corporation-msrdc-exe Appears MS Office apps are trying to modify RDP to establish a remote connection to something? Doesn't appear to be legit activity to me.

Looks good. No Eset alert.

Disable Network Inspector via Eset GUI when using the PC at work. Re-enable Network Inspector when using the PC at home.

Website still infected. Get Eset alert upon attempted site access. Here's Sucuri's report on the site: https://sitecheck.sucuri.net/results/epainfo.pl

No, it's a separate company: https://www.safetica.com/company-profile . It does collaborate with Eset on security issues via Eset Technical Alliance. You can create a support request to Safetica here: https://support.safetica.com/en/knowledge-base/kb-tickets/new .

Instructions for use of Eset's decryptor for TeslaCrypt here: https://support.eset.com/en/kb6051-how-do-i-clean-a-teslacrypt-infection-using-the-eset-teslacrypt-decrypter . It supposedly works on ver. 3.0 and 4.0 of TeslaCrypt. If this is the decryptor you used and it didn't work, my guess is you got nailed by TeslaCrypt variant that is not decryptable.

Outlook is included as part of MS Office Pro or via MS Office 365 subscription. It can be purchased from MS Store here: https://www.microsoft.com/en-us/microsoft-365/p/outlook/cfq7ttc0hlkq?activetab=pivot:overviewtab Also as this article notes: https://support.eset.com/en/kb2138-email-clients-compatible-with-windows-eset-products , Eset currently only supports Outlook via e-mail scanning plug-in option.

My system is 13 years old also using two HDDs. I have been using Win 10 since 2016 with Eset installed and have never seen this AMSI error.

This has been discussed previously in the forum. Both Adguard installed ver. and Eset use the Windows Filtering Platform. To use both Adguard installed and Eset concurrently, you must disable AdGuard's use of Windows Filtering Platform as shown here: https://adguard.com/kb/adguard-for-windows/solving-problems/wfp-driver/ .

This was discussed in another forum thread which I currently can't find. MBAM is now a full fledged AV solution and as such now registers itself in Windows Security Center as Eset does. Windows 10/11 only allows one third party AV to register itself as the active real-time AV solution. This is where the conflict is and the source of the Eset AMSI error. Why this just recently started with devices having both MBAM - real-time mode and Eset installed only Microsoft knows. The only solution is to disable MBAM real-time mode and run it as an on-demand second opinion AV.