itman

Well, I'll be damned! It appears AT&T is indeed forwarding IPv6 DNS requests to Cloudflare:

@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.

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

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.

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.

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.

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.

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.

Since the Eset KB article only addresses the ActiveX vulnerability, does Eset also protect against .rtf vulnerabilty?

What I am observing is there is a bigger issue. Appears Eset is not properly initializing coming out of Win 10 fast startup mode. I am having issues with Eset Network Protection; namely Network Inspection not working properly.

Let's review how to resolve this. First, note that HIPS allow rules take precedence over ask or block rules. The conhost.exe startup issue resolution from powershell.exe was discussed in the thread you link in your posted. A HIPS allow rule would have to be created to allow conhost.exe startup from powershell.exe. Likewise, I don't see a major security issue allowing powershell.exe starting ipconfig. As far as cmd.exe startup from cscript.exe, it will create a security vulnerability. The problem here is the "stone age" feature capability of the Eset HIPS. One missing feature is the direct monitoring of script execution. That is the capability to create for example, a rule to allow cscript.exe to execute a given script by name. This could be facilitate by allowing command line specification feature; e.g. wscript.exe scriptname.ws. Note that Eset allow action is global in nature. In this case, the allow of the script execution, if possible, would allow cmd.exe within the script to also be executed. -EDIT- Also the Eset HIPS needs whitelist capability in regards to scripts. Any scripts listed there would be allowed to run regardless of existing HIPS block rules in regards to their associated script engine executable's.

https://www.bleepingcomputer.com/news/microsoft/microsoft-fixes-windows-cve-2021-40444-mshtml-zero-day-bug/

I guess I am the lucky one since this is the first time it every happened to me. Also, I would be aware of this malfunction since at least one of my HIPS ask rules triggers daily. BTW - my prior noted HIPS bork incident was much more serious. The HIPS was not injecting its ebehmoni.dll and/or ebehmonl.dll Deep Behavior Inspection .dlls into select processes; e.g. cmd.exe, that it monitors. This required a re-install to fix.

Eset real-time PUA and Suspicious detection settings are shown in the below screen shot. For Eset to detect these, the setting must be set to a non-Off setting:

Per the above TrustedSec article I linked to, the below is indicative of malicious conhost.exe usage. Eset HIPS rules do not have command line specification capability, so there is no way to monitor for its usage: