Detecting and Removing "Everyone" Share Permissions on Folders

Hello everyone,

I'm looking to implement a BigFix policy (a Fixlet running as a policy) to enhance security by identifying and correcting inappropriately broad file share permissions on our Windows endpoints.

The goal is two-fold:

Detect all local folder shares where the "Everyone" group has been granted permissions.

Remediate by removing the "Everyone" group from the share permissions list for those identified shares.

1. Detection (Relevance Language)

I'm struggling to construct the proper Relevance expression to accurately identify these shares.

My attempt (or proposed idea) so far: I need to iterate through all active shares and check the associated security descriptor for an Access Control Entry (ACE) that specifically references the "Everyone" security principal.

Could someone provide a robust Relevance statement (using, for example, the share inspector or security descriptor inspector) that will return True only if a machine has at least one local folder share configured with "Everyone" permissions?

2. Remediation (ActionScript)

Once detected, the action should use a command-line tool (like net share or, preferably, PowerShell) to modify the permissions.

I believe using PowerShell is the most reliable method for granular control over share permissions.

Question: What is the best and most robust way to wrap a PowerShell script like the one above into a BigFix ActionScript for seamless execution and reporting? Should I use a temporary .ps1 file or execute the script directly using action shell?

Any examples for the Relevance and the corresponding ActionScript would be highly appreciated!

Thank you!

1 Like
  • Detection (Identify Shares with Everyone permissions)
    There is a forum post that lists some information about this please reference https://forum.bigfix.com/t/shared-folder-permissions/5193/3?u=jstev

    This Relevance will give you a relevance statement that can be used for your Task to so that it will represent a boolean value if a share with a trustee as “everyone” exists.

Exists((names of it whose (exists (account name of trustee of entries of dacls of security descriptors of it) whose (it = "Everyone")) of network shares))

If you would like to create an analysis you can use this to gather information about those shares.

(name of it, (account name of trustee of it, read permissions of it, write permissions of it, execute permissions of it) of entries whose (account name of trustee of it = “Everyone”) of dacls of security descriptors of it) of network shares

  • Remediation (Delete Share)
    This action will build a batch file with a list of net share commands for each returned shared with everyone as a trustee. Then you can have bigfix execute the batch file to delete the shares.

delete __createfile

createfile until eof
{concatenation "%0d%0a" of ("net share %22" & it & "%22 /delete") of (names of it whose (exists (account name of trustee of entries of dacls of security descriptors of it) whose (it = "Everyone")) of network shares)}
eof

delete deleveryoneshares.cmd
copy __createfile deleveryoneshares.cmd
waithidden deleveryoneshares.cmd

5 Likes

Thank you so much for the comments!

Relevance returns (Everyone, True, False, True), which would be the three Boolean values?

q: (name of it, (account name of trustee of it, read permissions of it, write permissions of it, execute permissions of it) of entries whose (account name of trustee of it = "Everyone") of dacls of security descriptors of it) of network shares
I: Current Selection Evaluation
A: MXToolkit, ( Everyone, True, False, True )

The proposed action removes the shared folder, which is allowed. What we don't allow is the "Everyone" permission.

For the latter, we use:

waithidden powershell -command "Revoke-SmbShareAccess 'SHARED_FOLDER' -AccountName 'Everyone' -Force"
waithidden powershell -command "Revoke-SmbShareAccess 'SHARED_FOLDER' -AccountName 'Everyone' -Force"

A few tweaks to @Jstev’s code that may suit your use case

Relevance
exists network shares whose (exists trustee whose (it as string = "Everyone") of entries of dacls of security descriptors of it)

Action

createfile until EOF
{concatenation "%0d%0a" of ("Revoke-SmbShareAccess '" & it & "' -AccountName 'Everyone' -Force") of (names of network shares whose (exists trustee whose (it as string = "Everyone") of entries of dacls of security descriptors of it))}
EOF

delete removeeveryonefromsmb.ps1
copy __createfile removeeveryonefromsmb.ps1
waithidden powershell -file removeeveryonefromsmb.ps1

Before executing the PS1, maybe run in the fixletdebuger and look in the “C:\Program Files (x86)\BigFix Enterprise\BES Client__BESData__FixletDebugger” folder for the ”removeeveryonefromsmb.ps1” and verify the format and detected shares match your requirements.

