Reversing Wdigest configuration in Windows Server 2012 R2 and Windows Server 2016

Reversing wdigest configuration in Windows Server 2012 R2 and Windows Server 2016. Wdigest is an authentication protocol used in Windows. It enables the transmission of credentials across a network in MD5 format or message digest. It was designed to increase security over basic authentication initially used back in Windows Server 2003 for LDAP and Web authentication. By today’s standards, since Windows Server 2012 and Windows 8.1 Wdigest is disabled by default, the functionality was also back ported to earlier versions of windows, such as Windows 7 for you to disable via reg key. The problem with wdigest is it stores usernames and passwords in clear text. Tools such as mimikatz/wce were/are able to dump clear text passwords out from LSA and where wdigest was used , clear text passwords would be obtained.

The question is: As this is now disabled by default can wdigest simply be enabled by attackers adding the reg key and still used to dump clear text creds?… The short answer is yes it can. See below:

The reg key to disable wdigest in earlier operating systems is: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\WDigest creating a DWORD ‘UseLogonCredential’ setting the vlaue to 0 disables it. 1 enables it.

Using a vanilla install of Windows Server 2012 R2, dumping creds we can see no clear text password is displayed in the wdigest field when running mimikatz.

Lets add the reg key and ‘Enable’ by adding a value of 1.

I immediately retried mimikatz and had the same result as before (no clear text password), I did kind of expected this however wanted to go through the motions to test. Next a log off and back on and retest. Then reboot and retest.

So, I log off and back on first:

Oh dear.

OK so what about Windows Server 2016? Lets try:

Now for the reg key, to enable :

As we know 2012 needed a log off and back on, presumably to cache the credentials, lets assume the same is needed with 2016.

Oh dear oh dear.

Ok so what can we do to prevent this. There are several methods such as, protecting the LSA and LSASS process in Windows 8.1 and Server 2012 R2 which I have talked about this here. Enabling Credential Guard, new for Windows 10 and Server 2016. Protected Users in AD. From here reducing the credential foot print of users on machines, ie blocking users from rdp’ing into other machines, disable Domain Admin’s from logging in to workstations, user a ‘Server Admins’ group instead. Having dedicated user privilege separation. Monitor for the above reg key changes. All the time we are trying to reduce the ability for an attacker to escalate privileges by dumping credentials, then moving on laterally through the network, reducing their ability to gain access to higher privilege accounts.

4th December 2017

Protected Users Group in Microsoft Active Directory

In this post we will be discussing the Protected Users group in Microsoft Active Directory. This is to try and raise awareness of this security feature built into Microsoft Windows Active Directory (AD) 2012 R2 Domain environments. The Protected Users group in AD gives its members additional security features and protection when logging into Windows Server 2012 R2, Windows 8.1 and above.

If an account is made a member of the group. The user account can only authenticate using the Kerberos protocol. We will demystify this shortly with an example, however in brief it means that this user will not be able to authenticate with NTLM, WDigest Authentication, or CredSSP. Which means using one of these Security Support Providers (SSP) will fail. This is a win, as we know the NTLM hash is obtainable and is very crackable, Digest Auth stores credentials in clear text in memory, CredSSP also stores clear text credentials however is an interesting one as this may break applications that use it. However you might argue as you would probably only use this for high privilege accounts, (as Microsoft advises here) it might not be so much of an issue, and would probably be re-evaluated on a case by case basis after testing.

In addition to the above, the account will not use DES or RC4 in the pre-authentication stages. The domain therefore must support AES.

There are a couple of caveats that you should be aware (you can read about these here) of when using this as an option to help mitigate credential theft:

This will only take affect on Windows 8.1 and Windows Server 2012 R2, so no change for Windows 7 and Server 2008 I am afraid. So when logging into Windows 7 or Server 2008 variants your don’t get the protection from Protected Users membership.

Windows Server 2012 R2 Domain Functional Level is required.

Managed Service Accounts (MSAs) and group Managed Service Accounts (gMSAs) as well as computer objects can not be added to the group. (technically they can, however it will break things).

What does all this mean then in actual protection terms, what does it look like?

I feel an example coming on:

Lets test with Windows Server 2012 R2. If we dump creds on a vanilla install with mimikatz this is typically what we would see. So no wdigest as this is disabled by default however what we can see and retrieve is the NTLM hash for the account ‘Adam2’, which as we know can be cracked off-line.

Now if we add our account to the Protected Users group and test, lets see what happens. Lets log off and back on and re-run mimikatz:

