What are the pros and cons of disabling admin shares for security reasons?

William Fulks
William Fulks used Ask the Experts™
on
My workplace recently got hit with a variant of the Emotet trojan and we found that it spread itself over the network via the default admin shares in Windows. As part of the disinfection process, the first thing we do is cut off the admin shares and restart, then clean up the PC.

My question is regarding what other issues we might expect to find after disabling those admin shares?

I know from a tech support standpoint it makes our job in IT a little harder because we can't just open \\pcname\c$ any more. So far, we have one legacy application (Dictaphone) that is throwing file access errors after turning off the shares. Another user says they are unable to scan from their Brother multifunction printer. We have a few hundred PC's on our network and they are all running either Windows 10 or Windows 7.

Since enabling them is a default Windows setting, we are concerned about the long term effects of this like crippling some application functions, etc. I wanted to throw this question out there to the experts to see if you know of background processes or services that utilize the shares and how much more trouble we might be creating for ourselves.
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Technical Specialist
Awarded 2017
Distinguished Expert 2018
Commented:
Do not disable Admin shares. You need to secure the administrative accounts on these devices

Rather consider the following

Enable Windows Firewall

Windows Firewall as Code
https://www.experts-exchange.com/articles/31687/Windows-Firewall-as-Code.html

Protect the built-in administrator password

Active Directory - Securely Set Local Account Passwords
https://www.experts-exchange.com/articles/31583/Active-Directory-Securely-Set-Local-Account-Passwords.html

Since enabling them is a default Windows setting, we are concerned about the long term effects of this like crippling some application functions, etc. I wanted to throw this question out there to the experts to see if you know of background processes or services that utilize the shares and how much more trouble we might be creating for ourselves.
Most software/computer management systems rely on admin$ shares

I know from a tech support standpoint it makes our job in IT a little harder because we can't just open \\pcname\c$ any more.
Hopefully using a separate admin account or tier isolate?

Active Directory - Simple Tier Isolation
https://www.experts-exchange.com/articles/29515/Active-Directory-Simple-Tier-Isolation.html

Securing Active Directory Administrators Groups
https://www.experts-exchange.com/articles/29596/Securing-Active-Directory-Administrators-Groups.html

My workplace recently got hit with a variant of the Emotet trojan and we found that it spread itself over the network via the default admin shares in Windows.
Your environment is over-permission setup delegation

Delegation the proper way
https://www.experts-exchange.com/articles/29366/Delegation-the-proper-way.html
JohnBusiness Consultant (Owner)
Most Valuable Expert 2012
Expert of the Year 2018

Commented:
We do not disable Admin shares but no one except server Administrators can access them. All users use folder shares and all our applications work within these rules
William FulksSystems Analyst & Webmaster

Author

Commented:
I do agree about the over-permission setup. We are doing a full review of how we're configured and making some changes, as well as investing in better protection software. The weakest link is still the end user. People just won't listen when we tell them not to open everything they get in their inbox!
Rowby Goren Makes an Impact on Screen and Online

Learn about longtime user Rowby Goren and his great contributions to the site. We explore his method for posing questions that are likely to yield a solution, and take a look at how his career transformed from a Hollywood writer to a website entrepreneur.

JohnBusiness Consultant (Owner)
Most Valuable Expert 2012
Expert of the Year 2018

Commented:
Maybe some additional user training. Employees where we are consultants tend to listen and we do not have a lot of difficulty
William FulksSystems Analyst & Webmaster

Author

Commented:
I am putting a class together, actually.

The main reason we disabled admin shares was to treat this infection. The alternative would be to shut down the entire network and go case by case, and that simply wasn't an option.

Emotet hijacks the admin password and uses it to spread via the admin shares, so it was already system-wide by the time we realized what was happening.
Shaun VermaakTechnical Specialist
Awarded 2017
Distinguished Expert 2018

Commented:
The weakest link is still the end user. People just won't listen when we tell them not to open everything they get in their inbox!
I don't share this sentiment. These kinds of attack can easily be avoided and in the worst case be isolated.

Emotet hijacks the admin password
Look into LAPS or the links I shared to my articles above.
William FulksSystems Analyst & Webmaster

Author

Commented:
Shaun, I am reading through your articles and sharing them with our senior network/server guys. Good stuff!
Distinguished Expert 2018

Commented:
There is no need for accounts that are admin everywhere. Simply no need. Infections like these wouldn't happen if people understood that.
The account to do administrative tasks should be unique per machine.
Microsoft made a mistake by nesting the domain admin group into the local admin group, in my opinion. It led to people actually using it on the endpoints while that is one of the worst things an admin could ever do.
Read https://www.experts-exchange.com/articles/18180/A-concept-for-safe-user-support.html