My apologies, I interpreted it as you wanted to remove the share if it was shared with everyone, but it sounds like you just want to remove the permission. You can do the same thing to build a powershell script to execute or you can use the same logic and create a batch file which executes individual powershell scripts. Either way should work.delete __createfile

delete __createfile

createfile until eof{concatenation "%0d%0a" of ("powershell -command %22Revoke-SmbShareAccess %27" & it & "%27 -AccountName %27Everyone%27 -Force%22") of (names of it whose (exists (account name of trustee of entries of dacls of security descriptors of it) whose (it = "Everyone")) of network shares)}eof

delete deleveryoneshares.cmdcopy __createfile deleveryoneshares.cmdwaithidden deleveryoneshares.cmd

Regarding your question about the relevance statement and what the Boolean values mean

(name of it, (account name of trustee of it, read permissions of it, write permissions of it, execute permissions of it) of entries whose (account name of trustee of it = "Everyone") of dacls of security descriptors of it) of network shares
I: Current Selection Evaluation
A: MXToolkit (Share name), ( Everyone (trustee), True (read permissions), False (write permissions), True (execute permissions) )

The first value is the share name, The second value is the trustee (which user or group has the permission shared to it), the third value is a true or false shows whether the trustee has read permissions to the share, the fourth shows whether the trustee has write permissions to the share, and the fifth shows whether the trustee has execute permissions on the share.

1 Like

Excellent, it worked perfectly!

Question: Should I first create a Fixlet and then execute an action, and the important part is execution... is this correct? What would be the best way?

If I were having to perform this task, I’d first be thinking about creating a property to audit shares so I have visibility of what will be impacted. Depending on your environment, you may have systems with admin shares, eg print$.

names of network shares whose (exists trustee whose (it as string = "Everyone") of entries of dacls of security descriptors of it)

I’d also create the fixlet so relevant systems start to report in. Once I was happy that my environment would not be adversely impacted and I’d taken suitable due diligence to avoid unknown situations and only then would I think about deploying an action. I would possible also think about leaving data on the endpoints, created by the action, so I could track what shares have had “Everyone” removed and perhaps a counter to show how many times a share has been “corrected”. This would bring a visibility of endpoint where perhaps people or process are re-instating the undesired permission and could be a simple registry key/value.

As for the action, I’d probablay think about having this as a policy action so re-apply while relevant with a suitable wait duration. Probablay no less than 1hr, to avoid potential for rapid re-run if the share failed to get reset for whatever reason, and set it with a re-try on failure for at least 3 times just in case the action fails and I want to see what systems have failed vs become relevant again. Also, as actions may be stopped and re-deployed following fixlet changes, I would not rely on the action stats in case I had to make changes to cater for edge case situations, hence leaving indicators on the endpoint mentioned above.

1 Like

Excuse my ignorance, but how can I view the remediation statistics for the actions taken?

We've run several tests and everything is working perfectly, which is exactly what we wanted!

However, it would be very helpful to have traceability of the shared folders where the "everyone" permission was removed and how many times it was done. Is this possible? How can I achieve this?

As part of the task you would need to create a log file or something each time it ran then you can create a relevance statement as an analysis that reports on the lines of that log file.

Do you think it's possible to have a whitelist of shared folders?

I can think of two options:

  1. Applying relevance at a general level to all endpoints.
  2. Creating a registry key on each endpoint with folder names separated by commas (","), and having relevance evaluate it.

The first option is more general and requires less maintenance.
The second is more specific but requires more maintenance.

What do you think? Could it be designed?

Thanks!

I suspect the approach will depend on your environment and the number of endpoints with shares, if they are servers or workstations and if there are any naming standard for shares that allow for an approach that has less admin overhead to maintain.

If there isn’t a naming standard, might not be a bad idea to consider one as then you could have the option to exclude any share that has a certain name and can apply at the global level, aka your option 1. Option 2 would also be plausible though that would mean someone needs to maintain data on each endpoint for the shares to exclude, though this can of course be inspected with relevance to make the permission changes dynamic to each endpoint.

There are certainly options that Bigfix could facilitate, its down to how creative can one be. Certainly using a combo of ActionScript with relevance substitution to create a PowerShell script tuned to the environment at the endpoint is the approach I’d be thinking of.