Skip to content

šŸ‘¤ Users

One of the key points for using Active Directory is the users management. Every organization manages its users in different ways, setting for them name formats, assigning different permissions, etc.

To easily manage the users in Active Directory, their are stored as a objects in the centralĀ databaseĀ that can be consulted and manipulated from any point of the domain (if you have enough rights).

User properties

User Identifiers

The user object stores many different data, but the first attributes to be taken into account are those that allows us to identify an user.

For identifying an user usually the username is used, that is stored in theĀ SamAccountNameĀ attribute. Additionally, theĀ SIDĀ (Security Identifier) can also be used to identifying the user.

The user SID is similar to the domain SID, and, in fact is the combination of the domain SID plus the user RID (Relative Identifier), which is the last number that appears in the user SID.

PS C:\Users\User> Get-ADUser User


DistinguishedName : CN=User,CN=Users,DC=etherdrake,DC=local
Enabled           : True
GivenName         : User
Name              : User
ObjectClass       : user
ObjectGUID        : 58ab0512-9c96-4e97-bf53-019e86fd3ed7
SamAccountName    : user
SID               : S-1-5-21-1372086773-2238746523-2939299801-1103
Surname           :
UserPrincipalName : user@etherdrake.local

Get user information

In this case the domain SID isĀ S-1-5-21-1372086773-2238746523-2939299801Ā and the user RID isĀ 1103. Some tools display the SID in their output instead of the username (since its used in some structures likeĀ security descriptors), so you should be aware of its format in order to identify it.

Also, theĀ DistinguishedNameĀ is used by theĀ LDAP API to identify the objects, so if you query the database by using LDAP (which is one of the most common ways) you will probably see references to objects through itsĀ DistinguishedName.

User Secrets

Moreover, the database also needs to store the user secrets in order to allow the Domain Controller to authenticate the user. The user password is not stored in plaintext, but the following secrets derived from it are saved:

  • NT hash (and LM hash for the older accounts)
  • Kerberos keys

Needless to say, that user secrets cannot be retrieved by non admin users. Not even the domain computers can access to them, but leave the authentication to the Domain Controller.

In order to get the user secrets, you need administrator privileges (or equivalent) toĀ dump the domain databaseĀ with a dcsync attack or grabbing theĀ C:\Windows\NTDS\ntds.ditĀ file from the Domain Controller.

LM/NT hashes

TheĀ LM and NT hashesĀ are stored both in Windows localĀ SAMĀ and Active Directory NTDS databases to authenticate the local and domain users, respectively. These hashes, both LM and NT are 16 bytes long.

Password: 123456 LM hash: 44EFCE164AB921CAAAD3B435B51404EE NT hash: 32ED87BDB5FDC5E9CBA88547376818D4

LM and NT hashes of a password

However,Ā LM hashes are pretty weakĀ so they are not used since Windows Vista/Server 2008. TheĀ procedure to create an LM hashĀ is the following:

  1. Convert the user password into uppercase. (This reduces the search space for a bruteforce attack).
  2. If the user password is less than 14 characters is padded with NULL characters until the length is 14. If the password is more than 14 characters, then is truncated. (Is useless to have passwords of more than 14 characters).
  3. The password is then split in two strings of 7 bytes each one.
  4. Each 7-bytes string is used as key to encrypt theĀ KGS!+#$%Ā string using the DES cryptographic algorithm. This result in two hashes.
  5. The resultant two values are concatenated in order to form the LM hash. (You can crack each part separately)

upper_password = to_uppercase(password) 14_password = truncate_to_14_bytes(upper_password) 7_part1, 7_part2 = split_7(14_password) hash1 = des(7_part1, "KGS!+#\(%") hash2 = des(7_part2, "KGS!+#\)%") lm_hash = hash1 + hash2

LM hash calculation pseudocode

On the other hand, the NT hash is a little stronger, but aĀ saltĀ is not used to calculate it, so it can be cracked by using precomputed values (likeĀ rainbow tables).

If you are curious, the NT hash is calculated by applying theĀ MD4Ā algorithm (thatĀ is obsolete) directly to the Unicode version (specifically the UTF-16LE encoding) of the user password.

nt_hash = md4(encode_in_utf_16le(password))

NT hash calculation pseudocode

