- AccessChk: View effective permissions on files and folders - Thu, Apr 13 2023
- Read NTFS permissions: View read, write, and deny access information with AccessEnum - Wed, Mar 29 2023
- Kill Windows a process with Tskill and Taskkill - Mon, Mar 13 2023
Having properly configured NTFS permissions is a crucial part of Windows system security. NTFS permissions define which user and system accounts have permissions to read, write, or delete a file or folder. These permissions protect the system and applications from inappropriate (malicious) user actions.
For example, a user could replace an application executable with a malicious one if the application folder has misconfigured NTFS permissions. Good examples of such folders are Program Files and Program Files (x86), where standard users have no Write permissions.
In most cases, administrators use NTFS permissions to configure user access rights to folders storing company data. Such folders are usually stored on a server and accessed via a network as shared folders. These folders have two types of permissions: NTFS and share permissions.
Do not mistake these for one another. NTFS permissions control access to the file system itself and are applied when accessing the file, whether locally or remotely. Share permissions define access to the shared object (e.g., \\server\share) and are applied only when accessing the folder from the network. This post focuses only on NTFS permissions.
How AccessEnum works
AccessEnum is a simple but very powerful GUI tool. By powerful, I mean it can make your NTFS audit quick and easy. You don't need to iterate over hundreds or thousands of items, checking for misconfigured permissions somewhere in that list. Instead, AccessEnum will show you only files and folders that have different permissions from their parents. However, understanding the tool's logic and output requires a little knowledge, so let's get into it.
Let's say I need to audit my C:\apps folder where I install all my applications. The NTFS permissions on C:\apps are:
- SYSTEM—Full Control permissions
- Administrators—Full Control permissions
- Users—Read permissions
To scan a folder, type the path in the dialog box, or press Directory > Scan.
As you can see in the picture, AccessEnum shows only three permission types. This is because the tool abstracts the access control model. Simply put, the Read column shows objects that have Read permissions granted by either Read or Full Control permissions.
The same goes for the Write column; permissions might be granted via Write, Modify, or Full Control. An object is shown in the Deny column if a user or group has explicitly been denied any type of access. You can click the column name to sort the list by that column. If AccessEnum cannot read an object's permissions, an Access Denied message is shown.
By default, AccessEnum shows only objects that have less restrictive permissions than their parents. To list objects that have different permissions in any way, go to Options > File display options… and select Display files with permissions that differ from parent.
Permissions for local system and service accounts are also not visible by default. This is because in normal conditions, such permissions are not interesting. To show them anyway, select Show Local System and Service accounts from the Options menu.
Analyzing the output
AccessEnum compares the permissions against the parent of each file and folder and shows only the differences. The output is sorted by path by default, so you can easily see the subtree of differing objects. In my case, I scanned the C:\apps folder. You can see configured permissions on the folder, as I described earlier.
The first differing object found is the C:\apps\3rd party app folder. The object is listed because the group LAB\SG-DATA-RW is an extra permission configured on this subfolder that confers both Read and Write permissions.
The next item in the list is C:\apps\3rd party app\Even Worse Subfolder, which is a subfolder of the C:\apps\3rd party app folder. The output might be a bit confusing at first; the results are the same as on the C:\apps folder, which was selected for scan. The reason why the Even Worse Subfolder is shown is that it has different permissions than its parent, which is the 3rd party app folder.
The fourth object shown is a file called The worst text file.txt, located in Even Worse Subfolder. What you can see here is that the user LAB\leos has Read and Write permissions, and the group LAB\SD-DATA-RW has been denied access to the file. As mentioned earlier, an object is shown here if any type of access is denied, so at this point, you don't know exactly which permission is denied.
The last object to mention is the C:\apps\Bad software folder. What you can see is that the Everyone group has both Read and Write permissions. But I have also added the LAB\leos user manually to the permissions list. Why isn't it shown?
The record for LAB\leos is not shown by AccessEnum because the permissions that the user has are already granted by the Everyone group. In such cases, the extra records are filtered out. Note that such filtering only works for well-known groups; it doesn't work for permissions granted by local or domain security groups.
Unfortunately, AccessEnum cannot fix permissions for you. However, you can right-click the object in question and click Properties… to open the object properties and fix the permissions. Another option is to use the Explore… button, which will open a folder in File Explorer. The last option in the context menu is to exclude such objects from the scan.
Compare saved output
AccessEnum allows you to save the results to a text file and compare them. This can be useful in checking whether the permissions were fixed properly. In addition, you can compare the results on a different computer. To do so, you first need to run a scan against a folder, and then use the Compare to saved… option from the File menu. As a result, you can see which folders were removed (meaning that their NTFS permissions are no longer misconfigured) or added to the current scan results.
Find misconfigured permissions in the registry
AccessEnum can also scan Windows registry permissions, which are technically not NTFS permissions. To scan a registry key, type the key path or use the Registry… button, and browse to the key. As you can see in the output, I have several Access Denied errors. That's because I am not running AccessEnum as an administrator, so the tool was unable to read the key security descriptor.
Subscribe to 4sysops newsletter!
Auditing or finding misconfigured permissions can be a difficult task. In this post, you learned how to use AccessEnum to help accomplish the task.
Want to write for 4sysops? We are looking for new authors.