itman
-
Posts
12,153 -
Joined
-
Last visited
-
Days Won
319
Posts posted by itman
-
-
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; xxxxxxxInterestingly, 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.
-
1 hour ago, Marcos said:
Yes, if the downloaded file was malicious I'd expect it to be detected.
Which means if the file was 0-day malware, you're nailed.
-
1 hour ago, Marcos said:
Administrators can see any download activities by certutil in ESET Inspect and can take actions automatically based on LiveGrid information about downloaded files for instance.
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;
QuoteIn 2017, Casey Smith, the same infosec researcher who told us about the risks in regsrv32, found a dual use for certutil. Smith noticed that certutil can be used to download a remote file.
This is not completely surprising since certutil has remote capabilities, but it’s clearly not checking the format of the file — effectively turning certutil into LoL-ware version of curl.
As it turns out, hackers were way ahead of the researchers. It was reported that Brazilians have been using certutil for some time.
So if hackers obtain shell access through, say, an SQL injection attack, they can use certutil to download, say, a remote PowerShell script to continue the attack — without triggering any virus or malware scanners searching for obvious hacking tools.
Eset could create an internal HIPS rule to scan for such command line usage of certutil.exe.
-
3 hours ago, Marcos said:
The update is probably no longer available
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.
-
1 hour ago, Lgaalvarez said:
We detected that the XMRig miner virus entered a PC and it was very complicated to remove it, in fact this virus was AUTO EXCLUDED from the antivirus and was installed as a service.
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 ;
QuoteTime;Scanner;Object type;Object;Detection;Action;User;Information;Hash;First seen here
4/12/2024 10:48:38 AM;HTTP filter;file;https://objects.githubusercontent.com/github-production-release-asset-2e65be/88327406/90f88b9c-a0e7-4636-8d46-3a5e9700bd95?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAVCODYLSA53PQK4ZA/20240412/us-east-1/s3/aws4_request&X-Amz-Date=20240412T144818Z&X-Amz-Expires=300&X-Amz-Signature=a7f5e0c9b814adcdc5f33fd6d4c745d8dc59ad54cc235646d9233cfaa3e7f5bf&X-Amz-SignedHeaders=host&actor_id=0&key_id=0&repo_id=88327406&response-content-disposition=attachment; filename=xmrig-6.21.2-msvc-win64.zip&response-content-type=application/octet-stream;Win64/CoinMiner.TM potentially unwanted application;connection terminated;xxxxxxxx;Event occurred during an attempt to access the web by the application: C:\Program Files\Mozilla Firefox\firefox.exe (27BB8D2FC02CD2BBC184D07357AAA9903D88B425).;91680B78B255CE4C174E41C6D905FDBC9F5006B6;Of note is the Eset detection is a PUA. This means one must respond to deny its download.
-
2 hours ago, SeriousHoax said:
I can confirm that using AdGuard for Windows (didn't test their VPN) nullifies ESET's ability to block malicious websites no matter what settings are changed in AdGuard. Once AdGuard is on, ESET is gone.
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.
-
-
FYI -here.
Since you are using NOD32, you are using the Win firewall. On Win 10/11, ping firewall rules are not enabled by default. Also, no default ping firewall rules exist for the Public profile. Check your Win firewall rules.
-
19 minutes ago, Alessandro Cacciari said:
However: from your router (if capable) can you ping your computer?
No problem;
-
I was able to ping my router's IPv4 address using ESSP ver.17.1.9 on the Public profile network connection w/o issue. I do have HTTP/3 network traffic scanning disabled.
-
10 minutes ago, danjacoyle said:
From the log files on one of the endpoints
Same detection I received;
QuoteTime;Scanner;Object type;Object;Detection;Action;User;Information;Hash;First seen here
4/2/2024 8:37:51 AM;Real-time file system protection;file;C:\Users\xxxxxx\AppData\Local\Temp\DODD22.tmp;a variant of MSIL/Microsoft.Bing.D potentially unwanted application;deleted;NT AUTHORITY\SYSTEM;Event occurred on a file modified by the application: C:\Windows\System32\svchost.exe (445F5F38365AF88EC29B357F4696F0E3EE50A1D8).;1E908ED6CF873C77790C7EE03CE1673BF2850B92; -
6 hours ago, Marcos said:
We kindly ask you to reproduce the issue while capturing the network communication with Wireshark and advanced network traffic scanning enabled
The problem is loss of IPv6 Internet connectivity doesn't happen immediately as described here: https://forum.eset.com/topic/40527-eis-17190-and-http3-scanning/?do=findComment&comment=182347 . Plus, you have to be constantly monitoring network traffic as to when this occurs.
-
Microsoft has started changing the default search engine in Chromium browsers to Bing. This also means Chrome. This is what Eset is detecting as PUA activity and rightfully so.
-
3 hours ago, Guest admin said:
The address address is 202.182.98.100
I would say it's a valid detection: https://www.virustotal.com/gui/ip-address/202.182.98.100 .
Additional reference here: https://symantec-enterprise-blogs.security.com/threat-intelligence/shuckworm-russia-ukraine-military . Also, https://1275.ru/ioc/2192/shuckworm-apt-iocs/ .
-
One more test and this one is the most interesting one to date.
I created an Eset firewall rule to block any in/out network traffic for UDP, remote ports 80,443,8443. Moved the rule to the top of the rule set. Connected again to QUIC test web sites.
Guess what happened? Appears Eset forum uses QUIC. In any case, QUIC UDP traffic is being detected by the firewall but I never see it showing up in TCPView.
-
More testing last night. What a mess. But, a lot of progress.
First is I found out why QUIC sites weren't processing in Firefox. Somehow there were two network.http.http3.enabled settings were present in about:config. The first instance was set to false and the second one set to true. Deleted the false instance and now the above posted QUIC test sites all show QUIC is enabled.
Next, I disabled DoH in Firefox resulting in use of my ISP assigned DNS servers.
I then proceeded to test and observe what was happening network-wise when I accessed the QUIC test sites. No UDP 80/443 connections whatsoever. But for IPv6 connections, the expected TCP 6rd tunnel connection to tunnel broker IP addresses being made.
Bottom line - the QUIC UDP traffic is immediately being converted to IPv6 TCP 6rd tunnel traffic. Eset HTTP/3 scanning is interfering with the 6rd TCP tunneling processing resulting in the IPv6 existing 6rd tunnel configuration being borked. Since I have not encountered any issues to date with Eset processing the TCP 6rd tunnel network connections, I assume it can detect any malicious QUIC network traffic embedded within. Further proof of this was when access to https://crackingpatching.com ; discussed at length in two other forum threads, was tested. Eset blocked access as noted below. The point to note is the connection was made via IPv6 whereas in the past, connection was made via IPv4 when HTTP/3 was disable in Firefox;
QuoteTime;URL;Status;Detection;Application;User;IP address;Hash
4/8/2024 1:54:15 PM;https://crackingpatching.com;Blocked;Internal blacklist;C:\Program Files\Mozilla Firefox\firefox.exe;xxxxxxxx;2606:4700:3030::ac43:db5f;27BB8D2FC02CD2BBC184D07357AAA9903D88B425As far as access to QUIC IPv4 web sites, I will just have to live with the risk. I believe that is minimal due to Windows preferring IPv6. What Eset needs to do is provide an option to only scan IPv4 QUIC traffic.
ESET SSL protection produces an invalid certificate chain for NodeJS apps
in Quick questions by guests (registration not required)
Posted
Only URL I could access w/o issue using latest ver. of Firefox was for openrouter.ai. The other two URLs resulted in;