Access To Admin Shares

[itman 1,659]

Win 10 x(64) Home 1803, Eset IS 11.2.49

A while back, I posted about this. I basically closed the thread since I thought I was causing the logging activity by accessing the Remote Connections feature in Windows. Well, that is not the case now and I am seeing these events periodically in my Eset Networking log. As the below screen shot shows, the activity is originating from the Win System process with to/from IP addresses of localhost connections. Checked my Win host file and no modifications made to it.

In other words, the activity looks legit and I don't know why Eset IDS's prevent access to admin shares protection is being triggered. The only thing noteworthy in this regard is Eset was recently(last month) installed on a reset ver. of Win 10 1803. At that time SMBv1 client was enabled; due to Microsoft's dis-security choice to do so on clean installations. Once I realized this, I uninstalled it via Win program features option. Suspect that somehow this borked  Eset's IDS and it still believes SMBv1 is active? 

 

[itman 1,659]

Just noticed something.

Re-checked SMBv1 status in Win Features. Although I had previously uninstalled SMBv1 - client and auto disabling, SMBv1 still showed partially installed. So I totally uninstalled it.

Next when I reinstalled MS Office Pro 2010, I got lazy and let it install everything. So I just uninstalled SharePoint thinking that also might be the "culprit."   

Will report back if the IDS alerts reappear.

[itman 1,659]

Prior noted mitigations didn't stop the admin share access log entries. Received 22 of them at 7:09 PM last night.

To begin with, I am at a loss on how to find what is causing this. I could create an Eset firewall rule to block all inbound port 445 traffic and move it to the top of the rule set. However, I believe IDS detections take precedence over firewall detections?

Also, I am questioning if this is a legit IDS detection. Eset's own default firewall rule of "allow all traffic with the computer" would have allowed the localhost connection activity.

@Marcos, believe we have another ver. 11.2.49 bug here.

Edited August 7, 2018 by itman

[itman 1,659]

I finally have been able to stop the stop the above admin share access alerts. This is going to be a long posting.

A bit of research yielded that there is a rather obscure and not widely published way to allow access to the admin shares by virtually any remote server. It involves locally on the device creating a localhost proxy server to access the admin shares. Connection-wise it manifests exactly as shown in my above Eset Network log screen shot. The minute I read that, I immediately disabled the WinRM service. Note that in my previous Win 10 1803 installation which was originally a Win 7 to 10 upgrade, I always had WinRM disabled which might be a partial explanation why this Eset admin share access blocking was never evidenced.

On the next subsequent boot and monitoring network connection activity, it was clearly obvious something was amiss with many connections being dropped, etc.. Windows event log showed the following; Windows Update connection failed, Network List Manager report no connectivity, and Win Metadata and Internet  Services could not establish. Researching this yielded Windows Security Center Device Health and Maintenance baloney checks for updated device drivers and the like at boot time. Apparently, Win 10 1803 enables Win Remote Management service to do so. The workaround for this since I am using a wired Ethernet connection is to set the wired autoconfig service to automatic eliminating the aforementioned startup errors. Only the Microsoft "God" knows how it was originally establishing connections via Win Remote Management at boot time.

I would like to state that Microsoft established the admin share localhost proxy in all this remote connection crap. The problem is that the Eset Network log entries for such activity didn't occur at boot time nor at any other Win Update time. The logging activity occurred at random times. All this stealth remote access activity by Microsoft though does lead me to speculate that there is a major vulnerability in Win 10 1803 that can allow an attacker to set up a localhost proxy to access the admin shares.

Edited August 8, 2018 by itman