Jump to content

itman

Most Valued Members
  • Posts

    8,861
  • Joined

  • Last visited

  • Days Won

    215

Everything posted by itman

  1. There is also another marketing option in regards to LiveGuard usage. Simply sell it as a subscription option for all Eset Home product versions as currently done for EDTD . The first 30 days would be free so one could trial the feature. I believe this is important since I suspect there are a number of home users who will feel LiveGuard's aggressive blocking and cloud scanning are not to their liking. After 30 days without a subscription purchase, LiveGuard would revert to blocking and cloud scanning of suspicious files only as I posted previously. As for subscription pricing, it would be dependent upon product purchased. It would cost the most for NOD32 and be free in ESSP. Eset could also offer bundling option incentives with a combined Eset product license plus LiveGuard subscription purchase costing less than if purchased separately. Incentive subscription pricing could be offered for a certain limited period to induce existing Eset users to purchase the feature. I also believe the above will generate more revenue for Eset than forcing existing users to upgrade to Smart Security.
  2. True. But in this context, you are referring to the exploiting of a 0-day vulnerability. There are thousands, if not millions of malware, that are quite effective without falling in the exploit category.
  3. I am going to give Eset "an out" in regards to LiveGuard use in EIS and NOD32 and I strongly suggest they do what I propose. To begin, an ESSP user has privately confirmed to me that LiveGuard processing is identical to EDTD processing. That is, it is performing absolute block-at-first-sight cloud submission and analysis. This actually was a surprise to me. By absolute submission, I mean the file is being submitted to the cloud w/o any Eset exisiting reputation status factoring. My proposal is LiveGuard be employed in EIS and NOD32, but only used for locally Eset detected suspicious files. Based on my experience, the upload volume of these files is next to nil. As such, the cost factor to Eset to provide this capability in regards to Azure server use would be the same. It has infuriated me to no end since my 0-day usage of Eset that it would detect a suspicious file, but allow it to run unabated.
  4. Let's "cut to the chase" in regards to Eset's cloud scanning. As shown in the diagram in this article: https://help.eset.com/edtd/en-US/overview.html , Eset is using Microsoft's Azure AI servers. Microsoft will gladly allow anyone who so desires use of those servers. Obviously, this use is not for free. The question however is just how expensive is their use? There is a low budget developer who markets a security product add-on named VoodooShield: https://voodooshield.com/ which is popular with participants of the security forums; e.g. wilderssecurity.com. This product also uses the Azure AI servers. There is both a free and a paid version of this product. As far as I am aware of, both the free and paid versions use the Azure AI cloud servers.
  5. I just checked U.S. prices for Eset. ESSP costs $10 more per year than EIS. As such and for me personally, the increased price is not a major factor. This important LiveGuard feature being included only for ESSP does "leave a bad taste in my mouth." For starters, Eset should have had LiveGuard capability in its consumer product versions long ago. Like feature capability has existed for some time in Eset competitor consumer products as you noted. This includes Microsoft Defender that doesn't cost anything. I also have no need for the extra features ESSP provides and feel upgrading to it for LiveGuard capability is shady marketing tactic. It also should be noted that EIS costs on the average, significantly more than its competitor's equivalent products. Bottom line to Eset - include LiveGuard in EIS or be prepared for a significant loss of your existing EIS product base.
  6. Go to this web site: https://www.amtso.org/feature-settings-check-potentially-unwanted-applications/ and run the test. Do you receive the following Eset PUA alert:
  7. https://help.eset.com/essp/15/en-US/idh_config_liveguard.html Based on Eset's write up, LiveGuard has the capability to block suspicious process execution until full Eset cloud analysis completes. So we are still dependent upon Eset's other protection mechanisms to determine suspicious status. Micosoft Defender block-at-first-sight processing on the other hand submits all unknown files based on SmartScreen reputation status for cloud scanning. Its major weakness is it only performs this analysis for files downloaded from the Internet and as such, have the "mark-of-the-web" ADS associated with them.
  8. Was this a upgrade to Win 11 via Windows Update? Since neither Eset nor Microsoft Defender show as active Antivirus or Firewall protection, it appears there may be an issue with the upgrade to Win 11. By default, Microsoft Defender should show as active Antivirus and Firewall protection if no third party antivirus solution is installed. Is Eset actually running on this device?
  9. There are other issues also: https://www.bleepingcomputer.com/news/microsoft/windows-11-microsoft-is-investigating-these-eight-problems/ The most interesting one is you can't upgrade to Win 11🙄:
  10. As @Marcos noted, .dll files cannot directly access the Internet. They can only do so under some type of programmatic control. Posted below are references on some ways malware does so. You either have to rely on other Eset protection mechanisms to detect these malicious activities, or do so manually via the Eset HIPS. This is difficult to do without blocking legit system activities since the HIPS doesn't allow for monitoring of process command line parameters. The best way to do so is via monitoring of child process startup activities from these exploited processes as noted in this Eset KB article in regards to ramsomware firewall rules: https://support.eset.com/en/kb6132-configure-firewall-rules-for-eset-endpoint-security-to-protect-against-ransomware References: https://attack.mitre.org/techniques/T1574/002/ https://attack.mitre.org/techniques/T1055/001/ https://attack.mitre.org/techniques/T1218/011/ https://attack.mitre.org/techniques/T1218/010/
  11. Again and as previously noted: Refer to this article: https://www.thewindowsclub.com/how-to-repair-or-rebuild-the-wmi-repository-on-windows-10
  12. The way to stop this deceptive marketing practice is for Eset eStore to do as other web merchants do that I frequent. These web sites will ask you on initial purchase if they can save your credit card data. If you say no, by definition you are making a one-time purchase. This also makes the auto-pay issue a moot point since without credit card data retained, there is no way to perform an auto renewal. People need to petition Mastercard and Visa to make this a requirement for any web merchant that accepts their cards,
  13. Appears to me the displayed message is originating from your router. Are you using a DWA0120 model router? If so, I would do as suggested in step 2) of the displayed message.
  14. I had to perform some additional system and Eset Networking modifications and now Eset Networking/firewall is "peacefully co-existing" with my device/router. If after reading this, you get a migraine headache. Take two large migraine relief tablets and go to bed. I forgot to replace Eset firewall default DHCPv6 rule which doesn't work with my router with the Win 10 firewall DHCPv6 rules that do work. Next, I noticed that Eset Network Identification active connection processing appeared borked. Decided it was time for a full Win 10 network reset. Upon system restart from this, I noticed that my IPv6 DNS servers were fully initialized in both Win 10 and Eset. That is external AT&T IPv6 DHCP/DNS server showed as primary IPv6 DNS server in Win 10 and local subnet IPv6 DNS server as secondary IPv6 DNS server in Win 10. Additionally, both IPv6 server IP addresses showed in Eset DNS server Zone. This result is critical for Network Inspector correct DNS server determination which I will get into next. This morning upon first Win 10 fast startup of the day, I observed something never seen in Eset use to date. Both IPv6 server IP addresses showed in Eset DNS server Zone. However, at that time only the external AT&T IPv6 DHCP/DNS server showed as primary IPv6 DNS server in Win 10. Within a couple of minutes, the handshaking processing completed and the local subnet IPv6 DNS server was assigned as secondary IPv6 DNS server in Win 10. If the above processing holds true from now on for all future system restart modes, it confirms prior statements made by Eset that Network Inspector is determining and saving network settings at either Eset installation an/or when the Windows network is completely rebuilt from scratch as is done via Win 10 network reset option. In my case, this is critical for Eset not misinterpreting the various IPv6 DNS setting combination settings done by my router as rogue DNS server setting modification to my router. The last remaining piece of this Eset Networking inspection puzzle mess was the misinterpreted outbound network traffic from my device as inbound traffic upon resume from system initiated sleep mode with no prior system sign off. This had settled down to only DNS and mDNS; i.e. port 5353 traffic as show below: Time;Event;Action;Source;Target;Protocol;Rule/worm name;Application;Hash;User 10/3/2021 10:38:32 AM;Communication allowed by rule;Allowed;192.168.1.xxx:5353;224.0.0.251:5353;UDP;Rule created by wizard for: svchost.exe;C:\Windows\System32\svchost.exe;010DB07461E45B41C886192DF6FD425BA8D42D82;NT AUTHORITY\NETWORK SERVICE Time;Event;Action;Source;Target;Protocol;Rule/worm name;Application;Hash;User 10/3/2021 10:38:33 AM;Communication allowed by rule;Allowed;192.168.1.xxx:57839;192.168.1.25x:53;UDP;Rule created by wizard for: svchost.exe;C:\Windows\System32\svchost.exe;010DB07461E45B41C886192DF6FD425BA8D42D82;NT AUTHORITY\LOCAL SERVICE Turns out the above is being generated as a result of NetBios and mDNS connectivity handshaking processing from the Ethernet PowerLink adapter my PC is connected to. Eset networking is totally clueless on how to handle this network traffic. So I created specific Eset firewall rules to handle the above. Bottom line- Eset has really created a network mess with current Network Inspector processing for select customized routers. God help you if you happen to fall into this category.
  15. Later Win 10 versions have a built-in optional feature called "Windows Subsystem for Linux; i.e. WSL. If you did not manually enable this option, it is possible an attacker might have. WSL can be also enabled by running a single command line using PowerShell or via cmd.exe as noted in this Microsoft article: https://docs.microsoft.com/en-us/windows/wsl/install. It has been long theorized that the bash component of this Linux feature could be abused. It is no longer a theoretical abuse and attackers are currently using it: https://www.bleepingcomputer.com/news/security/new-malware-uses-windows-subsystem-for-linux-for-stealthy-attacks/ . Of note: In any case, the above would be an explanation for what Eset's Connected Home Monitor is displaying in regards to Linux use.
  16. Verify Eset's marketing messages option is disabled per the below screen shot:
  17. Refer to this Eset Knowledge-based article: https://support.eset.com/en/kb2933-arp-icmp-or-dns-cache-poisoning-attack-in-eset-home-products-for-windows The important part to note is the following: If the Eset ARP poisoning alerts show IP addresses within one of the above addresses ranges, then it's not a real ARP poisoning attack.
  18. Wrong again! At least now I remember why this won't work: This does force an immediate connection to the external AT&T IPv6 DHCP/DNS server, but doesn't allow the router to perform its necessary setup processing to the fixed allocated local subnet IPv6 DNS server. I have however found the Eset "culprit." It's the "Notify about newly discovered network devices" option for Network Inspector. With that option disabled, all my IPv6 networking is being set up correctly and I no longer have to trust both IPv6 servers to prevent Eset firewall processing from going bonkers.
  19. I was one step away from uninstalling Eset this morning and it dawned on me there was one last thing I haven't tried in regards to my auto config. IPv6 network connection. So what the hell, let's try that. My previous experience with use of Cloudflare IPv6 DNS servers yielded the following. If I "dumb down" my IPv6 server settings so Eset's Network Inspector/Inspection processing sees a fixed predefined network connection, it doesn't go spastic resulting in a borked network connection from it. So I specified my external AT&T IPv6 DHCP/DNS server IP address on my network adapter Windows IPv6 DNS settings as primary and my fixed allocated local subnet IPv6 DNS server as secondary. Now, let's pause a moment. I never considered doing this recently since I tried the same when I first installed Eset Smart Security in 2014. It didn't go very well and never considered it since. The difference from then to now is I have detail knowledge in how my router auto allocates my ISP IPv6 servers. Ditto for "quirks" with Eset in regards to trusting network devices and its validation of them. Continuing, I next kept my fixed allocated local subnet IPv6 DNS server IP address as an Eset Trusted IP address and removed the external AT&T IPv6 DHCP/DNS server IP address. Trusting the fixed allocated local subnet IPv6 DNS server IP address is the key component in getting Network Inspector/Inspection processing not to go bonkers. The router is pinging this IP address every 30 secs along with IPv6 gateway IP address for connectivity purposes. Additionally, the router is using NetBIOS and mDNS; i.e. port 5353, periodically against this IP address. Note that Eset doesn't even have default firewall rules for port 5353 network traffic. Luckily, the Win 10 firewall does have an inbound rule for it applicable to all its network profiles. The port 5353 element is interesting. I came across a hard to find article that Ethernet based Powerlink adapters use mDNS for device-to-device communication and I use them to connect to my PC. So that might be another element in this Eset network configuration mess. Rebooted and I was utterly amazed had how fast, smooth, and most importantly, my IPV6 network configuration was set up with Network Inspector enabled. I am 100% convinced everything is correctly configured since I now see a network binding for the fixed allocated local subnet IPv6 DNS server IP address to the external AT&T IPv6 DHCP/DNS server IP address; something that always existed prior to ver. 17. This proves to me something has changed in ver. 17 in regards to Network Inspector/Inspection and I don't believe anything Eset says publicly to the contrary.
  20. I got Network Inspector to "peacefully co-exist" with my router by doing something I will now admit, I did in the past. So let's get to this. If I add both the IPv6 addresses for my local subnet allocated DNS server and the external dedicated AT&T DHCP/DNS server as to Eset's Trusted addresses, everything works w/o conflict. But here's the problem with this. Whereas I have no qualms with adding to Trusted addresses the local subnet allocated IPv6 DNS server since it's primary purpose is for caching IP addresses, I do have a major issue with adding the external dedicated AT&T IPv6 DHCP/DNS server IP address. Simply put if this server gets hacked, I am literally "dead meat" since anything it does will be allowed by the Eset firewall. There is also the issue if either of these allocated DNS servers IP addresses are changed by AT&T although to date, this hasn't happened. The simple Eset solution is to have Network Inspector "butt out of" DNS server validations when no explicit DNS server addresses are specified on the IPv4 and IPv6 network adapter settings. Since we all know "hell will freeze over first" before Eset does something about this, I won't be renewing my Eset license subscription. I'll be switching to Microsoft Defender and using the money I spent on Eset to add an ATP subscription now that I am using Win 10 Pro. Something that can't be done in Eset consumer versions; i.e. add EDTD protection.
  21. Good advice. I am tired of wasting my time in this forum reporting Eset problems that ultimately get dismissed.
  22. I will again reiterate what happens on my EIS installation when Network Inspector is enabled. At system restart time, a half dozen ekrn.exe UDP and UPDv6 are established along with an ekrn.exe port 138 connection. These remain for a couple of mins. and are then dropped. In the past, one ekrn.exe UDP and UDPv6 remained. On ver. 17, the UDPv6 connection is usually permanent dropped and not later reestablished. Upon resume from Win 10 sleep mode, a dozen ekrn.exe UDP and UPDv6 are established along with an ekrn.exe port 138 connection. These remain for a a couple of mins. are then dropped. In almost every instance on ver. 17, the UDPv6 connection is usually permanent dropped and not later reestablished. In regards to the ekrn.exe UDPv6 connection when dropped. If I perform anything related to current network status such as ipconfig /all or view network settings in Win 10, the ekrn.exe UDPv6 connection is reestablished and remains in effect until system shutdown/sleep mode. With Network Inspector disabled, I have no borked Eset firewall activity where my normal outbound network traffic is being interpreted as inbound traffic and being blocked upon resume from sleep mode. Although there have been two incidents where this occurred for a couple of port 53 DNS connections. Now really, is this passive behavior? Network Inspector stays permanently disabled on my device. -EDIT- BTW the same above behavior occurs the minute the Network Wizard is opened with the result being the ekrn.exe UDPv6 connection being permanently dropped.
  23. Let's analyze in more detail logically; something Eset developers appear to be incapable of doing. The above quote implies that Network Inspector is directly linked to Connected Home Monitor functionality. Next is Eset adequately warns that Connected Home Monitor should only be used when the Home/Office profile is the active network connection profile. By default, Eset installs with the "use Windows settings" option. Again by default, the Win 10 firewall uses the Public profile. Therefore the network connection established by Eset is using the Public profile. Since Connected Home Monitor use is N/A in regards Public profile use, by default Network Inspector should be disabled. It should only be auto re-enabled when one switches the active network connection profile to the Home/Office profile.
  24. Err, what? I posted previously that it resolved all my IPv6 connectivity issues and Eset recognizing that an IPv6 exists via establishment of an ekrn.exe connection monitoring UDPv6. All of them. There never has been an issue with the Win 10 firewall properly recognizing my IPv6 connection or interfering with any aspect of it connectivity processing. I have previously posted Eset needs to provide an option to only use its firewall for outbound network traffic of user custom rules. All other network traffic would be handled by the Win firewall. This, I 100% disagree with. If everything I have posted in this thread hasn't effectively communicated there is an issue with Network Inspector, nothing I posted further would do so and would be a waste of my time.
×
×
  • Create New...