No NTLM hash, this is because members of the protected users group will only authenticate with Kerberos and not with NTLM. Great. This seems like a win for high privilege accounts. More to come on this soon.

1st December 20172nd December 2017

Protecting the LSASS.EXE process with RunAsPPL

Protecting the LSASS.exe process with RunAsPPL is in an important part of hardening Windows Server 2012 R2 and Windows 8.1. Credential theft is trivial with Administrative level privileges, I have blogged about the use of mimikatz several times in the past. This post is here to try and raise awareness of what we can do to help protect against adversaries getting there hands on creds. Doing everything we can to try to protect against credential theft is clearly important. There are now advances in Windows 10 and Server 2016 that help mitigate this with Credential Guard, however earlier versions of windows are still vulnerable. The Local Security Authority Server Service (LSASS) process in windows is responsible for authenticating/validating users that login via local console or remote desktop. Tools such as mimikatz interact with the lsass process to extract credentials, whether that’s directly on the server or workstation at the time of attack or dumping the lsass process to a file and extracting credentials off line at a later stage.

With Windows Server 2012 R2 and 8.1 there is a feature called LSA (Local Security Authority) Protection according to the following Microsoft page we are able to run LSASS as a protected process. This essentially prevents mimikatz from working correctly out of the box. In addition to this it will prevent you from being able to dump the lsass process to a file through task manager. With some tweaking you can get around this however a driver or signature verification code would need to be added into the mix for it to work properly and be able to interact with the lsass process as a protected process (this can be monitored though through the event log). The following registry change can be added to enable the protection at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa adding a new DWORD entry of “RunAsPPL” with a value of 1. This does require a reboot however.

Lets see it in action on Windows Server 2012 R2. Before the change you can see I am able to dump the lsass process to a file from task manager:

This file could then be used with mimikatz on or offline to extract NTLM password hashes for cached credentials.

Lets make the change, and reboot:

And after:

Good! And if we try to run mimikatz on the server:

This doesn’t offer total protection however if we can slow down our adversaries and try to stay one step ahead we are in a better place than before. Clearly if you have plugins in your environment that need to interact with the lsass process this may break things so testing is a must, there is an auditing mode highlighted here that will help identify any that fail.

Hope this helps.

9th November 20179th November 2017

Quicktip: VirtualBox VM boot on host startup

To enable a virtual machine in VirtualBox to start automatically on host startup do the following:

(For Windows 10 host OS)

On the host OS right click on your start menu and type ‘shell:startup’ like below:

This will open up your startup folder. From here go into VirtualBox right click on your VM and select ‘Create shortcut on Desktop’ like below:

Then copy the shortcut from your desktop into the startup folder like below:

Simple, hope you enjoyed this quick tip.

26th July 201723rd July 2017

Top Three Command and Control Exfiltration methods

Just a quick post to list out some of my favourite Command and Control (C2) exfiltration methods.

Standard TCP connect using ‘Invoke-PowerShellTcp’ from Nishang framework. This is a super easy comprising of a netcat listener for the server and PowerShell for client side makes this a very accessible exfil method read about it here. How do we prevent this: block TCP access on the boundary firewall. No excuses for this one. In addition there is a whole host of client side mitigation, such as PowerShell logging and denying PowerShell execution etc.
DNS tunnelling using dnscat. Well what can you say about this, if all else false this will probably get you off the network in most places. Read about this here. How do we prevent this: This is more challenging, first verify if DNS is actually required, for example if this is a server subnet, azure or AWS do your servers really need to resolve address that can’t already be taken care of by internal DNS Server not resolving names to the outside or could you use a static hosts file? Secondly various IDS and firewalls can be tuned to detect this type of DNS traffic, so for example does that DNS request really need to be that big/long, wow that is a lot of DNS traffic from that box? no probably not – its DNS tunnelling.
ICMP tunnelling again using the Nishang framework, Mittal has written a nice client side PowerShell method for connecting, read about this here and the backend server here. How do we prevent this: block ICMP access on the boundary firewall. Its unlikely that you will need ICMP off the network.

23rd July 2017

Creating and mangling custom word lists!

Creating custom word lists:

