by greg.spyra


Corporate information security policies among general personal data handling policies, acceptable encryption policies and others, often define privileged access policies. While most of the organizations aim to use one central identity many of them still maintain secondary privileged identities that are entitled to perform sensitive operations.

Privileged Digital Identity

One of the reasons why secondary identities are in use is that a single identity, when stolen gives attacker both un-privileged and privileged rights. One identity is often used to access all corporate systems without need of identity re-verification.

Central employee digital identity (account) because of its common use is exposed to several risks and secondary privileged identity, when properly used under well-defined privileged access security policies eliminates these risks.

Single sign-on (SSO) functionality together with single identity model simplifies access to corporate systems by eliminating a need of re-authentication although at the same time it leads to certain risks. E.g. when authenticated primary identity session is compromised attacker gains access to all SSO enabled systems.

SSO enabled systems hosting sensitive information should support additional safeguards including additional authentication factor or re-authentication of one of the authentication factors what would sufficiently verify legitimate access attempts.

Furthermore correctly implemented data protection program enforces Separation of Duties principle, which ensures that one physical person and one identity cannot perform sensitive operations.

MS AD DS Password Policies Issue

Privileged access policies define password policy for privileged accounts (identities). Unlike unprivileged identity here only strong passwords should be used.

Under Microsoft Active Directory Domain Services (MS AD DS) granular password policies can be defined for different accounts based on their location or security group membership. Employee privileged account, if properly configured will enforce use of only strong passwords making common attacks harder to perform.

Problem that arose here is how to enforce use of two different passwords for unprivileged and privileged accounts. Privileged account password, defined under stronger than unprivileged account password policy, can still be used by employee for both accounts. MS AD DS password policies can define password complexity but cannot enforce employee to use different passwords for each owned account.

Identity and Access Management (IAM) or Privileged Access Management (PAM) systems can perform such checking when employee initially sets account passwords in interconnected systems, however this introduces another risks related to actual implementation of such a functionality. These systems would need to store password hashes for each account therefore maintain another replica of password hashes. For an attacker this is another location where credentials related information could be stolen.

Privileged Account Password Audit

Here we would like to introduce rather static approach, which can be a part of an internal corporate information security audit program. Regularly reviewed account passwords can identify unprivileged accounts that share same password with privileged accounts. While most of the systems store passwords as a hash, the properly implemented privileged password audit process can be relatively secure as password verification can be scoped only to salted and unsalted hashes comparison.

Password Hash analysis


Microsoft Active Directory Domain Services (MS AD DS) is build on top of a flat Extensible Storage Engine (ESE) database. ESE leverages NTDS.DIT to store directory tables. Internal MS AD DS database structure is not that different from what one can see using advanced GUI tools, although internal row numbering is implemented as low level Distinguished-Name Tags (DNT), unique and small values making MS directory capable to store and process approximately 2.15 billion objects during its lifetime.

While MS AD DS seems to be extremely efficient to deliver identity meta-data platform for large enterprises and global organizations it is capable of storing identities with its underlying metadata of entire world population which currently reach something about 7.3 billion people.

Basically NTDS.DIT database file contains 12 tables:

  • MSysObjects
  • MSysObjectsShadow
  • MSysUnicodeFixupVer2
  • datatable
  • hiddentable
  • link_table
  • sdpropcounttable
  • sdproptable
  • sd_table
  • MSysDefrag2
  • quota_table
  • quota_rebuild_progress_table

Each table stores different directory partitions data, however identity (user) information is stored under datatable table.

Export ESE DB table data

To obtain datatable data we will need some tools and libraries that are dedicated to read directly ESE database file. For our Proof of Concept we will use libesedb library and Mac OS X 10.9 system. Additionally to simplify our data mining we will use Python and PyCrypto library.

Assuming we have the latest Xtools installed we need to compile libesedb project.

Figure 1. Configure libesedb project before compiling

Figure 1. Configure libesedb project before compiling

Figure 2. Initiate libesedb library compilation

Figure 2. Initiate libesedb library compilation

Figure 3. Complete libesedb library installation routine

Figure 3. Complete libesedb library installation routine

Next step is obtaining NTDS.DIT database file from one of our domain controllers. There are several ways to copy NTDS.DIT file. For large enterprises it is recommended to use Windows server backup, however for our testing we will use MS Volume Shadow Copy Service (VSS). By default NTDS.DIT file is located under %SystemRoot%\NTDS folder but due to security reasons engineers often place it on non-system disk.

Figure 4. Enable shadow copy for system drive

Figure 4. Enable shadow copy for system drive

Now NTDS.DIT file can be easily copied, however only from the shadow copy. It is important to make a copy of another SYSTEM file, which will be used in later stage to encrypt our password hashes.

Figure 5. Copy required files from shadow copy

Figure 5. Copy required files from shadow copy

Decrypt Password Hashes

Password hashes are still encrypted in our export file with DES algorithm using hive. Hive is a 16-byte long boot key used to encrypt various Windows objects meta-data. Hive in MS Windows systems is simply obfuscated in system registry. Tools we will use to select only security principals from our DB with respective hashes can derive hive from SYSTEM file (we have already copied together with our NTDS.DIT file).

Creddump Python toolset comes with an useful[1] script, which returns all the information we need to complete our analysis.

Figure 6. Retrieve accounts with password hashes using script

Figure 6. Retrieve accounts with password hashes using script

From filtered export data we can see two accounts: priv_user020012 and user020012 have the same password hash therefore employee uses the same password for both privileged and unprivileged account.


[1] Please note that in its current release uses script, which was created for Python 2.x. It has to be slightly modified for Python 3.x which throws an error on non trivial cross-data types casting.


Line: if ((int(tmp[user_accountcontrol_index]) & 2) > 0) and (include_disabled == False)

Replace with: if tmp[user_accountcontrol_index] and ((int(tmp[user_accountcontrol_index]) & 2) > 0) and (include_disabled == False):


The highlighted security issue is a common problem in all types of organizations where additional privileged accounts are used to separate privileged operations from unprivileged ones. We shown that the problem can be addressed with a routine information security audit program supported by simple toolsets what has been shown in above PoC. Efficient implementation should automate all the steps required to verify accounts password compliance by identifying accounts and employees that do not comply with privileged accounts password policies.