Password Audit and Control Guidance - Active Directory

Tldr

Password filters

Less tl;dr

I keep finding loads of password reuse in target environments. This is particularly common in users that keep low and high privileged accounts, and the practice generally results in trivial privilege escalation within the environment. This practice provides an “easy win” for an attacker, and serves to undermine an organisation’s security programme and the effectiveness of its defence-in-depth controls. I think the following could help solve the problem, or at least work towards making it significantly less bad (Although you only need one win as an attacker for password reuse).

The problem

Poor user security practices, such the selection of weak passwords and their reuse across multiple accounts, are providing attackers with easy access and trivial privilege escalation capability within an environment. When a standard user account shares credentials with a higher-level account, such as one for an administrator to a group of servers, it can lead to substantial lateral movement for an attacker. This is especially true in the case of the user being a member of domain admin or a similar highly privileged group. A contributing factor to the ease of privilege escalation is the account naming schemes for user accounts, as they can make it trivial to escalate within an environment whilst generating minimal noise – at best, a single login event. The problem is significantly worse in environments with forest-level trusts in Active Directory which, by default, do not allow either side to masquerade as other users within the other foresti. This means that, when password reuse occurs, it generally results in a foothold within the other forest.

The problem poses the following questions:

• How many users are using the same credentials across accounts? (In particular, do administrators use the same credentials across their non-administrative accounts?)
• How many users use ‘weak’ credentials that could be easily guessed or cracked by an attacker?

The solution

Two ideas:

• Password auditing. The suggested process can be performed periodically to measure the extent of the problem within an environment.
• Prevention controls. The suggested mechanisms can be implemented to increase the sophistication of password complexity requirements and to prevent password reuse within the environment. (It should be noted that these options require modification to key authentication mechanisms within the environment; namely the domain controllers.)

Risks

• Any information extracted from Active Directory that is not adequately controlled (i.e. through loss, theft or the improper clean-up of an analysis host) increases the likelihood of a malicious internal or external party obtaining and using the credential information to move through the environment. The impact of such a compromise can be substantial due to Pass the Hashi style attacks.
• Consequently, when the credential data is in a hashed state it can still be used to successfully authenticate to systems.
• I don’t think Microsoft endorse this kind of thing at all, even though with password filters they’ve made it pretty easy.

Doing an Audit

The process can be broken the following components.

• Audit. Obtaining and analysing credentials:
  • Offline vs online credential gathering mechanisms.
  • Domain controller selection.
  • Analysis host selection.
  • Credential types.
• Technical. Controls to prevent poor password selection and reuse:
  • Preventing weak passwords.
  • Preventing cross-account password reuse.
  • Inter-forest considerations.

Obtaining creds

Three options are listed here as mechanisms for performing credential gathering: DCsync; recovery from NTDS.DIT; and reversible encryption. The first (DCsync) and third (reversible encryption) options are online mechanisms, whereas the second (recovery from NTDS.DIT) can be performed offline. Offline analysis is the preferred option, as the audit can be performed without environment interaction, which prevents the introduction of tools to the corporate environment as well as the generation of alerts that require investigation. If the environment maintains backups of its key infrastructure, the recommended approach would be to retrieve domain controller backup for the credentials analysis.

DCsync

This option entails abusing the well-known API call ‘IDL_DRSGetNCChanges’i over a network to a domain controller, via a technique known as DCSync. The API call needs high level privileges (generally domain administrator) and can be used to download all users’ credentials. This can be achieved with tools such as Mimikatz, however that approach replicates common attack strategies which should not generally be ignored by a security team.

Recovery from NTDS.DIT

This option involves taking an existing, recent backup of a domain controller, then recovering the ntds.ditiv file, SAM, SYSTEM and SECURITY registry hives onto a separate machine. Tools such as Impacket’sv SecretsDump.py can be used to dump the hashed credentials out of the Active Directory database. If backups are not available, this could also be performed online using inbuilt Windows utilities such as Volume Shadow Copy to retrieve the files, which can then be processed with the Impacket tooling.

Reversible encryption

This option uses a known feature in Active Directory that stores passwords with reversible encryption, however the encryption only takes effect after the user has changed their password. This would bypass the requirement to crack credentials and determine patterns against the entire dataset.

Note. With this approach, passwords are effectively stored plaintext. As such, this option may be unappealing, particularly for risk averse organisations. Also, it seems like terrible advice

Selecting a DC

Any domain controller for the domain that is to be audited is sufficient for obtaining credentials, with one exception. The selection of a read-only domain controller would not be suitable, as it would only retain credentials for select accounts as per its configurable replication policy. In the case of multiple domains, a domain controller from each domain would need to have credentials extracted.

Analysing credentials

Host selection

Once credentials have been obtained and transferred to a suitable host, connecting the device to the network increases the risk of an attacker retrieving credentials for the entire domain through the compromise of that single host.

