Snaffler
Discover Sensitive Data Across Active Directory File Shares
Snaffler is an open-source security tool that helps authorized security professionals map readable network shares across Windows and Active Directory environments, then surface the files most likely to matter. It walks accessible directory trees and applies configurable rules to flag documents that may hold credentials, configuration data, keys, scripts, backups, connection strings and other secrets scattered across corporate file servers.
Authorized use only. Run Snaffler solely on systems, networks and domains you own or have explicit written permission to assess.
Active Directory Focused
Built around Windows domain environments, domain-joined systems and the readable network shares that sit inside them.
File Share Discovery
Finds accessible SMB and file shares across target systems so nothing quietly stays off the security radar.
Sensitive Data Detection
Applies rules to identify files that are likely to contain credentials or other valuable security information.
Configurable Rules
Supports flexible rule sets and configuration options that shape scanning behaviour, scope and output.
What Is Snaffler?
Snaffler is an open-source security tool designed for Windows and Active Directory network environments. Rather than asking an assessor to browse file servers by hand, Snaffler automates the tedious part of the job: it queries the domain for relevant computers, checks which network shares are actually readable with the credentials it has been given, and then works through those shares systematically.
Once a readable share is identified, Snaffler walks the directory structure beneath it and evaluates what it encounters against a configurable rule set. Rules can look at file names, extensions, paths and — where configured — selected file contents. A file called unattend.xml, a stray web.config, an old PowerShell deployment script or a forgotten database backup will look very different to a rule engine than the thousands of ordinary spreadsheets sitting next to them.
The result is a prioritised stream of findings rather than an undifferentiated file listing. Matches are categorised and surfaced so a human can review them, and output can be written to the console or to log files for later analysis. That output is the starting point of a review, not the conclusion of one — Snaffler indicates that a file looks interesting, and a person still has to confirm whether it genuinely exposes anything.
In practice, Snaffler is used during authorized penetration tests, red-team engagements, Active Directory security audits and defensive assessments. Blue teams run it against their own estates to find credential exposure before somebody else does. Because it is open source, teams can read exactly what it does, extend its rules, and run it inside their own labs. Snaffler should only ever be pointed at environments you own or have been explicitly authorized to test.
- Open source — the project is public and community maintained.
- Domain aware — discovers relevant systems from Active Directory.
- Share centric — focuses on shares that are actually readable.
- Rule driven — matches on names, paths, extensions and content.
- Tunable — threads, queues, scope and limits are configurable.
- Reviewable output — console and file logging for later analysis.
How Snaffler Works
Four stages take a Snaffler scan from a domain name to a short list of files worth a human’s attention. Each stage narrows the field, so the review at the end is manageable.
Step 1 — Discover Systems & Shares
Snaffler queries Active Directory to build a picture of relevant domain systems, then checks which network shares are reachable and readable with the credentials supplied. Shares that cannot be read are dropped early so effort is spent where access actually exists.
Step 2 — Walk Directory Trees
For each readable share, Snaffler traverses the accessible folder structure beneath it. Recursive walking is what turns a handful of share names into a complete inventory of the files an account can reach — including the deep, forgotten paths nobody browses manually.
Step 3 — Inspect File Names & Content
Rules evaluate what has been found. File names, extensions and paths are matched first, and where the configuration allows it, selected file contents are examined too. This is where a generic file listing starts becoming a security signal.
Step 4 — Prioritize Findings
Matches are categorised and surfaced so the most interesting results stand out from routine ones. Output goes to the console and, when configured, to log files — giving the assessor a ranked starting point rather than an overwhelming dump.
Snaffler Features
A compact tool with a deliberately focused feature set: find the shares, walk them, match them against rules you control, and hand back something a person can act on.
Active Directory Share Discovery
Uses the domain as its starting point, building a target list of systems and shares instead of relying on a hand-written host file.
Readable SMB Share Enumeration
Checks which SMB shares are genuinely readable with the supplied context, so the scan concentrates on real, usable access.
Recursive Directory Walking
Traverses accessible folder structures to depth, reaching the buried paths that manual review almost never gets to.
File Name Matching
Matches on names, extensions and path fragments — often the fastest way to spot configuration files, key material and backups.
File Content Inspection
Where configured, selected file contents are examined so that interesting strings inside otherwise ordinary files are not missed.
Rule-Based Detection
Detection logic lives in rules rather than hard-coded checks, which keeps behaviour transparent and adjustable.
TOML Configuration
Scan behaviour is driven by TOML-based configuration, so settings are readable, reviewable and easy to keep in version control.
Console & File Logging
Results can be streamed to the console during a scan and written to log files for later analysis and reporting.
Structured Output Options
Output formatting options, including machine-readable JSON, make it practical to feed findings into other tooling.
Multithreaded Scanning
Work is spread across threads so large estates can be covered in a realistic amount of time rather than overnight.
Custom Rule Support
Teams can add their own rules for the naming conventions, product names and file types specific to their environment.
Flexible Targeting
Scope can be narrowed to particular systems, shares or paths, which keeps assessments within the boundaries you were authorized to test.
Why Security Teams Use Snaffler
Both attackers-with-permission and defenders care about the same question: what can an ordinary domain account already read? Snaffler answers it consistently.
Find Credential Exposure
Passwords end up in scripts, config files and handover documents. Surfacing that exposure inside your own estate lets you rotate and remediate before it is abused.
Identify Risky File Shares
Shares are often opened up during a project and never locked back down. A scan makes over-permissive shares visible so ownership and permissions can be corrected.
Reduce Manual Searching
Browsing file servers by hand does not scale past a few thousand files. Automating the sweep frees analyst time for the judgement calls that actually need a human.
Prioritize High-Value Findings
Categorised results mean a reviewer starts with the handful of files most likely to matter instead of reading a flat list from the top.
What Can Snaffler Help Identify?
Rules are written around the kinds of files that historically hold secrets. These are the categories that most often turn up on internal shares during an authorized assessment.
A match is a lead, not a verdict
A rule match tells you a file resembles something sensitive. Whether it genuinely contains live credentials, current keys or protected data always requires human review. Placeholder values, expired secrets, sample configs and test data all match the same patterns as the real thing — so validate each finding before drawing a security conclusion or raising it as an issue.
The Snaffler Workflow, End to End
From the domain to a reviewed finding — each stage feeds the next, and each one throws away everything that is not worth carrying forward.
Flexible Snaffler Configuration
Snaffler is configuration-driven, which is what lets one tool behave sensibly in a 200-host lab and a 20,000-host enterprise. Settings are expressed in TOML, so a scan profile is readable, reviewable and easy to keep alongside the rest of your assessment tooling.
- Thread settings — control how much parallelism a scan is allowed to use.
- Queues — share discovery, tree walking and file scanning are handled as separate stages.
- Logging — stream to the console, write to a file, or do both.
- Output formats — human-readable text or structured output for downstream tooling.
- Targeting options — keep scope tight and inside your authorization boundary.
- File size limits — skip objects too large to be worth reading.
- Custom rules — add detections for your own naming conventions and products.
- Rule directories — organise rule sets into folders and load the ones you need.
The panel opposite is a stylised illustration of configuration concepts. Check the official repository for the authoritative option names, defaults and syntax before running a scan.
# Illustrative configuration concepts only. # Always confirm real option names in the official docs. [scan] threads = 24 # parallel workers share_queue = true # stage 1: find shares tree_queue = true # stage 2: walk folders file_queue = true # stage 3: inspect files max_file_size_kb = 10000 # skip very large files [targeting] domain = "lab.internal" include_hosts = ["FS01", "FS02"] exclude_paths = ["\\print$", "\\ipc$"] [rules] rule_dirs = ["./rules", "./rules-custom"] match_filenames = true match_contents = true [output] console = true log_file = "./snaffler-run.log" format = "json"
Designed for Large File-Share Environments
Snaffler separates its work into distinct processing stages — discovering shares, walking directory trees, and scanning files — so each can progress independently instead of blocking the others. Resource usage is not fixed: thread and queue settings let you tune how aggressive a scan is, which matters when you are working inside a production estate and need to stay considerate of the network and the file servers themselves. Start conservative, watch the impact, and scale up only within the limits your authorization allows.
Throughput depends entirely on your environment — host count, share size, network conditions, file server load and the thread settings you choose. No universal benchmark figures are claimed here.
Common Snaffler Use Cases
Every scenario below assumes the same precondition: documented, explicit authorization covering the systems in scope.
Authorized Penetration Testing
Within an agreed scope and rules of engagement, Snaffler helps testers understand what a domain account can already read — often one of the more revealing findings of an internal test.
Red-Team Assessments
Red teams use share discovery to model realistic paths through an environment while operating under an authorised engagement letter and agreed constraints.
Active Directory Security Audits
Audit teams run scans against their own domains to measure how much sensitive material is reachable with standard user access and track that number over time.
Credential Exposure Discovery
Finding hard-coded passwords and stray key files inside your own estate is the first step toward rotating them and fixing the process that put them there.
File-Share Risk Reviews
Permission reviews benefit from evidence. A scan shows which shares are broadly readable and what they actually contain, so remediation can be prioritised properly.
Defensive Security Assessments
Blue teams use the same visibility defensively — running scans on their own infrastructure to close exposure before an adversary discovers it.
Snaffler vs Manual File Share Review
Manual review still has a place — judgement, context and validation are human work. Everything before that stage is where tooling earns its keep.
| Capability | Manual Review | Snaffler |
|---|---|---|
| Network-share discovery | Manual browsing, host by host | Domain-driven enumeration of readable shares |
| Recursive scanning | Limited by patience and time | Automated traversal of accessible trees |
| Rule-based filtering | Relies on the reviewer's memory | Configurable rule sets applied consistently |
| File-name analysis | Ad hoc, easy to miss patterns | Systematic matching on names, extensions and paths |
| Selected content inspection | Only files that get opened | Content matching where configured |
| Repeatability | Different every time it is run | Same config produces a comparable scan |
| Large-scale review | Impractical beyond a few servers | Multithreaded work across many hosts |
| Structured output | Notes and screenshots | Console and file logging, machine-readable formats |
| Custom rules | Not applicable | Add detections for your own conventions |
Understand Snaffler Findings
A Snaffler run produces a stream of matches: the file it found, where it found it, and which rule caused it to be flagged. Not every match carries the same weight. Some point at material that would be serious if it were live; others are ordinary files that simply happen to match a broad pattern. Output can be read on the console during a scan or written to a log file so the review happens calmly afterwards, and structured formats make it straightforward to sort, filter and hand findings to colleagues.
Matches that resemble key material, credential stores or backups. Review these first — and "resembles" is doing real work in that sentence.
Configuration files, deployment scripts and similar operational content that frequently contains secrets but often does not.
Files that matter only in light of what else you know about the environment, the owner or the project.
Broad matches that mostly help you understand the shape of a share rather than flagging risk directly.
Validate before you conclude. The categories above describe how teams typically triage results; they are a review convention rather than a claim about exact labels the tool emits. Confirm the real classification scheme in the official documentation, and confirm every individual finding by hand before it becomes a reported issue.
Getting Started with Snaffler
A responsible first run looks less like ‘point it at the network’ and more like the five steps below.
Download From the Official Repository
Get Snaffler from the project's own GitHub repository rather than a mirror or a re-upload. Security tooling from an unverified source is a risk in its own right.
Review the Documentation
Read the project's README and options before running anything. Understanding what each setting does is what keeps a scan predictable.
Prepare an Authorized Test Environment
Use a lab domain, or an estate you own or have written permission to assess. Confirm scope and timing with the system owners before you begin.
Configure Your Scan Scope
Set targeting, thread counts and size limits deliberately so the scan stays inside the authorized boundary and stays considerate of production systems.
Review Output Carefully
Treat results as leads. Validate each finding, handle anything genuinely sensitive securely, and report through your organisation's disclosure process.
Snaffler Releases & Updates
Snaffler is an actively maintained open-source project that has continued to receive releases and updates from its contributors. Because version numbers move, this page deliberately does not hard-code one — check the official GitHub Releases page for the latest build, release notes and any published checksums.
Latest Build
Release artefacts are published on the project's GitHub Releases page. Check there for the current version rather than relying on third-party listings.
Release Notes
Each release generally documents what changed. Reading the notes before you upgrade avoids surprises in behaviour, options or rule handling.
Source & Issues
The repository holds the source, the issue tracker and contribution history — the best place to verify anything you read about the tool elsewhere.
Verify Your Download
Download from the official repository and verify any checksums that are published. Security tooling deserves the same supply-chain caution as anything else.
Use Snaffler Responsibly
Snaffler is a security assessment tool. Use it only on systems, networks, and domains you own or have explicit authorization to test. Sensitive findings should be handled securely and disclosed through appropriate organizational processes. Unauthorized scanning of systems you do not control may be unlawful in your jurisdiction and is never endorsed here.
Snaffler FAQs
Twenty-five common questions about Snaffler, its rules, its output and using it responsibly.
Snaffler is an open-source security tool built for Windows and Active Directory environments. It discovers domain systems and readable network shares, walks the accessible directory structures beneath them, and applies configurable rules to highlight files that may contain credentials, keys, configuration data or other sensitive information worth a security reviewer’s attention.
It is used during authorized security work — penetration tests, red-team engagements, Active Directory audits and defensive assessments — to answer a specific question: what sensitive material can be read from network file shares with a given level of access? It replaces slow manual browsing with a systematic, repeatable sweep.
Yes. Snaffler is an open-source project maintained by its contributors and hosted publicly on GitHub. That means you can read the source, review exactly what it does before running it in your environment, raise issues, and extend it. Always check the repository for the current licence terms.
Active Directory is central to how it works. Rather than requiring a manually assembled target list, Snaffler uses the domain as its starting point to identify relevant computers, then determines which of their shares are actually readable with the credentials it has been given before any scanning begins.
It focuses on Windows-style SMB network shares reachable inside the target environment. The practical constraint is access: shares that cannot be read with the supplied context are of no use and are dropped early, so the scan concentrates on the file shares an account can genuinely reach.
It can. File names, extensions and paths are matched first because that is fast and often sufficient. Where the configuration allows it, selected file contents are also inspected so that interesting strings inside otherwise unremarkable files are not overlooked. Content inspection is bounded by configurable file size limits.
Through rules rather than fixed, hard-coded checks. Rules describe the naming patterns, extensions, paths and content characteristics associated with sensitive material. Anything matching is flagged and categorised. Keeping the logic in rules is what makes the tool’s behaviour transparent and adjustable per environment.
Rules are the definitions that tell Snaffler what counts as interesting. They cover things like configuration file names, key file extensions, backup patterns and credential-related strings. Rules are grouped into sets and loaded from rule directories, so you can enable the ones relevant to a particular assessment.
Yes. Custom rule support is one of the reasons teams adopt it. Every organisation has its own naming conventions, internal product names and file types, and generic rules will miss them. Adding your own detections makes results far more relevant to your specific estate.
Snaffler uses TOML-based configuration. TOML is plain text and easy to read, which means a scan profile can be reviewed by a colleague, kept in version control alongside your other assessment tooling, and reused consistently across engagements. Check the repository for the authoritative option names and syntax.
Structured output options including JSON are supported, which matters when findings need to go somewhere other than a person’s screen — a triage spreadsheet, a reporting pipeline, a ticketing system or your own analysis scripts. Confirm the exact flags and format in the official documentation.
Yes. Results can be streamed to the console while a scan runs and written to a log file for later analysis. File logging is the more practical option for larger scans, where output volume makes live console reading impractical and you want a durable record to review afterwards.
It is. Work is distributed across multiple threads so that large environments can be covered in a realistic timeframe. Thread counts are configurable, which lets you dial the intensity up in a lab and back down when scanning a production estate where impact on file servers is a real concern.
Because the three jobs have very different characteristics. Discovering shares, walking directory trees and reading files each take different amounts of time and hit different bottlenecks. Handling them as separate stages means a slow file server does not stall discovery elsewhere, keeping overall throughput steadier.
It is designed with large file-share estates in mind — separate processing stages and multithreading exist precisely for that. Real-world performance still depends on host count, share size, network conditions and how conservatively you have configured threads, so plan and measure rather than assuming a fixed rate.
No. Offensive security teams were the original audience, but the visibility it provides is equally valuable defensively. Anyone with responsibility for an Active Directory estate benefits from knowing what a standard domain account can already read across the organisation’s file shares.
Absolutely, and many do. Running it against your own environment surfaces credential exposure and over-permissive shares so they can be remediated before someone else finds them. Repeating the scan periodically also turns a one-off finding into a metric you can actually track over time.
From the official project repository on GitHub at github.com/SnaffCon/Snaffler. Use the official source rather than mirrors or re-uploads — security tooling obtained from an unverified third party carries real supply-chain risk, and verifying provenance takes only a moment.
On the project’s GitHub Releases page. Version numbers change, so checking there directly is more reliable than trusting a number quoted on any secondary website, including this one. The releases page also carries release notes and any published verification details.
It is a legitimate security tool, but it is not risk-free to run carelessly. Scanning generates network and file server load, and the output may contain genuinely sensitive data that must be protected. Use it only with authorization, tune your settings conservatively, and handle results securely.
No, and this is an important distinction. A rule match indicates a file resembles something sensitive — it does not confirm that any credential inside is current, valid or usable. Placeholders, expired secrets and sample configuration all match the same patterns as real material.
Always. Automated matching narrows thousands of files to a manageable shortlist, but deciding whether a finding represents genuine exposure requires human judgement and environmental context. Treat output as leads to investigate, never as a finished list of confirmed security issues ready for a report.
Extensively. Rules, rule directories, targeting scope, thread and queue settings, file size limits, logging destinations and output formats are all configurable. Because the project is open source, teams comfortable with the codebase can go further and adapt behaviour to their own requirements.
A readable share is a network share that the account being used can actually access and list, as opposed to one that merely exists and is visible by name. The distinction matters enormously: a share you cannot read is irrelevant to a scan, so Snaffler filters those out early.
Snaffler.org should clearly identify itself as an independent informational resource unless it is actually operated by the official project maintainers. Snaffler itself is maintained by its own contributors on GitHub, and that repository is the authoritative source for the software, its documentation and its releases.
Explore Snaffler for Active Directory Security Assessment
Learn how Snaffler works, understand its file-share discovery process, explore configuration concepts, and visit the official open-source project to get the software, the documentation and the latest releases straight from the source.
Independent Resource Disclaimer
Snaffler.org is an independent informational website unless otherwise stated. Snaffler is an open-source security project maintained by its respective contributors. Product names, trademarks, repositories, and third-party projects belong to their respective owners. Content on this page is provided for educational purposes and for use in authorized security assessments only.