Many times the NT hash is called NTLM hash, however this can be confusing since the NTLM protocol also use hashes, called NTLM hashes. In this article an NTLM hash will be a hash of the NTLM protocol.

Many tools allow you to extract the LM and NT hashes, and they usually return an output with several lines, one per user, with the formatĀ <username>:<rid>:<LM>:<NT>:::. In case of LM is not being used, its value will beĀ aad3b435b51404eeaad3b435b51404eeĀ (the LM hash of an empty string).

Administrator:500:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0::: Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0::: DefaultAccount:503:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0::: WDAGUtilityAccount:504:aad3b435b51404eeaad3b435b51404ee:6535b87abdb112a8fc3bf92528ac01f6::: user:1001:aad3b435b51404eeaad3b435b51404ee:57d583aa46d571502aad4bb7aea09c70:::

Hashes dump format

It is important for a pentester to recognize NT hashes since, even they are not the user passwords, are used for authenticate in Windows machines, so they are very useful. They can be used to performĀ Pass-The-HashĀ orĀ Overpass-the-HashĀ attacks in order to impersonate users in remote machines.

Additionally, you can try to crack the LM and NT hashes withĀ hashcatĀ to recover the original password. If you are lucky and the LM hash is present, this should be quickly.

Kerberos keys

Apart from the LM/NT hashes, theĀ Kerberos keys, derived from the user password and used in the Kerberos authentication protocol, are stored.

The Kerberos keys can be used to ask for a Kerberos ticket that represents the user in Kerberos authentication. There are several different keys, and different ones are used for different Kerberos encryption support:

$ secretsdump.py 'etherdrake.local/Administrator@192.168.100.2' -just-dc-user user
Impacket v0.9.21 - Copyright 2020 SecureAuth Corporation

Password:
[*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash)
[*] Using the DRSUAPI method to get NTDS.DIT secrets
etherdrake.local\user:1103:aad3b435b51404eeaad3b435b51404ee:cdeae556dc28c24b5b7b14e9df5b6e21:::
[*] Kerberos keys grabbed
etherdrake.local\user:aes256-cts-hmac-sha1-96:ecce3d24b29c7f044163ab4d9411c25b5698337318e98bf2903bbb7f6d76197e
etherdrake.local\user:aes128-cts-hmac-sha1-96:18fe293e673950214c67e9f9fe753198
etherdrake.local\user:des-cbc-md5:fbba85fbb63d04cb
[*] Cleaning up...

Kerberos keys extracted from the domain database

These keys can be used in aĀ Pass-The-KeyĀ attack to retrieve a ticket for the impersonated user. Then you can use that Kerberos ticket to authenticate against different services of the domain on behalf of the user.

UserAccountControl

One interesting property of the user class is theĀ UserAccountControlĀ (UAC) (do not confuse it with the User Account Control mechanism to avoid executing elevated programs in Windows machines).

The UserAccountControl property contains aĀ series of flagsĀ that are very relevant for the security and the domain and used in many attacks mentioned in this post. Here are the most relevant:

  • ACCOUNTDISABLEĀ -> Account is disabled and cannot be used.
  • DONT_REQUIRE_PREAUTHĀ -> The account doesn't require Kerberos pre-authentication.
  • NOT_DELEGATEDĀ -> This account cannot be delegated through Kerberos delegation.
  • TRUSTED_FOR_DELEGATIONĀ -> Kerberos Unconstrained Delegation is enabled for this account and its services.Ā SeEnableDelegationPrivilegeĀ required to modify it.
  • TRUSTED_TO_AUTH_FOR_DELEGATIONĀ -> The Kerberos S4U2Self extension is enabled for this account and its services.Ā SeEnableDelegationPrivilegeĀ required to modify it.

Other user properties

There are other properties that can be useful in a pentest:

  • DescriptionĀ -> A description of the user. It can give an idea of the permissions of the user, and sometimes even includes the password.
  • AdminCountĀ -> Indicates if the user (or group) is protected by theĀ AdminSDHolderĀ object, or it has been. Since sometimes is not updated, use it only as a reference.
  • MemberOfĀ -> Groups of which the user is a member. This property is logical and is generated from the groupsĀ MembersĀ property.
  • PrimaryGroupIDĀ -> The primary group of the user. This group doesn't appear inĀ MemberOfĀ property.
  • ServicePrincipalNameĀ -> Services of the user. Can be useful for the Kerberoast attack.
  • msDS-AllowedToDelegateToĀ -> The list of services for which the user (and its own services) can impersonate clients using Kerberos Constrained Delegation.Ā SeEnableDelegationPrivilegeĀ required to modify it.