For this reason, analysis will ideally be performed on an air-gapped device, whether it be a workstation or special purpose server. The secure transfer of data to the host could be performed via a USB storage medium that is then promptly erased upon confirmation that the Active Directory database and relevant components have been successfully transferred to the secured host.

Ideally, the analysis host would have several high-performance GPUs to facilitate password cracking (see Appendix - Hardware considerations). However, as the passwords are unsalted, a simple script to compare hashes would identify any passwords that are used across multiple accounts.

Note: The analyst that performs this procedure will have derived domain admin (or any group) membership for all domains for which they have an exported dataset.

Credential types

Active Directory holds multiple types of accounts that will also be extracted during the credentials gathering process. Although analysis primarily sticks to “human” user accounts, awareness of the other types of accounts and edge cases is important.

When exporting credentials from Active Directory, the following form of usernames will be observed.

• Accounts not ending in a dollar sign (e.g. USERNAME);
• Accounts ending in a single dollar sign (e.g. DEVMACHINE$); and
• Explicitly named account ‘krbtgt’.

Accounts without a dollar sign are generally user accounts, and will therefore form the bulk of the analysis.

Accounts ending in a dollar sign are either machine accounts or Active Directory trust keys. Both are randomly generated, will automatically change periodically, and are of little interest for analysis. These accounts should not be included in statistical analysis or overall totals.

One special account needs to be mentioned – the ‘krbtgt’ account. This account is used for Kerberos and will also have a randomly generated password, however this credential does not change. If this account hash is compromised, it can result in a situation where an attacker can create legitimate Kerberos tickets for valid accounts and set permissions which do not necessarily reflect “real” Active Directory permissions.

Controls to prevent poor password selection

Although password policies in Active Directory can have complexity enabled, users can still select known bad passwords that, although comply with complexity requirements, are considered weak. The inbuilt complexity functionality is able define a minimum length and require inclusion of some or all character class types (lower alpha, upper alpha, numeric, and symbol), however it cannot prevent the use of common strings such as the organisation name or ‘password’

Note: While passwords such as ‘Summer2019!’ will meet most complexity policies, they are not considered strong passwords. Common strings and predictable variations are repeatedly observed in testing engagements, and provide attackers with an easy, low-privileged foothold within an environment

Preventing weak passwords

To combat the inflexibility of Active Directory’s inbuilt password policy, multiple open source projects have been created to address its limitations. The most notable of these is OpenPasswordFilteri. The solution follows these steps.

• On a password change event, the password is sent to a domain controller.
• The domain controller checks the unencrypted password against the inbuilt password policy.
• The domain controller checks the unencrypted password against every loaded Password Filter.

As such, the solution can be configured to:

• outright block a given password (e.g. Summer2018); and
• block passwords with a given a partial string (e.g. block any password with ‘Welcome’ or ‘Summer’).

Implementation requires some modification to domain controllers. Specifically, it requires the installation of a service to manage a list of bad passwords (and partial matches), and then the loading of a dynamic linked library (DLL) into the Local Security Authority Subsystem Service (LSASS) at boot. This must be performed on all domain controllers for the domain.

Note. The degree of supportability for this solution from Microsoft is uncertain; however, as this method is published on MSDN, it is assumed to be endorsed.

Preventing cross-account password re-use

While not a specific goal of the Open Password Filter project, modifications can be made to the solution to stop users from reusing the same password in the domain. A simple approach could be as follows.

• Automatically export and ingest the entire domain’s worth of password hashes periodically into the password comparison service.
• Compare incoming password changes (after hashing) to the hashed password dataset, rejecting if a matching password exists.

This simple process would be user agnostic and would therefore not require mapping between a given user account and any standard or administrative equivalents. However, this simple approach may not be ideal for reasons such as:

• There is a potential to bypass the process under circumstances where an administrative user resets both an unprivileged and privileged account within the hash loading period; and
• as a user agnostic approach, a failed password change for one user could inform them of its existing use and prompt the spraying of the password against the domain to find the matching username.

A more complex process could compare the incoming password against a matching username, providing the account names are programmatic and derivable from non-privileged accounts.

Note. Implementation of this type of solution should be limited to domain controllers; any host that would be sent passwords for comparison would need to be treated as a domain controller. Additionally, the solution’s tuning could increase the level of alerting to which a security team would need to be aware.

Cross domain applicability

These technical controls would not provide a cross domain solution without some modification and serious thought. A naïve implementation might store credentials for a separate forest, which would result in breaking the forest security boundary.

A different approach could involve an automated process that attempts to log into the other domain with the credentials given on a password reset – this could be filtered to specific accounts matching a regular expression (i.e. privileged only). If a successful login occurs in the other forest, the password’s cross-forest reuse is identified can then be rejected. This solution would generate parallel domain login events which would need to be acknowledged by a security team.