The tools
So I’ve been re-writing an old private tool in the glare of GitHub with a number of improvements under the catchy moniker of the ‘Windows DACL Enum Project’.
So far I’ve completed (the planned list for future tools is quite long so I’ll spare you):
Process and thread permissions with the following functionality:
- Process name, binary PID, integrity level and user it is running as.
- Process permissions (-p).
- Thread permissions (-t).
- Module and associated file system permissions (-m).
- Remove background noise around non mapped SIDs (-x).
Service permissions
- PID and user it is running as
- Integrity protection level (Windows 8.1 / Server 2012)
- Service control manager permissions.
- Associated file permissions for the launch executable.
File system permissions
- Specific path (-p).
- Remove background noise around non mapped SIDs (-x).
Registry permissions
- Specify the hive to dump (-r).
- Remove background noise around non mapped SIDs (-x).
- Exclude SYSTEM and Administrators from all output (-s),
Windows stations and desktop permissions (run Chrome before and after running this).
All of these tools have three big significant improvements over the previous incarnation:
- SID to username mapping.
- Context aware permission dumping.
- Bad stuff detection technology – flag obviously scary and weak permissions.
An Interesting Example of a Weak Registry DACL
Please note the configuration described below is the NOT the default. However due to as yet unknown reason it is quite a common configuration (scientific sample size of 3 out 5 Windows 7 machines looked at here within NCC). Anyway while testing the registry permissions dumping tool and looking for entries with ‘- Alert’ the following registry key was flagged:
HKLMSOFTWAREMicrosoftWindowsCurrentVersionexplorerDriveIcons
On the machines were we’ve observed this weak DACL there is an entry for ‘Users’ where they have full control overriding the inherited permissions.
What can this registry key be used for?
Well as the name implies it is used for assigning icons for drives. For detailed information read the MSDN article:
How to Assign a Custom Icon and Label to a Drive Letter.
So what?
Well I booted this finding out to NCC’s internal technical mailing list posing a hypothesis that if one were to specify a UNC path to a file in this registry key it may be used to obtain hashes of other users in shared computing environments (Terminal Services, Citrix or shared workstations) when the user opens Explorer.
Matt Summers (@dive_monkey) was good enough to give this a go and sure enough… well it worked as expected. So a good pentest tip to keep in the brain banks.
Wrap-up
Well that is it, nothing more than a quick heads up that even low privileged registry writes that don’t directly result in code execution in the context of other users can still be fun.
Original Publish date: 04 November 2013
Original Author: Ollie Whitehouse