Important Users

To consult the users there are several options, like theĀ net user /domainĀ command, or Powershell. There is no need to have an special privilege to list users, any user can do it.

PS C:\Users\User> Get-ADUser -Filter * | select SamAccountName

SamAccountName
--------------
Administrator
Guest
krbtgt
user
han
BALENA$

List users with Powershell

As you may notice, my test domain is little with very few users, but in a real engagement there will be hundreds or thousands of users. So it should be important to distinguish what are the really important. This could be a little tricky since it depends on the organization, but usually members of the IT team use to have privileged users, they need it to do their work.

Moreover, by default theĀ built-inĀ AdministratorĀ user is the most privileged account of the domain. It can perform any action in any computer. So if you are able to compromise this account, you can have total control of the domain (and even the forest by usingĀ the SID history attack).

Additionally, theĀ krbtgtĀ account is very important too. Its secrets (NT hash and Kerberos keys) are used to encrypt the tickets (specifically the TGTs) used by Kerberos that allows to authenticate users. If you are able to compromise theĀ krbtgtĀ account, you will be able of createĀ Golden Tickets. Usually, this account can only be compromised by dumping the domain database, since its only used in the Domain Controllers, which will require that you have administrator privileges in the domain.

Computer accounts

Another thing to take into account is that in a organization, each person has its own user, and even certain people like the IT department could have more than user per person to perform different tasks. Moreover, alsoĀ each computer of the domain has its own user, since they also need to perform their own actions in the domain, like for instance, update the Group Policies, verify the credentials of domain users logged in the computer, etc.

The difference between user accounts and computers accounts is that the firsts are stored as instances ofĀ User classĀ in the database whereas the others are stored as instances ofĀ Computer classĀ (which is a subclass of User class). Moreover the computer accounts names are the computer hostname finished with a dollar signĀ $.

You can check it by executing the following command:

PS C:\> Get-ADObject -LDAPFilter "objectClass=User" -Properties SamAccountName | select SamAccountName

SamAccountName
--------------
Administrator
Guest
DC01$
krbtgt
user
WS01-10$
WS02-7$
DC02$
han
BALENA$

Retrieve all users of the domain

As you can see, there are many more users than using theĀ Get-ADUserĀ command, since subclasses of User class are now included. You can appreciate that new accounts finish with a dollar sign and seems to have a computer name. For example,Ā DC01$Ā andĀ DC02$Ā for the Domain Controllers andĀ WS01-10$Ā andĀ WS02-7$Ā for the workstations.

Moreover, the computer objects also saved information about their operating system, that can be retrieved from the attributesĀ OperatingSystemĀ orĀ OperatingSystemVersion.

Also, many organizations have rules to choose the name of the computers as well as the users, so if you are able to make sense of the names, you may be aware of the use of the computer and user accounts and which of the can be privileged or contain access to sensible information. Additionally you can check another attributes of the objects likeĀ DescriptionĀ in order to find more information there (and even cleartext passwords). TheĀ Find-DomainObjectPropertyOutlierĀ Cmdlet ofĀ PowerviewĀ can be useful for that purpose.

Trust accounts

However there is also theĀ BALENA$Ā account that appears in bothĀ Get-ADUserĀ andĀ Get-ADObject, but whose name is finished by a dollar sign. That could be normal user (there is no problem with creating usernames finished withĀ $), however, as we have seen previously, there is a trust with theĀ bal.enaĀ domain.

When an trust is established, an associated user object is created in each domain to store the trust key. The name of the user is the NetBIOS name of the other domain, finished in $ (similar to a computer account name). For example, in case of the trust between the domains FOO and BAR, the FOO domain would store the trust key in the BAR$ user, and the BAR domain would store it in the FOO$ user.

PS C:\> Get-ADUser  -LDAPFilter "(SamAccountName=*$)" | select SamAccountName

SamAccountName
--------------
BALENA$

List trust accounts in domain

ThisĀ BALENA$Ā user object is used to store the trust keys, which are the NT hash or Kerberos keys (one of other is used depending on the context). If you canĀ get the secretsĀ of this account, you can createĀ inter-realm Kerberos tickets.