Jump to content

itman

Most Valued Members
  • Posts

    8,821
  • Joined

  • Last visited

  • Days Won

    213

Everything posted by itman

  1. As far as the Eset CompuTrace detection, refer to this KB article: https://support.eset.com/en/kb6567-you-receive-an-eset-uefi-detection?ref=esf Mouse click on the "Clean" button for the Eset shown PUA alert.
  2. Well, there was one last thing I had to perform to get the router, Win 10, and Eset networking to play together nicely. I have long suspected that Win 10 Smart multiple-homed DNS name resolution was the source of most of my network issues. This was further amplified by Eset networking initialization. But since this feature was using my ISP DNS servers combined with the way the router establishes Win 10 network connectivity, I could never definitively nail it down. You can read about what Win 10 Smart multiple-homed DNS name resolution does here: https://www.ghacks.net/2017/08/14/turn-off-smart-multi-homed-name-resolution-in-windows/ . The gist of the what is does is: What I have been observing after my Win 10 networking "from hell" reconfiguration activities described previously is at Win 10 fast startup and/or startup from sleep mode predominately is multiple connections to IPv4 address 1.1.1 to port domain. Err what? Port domain turns out to be port 53 and of course, 1.1.1.1 is Cloudflare's IPv4 DNS address. First, I have never ever seen these domain connections before. Next is I shouldn't be using Cloudflare's IPv4 DNS server on an IPv6 network. Bottom line is here is a graphic example of my Win 10 network connection being borked by Smart multiple-homed DNS name resolution processing. As far as what this did to Eset's network connectivity processing can best described as a double-whammy bork from the deepest depths of networking hell. Anyway, I have disabled Win 10 Smart multiple-homed DNS name resolution and finally, all is well networking-wise.
  3. I just manually added two entries to my Win 10 hosts file using notepad. See below screen shot. I received no alerts from Eset real-time protection. So something else is going on in regards to your EIS installation.
  4. Sorry, it was a typo on my part. It should show port 8883. Also and again if there are ekrn.exe issues with syncing of Push Notifications, port 8883 will show for a while and then be dropped in a repetitive loop. TCPView will actually show this activity in that "Sync" with be shown in its Status column with "Established" connection status never being shown.
  5. Next time this updating issue occurs, use a network connections monitor to ensure ekrn.exe has a solid connection to port 8883. You can use Eset's Network Connections tool or TCPView. I prefer TCPView since it will show if there are sync issues with the connection to port 8883, ekrn.exe is trying to establish. Eset uses port 8883 with fallback to port 443 for Push Notifications. If there are issues with getting that connection, it will cause this bork Eset updating behavior some are experiencing.
  6. Works fine on EIS. For Detection exclusions, mouse click on the gear symbol next to Real-time file system protection. Then select "Edit Exclusions."
  7. Eset HIPS rules are not case sensitive. See below HIPS log entry of "C:\Program Files\internet explorer\iexplore.exe" startup being blocked from cmd.exe: Time;Application;Operation;Target;Action;Rule;Additional information 9/20/2021 4:09:23 PM;C:\Windows\System32\cmd.exe;Start new application;C:\Program Files\internet Explorer\iexplore.exe;Blocked;User rule: block child process startup from cmd.exe; Your problem is related to this. It appears this elevate process you are using is indeed case sensitive. Also note that this elevate process not only changes IE permissions but appears to also start it. Existing Eset anti-ransomware rules will not monitor any process startup activity from elevate.exe. HIPS rules are not global in nature. For example; they will monitor IE startup from cmd.exe. They will monitor elevate,exe startup from cmd.exe. If elevate.exe is allowed to start by cmd.exe, anything that elevate.exe starts will be allowed to run. A separate HIPS rule needs to be created to monitor elevate.exe process startup.
  8. By default, Eset network Profile selection is "use Windows settings." As I previously posted, Win 10 firewall default network Profile setting is Public. Therefore if using default settings on both, Eset's Network profile would always be set to Public. -EDIT- Some additional detail here. Win 10 firewall defaults to the Public profile for a reason. It auto disables Network Discovery. The way you're supposed to securely do file sharing on a Win 10 device is to right mouse click on the file to be shared on the network and select the "Give Access" option. This also brings up why Eset has the "Home or Office networking" profile option in the first place since it in effect, overrides Win 10 built-in network security. The most damning aspect of the Home or Office networking Eset profile is it enables NetBIOS access by default.
  9. No problem here for either HTTP or HTTPS cloudcar.exe attempted download and Eset detection when using Firefox.
  10. One important observation I forgot to mention. When I using Cloulfare's IPv6 DNS64 servers besides the Eset Push Notifications issue, the first thing to manifest was the Eset "hung" updating and constant Eset desktop toolbar icon spinning wheel issue. I therefore conclude this current Eset hung updating issue has nothing to do with what has been stated to date in the forum. Rather, the problem is related to Eset Push Notification processing malfunction in some way.
  11. Today is Sunday and I can finally state I have Eset Networking finally setting up a stable and correct networking configuration. Additional things I had to do to accomplish this is: 1. Configure my network adapter IPv4 connection DNS settings to use Cloudflare IPv4 DNS servers. Again, amazed AT&T allows this. 2. Ensuring all Eset network settings where "use Windows settings" are applicable are enabled. Since the Windows firewall defaults to Public profile use and this is what I want my system to use, this suits me just fine. 3. Using the latest network connection Eset establishes and deleting any others that might exist. At this point, I have in effect bypassed any networking auto configuration activities my router was performing and Eset's resulting bork network configuation of those auto configuration activities. The interesting part now is I observe ekrn.exe performing UDP and UDPv6 local proxy monitoring activities but Eset Network Connections tool no longer shows local host 0.0.0.0 and 0.0.0.0.0.0 addresses. My final comment is Eset needs to immediately address this Push Notifications issue with DNS64 use. When I was using Cloulfare's IPv6 DNS64 servers, I performed the AMTSO Cloudcar test. Immediately Eset detected and blocked the connection prior to any attempted file download activities which is the correct result for this test. Such is not the case when the Clouldflare's non-DNS64 IPv6 DNS servers are used. As shown below, Eset is detecting a "stub" download of the clouldcar.exe file: Time;Scanner;Object type;Object;Detection;Action;User;Information;Hash;First seen here 9/18/2021 2:35:18 PM;Real-time file system protection;file;C:\Users\xxxxxx\AppData\Local\Temp\Z76h0z2s.exe.part;Suspicious Object;cleaned by deleting;xxx-xx\xxx;Event occurred on a file modified by the application: C:\Program Files\Mozilla Firefox\firefox.exe (C4BD2C3764935F306A02DF54090F9435EB922780).;F4053231135502B4E8EA2B4D2E32ABEFE3A08765;9/18/2021 2:16:02 PM -EDIT- I guess I should clarify what I posted above. There is noting wrong with Eset's detection in the Cloudcar test. Rather, it is the speed difference the detection took when using Cloudflare IPv6 DNS64 servers. The connection to Eset cloud servers and resultant detection was almost instantaneous versus a 2 - 4 sec. delay when not using those servers. This translates to a dramatic increase in browsing speed if I can use those servers. Something I can't presently do because of the Eset Push Notification issue with DNS server based DNS64 processing.
  12. Tip - if you delete your credit card info in your US eStore account, there is no way for Eset to perform an auto-renewal.
  13. It's a new day. I have discovered a new networking feature, And of course, Eset networking support borked it! The new and important find is if you are using an IPv6 only network which is the case for my ISP, AT&T Unverse, and using third party IPv6 DNS servers, you should be using DNS servers that fully support DNS64. Again, DNS64 is used to convert IPv4 addresses to IPv6 addresses in a 4-6-4 tunnel on the ISP network. The new find is Cloudflare has such dedicated servers. You can read about this here: https://developers.cloudflare.com/1.1.1.1/ipv6-networks . Great! Set my network connection to those IPv6 addresses and modified Eset's connected network setting likewise. Now for the Eset bork of this capability. The first thing I noticed was it appeared Eset was having trouble establishing a connection on port 8888 likewise on port 443 which is what Push Notifications falls back to. Sure enough, after a half hour Eset displayed the dreaded could not establish a connection to its Push Notifications server. So what is the friggin problem? Eset Push Notifications uses the MQTT protocol designed to create machine-to-machine; i.e. tunnel, connections to IoT devices. It appears this protocol is not compatible with DNS64 which makes sense if you think about it. So once again Eset implements something without thoroughly testing its compatibility with established networking features. @MarcosEset needs to be sending Push Notification traffic via IPv6 to resolve this issue. Assume Eset will have to provide a GUI setting option to receive Push Notifications via IPv6 or IPv4 connection. Or better, if Eset sees an IPv6 connection is established, prefer that over IPv4 for Push Notifications communication.
  14. Well, true to Eset form and unfortunately, Eset dropped monitoring of the IPv6 connection upon resume from sleep mode. See below screen shot. As previously discovered, performing ipconfig /all or showing existing networking details within Win 10, causes Eset to immediately recognize the IPv6 connection.
  15. Well, I'll be damned! It appears AT&T is indeed forwarding IPv6 DNS requests to Cloudflare:
  16. @Marcos, I found a workaround to my IPv6 networking issues and it was by sheer luck. More on that later. First, a brief review of my network situation. My ISP is AT&T Uverse. It is a long known fact that they require you to use their DNS servers. Next up is how IPv6 network and connectivity is established. It is not done via conventional DHCPv6 methods. Note that AT&T Unverse provider routers are programmed to perform the actual IPv6 network setup and connectivity to it at system startup time. First, limited IPv6 connectivity is established. Next the router using ICMPv6 sets up the actual local device IPv6 network and establishes full AT&T IPv6 connectivity to it. This includes, and most important, IPv6 connectivity between AT&T actual IPv6 DNS servers, a dedicated IPv6 relay DNS server, and a dedicated IPv6 local device DNS server as shown in the following diagram: ATT real IPv6 DNS servers <----> reserved AT&T relay DNS server allocated within local device Ethernet IP address range <----> local device IPv6 DNS server controlled by IPv6 gateway. The above takes about 1 - 2 mins after system startup to perform and the IPv6 network and DNS servers to initialize and become fully operational. The above IPv6 network processing co-existed with Eset network processing aside from an occasional "hiccup" until ver. 17; with 17.2.24 totally breaking the processing. My strong suspicion is overly aggressive Eset Network Inspection processing "choking" on the setup of an IPv6 network "on-the-fly." Now for the workaround. Trying over time every solution "know to networking mankind," I thought "what the hell." Let's try Cloudflare IPv6 DNS ervers. To my utter amazement, it worked! At least. so far. Note, I did not change my IPv4 DNS servers to Cloudflare ones. I am now receiving full IPv6 network initialization at boot time resulting in Eset Networking not "going bonkers." All system startup modes; restart, win 10 fast startup, and resume from sleep all work presently w/o issue. My suspicion is AT&T is using IPv4 DNS server settings to determine that their DNS servers are used and allowing third party IPv6 servers. I also believe that the third party IPv6 DNS servers are now acting as the relay DNS servers to the actual AT&T IPv6 DNS servers.
  17. It doesn't matter since Eset blocks the conhost.exe startup from cmd.exe. As such, the script would never proceed to the point where the elevate process executes. Are you stating that this elevate process you're using spawns wscript.exe to run iexplore.exe? Note the way to run iexplore.exe as you are doing is to create a .vbs script containing the following code: https://stackoverflow.com/questions/1340355/launch-programs-whose-path-contains-spaces
  18. I created a .cmd script containing the following: wscript.exe "C:\Program Files\internet Explorer\iexplore.exe" I then created an Eset HIPS rule to block any process startup from cmd.exe. The result was: Time;Application;Operation;Target;Action;Rule;Additional information 9/17/2021 11:00:59 AM;C:\Windows\System32\cmd.exe;Start new application;C:\WINDOWS\System32\Conhost.exe;Blocked;User rule: block child process startup from cmd.exe; It appears you are using this utility: https://code.kliu.org/misc/elevate/ ; i.e. elevate, to bypass UAC and elevate to admin privileges. In any case, that should have no bearing on blocking the conhost.exe startup from cmd.exe.
  19. For installations that employ scripts in daily use, I would recommend that Eset firewall rules to prevent ransomware be deployed: https://support.eset.com/en/kb6132-configure-firewall-rules-for-eset-endpoint-security-to-protect-against-ransomware . At least, the rules that apply to the Windows script processes; i.e. wscript.exe, PowerShell.exe, etc.. Then remove the associated HIPS script rules added. If one is using scripts that by design establish remote connections, it is much easier to create Eset firewall exception rules to allow that activity by IP address. In regards to above, the objective is to prevent 0-day, in-the-wild, ransomware attacks. A number of these attacks use scripts to establish a remote connection to the attacker's C&C server to download the ransomware payload. The payload is then deleted from the targeted network after files are encrypted. This activity's objective to avoid having the payload discovered on the targeted network in effect, ending the ransomware use in future attacks.
  20. I must say that use of Win 10 Pro for this consumer test series is totally inappropriate if RDP based malware was deployed. Most individual consumers use Win 10 Home and RDP in it is disabled by default.
  21. I was referring to Eset Network Protection "borking" my existing local network settings. I have made multiple posting in regards to my unique router hardware issue with Eset networking processing. For a while, my existing settings were stable with no issues. This has changed with ver. 17 with the situation becoming unbearable. I suggest Eset modify the firewall to give an option to only use its firewall for outbound user custom rule processing. All network identification and inbound rule processing would be done by the Win 10 firewall.
  22. To begin, dismhost.exe running from the user temp folder is OK. I monitor dism.exe execution via Eset HIPS and the only thing that starts it on my Win 10 20H2 installation is cleanmgr.exe running from a Microsoft set up scheduled task. The above said, PowerShell usage is "baked into" Windows and is used internally for many OS functions. As such, it is entirely possible Windows internally is initiating the above activity you posted. As I posted previously, I monitor all Powershell.exe startup via Eset HIPS. I also monitor my Windows Powershell event logs and I have multiple daily event log entries showing PowerShell running to perform required system maintenance activities. Also, I have never once received an alert from my Eset HIPS Powershell start up rule in regards to this activity. So however Windows is running Powershell in the background, the Eset HIPS doesn't detect this activity. Bottom line is I have seen enough to state that the recommended Eset HIPS rule to monitor child process startup from Powershell wasn't thoroughly tested and should not be used.
  23. Since the Eset KB article only addresses the ActiveX vulnerability, does Eset also protect against .rtf vulnerabilty?
×
×
  • Create New...