itman
-
Posts
12,245 -
Joined
-
Last visited
-
Days Won
322
Posts posted by itman
-
-
I will also add that as I have posted in other forum replies, it is virtually impossible to block nVidia telemetry via a firewall;
Quotenvtelemetry.dll
A new report suggests that Nvidia Telemetry still works in the latest drivers even if you follow all the guidelines mentioned above. Nvidia seems to have baked this into the file nvtelemetry.dll which you need to delete to block C:\Program Files\NVIDIA Corporation\Display.NvContainer\NVDisplay.Container.exe from connecting to *.gfe.nvidia.com
You need to delete or rename nvtelemetry.dll on the system. Search for the file and rename it in any location you find it.
https://www.ghacks.net/2016/11/07/nvidia-telemetry-tracking/
As deleting this .dll can cause other issues, the only effective way to block the telemetry is via IP address blocking.
-
20 hours ago, Joe S said:
I'm dealing with this absurdity of the over hyper interactive firewall in version 16.2.13.0 that constantly asks me again and again and again the same old jazz every time like a mentally incapacitated person or kid.
As far as NVIDIA Container goes, the parent service process is spawning a same named child process running from a different location;
Assuming that the first firewall rule created by Interactive mode was for the NVIDIA Container service process and the child process setting was enabled for that rule, it should block any outbound network traffic from any spawned child processes.
Otherwise, a manual firewall rule will have to be created for the for the NVIDIA Container service process and the child process setting enabled.
I also suspect the same applies for the other process shown in your screen shot where duplicate rules are being created.
-
Try running;
sfc /scannow
from an admin level command prompt window. It should set Win file permissions back to default values.
-
Since the question of AMD processor use has come up, the above linked SE Labs test article has answered how effective was EDR software on that processor. It was 73%. Note that the report does not state what vendor EDR software; or all that interface with Intel vPro processors, was used in the test. However, it does illuminate the fact that base ransomware protections within these EDR solutions is no where as effective as claimed.
-
49 minutes ago, SeriousHoax said:
If you do an image search, you'll find this image on a random Indian website
Two recent postings on the Kaspersky forum; also from yesterday;
Here's one from 2016 where the photo was probably hijacked from: https://wajraoforce.in/wajra/50-kb-photo/
-
On 9/21/2023 at 7:09 AM, AnthonyQ said:
Tbh, I haven't seen and tested this feature in action because Intel TDT was rarely triggered by the ransomware samples I tested.
I am going to use this comment as a "lead in" to separate "the fact vs. fiction" in regards to Intel TDT protection.
I found an article that covers this subject in regards to ransomware protection that skips the technobabble usually associated with it. Below are the key excerpts from the article;
QuoteIntel has introduced its 13th Generation Core processor line, which the company claims is the first to build threat detection into hardware. In combination with endpoint detection and response (EDR) platforms from Intel partners, the new vPro processors promise a 70% reduction in attack surface compared to four-year-old PCs. Windows 11 systems can also take advantage of vPro’s memory encryption to provide better virtualization-based security.
In tests conducted by SE Labs and commissioned by Intel, the vPro platform had 93% efficacy at detecting top ransomware attacks, a 24% improvement over software alone. Other tests conducted by IDC showed that vPro’s virtualization security could result in a 26% decline in “major” security breaches and 21% fewer impactful security events while improving security team efficiency by 17%.
Intel TDT and EDR
Antivirus and EDR solutions providers might run Intel’s models with the default configuration. More advanced vendors can add indicators from their own research to the ML inference configuration. Intel will deliver updates to partner vendors as new threats emerge.
EDR providers with Intel TDT-enabled solutions include Crowdstrike, Microsoft, Trend Micro, Eset, Acronis, and Check Point. EDR solutions that are not Intel TDT-enabled should work as before with the new vPro systems but without the extra boost. “It’s always faster and more productive to do things in hardware than to try and simulate the same thing with software. With AI, that’s even more so,” says Gold. “AI-accelerated threat detection is a major advance over just looking at code and trying to see if it’s bad, as many antimalware solutions do. AI looks at the behavior and makes a judgment on the risk involved. That’s a major improvement over signature-based solutions.”
Similarly, Intel TDT-enabled EDR solutions will run normally on non-vPro 13th-generation systems. “If the app sees a component (in this case vPro), it can leverage that component. If the component isn’t there, it still works but perhaps not as fast or as effectively,” says Gold.
https://www.csoonline.com/article/574867/security-at-the-core-of-intel-s-new-vpro-platform.html
Let's summarize;
1. Maximum Intel TDT protection is had on the vPro processor line with the greatest protection had on the 13th generation processor line running on Win 11. Of note is the 13th generation processors are the only ones which have TDT protection built within the processor circuitry.
2. In regards to how effective AV solutions that currently interface with Intel TDT vPro processor line are, please refer to this test; also referred to above, performed by SE Labs: https://selabs.uk/reports/enterprise-advanced-security-ransomware-intel-threat-detection-technology-2023-02/ . Of note are the following test results;
a). The vast majority of ransomware protection is had by Intel TDT protection.
b). AV software interfacing with Intel TDT protection added marginal detection capability; in the 3 - 5% range.
3. As far as how effective Intel TDT protection against ransomware is in older non-vPro processors with or without AV software interface is highlighted in bold red above. In other words, it is unknown.
In regards to point 3.) until I see any definitive AV lab testing of these AV solutions using older non-vPro processors against ransomware, I consider that protection to be vaporware.
-
5 hours ago, kapela86 said:
It kinda sux that you can't see what URL user visited that triggered this script. This would be very usefull.
Example of Balada Injector malware deploying stay.decentralappps.com given in this article: https://www.geoedge.com/balda-injectors-2-0-evading-detection-gaining-persistence/ .
Bottom line is any legit but vulnerable web site can be nailed by this.
-
Looks like this domain is well known: https://securedstatus.com/how-to-remove-decentralappps-com/ . As suspected, it is redirect malware.
-
1 minute ago, Marcos said:
It's working, I removed my comment. I was looking at the Process column and because of that I erroneously assumed that the detection was triggered on a disk.
Perhaps not on Chrome? Op's screen shot shows Eicar .zip detection on disk; not via HTTP filter.
-
The Eicar .zip download should have been blocked by Web Access protection; i.e. HTTP filter;
Time;Scanner;Object type;Object;Detection;Action;User;Information;Hash;First seen here
9/21/2023 11:09:05 AM;HTTP filter;file;https://secure.eicar.org/eicar_com.zip;Eicar test file;connection terminated;xxxxxx;Event occurred during an attempt to access the web by the application: C:\Program Files\Mozilla Firefox\firefox.exe (1EA307959A891AA89787D5101669BB3587D8C48C).;D27265074C9EAC2E2122ED69294DBC4D7CCE9141; -
Definitely a malicious domain;
-
I question the wisdom of the Trusted Publisher option. Certificates can be spoofed. Unless Eset is actually verifying the process is validly signed; note this could be for every process run with the same Pulisher in the case of Trusted Publisher only evaluation criteria, the option should be eliminated.
-
23 minutes ago, blur said:
The icon is on the right corner.
Refer to the below screen shot.
If you disable the highlighted setting in Eset Banking & Payment Protection settings, the green frame around the browser window plus the icon notification that Eset is operating in B&PP mode will not appear;
-
4 hours ago, tman555 said:
Can opening the port through Windows Firewall work?
Assuming ESSP Firewall Filtering mode is set to Automatic which is the default setting, the Win firewall is not your issue.
-
48 minutes ago, tman555 said:
This is what appears when I click on the notification of proxy gui
The first alert states "The license will expire soon." Is this a trial license?
The second alert states "Operating system updates available."
As far as the limited cloud access warning goes;
QuoteResolve the "Limited Direct Cloud connectivity" warning
TCP/UDP port 53535 must be open
Communication with ESET's servers has changed and communication on UDP and TCP port 53535 must be allowed on a firewall for ESET LiveGrid, Antispam and Web Control to work. To resolve an ESET product with a limited Direct Cloud connectivity issue, TCP/UDP port 53535 must be open.
You may be unable to access an ESET Cloud connection due to a temporarily disabled internet connection or a network outage from your service provider.We recommend checking the internet connection with your internet service provider or using a different network and changing the Domain Name System (DNS) to, for example, 8.8.8.8.
If the issue remains, we recommend you check the connectivity to all ESET LiveGrid, Web control/Parental Control and Antispam IP addresses on the given ports.
-
What is the second Eset notification for?
I suspect one or more of your Eset protection mechanisms are disabled. Open the Eset GUI and verify no alerts are shown.
-
FYI;
QuoteVarious tools can be used in order to hijack a certificate from a trusted binary and use it to a non-legitimate binary.
python sigthief.py -i consent.exe -t mimikatz.exe -o signed-mimikatz.exe
Sigthief – Stealing Certificates
SigPirate.exe -s consent.exe -d mimikatz.exe -o katz.exe -a
SigPirate – Stealing Certiificates
The consent file is an executable which is part of Windows operating system and therefore it is digitally signed by Microsoft. The binary will appear to have a digital signature of Microsoft.
Malicious Binary with Trusted Certificate
As previously the digital signature will fail to validate.
https://pentestlab.blog/2017/11/06/hijacking-digital-signatures/
-
2 minutes ago, sovchen said:
Except it's not a problem. That post is an example of the functionality I need. A wildcard rule would be exactly what I don't want in this case.
I was referring to the multiple Deny rules you created. The Allow rule would be positioned above the wildcard Deny rule so that it would execute first.
-
1 hour ago, sovchen said:
Note how I have multiple python installs working out of different locations in my filesystem. The firewall rule specifically points to the path of the executable.
This has always been a problem with Eset firewall rules. It would be solved by allowing wildcard "*" specification in path specification as the HIPS currently does;
e.g. W:\*\Python3.10.6\python.exe.
-
One possibility is this hack method: https://attack.mitre.org/techniques/T1036/001/ .
You will need to closely examine the signatures of the files that are generating these Eset detections.
-
My own opinion here is Eset should commission SE Labs to perform ransomware testing as CloudStrike did: https://selabs.uk/reports/enterprise-advanced-security-ransomware-crowdstrike-2022-oct/ .
-
2 hours ago, Purpleroses said:
I also see it under Nvidia web helper .exe and nvcontainer.exe
Nvidia web helper is GeForce Experience which I purposely never allow to be installed whenever I update my nVidia graphics card drivers.
I have never seen 127.0.0.1 used in conjunction with nvcontainer.exe. Suspect that has something to do with GeForce Experience running.
-
31 minutes ago, Purpleroses said:
I noticed under network connections this address 127.0.0.1 listening under some of my connections
If its ekrn.exe where the 127.0.0.1 connection shows, it is normal activity. Eset firewall proxy's network traffic using localhost. Also svchost.exe - IP Helper service uses 127.0.0.1. Finally, Firefox also uses 127.0.0.1 to proxy network traffic.
-
Based on this posting;
QuoteHi! I have a firewall that scans HTTPS traffic, and Proton Mail Bridge does not accept the certificate. (Which makes sense.) I would like to allow the traffic to skip inspection. What domains or IP addresses are accessed by the Bridge that can be excluded?
https://www.reddit.com/r/ProtonMail/comments/xsaspx/what_domainsip_addresses_used_by_proton_mail/
The issue is Eset SSL/TLS protocol scanning. Exclude the .exe associated with the Proton Mail Bridge app from SSL/TLS protocol scanning and see if that resolves the issue.
Unknown accounts
in General Discussion
Posted
asio3.sys - ASUS motherboad relater driver. It probably is OK but could be a vulnerable driver. You need to check on ASUS web site about this.
ctiaio64.sys - Creative Technology Innovation Co., LTd driver. Couldn't find any info on this one.
msio64.sys - MSI driver associated with MysticLight software. Perhaps a graphics card utility of sort. Eset in the past has flagged this one: https://forum.eset.com/topic/32126-eset-flagging-drivers-as-potential-malware/ , it's a driver that has had a vulnerability in it in the past.