This blog expands on a key theme from our recent webinar, “Beyond Vulnerability Scanners.” During the session, we explored how file shares often harbor critical risks that scanners miss — from cleartext credentials to exposed PHI. In this post, we take that insight further, breaking down how BreakPoint Labs operators assess network shares during real-world pentests and how you can use tools like Snaffler to uncover and analyze these exposures in your own environment.

An often overlooked area within pentesting engagements (and overlooked from a defensive perspective as well) is network shares and read-only access granted to said shares. Shares often contain a plethora of information that can be exploited by an attacker on the network, such as: cleartext credentials that can be then used to escalate privileges, or gain access to internal services and systems such as databases, internal intranet applications, switches/routers, etc; PII or PHI of employees or even customers of the client organization; KeepPass databases or other password vaults which can be cracked offline, and their contents compromised; and countless other instances of information exposure which an attacker can use to their benefit. Generally, in a pentesting engagement, we will be assessing the network from a “presumed compromise” or “assumed breach” scenario, and receive a standard user who has standard (non-privileged) access to the network and Active Directory domain being assessed, in conjunction with a domain-joined Windows host. Attackers might gain access to these internals by way of phishing or pivoting via a Remote Code Execution vulnerability on the external network (this is proving less common, but we still occasionally encounter it in engagements).

We will be approaching share analysis from this “presumed compromise/assumed breach” position. Organizations will often have tighter controls around their externals: a smaller external footprint, a WAF (Web Application Firewall) deployed (which is a useful mechanism to slow an attacker down, however, can be bypassed), email filtering to limit broadly-targeted phishing campaigns (though spear-phishing often will still make it through). However, once an attacker is “in”, we find that defenses slacken, particularly around shares. Enumerating shares from a Windows environment is trivial and does not commonly alert on EDR. It’s a standard Windows functionality, and alerting on it from a network level might prove to be too noisy or cumbersome. To speed our efforts along, we often use a tool called “Snaffler”. This binary may or may not flag on EDRs but could also be run through a C2 Beacon, which, if the beacon has successfully bypassed the EDR, would then be allowed to run unencumbered and gather the information available. In addition to Snaffler (or sometimes in lieu of, depending), from our provisioned kali host, we will pull hosts from nmap data with port 445 open and run a tool “SMBMAP” with our provisioned AD joined user credentials. SMBMAP will note what shares exist on the system and whether our user has read/write access.

For the purposes of this blog post, I’m focusing on shares that a user would have “READ ONLY” access to. “WRITE” access obviously opens up far more avenues of exploitation or operational disruption (e.g., an attacker simply deletes everything from a share, or uploads malware), and this may be covered in a future blog post. The recommendations around tightening share security are largely the same.

Snaffler Overview

Snaffler works by mapping the Windows hosts that it can see, from the perspective of the host it’s being run from (in our case, a provisioned, AD-joined jumphost on the domain). It can be run against the full domain or against hosts specified with the -n flag (for example, if you only have certain hosts in scope, or have pulled hosts from a specific network range). Our preference is always running it against the full domain if the full domain is in scope, with the caveat that this may take days or weeks to fully finish. Its output can be studied before finishing, and we often will analyze the results as they are coming in.

Targeting the full in-scope domain and saving the output to an output file.

Targeting specific hosts on the network (must be a comma-separated list with no spaces) and saving the output to an output file.

There are plenty of other flags and options for Snaffler to be run, and we recommend exploring its features for yourself:

https://github.com/SnaffCon/Snaffler

Snaffler spiders these hosts and peaks into shares for interesting files, determined by a pre-set list of keywords and file extensions (which can be added to and customized). It has the ability to look “into” most files–txt files, PS1 scripts, BAT scripts, python scripts, configs, anything one can reasonably open with a Text editor. It will point to these files in its output and highlight the interesting things it found, such as:

Sample of Snaffler output

