The Forgotten Attack Surface: File Shares

When organizations think about internal security, Active Directory usually gets most of the attention, and for good reason: it presents a massive attack surface. Identity sits at the center of almost every meaningful attack chain we see during internal penetration tests. After years of assessments, though, we are still consistently surprised by what turns up once we start enumerating file shares.

We have assessed organizations with strong passwords, well-managed Active Directory, legacy protocols disabled, and generally solid security practices, only to find years' worth of sensitive data sitting on shares that nearly every domain user could access. In some environments, we have found sensitive shares that did not even require a valid Active Directory account to access.

Some of the most valuable information we uncover sits in plain sight on a Windows file share that nobody has reviewed in years and does not require a sophisticated exploit or obscure Active Directory weakness to access. If you've never walked through your own file shares from the perspective of a low-privileged domain user, I recommend this exercise, as you may be surprised by what you uncover.

What Testers Are Actually Looking For

When we enumerate file shares during an assessment, we are not just browsing for interesting files. We are trying to understand how the organization operates, where privileged accounts live, what servers and applications exist, where credentials are likely stored, and which systems we can reach next.

A single spreadsheet can provide a wealth of information, helping us map out the attack surface without running noisy scans; a PowerShell script can provide credentials that lead to lateral movement or domain privilege escalation; and a comprehensive network diagram can eliminate hours of reconnaissance. The real risk here is whether a given file gives an attacker the context, credentials, or operational knowledge to move further and faster than they otherwise could without that information in hand.

What We Consistently Find

One of the most common configurations we encounter is a departmental share where Authenticated Users or Domain Users are granted read access to the entire directory tree. The original intent may have been collaboration, which seemed reasonable at the time (maybe when it was a much smaller company). Years later, those same permissions still exist, but access now extends to HR records, finance folders, legal documents, executive communications, and engineering repositories that were never meant to be readable by the entire domain.

We have pulled payroll data, employee performance reviews, salary information, passport scans, tax documents, acquisition planning materials, legal correspondence, and source code from departmental shares in environments where the Active Directory hardening was otherwise solid. The share permissions had just never been revisited after the initial setup.

Configuration files are some of the most useful files we find, and they appear more often than you'd think. Web.config files, appsettings.json, unattend.xml, various XML and INI files, and anything containing a SQL connection string regularly contain database credentials, service account passwords, API keys, internal application URLs, and occasionally encryption keys in plain text. Below is a mock web.config file showing the type of database connection string we typically uncover:

<?xml version="1.0" encoding="utf-8"?>
<configuration>

  <!-- Connection Strings Section -->
  <connectionStrings>
    <!-- Removes inherited connection strings to prevent conflicts -->
    <clear />

    <!-- Example 1: SQL Server Authentication (Username & Password) -->
    <add name="SqlAuthConnection" 
         connectionString="Server=myServerAddress;Database=myDataBase;User Id=myUsername;Password=myPassword;" 
         providerName="System.Data.SqlClient" />

    <!-- Example 2: Windows Authentication (Integrated Security) -->
    <add name="WindowsAuthConnection" 
         connectionString="Data Source=localhost\SQLEXPRESS;Initial Catalog=myDataBase;Integrated Security=True;" 
         providerName="System.Data.SqlClient" />
  </connectionStrings>

  <system.web>
    <compilation debug="true" targetFramework="4.8" />
    <httpRuntime targetFramework="4.8" />
  </system.web>
  
</configuration>

Legacy PowerShell, VBScript, and batch files stored on file shares are also a great source of credentials. Deployment scripts tend to contain passwords used during initial setup that were never rotated. Scheduled task scripts often include passwords passed as arguments or stored in variables at the top of the file. Mapped drive scripts can contain credentials for service accounts with significant access across the environment. The especially dangerous situation is a script that was created years ago, still works, and runs automatically, so nobody touches it, either because it's forgotten or because of a fear of knocking something offline that many employees rely on. The password inside it may not have been changed for years, if ever, because the script could break if it were.

Backup files are another common finding. We have encountered Hyper-V exports, VMware images, Windows Server Backup sets, and SQL database backups stored on shares accessible to low-privilege domain users. In some cases, we have been able to download an entire virtual machine image over the network, mount it offline, and extract local administrator credentials or domain-joined system data without ever touching the running machine. SQL backups can contain user tables, application data, or hashed credentials in locations that the database server itself would require specific application credentials to access. Having access to the backup file bypasses all of that.