In this post we are going through how to generate custom word lists with extra combinations based on an initial set of predefined words or generated words using John The Ripper. Why would we want to do this. Well you probably already have giant word lists that you can download from the internet such as the famous ‘rockyou’ list. Or passwords lists from breaches etc. What these huge lists don’t have are tailored words to suit your target specifically. For example we could use a tool called Cewl to spider a website and scrape all words on this site with a minumim length of 6 and a max of 10. We could also add words manually that relate to that target specifically. We then have a very custom set of words to do with that target, in which to generating new words for. (Obviously for a penetration test of which you have authoirsation to test). We could then use another program such as John The Ripper (JTR) to generate iterations of those words, for example adding the year to the end of the word. (this is a classic)

In this example we will use the list ‘list1.txt’ as our starting point. We will then use commands to output a new file called ‘newlist1.txt’. We will use JTR in Kali to do this. JTR has a set of predefined rules that will generate us new words based on the original words in any given list. We will add custom rule sets in JTR to generate different combinations of the original word(s). This configuration is found in /etc/john/john.conf.

Lets get started with an example. If we start with the list ‘list1.txt’ and add one word to keep things simple so we can see the words being generated by JTR and our custom rules. Lets start with the below rule which we will append to the bottom of our john.conf file like below:

Append the below text to the bottom of our john.conf file:

#My Custom rules.
[List.Rules:Rule1]
cAz”[0-9]”

like so:

custom rules in john.conf

Now use JTR to generate words using the below command:

john –wordlist=list1.txt –rules=Rule1 –stdout > newlist1.txt

Which looks like:

new words generated by JTR rule1

As you can see this simple rule adds numbers 0-9 to the end of the word and adds it to the new list called newlist1.txt.

Lets try a few more rules how about the below, append the text to the bottom of your john.conf.

