Microsoft’s Active Directory (AD) is ubiquitous among organizations and is a common target for hackers. Compromising AD can lead to the deployment of ransomware and theft of sensitive information, which can be costly to an organization and negatively impact their public image.
As a team of pentesters, we at Vumetric Cybersecurity regularly attack (and compromise) our clients’ Active Directory environments as a means to improving their security. In doing so, it has become clear that AD’s default implementation is often insecure and subject to common misconfigurations that increase risk. Windows networks often favor compatibility over security, leaving them open to attacks.
This post will cover the most common attacks and how to secure Azure Directory against them by using real examples from our pentesting methodology. The focus will be on traditional Active Directory implementations – not Azure AD – although some concepts will overlap.
What real-world attacks look like
We assume that attackers have gained some level of access, such as the following:
- A phishing campaign that has compromised a low privileged user’s workstation
- A hacker who has compromised an external system with internal network access
- A malicious actor with internal access such as a disgruntled employee
- An attacker with physical or wireless access to the internal network
From a simple foothold, further attacks can be launched. Ultimately, the goal is to gain credentials of higher privileged users and eventually a Domain Administrator (DA) to gain complete control over the AD environment. From there, ransomware can be deployed, sensitive information can be exfiltrated, and extortion attempts can begin.
We simulate this type of scenario during our pentests by working from a low privileged foothold with the goal of escalating privileges using the following attack paths.
Poisoning the Network
The Attack
Using our initial foothold, we target specific Windows protocols to man-in-the-middle attacks in an attempt to capture the password hashes of users on the network; specifically, name-resolution protocols for file and web resources, such as LLMNR, NetBIOS Name Resolution, and WPAD, which are typically enabled by default and inherently insecure.
Here is an example of hashes being capture using the Python tool Responder:
This type of attack can also be launched from Windows using a suite of PowerShell scripts called Inveigh.
This gets us the password hashes of network users that will let us move laterally or escalate our privileges. The password hashes can be cracked offline, or used in more advanced pass-the-hash and relay attacks to accomplish this.
Prevention
Prevention of this attack involves disabling the insecure protocols via Group Policy…
- LLMNR (Multicast Name Resolution)
- NetBIOS Name Resolution (NBNS)
- WPAD (Web Proxy Auto-Discovery)
…and enforcing required SMB signing while disabling support for the insecure SMBv1 protocol. Removing support for these legacy protocols and configurations should be at the top of every sysadmin’s list of how to secure Active Directory.
Please note: These protocols and configurations may be required to support certain network services and legacy systems. An investigation should be performed into the potential impact before deploying these policies. This applies to all recommendations made in this post.
Dumping Memory
The Attack
Windows stores hashed and sometimes plaintext passwords in memory, thus preventing users from repeatedly having to re-enter their password to access network resources.
Unfortunately, it also means that attackers can retrieve these credentials for all users with sessions on a compromised host.
If a Domain Admin is logged into a system an attacker has access to, that could mean Game Over in terms of a network’s security.
To retrieve credentials from memory, an attacker must have local administrative access to the system they are targeting.
This may be granted to them:
- as part of their current Domain User’s permissions by exploiting a vulnerability in the underlying system.
- or through the reuse of local administrative passwords – a common practice among sysadmins.
A tool such as mimikatz can be used to extract credentials from the memory of a Windows system:
This can also be done at-scale over the network using another tool called CrackMapExec:
Like with our previous attack path, these hashes can be cracked or replayed to escalate our privileges, move laterally in the network, or launch additional attacks.
Prevention
Preventing this type of attack can be hard, but the following can help:
- Don’t reuse local administrative passwords; use a solution like Microsoft’s LAPS instead.
- Implement memory-dumping mitigations, such as LSA Protection and CredGuard.
- Practice proper Domain Admin hygiene – DAs should only log into non-shared systems like Domain Controllers; Administrators should use separate “technician” accounts for their day-to-day duties.
- Deploy an antivirus with Tamper Protection that cannot be disabled or removed even by users with local administrative access.
Kerberos Weaknesses
The Attack
Kerberos is a ticket-based authentication protocol used on Windows networks. Two misconfigurations in Kerberos can allow attackers to request password hashes for the associated accounts, which may be highly privileged or even Domain Admins. From there, attackers can try to crack the password hashes in an offline attack in order to gain access to the accounts.
The first attack, known as “Kerberoasting”, requires the attacker to have at least Domain User access to retrieve the password hashes of an AD account with a Service Principal Name (SPN) assigned to it. SPNs are used to associate a service with an AD account (and grant its associated permissions) but also exposes that account to password hash disclosure via Kerberoast:
Here we see a password hash retrieved via Kerberoast by using GetUserSPNs from Impacket. Several other tools such as Mimikatz can also perform this attack. From that point on, we can attempt to crack this user’s password to gain access to their account.
An additional attack targets accounts with Kerberos pre-authentication disabled – typically done for the sake of compatibility. Similar to the preceding scenario, an attacker with access to at least a Domain User account – or with no domain access and a list of valid usernames – can retrieve the associated accounts’ password hash:
Once again, we’re using Impacket and GetNPUsers to retrieve the hashes while something like Rubeus can do this from Windows. This is known as “ASREPRoasting.”
We often see these misconfigurations during pentests and attackers are sometimes able to gain access to sensitive accounts (including Domain Admins) this way, leading to a quick compromise of the associated AD domain.
Prevention
The following steps can prevent and mitigate these attacks:
- Minimize the use of SPNs where possible.
- When using SPNs, practice the principle of least privilege with respect to the access they grant.
- Never associate SPNs with Domain Admins.
- Do not disable Kerberos pre-authentication, especially for sensitive accounts, such as Domain Admins.
- For any scenarios where SPNs must be used or pre-auth disabled, enforce the use of extremely complex passwords. Assume that the password hashes of the associated accounts are essentially public, so it should not be feasible to crack them with any realistic amount of resources.
Enumeration and Exploitation
The Attack
If we’ve been unable to escalate our privileges by the previously described means during a pentest, it’s time to look for other options. There are three attack paths that are often fruitful and leading to the compromise of an Active Directory environment:
- Vulnerability Scanning: This is straightforward – unpatched services lead to the compromise of sensitive accounts and resources. A common target is hypervisors because they must be patched manually and doing so creates downtime for all associated virtual hosts. This means that they are often neglected and remain vulnerable to critical exploits, such as CVE-2021-21972 for VMWare.
- Default Credentials: As a rule during pentests, at least one service will be accessible using a default username and password, such as “admin” / “admin”. More than once, this has directly led to compromising a Domain Admin account.
- Checking Network Shares: We routinely find unmapped network shares that are accessible to regular Domain Users, including “IT” shares that often contain plaintext passwords, licenses, configuration files, and other information that can be used to access additional accounts and services on the network.
Basically, we’ll enumerate as much information as possible about what’s accessible on the network, then leverage any weaknesses to our advantage.
Prevention
The basics! Change default passwords and never store passwords in plaintext – especially not in network shares accessible by regular users; password managers should be used to track this information. Keep systems patched including network devices, virtual machine hosts, software dependencies, and anything else that is not being updated automatically. It’s easy to neglect manual updates that may require scheduled downtime, which can leave critical systems exposed to attacks. In both these cases, it’s about doing what’s secure – not what’s convenient.
Summarizing How to Secure Active Directory
As cyberattacks on organizations become more prevalent and sophisticated, system hardening and proactive defense become essential. Let’s summarize the basic steps you can take:
- Disable LLMNR/NetBIOS Name Resolution/WPAD to prevent poisoning attacks.
- Enforce SMB Signing and disable SMBv1 to mitigate man-in-the-middle attacks.
- Implement LAPS and memory-dumping mitigations to protect accounts and resources if a limited compromise has occurred.
- Secure your Kerberos configuration.
- Enforce the use of strong passwords and password hygiene, especially for sensitive accounts.
- Do the needful: Patch your systems, run and monitor an IPS, audit your network resources and access control scheme, watch the logs, maintain robust backups, and stay abreast of the latest threats and attack methods.
While these items are a good start, they only represent the tip of the iceberg in the rapidly evolving field of cybersecurity. For peace of mind and a more thorough approach to network hardening, organizations should routinely engage the experts for a security audit or penetration test – and that’s where we at Vumetric Cybesecurity come in. If you’d like more information, reach out directly to a specialist.
