How to Secure Active Directory: a Red Teamer Perspective
Introduction
Although a number of organisations are moving to cloud solutions, such as Azure AD, a large number of them still have an on-premise Active Directory environment or a hybrid environment built around standard Microsoft Active Directory. In recent years, there has been a large number of vulnerabilities being disclosed for Active Directory, as well as a number of exploitation tools being made easily available to everyone on the internet. This blog post wants to illustrate how to secure your Active Directory environment based on the most common vulnerabilities that Proelians identifies during red team engagements and internal penetration tests.
Default Misconfigurations
Due to its complexity, Active Directory has a number of misconfigurations which, in some cases, are actually present in its default configuration.
Insecure Protocols
Active Directory makes use of LLMNR and NBT-NS for the discovery of network resources. These protocols can be abused by attackers with a tool such as Responder in order to disclose NTLM hashes of user accounts. By listening on the network for long enough, an attacker could potentially get access to privileged accounts and compromise your environment.
Luckily, these protocols can be disabled quite easily with the following GPO settings
Computer Configuration > Administrative Templates > Network > DNS Client
Enable Turn Off Multicast Name Resolution (should be set to "Enabled")
Relaying attacks
SMB => SMB
Another interesting attack is NTLM relaying. In summary, this allows an attacker to forward an incoming SMB authentication request to another system, which would allow them for example to use an authentication request coming from a domain administrator to authenticate to a privileged server, all without knowledge of the domain administrator password.
The caveat to this attack is that the target system must have SMB signing disabled or not enforced. This is enabled by default on domain controllers, however you need to enforce this policy on the domain as per Microsoft guidelines.
SMB => LDAP(s)
Although these settings will protect the environment from relaying an incoming SMB connection to an SMB server, there are a number of other relay attacks that can be performed, such as relaying SMB connections to an LDAP server. This could allow an attacker to perform Kerberos delegation attacks and take over servers within your domains under certain configurations. Additionally, a recent exploit (KrbRelayUp) was published which would allow a low privileged attacker with remote access to a system to quickly escalate their privileges to a local administrator. This works by default on any Active Directory environment, and the only way to prevent this and potentially other LDAP relay attacks is to enforce LDAP signing as per Microsoft recommendation.
ADCS
Active Directory Certificate Services (AD CS) is a built-in AD tool that allows administrators to manage public key certificates for services. If your organisation is using AD CS, be aware that a number of exploits are available for this which would allow an attacker to escalate their privileges to a domain administrator even on default AD CS configuration. An in-depth explanation of these attacks can be found on the original blog post and whitepaper.
A review of the AD CS configuration is needed to make sure that certificate templates in use by your organisation are not exploitable. Additional security consideration can be found on the Microsoft guidelines.
Securing Accounts
The core of Active Directory is the possibility to manage user accounts. It is possible to assign roles to groups or users so that they are granted (or not) access to network resources. Additionally, each system within your network has local accounts which are often overlooked and not periodically reviewed as they are not centrally managed.
Securing Local Accounts
Even when joined to an Active Directory domain, Windows systems can have local accounts which might be used when the machine is not connected to the network. Among them, probably the most sensitive ones are accounts with local administrator access, which include the default built-in "Administrator" account.
This account is unique for a number of reasons. When referring to the default local administrator account, most likely we are referring to the account marked as relative id (RID) 500. From an attacker point of view, the RID 500 account is particularly interesting as this cannot be locked out. This means that an attacker inside your network has an unlimited amount of time and attempts to guess or brute-force the local administrator password. Additionally, medium to large enterprises are often seen to re-use the password of the local administrator account across multiple machines, which means that an attacker who has managed to compromise one of your systems, will most likely have full access to other machines inside your network.
Luckily, Microsoft is now disabling the local administrator account by default starting from Windows 10 and Windows Server 2016, however your environment might still have this account enabled for legacy usage. In which case, Microsoft recommends the usage of the Local Administrator Password Solutions (LAPS) so that each administrator password is strong, unique, and can be managed in Active Directory.
Securing Domain Accounts
Securing Active Directory domain accounts can be a difficult challenge, as your organisation might have hundreds of active users. Typically, the main issues with domain accounts can be divided in:
Use of weak passwords
Unnecessary privileges assigned
There are number of recommendations that can be applied when it comes to password management:
Strong password policy: given the current password policy guidelines, the focus should be on enforcing passwords of sufficient length (CIS recommends at least 14 characters) so that users are educated to use passphrases (combination of random and memorable words) rather than passwords, as these are much more difficult to crack.
Review your password reset mechanism: if users requesting a password reset are all given the same common password, this creates a password reuse issue in the environment that could be easily exploited by an attacker.
Periodic Password audits: this could be done internally or by an external third party and it consists in performing password cracking exercises against your users’ passwords. You can find these hashed in your NTDS file on the domain controllers. There are a number of tools to perform this audit, but you should ensure that the tools or the parties performing the audit are trustworthy as you will be giving them access to your entire active directory database of passwords. Note that if you are using Active Directory Domain Service (AD DS) in Azure, Microsoft provides a password protection tool that prevents users from setting weak or banned passwords.
User Awareness: periodic security training that will help your users understand the risk of using a weak password is a very efficient way of reducing weak passwords within your network. Even with technical controls in place, an employee might still setup a password that could be considered weak, and that’s where user awareness training shows its benefits.
When it comes to unnecessary privileges, the main misconfigurations that we see when facing Active Directory environments relate to:
Unnecessary Administrator Accounts: your organisation might have users that are part of privileged groups such as Domain Admins or Enterprise Admins, which actually do not require said role. For example, some organisations might assign full permissions to members of the helpdesk group who only need the privilege to reset users' password, or give domain administrator privileges to a SQL administrator group which, in reality, would only need administrator access to your SQL servers. It is recommended to perform a periodic and regular review of all your privileged accounts to ensure that unwanted privileges are not assigned.
No Privilege Separation: when users do need domain administrator privileges, it is necessary to separate their privileged accounts to their standard user accounts that they need to use for their day-to-day activities, such as reading emails or browsing the web. If that is not done, it will mean that every action performed by the user will be done under a privileged account. In case of a user compromise, such as a malware delivered via email, the attacker would instantly get domain administrator privileges and compromise your domain.
Unnecessary Users and Group Permissions: sometimes, even standard domain user accounts might be assigned with unnecessary privileges, such as local administrator privileges on a legacy system. This is something that might go unnoticed for a long time and could be fairly tricky to detect. This is something that can be identified during an internal penetration test by running a tool such as Bloodhound which maps Active Directory users and relationships within a domain environment.
Audit Shared Folders
Another aspect that usually goes unnoticed is shared folders and network resources that your company makes available to their users. These include hundreds if not thousands of files, such as images, documents and tools. However, permissions of these files and folders could be insecure, as they might be too open for a certain group of individuals and expose sensitive files which are not appropriate for the user’s role. For example, if any domain users account is given access to a folder containing HR or financial data, this access would also then be available to an attacker who can compromise any domain user.
Additionally, information such as administrator passwords can also be disclosed in database files or scripts used by the IT department. This actually happened in the most recent Uber breach, where the attacker identified a PowerShell script with an administrator password on an open network share.
It is recommended to perform periodic review of shared resources to ensure that no sensitive information can be accessed from a standard domain user account point of view. There are PowerShell scripts such as the one made available by PowerView who can automate the process based on certain search criteria.
Monitor for Compromise
Even though you have hardened your corporate network following best practices and you are confident that an external attacker cannot breach the external perimeter, it is always recommended to assume a breach and monitor for signs of an internal intruder. Your organisation might be one compromised by a 0day or through phishing emails, and for this reason you should ensure that you have strong event logging and monitoring in place.
Windows Events
If you do not have access to any third-party tooling, Windows logging and monitoring still provides an excellent starting point for your security operations. A large number of events can be logged which relate to authentication, unauthorised changes to the environment, suspicious Kerberos events and many others. Windows have provided excellent guidelines on how you can start monitor your Active Directory for a compromise, alongside with a list of events which you should be look out for:
https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/appendix-l--events-to-monitor
Third-Party Monitoring
Third-party monitoring software might offer you a wider spectrum when it comes to events generated by a host or on the network. Software such as Endpoint Detection and Response (EDR) will collect data from an endpoint and will be able to detect and alert you even on the most sophisticated attacks. However, there are a large number of vendors offering EDR solutions, and they all vary in terms of the algorithm or metric used to detect an intrusion. Additionally, they might need fine tuning, as due to the very large number of events that they might generate, alerts related to a real compromise might get lost in the noise.
If you would like to evaluate the security of your Active Directory environment and test the reliability of your monitoring and logging solution, contact us and inquire about our internal penetration test and purple teaming services.
