File sharing may seem commonplace and trivial, such as dropping a document into a folder on a team's shared storage area or emailing someone a URL to access files using an online file storage service or cloud service.
What may seem normal to you, could in fact be a significant vulnerability for your organization due to the nature of the permissions assigned, encryption applied and levels of access control, all of which can each act as a single point of failure that could allow an unauthorized person access to sensitive information.
Common examples of this would include:
1. Misconfigured permissions — "Anyone" or "All" access granted versus specified users.
2. Exposed shares — SMB/NFS shares being published publicly on the internet or S3 buckets allowing public read access.
3. Sensitive data being stored in shared folders — Passwords, credentials, customer information, backup files or scripts.
4. The fisherman-eats-the-fish chain reaction — an attacker discovers the exposed shared file, steals credentials, moves laterally and deploys ransomware.
Most confirmed incidents of data breaches occur through an error of this nature, typically beginning with one open share or exposed shared folder being discovered and used by a criminal to steal credentials leading to the compromise of the entire organization’s network.
According to reports published from 2025-26, misconfiguration of both cloud storage and shared drives resulted in global leaks of billions of records and provided a point of entry for many ransomware attacks and insider-like access to sensitive information without any exploitation occurring.
Real-World Examples from Recent Breaches
Breaches from 2024 to 2025 included:
1. Cloud storage buckets with unrestricted public access were found to contain 10's of Terabytes worth of confidential information (ie. customer client lists, usernames and passwords, backups) that had ACLs set to public settings rather than authenticated access methods.
2. Within Internal file servers, improperly configured SMB shares (shares with excessive access permissions) served as an initial access point for attackers who listed out the available shares laundered hashes and credential information and escalated their privilege level.
3. Backups stored in a designated shared directory were improperly configured due to faulty backup tooling and therefore exposed API keys, source codes, and decompiled binary files on the web.
4. Third-party vendor businesses that failed to establish appropriate access controls exposed sensitive business documents leading to breaches affecting downstream clients (supply chain breach).
5. Ransomware crime groups used unprotected shares to deposit ransomware and/or to delete data from the files.
None of this was new technology; it was simple permission-related mistakes that were made worse by poor hygiene practices.
Practical Tools to Detect & Prevent Shared File Risks
Identifying and managing the risks of shared files can be accomplished by using free/open-source tools for small business and/or home environments or awareness testing.
1. BloodHound Community Edition (Free for AD) – Maps the permissions on AD and SMB shares. Identifies where information may be over-privileged in the context of shares. There are two methods for using BloodHound: install the application and collect data using SharpHound, or use the BloodHound visualizer to create links between high-value targets and their corresponding permissions.
2. S3Scanner/BucketStream (Free for AWS S3) – Scans for publicly accessible "buckets". Provides the S3Scanner command: 's3scanner --buckets-file buckets.txt --dump' to verify buckets and download them if public.
3. nmap + smbclient (Free for Network shares) – Discovers and tests for Network Share via SMB. Use the following command to perform a scan for public SMB User Shares on a subnet: nmap -p 445 --script smb-enum-shares 192.168.1.0/24
4. PowerShell / cmd Scripts (Built-in Windows) - Displays all local shares and the permissions associated with each.
5. Graylog / ELK Stack (Free Tier) - Monitors file access logs for suspicious activity.
6. TruffleHog or Git-Secrets – Used to scan repositories/ files in an effort to discover secrets.
Practical Code Examples: Checking & Securing Shares
1. Windows - Using Powershell, You Can Show All Available Shares
Powershell command for list of all shares:
Get-SmbShare | Select Name, Path, Description, ScopeName
Powershell command for checking permissions on a share (put Share Name in place of ShareName):
Get-SmbShareAccess -Name "ShareName" | Format-Table AccountName, AccessControlType, AccessRight
Powershell command to remove "Everyone" access (if applicable):
Revoke-SmbShareAccess -Name "ShareName" -AccountName "Everyone" -Force
Grant-SmbShareAccess -Name "ShareName" -AccountName "Domain\Users" -AccessRight Read -Force
2. Linux - To View Shared Folders via NFS/SMB
List of NFS exported directories:
Bash
exportfs -v
showmount -e localhost
Check SMB (Samba) shares:
Bash
testparm -s | grep -A 10 '\[' # Shows share configs
Secure example (Samba config snippet – /etc/samba/smb.conf):
ini
[SecureShare]
path = /srv/secure
valid users = @groupname
read only = no
browsable = yes
create mask = 0664
directory mask = 0775
force group = groupname
Restart Samba after changes: sudo systemctl restart smbd
3. AWS Command Line Interface (CLI) - To Check if your S3 Buckets are Publicly Accessible
List S3 buckets + List ACLs:
Bash
aws s3api list-buckets --query "Buckets[].Name"
aws s3api get-bucket-acl --bucket your-bucket-name
Block public access (recommended command):
Bash
aws s3api put-public-access-block --bucket your-bucket-name --public-access-block-configuration "BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true"
4. Basic script using Python and Boto3 library for scanning S3 buckets for possible exposure:
import boto3
from botocore.exceptions import ClientError
s3 = boto3.client('s3')
def check_bucket(bucket_name):
try:
acl = s3.get_bucket_acl(Bucket=bucket_name)
for grant in acl['Grants']:
if 'URI' in grant['Grantee'] and 'AllUsers' in grant['Grantee']['URI']:
print(f"Bucket {bucket_name} is PUBLIC!")
except ClientError as e:
print(f"Access denied or error on {bucket_name}: {e}")
# Example: check known bucket
check_bucket('your-company-backups')
Run with AWS credentials configured.
Preventative Measures:
1. Use a least-privilege security model. Never authorize access to "Everyone," or "Public." Assign users their activity group's access levels via "groups"/"roles."
2. Enable Access Logs so that an administrator can monitor the users who have accessed files.
3. Encrypted data at rest and in transit using AES-256 for electronic file storage.
4. Regularly scan for vulnerabilities by running Nmap or s3scanner on a weekly basis in smaller environments.
5. Multi-Factor Authentication and Just-in-Time access should be enabled for the use of Cloud File Shares.
6. Back Up Data Offline. You should never share "live" backups with other customers.
7. Educate Staff regarding the risk of sharing Sensitive Information with the General Public.
Conclusion:
"A Shared File" becomes "an Incident" when access can be misconfigured , compromising convenience and creating exposure. Nmap, AWS CLI and PowerShell can be utilized to quickly identify Misconfigured Access.
Code and Configuration can be secured by revoking access through "Broad Access" and by using "tokens"/"groups" Implementing the above measures can substantially reduce the risk of a breach to most companies. Once in place, companies should Treat "A Shared File" as "Locked Doors" and not as "Open Windows."
