itman

Only URL I could access w/o issue using latest ver. of Firefox was for openrouter.ai. The other two URLs resulted in;

If the following code exists in the latest ver. of the .ps1 script, "my gut is telling me" this is what is triggering LiveGuard;

Here's a 10 year old version: https://github.com/chocolatey-archive/chocolatey/blob/master/src/helpers/functions/Get-ChocolateyWebFile.ps1 that LiveGuard immediately triggers on and submits to Eset VirusLab for analysis; Time;Hash;File;Size;Category;Reason;Sent to;User 4/18/2024 1:12:42 PM;1932BE42169348A8B3727EB15F620E501C03F832;https://github.com/chocolatey-archive/chocolatey/latest-commit/master/src/helpers/functions/Get-ChocolateyWebFile.ps1;948;Script;Automatic;ESET LiveGuard; xxxxxxx Interestingly, appears this script has never been submitted to VirusTotal.

I finally got HTTP/3 scanning to work w/o taking down my IPv6 Internet connection by pretty much rebuilding my local network - a long and arduous undertaking with some very ugly findings. Discussion on this for another day. @Marcos, I have searched at length on the web for some way to test if Eset HTTP/3 scanning is working properly w/o success. Since the Eset forum uses HTTP/3 is it possible you could create a HTTP/3 web document with let's say, the eicar string embedded within. Then post a link on the forum to access it?

Using one of the LOLbins Project example for certutil.exe, I ran it as standard user from command prompt. It ran w/o issue; Of note is the downloaded file had no MotW status associated with it. This means it would not be Microsoft Defender cloud scanned. Also, no SmartScreen detection. Only thing displayed was an UAC alert to elevate to admin since the .exe is an installer with the alert noting untrusted publisher staus;

In regards to deploying certutil.exe to bypass EDR security solutions, this article: https://bishopfox.com/blog/edr-bypass-with-lolbins is worth a read. In a nutshell, just deploy another Win LOL binary.

Which means if the file was 0-day malware, you're nailed.

Since Microsoft Defender on Win 10/11 can detect this activity, Eset consumer and Endpoint vers. via HIPS scanning should also detect it.

The certutil.exe abuse shown in the uTube video is detailed here: https://bdure.medium.com/lets-defend-suspicious-certutil-exe-usage-eventid-113-93e379611663 . Also, the attack is well known for sometime; https://www.varonis.com/blog/the-malware-hiding-in-your-windows-system32-folder-part-iii-certutil-and-alternate-data-streams Eset could create an internal HIPS rule to scan for such command line usage of certutil.exe.

You can download the required Win 10 20H2 update from the Windows Catalog: https://www.catalog.update.microsoft.com/Search.aspx?q=kb5005611 . Prior to downloading and installing the update, thoroughly read this article: https://support.microsoft.com/en-us/topic/september-30-2021-kb5005611-os-builds-19041-1266-19042-1266-and-19043-1266-preview-a37f5409-f320-4175-9a66-c2682fc11c07 and verify all prerequisites are met.

I don't know how the miner got installed on one of your network devices. Eset does detect the installer download: https://xmrig.com/docs/miner ; Of note is the Eset detection is a PUA. This means one must respond to deny its download.

If you tested on Eset ver. 17.1.9.0, disable HTTP/3 scanning. AdGuard uses QUIC: https://adguard-dns.io/en/blog/dns-over-quic-official-standard.html .

I did more research into HTTP/3 processing by other security solutions with the following results. Almost all require that HTTP/3 be disabled in the browser. I could only find one security solution that actually is scanning HTTP/3 and it is Avast. The result of that scanning parallels Eset results to date with multiple comments in the Avast forum about all the app processing being borked when HTTP/3 scanning is enabled. Kaspersky, somewhat to be expected, appears to be the only security solution handling HTTP/3 network traffic properly. It internally blocks HTTP/3 which results in retransmission as HTTP/2 traffic. As such, no modification to internal browser HTTP/3 default setting is required. In my case and I believe the other poster having IPv6 connectivity being disabled w/Eset HTTP3 scanning enabled, I am fairly convinced it is due to the 6rd processing being performed by the ISP. Everything points to the UDP traffic being converted to tunneled TCP traffic in transit. Then reconverted to UDP upon access by the browser. I am not surprised about this since getting Eset to function properly with the 6rd tunneling my ISP performs has been a nightmare for the 10 years I have used Eset. Presently, I have disabled HTTP/3 processing in my browser and also Eset HTTP/3 scanning. It will probably remain this way for some time since I have zero confidence Eset will ever be able to resolve the 6rd tunneling conflict.

Here's an article on RPC port 135 attacks: https://cqr.company/web-vulnerabilities/unsecured-remote-procedure-calls-rpc/ .

Disable HTTP/3 protocol scanning and monitor if outbound firewall alerts disappear.