Discovering contents of folders in Windows without permissions

Published: 2020-02-18
Last Updated: 2020-02-18 19:21:56 UTC
by Jan Kopriva (Version: 1)
5 comment(s)

I recently noticed an interesting side effect of the way in which Windows handles local file permissions, which makes it possible for a non-privileged user to brute-force contents of a folder for which they don’t have read access (e.g. Read or List folder contents) permissions. It is possible that it is a known technique, however as I didn’t find any write-ups on it anywhere, I thought I’d share it here.

UPDATE: It turns out that John Page, aka @hyp3rlinx, actually did a write-up on the vulnerability in September 2019 - you may find it here.

The issue/vulnerability belongs to the CWE-203: Information Exposure Through Discrepancy[1] family and lies in the fact that Windows returns different messages/errors when a user attempts to access existing file or folder for which he doesn’t have read permissions and when he attempts to access a non-existent file or folder. This is true even if he attempts to access existing and non-existent files within a folder for which he doesn’t have any permissions.

The behavior is similar to a vulnerability commonly present in log in functions of web applications. In case of a vulnerable web apps, a log in function returns different responses when user tries to log in with existing username and a wrong password and when he tries to log in with a non-existent username. This vulnerability is customarily checked during penetration tests since, although a valid username by itself doesn’t help potential threat actors too much, it isn’t something we want to offer to them freely.

To demonstrate the issue present in Windows, I created two user accounts on a Windows 10 test machine. First one was an admin account named "user" (and yes, in hindsight this was not the most fortunate name for an admin account) and the second, a non-privileged account, was named "Test". I further created a folder named "Secret", containing a file "secret.txt", with explicit Full control permissions set up for SYSTEM, the Administrators group and the "user" account and no permissions for the "Test" account.

It is obvious that the "Test" account wouldn’t be able to access the folder or list its contents. However, using error messages, for example those generated by attempts to change the currently open directory (cd), the user might infer whether a file or subfolder exists.

Using the error messages, it would be a trivial matter to automate guessing of filenames using a dictionary or a brute-force attack.

Before I noticed that the cd command (and many others) might be used in this way, I wrote a very simple C# PoC app, which can provide the same information and which could easily be converted to brute-force filenames or “guess” them, based on a dictionary.

static void Main(string[] args)
	Console.WriteLine("Input a path to a file to see whether it is accessible, or - if inaccessible - weather it exists or not.");
	Console.WriteLine("Input 'exit' to exit.");
	string input = Console.ReadLine();
	while (input != "exit")
			Console.WriteLine("Access permitted");
		catch (Exception e)
		input = Console.ReadLine();

Similar guessing of paths to the one, which we could employ here, is often used to discover contents of different paths on web servers. Unlike on web servers however, in Windows environments we usually can’t access the contents of the files and subfolders we discover through a simple HTTP GET request. So is this vulnerability actually useful in any way?

By itself not so much, at least in most cases. Although it is definitely unpleasant, without chaining it with some exploit that would actually enable an attacker to read the data in discovered files, all it can do is let a potential malicious actor infer that some file or folder exists. This may be useful for some red teaming activities, but that’s about it.

The only exception I can imagine would be in a situation when a folder would be present on a file system with misconfigured explicit permissions set for subfolders contained within it. In Windows operating systems, it is possible to grant a user permission to interact with a subfolder, even though they don’t have any permissions set for the parent folder. In real life, cases of this nature will be far and few between and most will probably be the result of a mistake by an administrator. Nevertheless, if such a folder was present on a target machine, finding and accessing it would be at least plausible for an attacker. To demonstrate this concept, I’ve created a subfolder "Not_secret" within the C:\Secret path, containing a file named "not_secret.txt".

Afterwards, I gave explicit permissions for this subfolder to our "Test" user.

As you may see from the following output of the PoC app I mentioned above, the “Test" user would be able to interact with the subfolder, if he were to find it, even though he can’t interact with the parent folder.

As far as I’ve been able to determine, the CWE-203 condition is only present when interacting with local drives and not with remote file shares. A malicious user would therefore have to have direct access to the machine on which folders he wants to brute-force are present... Moreover, discovering their contents would definitely not be quick work for him. Nevertheless, although the speed of guessing, which an attacker might achieve, would be slow, and even though the confidentiality impact would be quite limited, this behavior of Windows is certainly less than ideal.

I’ve informed Microsoft Security Response Center about the vulnerability, however as they have determined that it does not meet the bar for security servicing it will not be patched. Although this may be viewed as less than optimal result, one positive point does come out of it – in future, if we ever need to determine what a folder, which we can’t access, actually contains, we have at least this (very inefficient) technique available to us to find out.

Jan Kopriva
Alef Nula

5 comment(s)


Hi Jan, thanks for your contribution!

Possibly this vulnerability may be mitigated by removing the "Bypass traverse checking" privilege (AKA "user right") of applicable users.

According to :
"If you remove a Windows account’s Bypass Traverse Checking user right, the user will notice a performance hit when he/she accesses files or folders on an NTFS-formatted drive because of the additional folder-level access checks that will occur in the background. That's why leaving Bypass Traverse Checking enabled is a performance- and NTFS- optimization trick."

Apart from the performance penalty, does anyone know whether removing this privilege actually mitigates the vulnerability described by Jan and/or breaks anything useful?

Erik van Straten
Interesting way of directory listing. I guess most will agree, that filenames are much more than only meta data. And in cases of forensics this is relevant.
Hi Jan,

It would be interesting to check this on the debugger level, to see the returned values of the APIs involved querying the filesystem.

Sometimes more interesting facts appears after going low-level, and certainly to query the fs is much faster, with a custom tool.

Fabio Martins
Can one get the same information by removing the hard drive, mounting it on a different system and just traversing NTFS?
hi thanks for the good information for me

Diary Archives