Password? See ​“Description”.

Example

In our test domainplayground.local, we created a user account named Topdesk with password T0pDesk!, which we also stored in the description field. This can make life easier for IT staff who need to log in to the account to administer the TopDesk application. Here’s a screenshot showing the new account’s properties:

Reading data from Active Directory

However, this data can be requested by any user within the domain. With the help of the tool PowerView or ADModule (Microsoft’s Powershell-based administration library for Active Directory) it is possible to search for accounts that contain data in this field:

Get-ADUser -Filter {description -like '*'} -Properties samaccountname, description | Select-Object samaccountname, description

This command requests data from all users and filters out all accounts that have an empty description field and then only shows the fields samaccountname and description.

The output of this command shows all accounts with a value in the description field. For the Topdesk user we see a description (T0pDesk!) that looks a lot like a password…

An attacker could use this data to authenticate to any machine within the domain. For example, this account may have local administrator rights on a computer object (in this example probably the server on which the TopDesk application was installed), or may have access to interesting shares, or, of course, to sensitive information within the TopDesk application itself.

What to do as an administrator

It is possible to request this information using the Microsoft Active Directory Management DLL. This DLL can be found by default on a Domain Controller and can be found on every Windows computer on which Remote System Administration Tools are installed. The same command as above can be used:

Get-ADUser -Filter {description -like '*'} -Properties samaccountname, description | Select-Object samaccountname, description

If you find any accounts containing a password in the description field, we recommend removing it. Clearing the description field for the Topdesk account, for example, can be done like this:

Set-ADUser Topdesk -Description $null

Safe storage of passwords

There’s a better way to store shared passwords: using a password manager such as Keepass. You’ll be able to read more about this in our next blog post.

How do you request this information without being a member of the domain?

The data can also be retrieved from a Windows computer that is not joined to the domain. We do need to provide valid login credentials for a normal domain user. We can do this by storing them in a variable using the get-credential cmdlet.

Then a pop-up will appear where we can enter the login details for our user:

Then, we use the following command (using PowerView) to request all account data from the Domain Controller located at IP address 10.0.0.3. We filter out the accounts with an empty description field and then we only show the fields samaccountname and description:

get-netuser -Domain playground.local -DomainController 10.0.0.3 -Credential $creds | Where-Object -Property description | select samaccountname, description

The output shows a description that looks like a password of the TopDesk account. The other descriptions are standard descriptions for domain accounts.

Testing from Linux/​UNIX

If you have no Windows system available, or anti-virus detection is an issue (for example in pentesting or Red Teaming assignments) you can do this from a UNIX/​Linux system (like Kali Linux) as well. Simply send a direct LDAP query to the domain controller:

This gives us a similar result to the one we got on Windows:

Final thoughts

It’s better to use a password manager for shared accounts than to use the Description field, because this field is readable for many more users than you’d like. Hackers can also use the information to expand their access within your domain.

We hope this blog post has provided you with the tools to clear out old password leaks from your domain!