Documentation can be just as useful. Network diagrams, firewall rule exports, IP address spreadsheets, VPN configuration guides, vendor documentation, disaster recovery plans, and password spreadsheets all show up regularly on file shares. One of the more useful files we have found during an engagement was an IT asset inventory spreadsheet created for an auditor. It listed every server, its IP address, operating system, role, and criticality rating. This information proved extremely useful for identifying key systems and helped establish the initial foothold that led to domain compromise through a chain of attacks.

Writable shares create a different kind of problem that can lead to unintended consequences. When a low-privileged user can write to a share, an attacker can plant a malicious SCF, URL, or LNK file that causes users who visit the share to unknowingly authenticate to an attacker-controlled host, capturing NTLMv2 hashes for offline cracking or for use in NTLM-relay attacks. Software distribution shares, upload locations, and staging folders are frequent targets for these types of attacks since they commonly have broad write access privileges assigned.

The domain controller SYSVOL share deserves its own mention because every domain user can read it by default. Group Policy Preference (GPP) files such as Groups.xml, ScheduledTasks.xml, Services.xml, DataSources.xml, and Drives.xml can still contain leftover cpassword values. Microsoft published the AES key used to encrypt those values in 2012, so any domain user can decrypt them. MS14-025 stopped administrators from creating new GPP passwords through the GUI, but it did not remove existing ones. Registry.xml files in the SYSVOL share can also contain autologon settings that follow the same encryption scheme, or even be present in plaintext.

How File Shares Get Forgotten

File shares rarely become insecure through a single bad decision. The more common story is years of small, reasonable changes stacking up. A department needs a new share. A project needs temporary access for a contractor. A new group gets added to the permissions. Employees change roles or leave, and home drives get orphaned. Servers are migrated to SharePoint or a NAS appliance, but the original file server stays online because nobody is quite sure what still depends on it.

Each decision may make sense in isolation, but fast-forward 5 or 10 years, and nobody is quite sure who still needs access to what, until the file share estate is a sprawling mess that no one has the time to tackle, partly because administrators often lack easy-to-use tooling.

Direct permissions, inherited permissions, nested group memberships, and leftover project access all layer on top of each other, which makes cleanup a daunting task. Organizations may know which groups sit on a share at the top level, but they rarely know how many users end up with access through three or four levels of nesting, or which shares still grant access to accounts belonging to people who left years ago. The moment someone starts digging into a large file server, the scope of the problem becomes obvious, and the fear of breaking something that still depends on a folder makes it easier to stop than to continue. Overly broad permissions are left alone, and the access footprint keeps growing.

We have seen entire file servers remain online long after an organization moved its data to SharePoint or another storage platform. The new environment may be properly secured while the old server is still reachable, with years of historical data sitting on it. In a few assessments, the most sensitive data we found throughout the engagement was stored on a server the organization considered decommissioned.

It Is Not Always Technical Data

Users frequently treat home drives and departmental shares like personal storage, sometimes because the company never provided an alternative and sometimes simply out of habit. During assessments, we have encountered tax returns, passport scans, banking information, medical documents, resumes, password spreadsheets covering both personal and company accounts, family photos, personal email archives, and plenty of other files that have no business sitting on a corporate file server.

None of this leads directly to Domain Admin, but an attacker does not only care about Domain Admin. Personal information, internal business documents, customer data, contracts, network diagrams, and other sensitive files can still make a compromise considerably more damaging. An attacker who has already achieved their primary objective can use that kind of personal data for targeted phishing, identity-based attacks, or simply causing harm to people whose information was never supposed to be there.

What Administrators Should Prioritize

You do not have to clean up every file server all at once. Focus first on the shares that pose the biggest risks. These include important departmental shares in HR, Finance, Legal, IT, and executive areas; shares open to Everyone, Authenticated Users, Domain Users, anonymous or guest accounts; shares where users with low privileges can write files, such as software distribution, upload, and staging folders; shares with configuration files, scripts, backups, virtual machine images, network documentation, or sensitive personal data; and any leftover file servers, NAS devices, or migration remnants that may not have a clear owner or business purpose.