And for the files it can’t see into (such as Word documents, etc), it will alert on those with suspicious names (e.g. Usernames-and-passwords.doc) or those with interesting file extensions (e.g. .kdbx (KeePass database file), .bak, .pem, etc. Again, these are determined by a preset but customizable list.

Snaffler is run from the context of the user running it. Whatever Snaffler can see, the user running it can also see. We run it first from the perspective of our standard, provisioned user, which is representative of a standard user on the organization’s network.

Due to the sheer breadth of most domains and their available shares, Snaffler is able to pull a lot of interesting information and a lot of not-so-interesting information. The real expertise here is the ability to sift through the data output. Snaffler makes our job a lot easier, but it’s not simply a “press this button and automatically reap rewards”. Snaffler is limited to the keywords it is searching and, therefore, might miss some gems.

Snaffler is a powerful tool. Let’s say you discover a unique password that Snaffler found in “\WINDOWSHOST1\DATA\scripts\transfer.py”. This password, “ay0techn0l0gy2007”, may exist in other files that Snaffler is not pulling. You can add this password “ay0techn0l0gy2007” to a custom .toml file before compiling the tool, and re-run the tool against either the full domain or select hosts (let’s say, for example, that above share “\WINDOWSHOST1\DATA\” which we suspect has many goodies). With this new keyword, Snaffler may find other files it wouldn’t have normally pulled, and allows us to more thoroughly report on potential leaks or may offer more insight into how or where the password is being used.

An example of a custom .toml rule file, located within Snaffler/SnaffRules/DefaultRules/FileRules/Keep/Code. In this example, we created “CustomRule.toml”. This .toml file will be in addition to the pre-existing rules dictated by Snaffler (that can also be customized if you wish.)

The real expertise that lies within share analysis is the ability to properly sift through the (often massive) amounts of data, determine what is useful, and manually explore the source drive to see if there are other interesting tidbits, files, things that Snaffler doesn’t see but that we know could provide a leg-up to full compromise of the network.

For example, let’s say Snaffler is pulling a bunch of things from \WINDOWSHOST1\DATA:

\WINDOWSHOST1\DATA\scripts\goodscript.ps1
\WINDOWSHOST1\DATA\scripts\transfer.py
\WINDOWSHOST1\DATA\passwords.csv

An operator should navigate to \WINDOWSHOST1\DATA\ and manually explore to see if there are any interesting items that Snaffler is failing to pull. Let’s say we manually navigate to \WINDOWSHOST1\DATA\ and see the following subdirectory “notes”, and navigate to that:

We see two text files. For curiosity’s sake, we open them:

“Note.txt” contains potentially valid information about accessing cisco devices on the network–a presumed username and password. Had we added the previously-discovered “ay0techn0l0gy2007” password to our custom Snaffler’s keyword .toml file, we may have discovered this note. 

Let’s look at note2.txt:

Another presumed username and password. We check Bloodhound and voila–”jdoe” is a valid username for the organization, a domain administrator. We try these gleaned credentials and find them to be valid. We have compromised the entire domain by way of share analysis.

This second note, note2, would not have been found with Snaffler unless .txt files had all been added to be included (which would result in a lot more data and a lot of false positives). These .txt files are just examples–this type of example could be seen in OneDrive notes or other file types. Nothing but manual assessment would have determined that these could be potentially legitimate credentials, even if Snaffler pulled all the .txt files on the network.

Often, with share analysis, you don’t necessarily know what you’re looking for until you find it. Like anything automated, Snaffler is a useful tool, but it will fail to paint the full picture. Snaffler helps point us in a direction, and we take it to the next level.

Real World Examples 

Oftentimes, we will pull whatever cleartext credentials we find in Snaffler output (or through our own manual analysis) and compile a list. We will then spray these credentials, low-and-slow (determined by the organization’s password policy), across the network. Password reuse is a frequent plague within organizations, and we will, more often than not, get hits on the passwords we have gleaned from different users throughout the domain. Sometimes, the full AD-joined username and password are simply in the Snaffler data. We check the validity of the password, and voila–we now have access to a different user within the domain, sometimes with higher privileges. Think of the types of users who would have their passwords stored in configuration files or scripts–these users are generally users who have the privileges to run such things to begin with or whose access is being used for a specific reason.

The first step of clean-up from a defensive perspective is limiting who can see shares and know what exists on these shares. Whitelist privileged groups or users who must access specific shares for their daily operations instead of whitelisting the entire domain or “Authenticated User” groups. There are likely shares that exist within a network that must be accessible for all users–know what these are and what exists on them, because if a standard user can see them, an attacker on the network can see them, too. PII, PHI, etc, should be closely guarded. Scripts should not contain cleartext credentials, even when whitelisted to privileged users.

This brings us to our next topic: Enumeration is never over. Enumeration always starts from ground zero when higher levels of access are obtained, especially for share analysis. In a recent engagement, BPL operators performed a standard share analysis from their provisioned user and did not see much. To our pleasant surprise (and slight shock), an organization finally understood the risks of read-only shares on the network and locked them down appropriately! BPL operators were then able to gain access to a higher-privileged account in the domain by password spraying the default password that the operators had been assigned. We thought that this default password might always be assigned to new users within the domain and, therefore, potentially in use for other accounts. BPL operators were able to gain access to several accounts via this method, one of which had over one thousand outbound rights over systems in the AD environment. This was determined by looking at the Bloodhound data and navigating to the “outbound rights” tab. Upon seeing this, BPL operators opened a command prompt as the newly obtained, elevated user and re-ran Snaffler from their perspective. This user had access to far more shares, C drives, etc, within the environment, plenty of which contained cleartext credentials, KeePass databases, etc. BPL operators were able to further escalate privileges and compromise several different environments within the organization’s sphere.

Redacted screenshot of privileges of compromised user as seen in BH; this user has privileges over 1,000+ machines on the network.

You might argue that the above situation is the fault of weak passwords versus shares containing too much information. The shares were properly whitelisted and locked down, after all. To that I say: it’s all interconnected. Pentesting does not exist in a vacuum. Attackers look at the bigger picture, how a puzzle piece fits into a whole, and so do we (the pentesters), and so should the organizations when considering a defense-in-depth approach. A stronger password would have limited our ability to further escalate, but as we all know, humans are often the weakest link in security. Our first recommendation for this scenario would be, yes, ensure that users who have excessive outbound rights, who have higher privileges, ensure these users have strong passwords. Ensure that you know what they can see and touch, and how their potential compromise could have a domino effect into the network. Ensure they only have the smallest amount of privileges needed to perform their operations. But we would also recommend that these shares, while “properly whitelisted,” should be vetted for their contents. Cleartext passwords should be stripped from scripts where appropriate or encrypted. Employee education around what shares are and how they function is paramount, as well.

In another engagement, BPL operators, through a more manual approach (determining which hosts on the network had SMB/port 445 open, using a different, linux-based tool SMBMAP to map their shares from the perspective of a standard AD user), saw a host serving a read-only share “WINDOWSHOST2/IT/”. BPL operators navigated to that share, saw that a KeePass database (IT.kdbx) hosted, downloaded the .kdbx, and proceeded to crack offline. The KeePass database had been protected by a trivial, easy-to-crack password. BPL operators then had access to the full contents of the KeePass database, including IT resource passwords and a domain administrator password. When discussing this with the organization, the organization claimed that a user had “briefly opened up the share to be accessed and had forgotten to lock it down again.” Another instance of user-error, that might have been prevented with stricter policies in place and further protected by a more complex password being used to protect a password vault (though since it can be cracked offline, a determined attacker with an unlimited amount of time might have been able to crack the password regardless).

Key Takeaways 

These examples are just two of many that we encounter nearly every engagement. Almost always, we find things on shares that a standard user should not have access to, and that the organization in question is surprised to see. Passwords should be stripped from scripts or encrypted where possible. Employees should know how shares work, who has visibility into the shares, and should perhaps have some methodology around cross-checking what is placed on shares, so they do not unknowingly invite risk into the organization (we have seen employee W2 forms, for example, hosted on shares that anyone within the organization can access). Higher- privileged shares should be closely guarded, allowing only minimal access (consider user-based privileges versus group-based, if only a specific user needs access), and their password should be strong and not reused anywhere in the environment.

Shares require a multi-pronged approach to stay safeguarded, and the best way to limit their risk is to limit the useful information that can be gleaned and used by attackers.

Keep Exploring the Risks Scanners Miss

This blog covered just one risk, but it’s part of a much broader attack surface. Watch our webinar, Beyond Vulnerability Scanners, to see how real pentesters uncover misconfigurations, exposed credentials, and AD abuse paths that scanners overlook, and get practical strategies to remediate them before they’re exploited.