Securing Active Directory (AD) is an important aspect of cybersecurity for any enterprise using it. AD is a central piece of infrastructure that houses user credentials, sensitive data and access to various company systems. Most attacks on Active Directory start with the attacker gaining foothold within the enterprise. From within, one would:
conduct reconnaissance > steal credentials > exploit and escalate privileges > exfiltrate data > apply persistence.
Here I will observe and recommend methods to harden AD security to reduce the overall attack surface.
Clean Up Stale Objects
Whilst maintaining a clean active directory and reducing clutter is nice overall from an operational perspective, AD objects are still an exploitable attack vector. Reducing the number of objects that do not have any members will reduce the attack surface. One should:
- Assess and determine whether the object is still in use, and make informed decisions to delete the objects, or at the very least;
- Consolidate objects if there are multiple that serve the same purpose, or have crossover functionality.
In doing the above, you will also have the opportunity to contextualise the objects by adding descriptions to them, which will support day-to-day desktop operations. Scope creep can occur with each additional object created without supporting documentation.
Get-ADGroup –Filter * -Properties Members | where { $_.Members.Count –eq 0 } |select groupcategory,samaccountname,distinguishedName | export-csv C:\Temp\Stale_Objects.csv
Clean Up Unused Accounts
As with stale objects, disabling or deleting unused or forgotten accounts will also reduce the attack surface. There are three benefits to conducting this:
- Limit the potential attack vectors.
- Eliminate any potential maintained persistence through a low-lying sleeping account an attacker has established. Hackers will also look for inactive accounts to enter the domain under the cover and not be suspect.
- Restrict access to information from unauthorized, terminated users. Manual terminations can also result in scope creep if the team is not consistently and proactively disabling users post-termination.
One should:
- Conduct an audit of user accounts based on PasswordLastSet or lastLogonTimeStamp
In doing the above, you can also reclaim database storage space.
Below code checks for all accounts.
$d = [DateTime]::Today.AddDays(-180)
Get-ADUser -Filter '(PasswordLastSet -lt $d) -or (LastLogonTimestamp -lt $d)' -Properties PasswordLastSet,LastLogonTimestamp | ft Name,PasswordLastSet,@{N="LastLogonTimestamp";E={[datetime]::FromFileTime($_.LastLogonTimestamp)}}
Restricting Service Accounts
Service accounts should be locked down as much as possible with least privilege applied to it. They are generally created and assigned to external vendors for admin and support purposes. These accounts are often forgotten, not monitored and can be hazardous as an attack vector. Service accounts are almost always over-privileged due to documented vendor requirements or because of operational challenges. Attackers may also look for common service accounts that are known to exist within Domain Admins.
One should:
- Apply a periodical password, set password expiry, or opting for password requests can assist in hardening security.
- Identify permissible rights to reduce privileges and remove service accounts from Domain Admins.
In doing so, you will reduce the risk of 3rd party compromise in a supply chain attack.
Implement Privileged Identity Management (PIM)
PIM enables you to limit standing administrator access to privileged roles, discover who has access, and review privileged access. It also allows for dynamic passwords to combat stolen admin credentials. Implementing PIM solutions, such as BeyondTrust, will also align the enterprise with ACSC’s Essential Eight Maturity Model.
Backup Active Directory
Incremental or full backups are pivotal for contingency planning and for the continuity of business operations. Domain Controllers (DC) are prone to failure, corruption, viruses and ransomware. Periodical backups of all domain controllers is highly recommended. There is no definitive answer on how long, how often, and how many DCs you should back up, however, enterprises should conduct backups applicable to their unique needs in accordance with the NIST Cybersecurity Framework and ISO/IEC 27001. Things to consider are:
- Purpose of the backup (Restoring critical failure vs additional implementation for accidental deletion)
- Full Backup vs System State Backup
- How many DCs across how many sites you have
- Resources available to support backup storage
System state backup on DC command:
wbadmin start systemstatebackup
Additional info: https://activedirectorypro.com/backup-active-directory/
Enforcing Stronger Password Policy
By default, AD offers a password policy that prevents the bare minimum. One should:
- Set account lockout threshold to minimum 3 attempts to prevent bruteforcing
- Implement a minimum of two breached passwords blacklists to prevent dictionary attacks. This also falls under the regulatory recommendation of NIST 800-63B. Further to this, offering a visual guidance is highly recommended
Check current password policy:
Get-ADDefaultDomainPasswordPolicy
Configure Read-Only Domain Controllers (RODC)
The main purpose of the RODC is the secure installation of the own domain controller in remote branches and offices where it is difficult to physically secure an ADDS role server. The RODC contains a read-only copy of the Active Directory database. This means that nobody can change data in AD.
Patching Vulnerabilities
This goes without saying. Privilege escalation can occur by exploiting unpatched vulnerabilities. Patching systems such as the AD and DC will also align the enterprise with ACSC’s Essential Eight Maturity Model.
Check Default Settings
Check auto permissions assigned to AD and rights to basic security groups such as account operators. Hackers who are familiar with default settings will look to checking and abuse these settings.
Last but not least…
Gaining a Deeper Understanding of the Enterprise’s Active Directory
Where time permits or if undergoing pentesting, understanding privilege relationships within the AD will enable one to identify paths of attack, such as identifying relationships and paths to go from a standard user object to domain admin object. This venture is greatly assisted by BloodHound: https://github.com/BloodHoundAD/BloodHound