Tips to harden Active Directory against SolarWinds-type attacks

The SolarWinds/Solorigate attacks used some concerning methodologies. One of them has been what is called the Golden SAML attack process. Security Assertion Markup Language (SAML) enables the exchange of authentication and authorization information between trusted parties. The Golden SAML technique allows attackers to generate their own SAML response to gain access or control. To do so, they must first gain privileged access to a network to access the certificates used to sign SAML objects. 

You have several means with Microsoft’s Active Directory (AD) to identify this and other techniques used in the SolarWinds attack and prevent them from happening. Firms like Trimarc Security have released PowerShell scripts to analyze and review your AD infrastructure. They provided a script for simple single AD environments to perform a review process. The script looks for key issues in an AD domain that could limit or reduce the security posture of a firm. Here’s what you should review even if you don’t use a script.

User account settings

The first issue involves user accounts. The script reviews for inactive accounts that have not been changed or logged into. The script performs additional reviews of settings that relate to Kerberos including checking for accounts that are configured to not require Kerberos pre-authentication, as attackers are known to have exploited this setting.

This attack is called AS-REP Roast. As part of the authentication process, there is an initial request to authenticate without a password. The attacker can then send a fake AS-REQ (authentication server request), and the key distribution center will immediately send back a ticket granting ticket (TGT) along with additional data encrypted with the user’s key—the password hash. Attackers can obtain this hash and crack it offline. While Microsoft added the control in Kerberos 5, you may still have the setting misconfigured.

Domain password policy

The next thing the script reviews is the domain password policy. Password spray attacks are effective against AD if weak passwords are used, so ensure that a proper password policy has been implemented. Trimarc recommends that you set a password policy with no less than 12 characters and preferably 16 characters or more. Anytime you choose a long password policy, ensure that the policy works with all applications in your domain. Any application that demands that you use a weaker password policy should be investigated for upgrading and or removal from your network as it’s weakening your security posture.

Active Directory backup policy

Some firms do not back up domain controllers and instead rely on installing new domain controllers and replication. Because of the impact of ransomware on networks, this policy is potentially dangerous and could leave a firm at risk. Review whether AD backups are being made. If you use a Microsoft-supported backup process, it sets a flag or attribute to identify the last backup date. If you do not perform a system state backup, you are not properly backing up your AD structure. Trimarc recommends that you run a system state backup to include the flexible single master operation (FSMO) at least once a month and keep them archived for at least six months.

Old Group Policy Preferences credentials

Group Policy Preferences were first released in 2008 and allowed an administrator to update and provide credentials. Because these credentials were encrypted using AE256, it’s possible to use a PowerShell function to reverse the encryption and obtain the plaintext value. While there is a patch to increase the protection by preventing the use of Group Policy preference passwords if you have an old enough domain, you may have inadvertently stored credentials values. Attackers will review your domain for these leftover passwords and use them to attack your domain.

Domain administrator rights and policies

Ensure that you’ve identified any user that is a domain administrator or has equivalent rights. Then review them for additional security issues. Change the passwords for these accounts regularly and add two-factor authentication (2FA) to them. You may need third-party software to add 2FA to administrator accounts.

The domain service account is the KRBTGT account, which is often disabled. It is used to grant Kerberos tickets or to generate golden tickets. An attacker who learns the password to the domain service account can create golden tickets. As MITRE notes, this attack sequence can enable adversaries to generate authentication material for any account in Active Directory. Change this password after any AD administrator leaves or at least two times a year If you follow US Department of Defense guidelines.

Unconstrained Kerboros delegations

The Kerberos “double hop” issue is an old attack method. Kerberos uses the double hop to maintain a client’s Kerberos authentication credentials over two or more connections. Audit and review for unconstrained Kerberos delegations and ensure that this is only used in very isolated situations or not at all. If the Kerberos delegation types are unconstrained when used in a web configuration, it allows impersonation of users to connect to any Kerberos service, not just to any specific service.

Linked Group Policy Objects

Group Policy is powerful and attackers know it. Group Policy Object owners may have the ability to change permissions that they shouldn’t. Be careful when linking GPOs to the domain root and domain controllers’ organizational unit. These owners should be limited to domain administrators or enterprise administrators.

Domain controller patching levels

Review patching levels of domain controllers to ensure that they are appropriate for your network. You should not have domain controllers running older or out-of-date operating systems. Not only does it expose your firm to security risks, it also prevents you from using newer authentication processes that rely on modern operating systems. All domain controllers should be running at a minimum Windows Server 2012 R2.

Review your ability to migrate to Windows Server 2016 or preferably Windows Server 2019 and have your domain infrastructure run on as the most current operating system as you can. Keep monthly patching to a reasonably current state. Having an unpatched Server 2019 will also place your network at risk from various security issues.