What Happened
During a penetration test, a red teamer discovered an unauthenticated Windows SMB file share at a tobacco company containing a folder marked “Confidential” with detailed product recipes — chemical percentages, weights, and volumes for their tobacco products. The share was accessible to every employee on the network. The pen tester downloaded one file to prove the exposure. The company’s security team denied the recipes were real and disputed the finding for a year. Eventually, the files were deleted or moved — implying they were genuine trade secrets that had been exposed to hundreds of employees with no business reason to see them.
No external breach occurred. This was an internal misconfiguration — Windows share permissions or NTFS ACLs were set incorrectly, or inheritance was applied carelessly during a migration, or an admin made a one-time exception and forgot to revert it. The result: confidential intellectual property readable by anyone on the corporate network.
Why Windows Permissions Failed
NTFS permissions and share-level ACLs are fragile and difficult to audit at scale. An administrator sets broad permissions on a share to make it easy for users to collaborate, then tries to use group membership to control access to sensitive subfolders. But when a new folder is created, or when inheritance is pushed down from a parent, or when an admin makes a quick exception to unblock someone’s workflow, gaps appear.
The knowledge base describes this exact failure mode: “There is no real way for all administrators to know precisely what the other administrators know and why they made DACL changes/exceptions. It is just too complicated and fast paced and there are just too many files and folders.”
Worse, the company had no visibility into who accessed the files before the pen tester found them. Windows Event Log file auditing is notoriously difficult to configure correctly — most organizations either don’t enable it, or they enable it and drown in noise, or they enable it on some folders but miss others due to inheritance problems or SACL changes that go untracked.
When the pen tester reported the finding, the security team had no way to prove the files hadn’t been accessed by dozens of employees over the prior months or years. They couldn’t show auditors or executives a clean audit trail. They couldn’t even prove their own admins hadn’t read the files.
How FileSure Defend Prevents This
FileSure Defend enforces file access policy at the Windows kernel level using a filter driver that intercepts file operations before they reach the file system. It operates independently of NTFS permissions and share-level ACLs — meaning even if an admin misconfigures a share, FileSure’s policy still applies.
Here’s a specific rule configuration that would have blocked the exposure:
File name filter: \\fileserver\recipes\* (or a local path if the share is mounted)
Allowed users: R&D_Engineers group
Allowed programs: Specific applications used by R&D (e.g., C:\Program Files\ChemSoft\formulator.exe)
Allowed machines: R&D workstations by hostname or IP range
Operations controlled: Read, Write, Delete, Rename
Drive type: Network or Fixed
With this rule in place, when the pen tester (or any employee outside the R&D group) tries to open a recipe file, FileSure intercepts the file read operation at the kernel level and blocks it — regardless of what Windows permissions say. The user sees an access-denied message, and FileSure logs the attempt with full context: username, machine name, file path, program name, timestamp, and whether the operation was blocked.
If the company had deployed FileSure before the pen test, they would have had an audit trail showing exactly zero unauthorized access attempts to the recipe files — or if there had been attempts, they’d know exactly who tried, when, and from which machine. When the pen tester reported the misconfigured share, the security team could respond with proof that no files were actually read, rather than disputing the finding for a year and hoping the files weren’t real.
FileSure also addresses the privileged user problem described in the knowledge base. Even if a domain admin or local administrator account is used to browse the share, FileSure’s kernel-level policy applies. An admin can’t “take ownership” of a file and bypass the rule — the file operation is intercepted before NTFS permissions are even evaluated.
Start a Free Trial
If you manage Windows file servers or workstations with sensitive data, you can download FileSure Defend and start a free trial at bystorm.com. No credit card required. The product installs as a kernel filter driver and begins enforcing policy within minutes.
Source: Open SMB file share: tobacco company — confidential product recipes exposed to any… | Threat Watch
Category: Data Loss Prevention
Tags: smb file share, insider threat, trade secret protection, kernel filter driver, file system security, data loss prevention, windows file auditing