Administrative shares are no risk.
JohnBusiness Consultant (Owner)
Most Valuable Expert 2012
Expert of the Year 2018

Commented:
We do NOT let users be admins . Bad practice and we do not allow it
DevAdminSystem Engineer | .NET Developer | Microsoft MVP | Technical Speaker

Commented:
William FulksSystems Analyst & Webmaster

Author

Commented:
Ermanno, that article applies to Server 2003 and XP.
Distinguished Expert 2018

Commented:
Now I have more time to write:

Normally, why could these shares even be a problem, what went wrong at your workplace? You wrote, that the malware accessed admin shares. Well, how can it do that, admin shares are not accessible by non-admins in the first place and the file sharing ports are even closed by default.
So you have made two mistakes together:
A execute malware as an account that had administrative permissions on more than one computer
B open the file sharing ports

A - I wrote about that already and linked an article that shows a way to eliminate the central cause for this, which is a flawed concept of how endpoint administration should be run
B should only be needed in a peer2peer network with no central server. Else, you would never have to do that, the ports would remain closed and that malware wouldn't be able to spread anywhere.

About c$: when would we need c$ in the first place? We would need it, if we
-use psexec or other remote shell applications to execute scripts against remote machines
-we fondle with files on remote machines
-we would like to be able to query computers using any kind of inventory software

These 3 use cases, although they might seem familiar and vital for some of you, should be avoided, if security matters.

->scripts can be run as scheduled tasks that we deploy using GPOs
->files can be dealt with using scripts or group policy preferences, or, if need be, using remote desktop sessions
->inventory software or scripts should again be run at the client and not be initiated from a remote machine

If you have questions, feel free to ask. Feedback is needed.
DevAdminSystem Engineer | .NET Developer | Microsoft MVP | Technical Speaker

Commented:
William I  know that the KB  applies to Server 2003 and XP but its validity is of a general nature, the advice not to disable these shares was then reiterated in the KB954422 https://support.microsoft.com/fi-fi/help/954422/how-to-remove-administrative-shares-in-windows-server-2008:

"Microsoft recommends that you not delete or modify these special shared resources."

The reason for this advice is that this shares are special hidden administrative shares that administrators, programs, and services can use to manage the computer environment or network.

Which means that some software may lawfully request the existence of such shares to work, an example is Veeam Backup & Replication, see for example the KB 1230 of Veeam https://www.veeam.com/kb1230:

"Make sure you can connect to the admin share (for example, \\Server Name\admin$) with the same credentials as provided to Veeam Backup & Replication for VSS."

I totally agree with you in using the most restrictive security policies possible, but as well as others who have written you can put in place several other protective measures, look also https://activedirectorypro.com/active-directory-security-best-practices/.

For example in the Hardening Microsoft Windows 10 version 1709 Workstations of ACSC https://www.acsc.gov.au/publications/protect/Hardening_Win10.pdf they not suggest to disable the admin shares but they suggest that  anonymous connections to workstations should be disabled:

"An adversary can use anonymous connections to gather information about the state of workstations. Information that can be gathered from anonymous connections (i.e. using the net use command to connect to the IPC$ share) can include lists of users and groups, SIDs for accounts, lists of shares, workstation policies, operating system versions and patch levels. To reduce this risk, anonymous connections to workstations should be disabled."

Not even in EUD Security Guidance: Windows 10 - 1803 of the NCSC (https://www.ncsc.gov.uk/guidance/eud-security-guidance-windows-10-1803) there is the indication to disable the admin shares

Concluding if the disabling you could find yourself in the situation of having to then rehabilitate them to make a program or a service work
William FulksSystems Analyst & Webmaster

Author

Commented:
The person who executed the malware did not have admin rights. From what I understand about this variant of Emotet, it hijacks saved passwords and we think it grabbed either the local or domain admin account (both of which had been used to sign into the PC at one time during configuration) and used that to go across the network.

I've seen malware that only affected one PC do things that require admin rights, despite the user not having them.
Distinguished Expert 2018

Commented:
Non-admins cannot Hijack passwords of other users. They simply can't.
There are exploits of various kinds, but on a patched system none of them would have enabled a non-admin to let a malware harvest passwords. Passwords of users that are admin on more than one machine, as in domain admin or support admin account, should never be even hashed on client computers. There is also no explanation why those should be saved on any client machines.

In other words: whatever you find out to be the reason - I am 99,9% sure it is due to grave misbehavior of the admin team.
William FulksSystems Analyst & Webmaster

Author

Commented:
Thanks everyone for the comments! I had a long weekend and haven't been able to check back in on this, but I will assign points today.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial