itman

I thought it did. But VT shows Eset doesn't: https://www.virustotal.com/gui/file/543991ca8d1c65113dff039b85ae3f9a87f503daec30f46929fd454bc57e5a91 Ref.: https://www.reddit.com/r/crowdstrike/comments/13wjrgn/20230531_situational_awareness_spyboy_defense/?rdt=47042 -EDIT- I forgot Eset detects vulnerable drivers as PUA's. Since PUA detection is not performed by Eset ver. used at VT, I assume Eset detects this driver?

Looks like Eset Cobalt Strike detection capability has improved! I found a sample not detected by Eset on VT. Upon download, Eset real-time detection caught it as suspicious; i.e. LiveGrid blacklist detection; Of note here is no LiveGuard submission was done prior to detection. One possible reason for Eset detection is the file sig, was invalid; https://www.virustotal.com/gui/file/220f6b9f96106f637b339e2c6aee7259e76a9fd8a7237bc69ca7c1412bb8f992

Appears that is the case.

As far as MBAM detection of wtrxus.com, it might be picking up that McAfee has blacklisted the domain: https://sitecheck.sucuri.net/results/wtrxus.com . Also, no one is detecting anything malicious with the IP address associated with wtrxus.com; At this point, I would say MBAM is giving a false positive detection. Finally if you are running MBAM in real-time mode, you shouldn't be since it can potentially interfere with Eset's real-time scanning. -EDIT- Quttera has also blacklisted the web site: https://quttera.com/detailed_report/wtrxus.com# although no reason given as to why. Also on VirusTotal, 6 vendors including Kaspersky rate the domain malicious: https://www.virustotal.com/gui/domain/wtrxus.com. Looks like alphaMountain.ai is the one rating the site as malicious,

Another important point about Cobalt Strike is the ability to deploy an AMSI bypass; https://hstechdocs.helpsystems.com/manuals/cobaltstrike/current/userguide/content/topics/malleable-c2-extend_controll-post-exploitation.htm Also and important is Eset's HIPS recommended anti-ransomware rules to prevent script startup from rundll32.exe won't work since that rule is only monitoring child process creation from its default Windows directory locations.

What is the name of the other malware remover you installed?

Since Eset won't detect Cobalt Strike beacons until Eset Lab analysis is done on them, I am posting a couple of articles on behavior detection of the beacons. The detection method doable via Eset HIPS capability which happens to be the most used method for deploying beacons is; https://www.logpoint.com/en/blog/how-to-detect-stealthy-cobalt-strike-activity-in-your-enterprise/ What you're looking for when the HIPS alert triggers if an ask rule is used is the following. However, I would make the HIPS rule/s a block one since there is no reason rundll32.exe or regsvc32.exe should be running from the above noted directories. https://socfortress.medium.com/detecting-cobalt-strike-beacons-3f8c9fdcb654 Note that Cobalt Strike pipes the rundll32.exe argument payload name making it "invisible" to AV solutions. * Refer to prior posted TrendMicro Play Ransomware attack analysis on the use of Adfind.exe.

It has already been stated that Eset detects the .exe as a potential unsafe app and the detection is correct.

Since I brought up Play ransomware, its latest supply chain attack method is most disturbing; 'Play' Ransomware Group Targeting MSPs Worldwide in New Campaign https://www.darkreading.com/cloud/-play-ransomware-group-targeting-msps-worldwide-in-new-campaign Bottom line - zero trust is a must - pun intended.

Per Eset Internet Security system requirements; https://help.eset.com/eis/16.0/en-US/sysreq.html Also note;

Some Cobalt Strike beacon's appear to be totally "off the detection radar." Such is the case of this beacon deployed by Play ransomware that has never been submitted to VT. Courtesy of TrendMicro: https://www.trendmicro.com/vinfo/us/security/news/ransomware-spotlight/ransomware-spotlight-play -EDIT- Also this beacon will run a .bat script which is atypical of many CS beacons; Hence, why I monitor all cmd.exe execution.

You can't. As commented upon in multiple forum postings, this capability won't be added until ver. 17 is released this fall.