[List.Rules:Rule2]
cAz”[0-9]”
cAz”[£!$@#]”
cAz”[0-9][0-9]”
cAz”[£!$@#][0-9]”
cAz”[0-9][0-9][0-9]”
cAz”[0-9][0-9][0-9][0-9]”

custom rules in john.conf 2

Which will in turn generate us the below:

new words generated by JTR rule2

As you can see I have had to tail the newlist.txt file as john has created a huge list, 11176 to be precise.

There are multiple sets of rules available across the internet, for example Korelogic have rules check them out here. See below for some further example rules:

#My Custom rules.
[List.Rules:Rule1]
cAz”[0-9]”
cAz”[£!$@#]”
cAz”[0-9][0-9]”
cAz”[£!$@#][0-9]”
cAz”[0-9][0-9][0-9]”
cAz”[0-9][0-9][0-9][0-9]”

#Replace letters for numbers
[List.Rules:Rule2]
>2!?Aso0
>2!?Asb8
>2!?AsB8
>2!?As1!
>2!?AsA4
>2!?Asa4
>2!?Ase3
>2!?Aso0se3
>2!?Aso0se3si1
>2!?Asi1
>2!?Ass5

Enjoy.

16th July 201716th July 2017

Active Directory Delegation of Control

No you don’t all need ‘Domain Admin’ rights, that includes you Mr IT Manager!

Users in the IT Helpdesk don’t all need ‘Domain Admin’ rights to perform daily tasks like password resets, user group changes and logging into users workstations for fixes. In addition to this they should also elevate rights and authenticate with another account in order to perform Active Directory (AD) administrative tasks, I wrote about this here. We can delegate special permissions to a security group in order for that group of members to be able to reset passwords and perform other AD related tasks. We can delegate this level of control on specific Organisation Units (OU), so for example all users under that OU can be managed by different levels of IT Support and there corresponding AD security group, i.e. a group for 1^st line IT Support called ‘IT Helpdesk ‘, ‘2nd line IT support’ and ‘3rd line IT support’ and so on, so we can have different levels of control. This means we give the permission to a group and in turn members of that group can perform special functions on the users that reside in that particular OU. Thankfully Microsoft have thought about this and there is a fairly straightforward way of achieving it by setting a set of stock permissions on the OU. To do this we can use the ‘Delegation of Control’ wizard in AD Users and Computers.

Delegation of Control Wizard

Ideally we want to split out our standard domain user accounts for standard non privilege duties like reading email and using Microsoft Word, then have a separate admin accounts ie ‘Adam-adm’ or ‘Adamadmin’ for the administrative privileges. These admin accounts can then be used to rdp directly to a separate management server which has the various tools installed. Tools like the Remote Server Administration tool set which has Active Directory Users and computers, DHCP and DNS etc.

Don’t use security groups you already have in your environment, create new groups. This might seem like it adds an extra complexity and more groups. However, if you botch your permissions on a group you are using for another function its not going to end well. If you later need to reverse changes or delete the group you can without fear of affecting other functionality.

Create a group for the help desk ie ‘IT Helpdesk’ for 1 st line staff. This should be used for password resets and group modifications etc.

Create a group for 2nd line support ie, ‘2nd line IT Support’. This should be used for all of the above including all other additional user account modification activities.

You may want to combine the first two groups into just one ‘IT Support’ group for smaller IT Teams. The point here really is to split out the duties so your helpdesk staff don’t have Domain Admin rights, and you’re not running elevated domain rights on your daily laptop/desktop, the principle of least privilege first should apply here. Only give the minimum required, no more.

Create a group for full Admins/3rd line support ie ‘3rd line IT Support’. This should effectively be used for all of the above tasks and any additional.

Keep the below points in mind when using the Delegation of Control wizard in Active Directory:

Always delegate permissions on a new AD group, not on one that is already in use.
Once applied to an OU there is no wizard to undo the changes. Changes will need to be manually undone.
You can re-run the delegation wizard again on the same OU to add additional permission, just not take away.
You can remove a newly added group from the security tab of an OU if needs be, (effectively reversing the changes).
Avoid setting permissions on individual user objects even if there is only one user, add the user to a group and make the changes on the group not the user. This is in case you need to revert changes. In addition to this you can always remove the user from the group.

Lets walk though an example.

As an example of how we can achieve this lets walk through the below lab. In this example we are going to delegate control in AD for password resets and user group changes for the ‘IT Helpdesk’ group, so that members of this group can carry out these tasks on domain users in the HR OU.

Right click on the HR OU and select the top option ‘Delegate Control…’ the wizard should pop up like below:

AD Delegation of Control Wizard

Select Next, and you will be prompted to add the group you want to grant the permissions too. In this case we will grant permissions to ‘IT Helpdesk’ as below:

AD Delegation of Control Wizard add group

Select Next. Now we will add the specific permissions that we want the ‘IT Helpdesk’ to have on users in the HR OU.

In this instance we are going to select the top five check boxes as these are a reasonable set of tasks that we would want our helpdesk staff to be able to perform. This obviously may be different from organisation to organisation depending on size and separation of duties. We will go with this as an example for now. Microsoft makes this very easy by grouping these tasks together in the form of the check boxes. We can go more granular than this if needs be, however for now we will continue with the pre-defined options.

AD Delegation add permissions

Select Next, then Finish.

You can verify your permissions be selecting the OU right clicking on properties, selecting the ‘Security’ tab, the group in question should have ‘special permissions’, select advanced, your will then be able to view the permissions. The top four Access Control Entries (ACE) will have been added.

AD Delegation permissions

In addition to this, select the ‘Effective Access’ tab, add the group and verify that the four permissions Create/delete Group objects and Create/delete User objects have a green tick next to them. (they are spread out, so scroll down)

AD Delegation permissions

As opposed to an alternative OU such as our ‘Admin’ OU which doesn’t have any delegation on it. The default permissions are as below:

AD Delegation permissions

The next thing to do is test the effective permissions to ensure the new ‘adm’ users of the ‘IT Helpdesk’ group can for example change a password of a user under the HR OU. It also worth testing this on a user account that isn’t in that OU so you can see the difference and error message that you will receive if you don’t have permission.

Et voila. I hope this helps. Remember test test test.

8th July 20173rd July 2017

Privilege Separation please…

No please don’t run ‘Domain Admin’ for daily tasks like reading email… use separate accounts and enforce privilege separation.

Separate user accounts should be used to perform Administrative tasks in Active Directory. Its far from ideal to be logged in to your daily work laptop as a Domain Admin to perform your business as usual tasks like reading email and surfing Facebook at lunchtime…

Ideally we want privilege separation for our accounts. Split out standard domain user accounts for standard non privilege duties like reading email and using Microsoft Word, then have separate admin accounts ie ‘Adam-adm’ for administrative privileges. These admin accounts can then be used to rdp directly to a separate management server which has the Remote Server Administration Tools installed for programs like AD Users and Computers, DHCP and DNS.

In Addition to having separate Admin accounts, don’t automatically add the account to the ‘Domain Admins’ group if it doesn’t need this level of privilege, (it most likely doesn’t) . Use the principle of least privilege first and delegate control using the AD Delegation of Control wizard. Its pretty straightforward to use. I wrote an article about delegation of control in Active Directory here.

5th July 20173rd July 2017

MiTM Thick Client Web Services Testing.

This post walks through MiTM Thick Client Web Services Testing designed for testing thick client web applications for web services using burp and iptables on an internal engagement.

Scenario:

So you need to man in the middle web traffic for application testing on an internal test. This could be either a thick client application for web services that has no proxy settings. Or a client device that is using the system proxy settings (ie proxy settings controlled from Internet Explorer). Or proxying traffic from a client device through the browser as any other usual web application test.

In this scenario the thick client application is installed on a corporate device. So we look to setup some sort of MiTM (Man in The Middle) scenario to watch and alter the traffic as we see fit. The client device IP address must remain the same (ACLs are in place for example or you are unable to change the IP address on the client device). A simple solution to this is two use two virtual machines on your testing laptop to get around having two default gateways with the same IP on one device. With some clever iptables rules we can essentially do a double nat type affair and spoof the client device on the corporate network, at the same time spoofing the gateway for the client device. Bingo MiTM nobody is non the wiser. I talk a bit more about iptables in this post.

If DHCP is used on the client device this is significantly simpler. Rather than using the same ip address range as the corporate network you can set this to an alternative IP and thus removing the need for two virtual machines supporting the double NAT scenario.

They say a picture paints a thousand words… so to bring it all together it the scenario looks similar to this:

Example 1 Configurable proxy settings on client device:

In this example the application on the client system is using the proxy settings configured for IE or Firefox. You are able to modify these and so you can redirect traffic to the proxy of your choice on 8080 for example like so. Note Chrome uses IE system settings:

Network Configuration:

Caution: Don’t use network-manager for this. Dual homing interfaces does not play nice in network manager. Stop the network-manager service first, verify it is stopped then continue to work in the standard networking service with the interfaces file.

service network-manager status

service network-manager stop

service network-manager status

service networking status

Now continue to work using just the interfaces file with the standard networking services.

Set the mac address of the eth0 on VM2 the same as the PC mac address

Ifconfig eth0 down

macchanger –mac 08:00:27:8D:CD:53 eth0

ifconfig eth0 up

On both VM2 and VM1:

echo 1 > /proc/sys/net/ipv4/ip_forward

VM2 interfaces file:

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 172.16.0.2
gateway 172.16.0.1
netmask 255.255.255.0
dns-nameservers 8.8.8.8 8.8.4.4


auto eth1
iface eth1 inet static
address 192.168.0.2
netmask 255.255.255.0
dns-nameservers 8.8.8.8 8.8.4.4

**Gateway is always set on the forwarding interface.

VM2 iptables:

iptables -t nat -A POSTROUTING –out-interface eth0 -j MASQUERADE

VM1 interfaces file:

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.0.1
gateway 192.168.0.2
netmask 255.255.255.0
dns-nameservers 8.8.8.8 8.8.4.4

auto eth1
iface eth1 inet static
address 172.16.0.1
netmask 255.255.255.0
dns-nameservers 8.8.8.8 8.8.4.4

**Gateway is always set on the forwarding interface.

VM1 iptables configuration:

iptables -t nat -A POSTROUTING –out-interface eth0 -j MASQUERADE

Using burp set your proxy to the listening IP and port.

Example 2: No proxy Settings/Thick client App or Web Services etc..

In this example you have a thick client app that doesn’t allow you to set a proxy and doesn’t use the system proxy settings. You can use ‘prerouting’ in IP tables on VM1. This will route traffic destination port 443 and ‘redirect this to port 8081 with this command:

iptables -t nat -A PREROUTING -i eth1 -p tcp –dport 80 -j REDIRECT –to-port 8080

iptables -t nat -A PREROUTING -i eth1 -p tcp –dport 443 -j REDIRECT –to-port 8081

Then using burp configure your proxy to listen on all interfaces for 8080 and 8081 do this for as many destination ports as required. In addition to this ensure ‘Support for ‘invisible proxying’ is enabled.

Things to Remember!:

After every reboot IP forwarding and iptables will reset so check both on a restart:

cat /proc/sys/net/ipv4/ip_forward

iptables -t nat -L -v -n

To make IP forwarding persistent you can do the following:

Edit /etc/sysctl.conf and uncomment the ‘net’ line:

# Uncomment the next line to enable packet forwarding for IPv4

#net.ipv4.ip_forward=1

DNS: hostnames will need to resolve on both the client and proxy machine.

Its is useful to create a bash script for your config for each machine. Then on a reboot there is no faffery looking for the right commands simply run the bash script. Note – the nameservers are pushed to the resolve.conf to save bringing down and back up the interfaces, and restarting the networking. A sample script might look like the below:

On the proxy VM:

#!/bin/sh

service network-manager stop
echo 1 > /proc/sys/net/ipv4/ip_forward

echo nameserver 8.8.8.8 > /etc/resolv.conf

iptables -t nat -A POSTROUTING --out-interface eth0 -j MASQUERADE

iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80 -j REDIRECT --to-port 8080
iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 443 -j REDIRECT --to-port 8081

This is definitely a labs worth! Hope this helps!

1st July 2017

Disable Domain Users from Enumerating other Domain Users, Domain Admins and other objects!

In this post we will walk through how to disable domain user enumeration. Disabling Domain Users from Enumerating other Domain Users, Domain Admins and other objects in Active Directory. Why might I want to do this? Well, once a domain user account has been compromised through exploitation, sooner or later the attacker is going to want to enumerate the domain further and gather ‘intel’, commonly known as situational awareness. During this process an attacker is going to want enumerate the domain and all its users including high privilege groups such as Domain Admins. This is a gold mine for an attacker as they can launch password spray attacks on those enumerated users. The attacker doesn’t have to guess the usernames as he/she can just query the domain, that’s half the battle won. The attacker will then use a single password such as Password1 against all the accounts, inline with the domain password policy avoiding account lockouts. By default any authenticated domain user can enumerate the entire domain, this is standard out of the box configuration for a domain controller. For example our test user ‘bob’ in our lab is a domain user, he can freely pull up a command prompt and simply enumerate all the domain users, domain admins and other objects such as computers and servers in the domain, just wonderful…(not!!).

disable domain enumeration

Microsoft why on earth would we want our domain users to enumerate our ‘Domain Admins’ group by default??

This just won’t do, so how can we fix it? We can deny read permissions to certain objects in the domain through the use of the access control lists (ACL) in Active Directory. A word of caution here, this is likely to break certain applications so the way we will go about this is in stages. For starters we won’t be modifying any permissions of any users or built-in groups. We will create a new security group called ‘Disable domain read’. We will then add users to this group that we want to deny the read permission for, so when a user of this group tries to read the domain they will get either no results or an ‘access denied’ message. Then add this group at various OU’s in the forest, ticking the deny read permission for that group, this will take affect on all users under that OU. This has the added benefit of simply being able to remove users from the group and also removing the group from any ACLs on OUs, should anything need to be reversed.

An Example

As with the above screen shot we can see that bob is able to enumerate the domain. Lets fix this. First we will create our group:

create disable domain read group

Now as a simple test we will add this group to the ACL of the HR OU. You can see in the below screenshot there are a list of users in this OU already. By making this change we will be denying the read permission on the OU and its contents for members of the group ‘Disable Domain Read’. So right click on the OU and select properties. Select the ‘Security’ tab, then ‘Add’, add in the security group, then select ‘Deny’ on the ‘read’ permission as highlighted in the red box.

Add group to ACL OU HR

Add ‘bob’ to the group and then lets try and enumerate the domain again. Lets see what happens:

disable domain enumeration

Great… bob has now been denied access to reading the users in the HR OU. However, can still see the ‘Domain Admins’ group. I have purposefully done the the configuration this way to show you how granular we can set the permissions. As the Domain Admins group isn’t in the HR OU it has not applied to that object. Now lets go to the other extreme and set at the top level for the entire domain. Apply the same access control entry (ACE) at the domain level, this will filter down to all objects including ‘Domain Admins’. In reality you would want to be more granular than this, applying the ACE in ACLs within the domain at specific OUs, this will give you more control. However as an example lets proceed:

Add group to ACL for the domain

Lets reboot our domain computer and test again:

disable domain enumeration

Perfect, now our domain user is not able to enumerate other domain user accounts and more importantly the ‘domain admins’ group. This is the other extreme and will likely break things so you should apply at specific OU’s however hopefully this should give you a good idea of how powerful the permissions can be and granularity in which we can apply them.

Using this method you should take into consideration that an implicit deny takes precedent over another ACE with the same permission. For example, if there were another ACE that explicitly was allowing the same action the deny would win and take precedent. This means that delegating rights to an OU after you have used this method to allow reading of permissions (ie the reverse) would not work.

Windows Security

This is why we have used a new separate security group just for domain users. If you were in a position where you needed a specific user or service account to be able to enumerate all domain users due to the way an application worked you could remove the user from the group and set alternative permissions on a new group with just that user in it.

Hope this helps. Remember test out your configuration before moving into production!