For each high-priority share, find out who can access it, including anyone who gets access through group memberships. Check what kind of data is stored there, if write access is really needed, and if the share still supports a business need. If no one can explain why a share exists or why it needs broad access, consider restricting it, archiving it, or retiring it.

File Shares Belong in Internal Penetration Testing

Internal penetration testing is about understanding how an attacker would actually move through the environment, not just whether they could exploit a specific vulnerability. File shares are consistently one of the most productive areas during an internal assessment, yet they are still sometimes treated as secondary to the Active Directory portion of the engagement.

The two are connected: Active Directory is usually where an attack starts, and file shares are often where an attacker learns enough to decide where it should go next. Credentials recovered from a configuration file or script can eliminate several steps that would otherwise take more effort, or not be possible at all. Documentation found on a share can replace hours of network reconnaissance. A backup file can expose data that the underlying system was configured to protect.

One common issue we uncover during an Internal Penetration Test is an overly permissive webroot (wwwroot) share on a Microsoft IIS server. When this type of share is exposed with broad read privileges, we look for configuration files such as the web.config, which often contains Microsoft SQL Server database connection strings. An exposed web.config file is easy to locate and read, and the credentials in it can open a database that would not otherwise be reachable via the path we were already following. If the account uncovered in the connection string has the right privileges, it can be used not only to access the database but also to compromise the underlying database server as well. Another issue we encounter is a shared wwwroot that is writable by unprivileged users. These permissions could be applied by a developer for convenience purposes and never revoked. When present and the right conditions exist, an attacker can write malicious code to this exposed wwwroot, browse to the file via the web server, and execute a reverse shell or web shell to gain remote code execution on the underlying web server.

The goal of a file share review is not to produce a list of every SMB share on the network. The useful part is understanding which shares a low-privileged user can reach, where permissions are broader than expected, where write access exists, and what sensitive data those permissions actually expose. A thorough review should answer which shares ordinary domain users can access, where users have unnecessary read or write permissions, whether credentials, configuration files, backups, or sensitive business data are exposed, whether old or unused shares are still available, and whether any of that data would help an attacker keep moving.

Some of that access will be completely legitimate, while the problem areas are typically the access that no one realizes exists or remembers granting.

A strong internal penetration test report should not simply note that sensitive data exists on a file share. It should identify which shares low-privileged users can access, which permissions are broader than they should be, which shares contain information that poses a meaningful risk, and which servers or shares have outlived their purpose entirely. That level of detail gives the people responsible for the environment a clear picture of what needs to change and a reasonable starting point.

Closing Thoughts

File shares become a security problem gradually, as permissions accumulate, temporary access becomes permanent, data gets forgotten, and old systems stay online because nobody is quite sure whether they can be removed. The organizations we work with are not being negligent when this happens, but are managing competing priorities, limited staff, and environments that do not stand still. File share hygiene slips because it is easy to defer when more urgent work is always waiting.

If your organization has not reviewed file share permissions for some time, there is no need to try to clean up every file server at once. Start with the shares that matter most, or work on an initiative to identify them if there is no clear share inventory: high-value departmental shares in HR, Finance, Legal, and IT, any shares with anonymous or guest access, shares where Everyone or Domain Users appear in the ACL, and any file servers that may have been partially or fully decommissioned. For two or three of those shares, look at who can actually access them, including access inherited through nested groups. Review what data is stored there and whether everyone with access still needs it. Then decide whether the share itself still serves a business purpose or can be scoped down or retired.

If nobody can remember the last time the organization’s file shares were reviewed, that is usually a good reason to take a look. These issues build up through years of permission sprawl, forgotten data, and small decisions that were reasonable at the time and never revisited after the immediate need was gone, making them an extremely productive area for attackers and a worthwhile area for defenders to address.

Have a question about this article or concerns about your file-share security?

Vilkas Cybersecurity uses proprietary tooling to identify Active Directory attack chains, inventory file shares, and perform in-depth reviews of file share permissions and sensitive data exposure. We continue to expand these capabilities as part of the tooling behind our assessments. If you have questions about your organization's file share security, fill out the form, and we'll get back to you shortly.