Are you referring specifically to this statement: https://forum.eset.com/topic/37283-interactive-firewall-useless-since-162/page/2/?_fromLogin=1#elControls_170624_menu ?

Here's Intuit article on how to create needed Win firewall rules: https://quickbooks.intuit.com/learn-support/en-us/help-article/multi-user-mode/set-firewall-security-settings-quickbooks-desktop/L7mq0coIY_US_en_US . You can use this to create equivalent Eset firewall rules.

VirusTotal display shows Eset is not detecting this app.

Obviously, I don't want to disable SSL/TLS protocol filtering and weaken my security protection. I just don't want my DNS processing hijacked. Further, my ISP prohibits use of DNS servers other than its own and will most likely block the DNS traffic on its relay DNS servers.

This activity just started with ver. 16.2. Refer to the below screen shot. Highlighted in black is my legit IPv4 DNS server address assigned via gateway DHCPv4 processing. Highlighted in red is a DNS connection to Google's public IPv4 DNS server address. This activity also appears to be related to Eset's use of Cloudflare's Comodo crl download. How do I stop Eset's download from Cloudflare?

I have a pretty good idea as to Eset's lack of Cobalt Strike beacon detection. It's not that Eset can't detect them at first sight, it just won't do so. I have had some DNS hijack incidents of late. To verify I did not not have some malware undetected by Eset, I downloaded and ran Kaspersky's Antivirus Tool (KVRT) and ran a full system scan including all internal hard drives. The only thing KVRT detected was 18 hack tools, POC's, etc. I have accumulated over the years used for testing purposes. Obviously, none of these had been detected by Eset. Cobalt Strike per se is not malware. It is a legit penetration test tool widely used by computer security audit concerns; an expensive one at that:https://www.cobaltstrike.com/product/pricing-plans . The problem with it, as with other like software, is these products always seem to be acquired by hackers. Eset will not detect hack tools per se. Only Eset can answer why but I suspect it has to do with false positive detection and Eset's aborence of such. If Cobalt Strike detection at first sight is a major concern, one would be better served using Kaspersky or a product that uses its engine which will detect hack tools.

I would contact Eset corporate headquarters in Slovakia. You can also express your concerns that you beleive the Eset distributor in Italy is engaging in "price gouging."

Refer to this: https://support.eset.com/en/kb6681-comparison-of-eset-liveguard-advanced-eset-threat-intelligence-and-eset-livegrid . The main difference between LiveGuard and LiveGuard Advanced is it is designed to interface with Eset server products. The only analysis done by LiveGrid in the Eset cloud is a file blacklist lookup. LiveGrid's primary purpose to forward suspicious files to Eset Lab for further analysis. Feature-wise the only difference between LiveGuard and LiveGuard Advanced is LiveGuard Advanced malware detection confidence level is configurable in regards to suspicious processes allowing the user to make the decision to allow or deny execution.

What do Cobalt Strike beacons look like? Here's one from a sample @AnthonyQ posted this morning using port 443; Here's one from a Joe's Cloud sandbox analysis using port 80; The common code between the two beacons; I guess this is an identification start.

BTW - hackers also get infected with infostealers; Over 120,000 Computers Compromised by Info Stealers Linked to Users of Cybercrime Forums https://thehackernews.com/2023/08/over-12000-computers-compromised-by.html

This has been answered in other forum postings. These will be added back when ver. 17 is released.

First, there are two default firewall profiles in Eset, Public and Private. Eset firewall profiles are assigned to the network connection/s Eset network processing creates. By default, the Eset firewall profile used for these network connection defers to the current Windows firewall profile which by default is Public. An existing Eset network connection profile can be changed by right mouse key clicking on the network connection and selecting "Edit" per the below screen shot. If the "Automatic" profile option is selected, Eset will defer to the current Windows firewall profile; Important! - Do not select "Forget" unless you intend to remove the existing network connection.

Actually, Eset does have an open beta method in the form of the pre-release update option which has to be enabled manually in the Eset GUI. The problem is most will not enable this option due to the potential operational issues that may present.