Yesterday, Rob discussed Collecting Workstation / Software Inventory Several Ways, including PowerShell. I don't spend nearly as much time as I used to going hands-on with systems, but everytime I need to solve a problem on Windows hosts, PowerShell is there for me. Sadly my PowerShell fu is weak as compared to where I'd like it to be, but as an assimilated minion (1 of 7) of the Redmond Empire I have the benefit of many resources. Luckily much content is publicly available and you have Lee Holmes to help you with PowerShell mastery. Lee really is the man on the PowerShell front, you'll note his Windows PowerShell Pocket Reference in it's rightful place on my desk.

Amongst my many pet peeves are overly permissive file shares with the likes of Everyone, Domain Users, Domain Computers, and Authenticated Users granted unfettered access. No one every leaves PII, config files, and user name password lists on a share, right? And no one with unauthorized or inappropriate access ever makes their way on to enterprise networks, right? Sure, Russ, sure. :-) Back in the real world, where would we be without an entire industry sector dedicated to DLP (data leak prevention solutions)? Oh yeah, probably in a world with less SPAM and cold calls, but I digress.

Step 1: We admitted we were powerless over misconfigurationâ??that our networks had become unmanageable.

Step 2: Came to believe that PowerShell could restore us to sanity.

I have fallen deeply, unmanageably, irrevocably in love with the Revoke-SmbShareAccess cmdlet available on Windows Server 2012 R2 and Windows 8.1 systems (Windows PowerShell 4.0). Having tried to solve this issue with the likes of Set-Acl and requiring serious counseling thereafter, Revoke-SmbShareAccess (and it's friends Block, Unblock, Get, and Grant) allowed me to do in three lines what could not be otherwise done easily or elegantly. 

"The Revoke-SmbShareAccess cmdlet removes all of the allow access control entries (ACEs) for a trustee from the security descriptor of the Server Message Block (SMB) share." Sweet!

Examples? You bet. The terms share and server are used generically here; you'll need to apply the appropriate nomenclature.

Local (single share, single account):
Revoke-SmbShareAccess -Name share -AccountName "Everyone" -force

Local (single share, multiple accounts):
Revoke-SmbShareAccess -Name share -AccountName "Everyone","Domain Users","Domain Computers","Authenticated Users" -force

Remote (single share, single account):
Revoke-SmbShareAccess -name share -CimSession server -AccountName Everyone -Force

Remote (single share, multiple accounts):
Revoke-SmbShareAccess -name share -CimSession server -AccountName "Everyone","Authenticated Users","Domain Users","Domain Computers" -Force

For Remote (multiple share, multiple servers, multiple accounts), where you want to use a list of servers and/or shares you can build a small script and define variables that pull from text lists.

$servers = Get-Content -Path C:\powershell\data\servers.txt
$shares = Get-Content -Path C:\powershell\data\shares.txt
Revoke-SmbShareAccess -name $shares -CimSession $servers -AccountName "Everyone","Authenticated Users","Domain Users","Domain Computers" -Force

Obviously, you'll want to tune, experiment, and optimize but hopefully this may help get you started on the cleanup process. You'll want to overly communicate with your user base advising them to create security groups granting share access only to those people (and systems) embedded in the appropriate group. Don't just go removing these permissions without an awareness campaign. You don't want that call: "You broke my entire service when you removed Everyone share permissions!" Argh. Remember also the nuances (they are many) between share permissions and NTFS permissions.

Good luck and cheers!

Russ McRee | @holisticinfosec