How and why threat actors target Microsoft Active Directory

Microsoft Active Directory debuted 22 years ago. In computer age, that’s old technology. Threat actors like old technology because it often has legacy code or processes that are not secured to modern standards or organizations have not kept up with patches and recommended settings.

Derek Melber, chief technology and security strategist for Tenable, discussed Active Directory risks at this year’s RSA conference. Attackers target domains. If they see a device joined to Active Directory, they will continue with the attack. If they don’t see a domain-joined machine, they will go on to another workstation. Below are some examples of how attackers can exploit legacy Active Directory vulnerabilities

sAMAccountName security bypass

Too often we focus on vulnerabilities that make the big headlines and miss those that are probably more impactful. For example, Melber cited the attention the Log4j vulnerability received, but another vulnerability came out the same week that impacts all Active Directory domains called sAMAccountName, which affects all systems that have the November 2021 or later updates. It is a security bypass vulnerability in Active Directory Security Accounts Manager, for which Microsoft has issued a fix (CVE-2021-42278).

After installing CVE-2021-42278, Active Directory will perform the validation inspections listed below on the sAMAccountName and UserAccountControl attributes of computer accounts created or modified by users who do not have administrator rights for machine accounts. It builds on a foundational default of every Active Directory domain: that a normal domain administrator wouldn’t mind if a non-administrator in the domain joins up to ten computers to that domain.

That might have sounded reasonable ten years ago, but now with the ability to deploy workstations using autopilot or any other technologies we have at our disposal, it no longer makes sense to allow non-administrator users to join workstations to the domain.

This setting has been around for years but many of us have not adjusted it or know about it. You’ll need to go into ADSIedit and set an attribute of ms-DS-MachineAccountQuota. This is the attribute responsible for above limit. By default, its set to “10”. Setting it to “0” disables this limit.

Attackers can combine the CVE-2021-42278 vulnerability with CVE-2021-42287 to “create a straightforward path to a Domain Admin user in an Active Directory environment that hasn’t applied these new updates. This escalation attack allows attackers to easily elevate their privilege to that of a Domain Admin once they compromise a regular user in the domain,” said Daniel Naim, Senior Program Manager for Microsoft Defender for Identity, in a blog post. Every Active Directory instance is vulnerable to this especially if you have not installed the updates on your domain controllers.

Misconfigurations that give attackers easy access

The top way attackers gain network access is phishing. The next way that attackers enter a domain is through vulnerabilities or misconfigurations that allow easier access. Many Active Directory configurations we’ve done over time were because line-of-business applications needed them or we didn’t understand line-of-business application needs well enough to properly configure our networks.

As Melber noted, several authentication protocols are automatically installed when Active Directory is installed: Kerberos, NTLM, NTLM v2 and LanManager. The older NTLM and LanManager protocols possibly can be disabled, but you probably do not want to disable without testing.

After obtaining a username and password for a domain, an attacker logs in and determines if the user has a domain account and can install software. Attackers often install a tool called AD Explorer that enumerates what is in a domain. They will mine cached credentials, harvest passwords and then determine if mined credentials have privileges on the domain.

One of the best ways to protect and deny attackers, according to Melber, is to use Microsoft’s Local Administrator Password Solution (LAPS), which sets up a random password for the local administrator account so that attackers can’t steal the one account and then laterally move to all workstations in the domain. The installation is straightforward and works to generate a random password for each workstation rather than keeping the same one for each workstation. He also recommended fine-grained password policies and implementing two-factor authentication. If you are looking for a web-based user interface for LAPS, I recommend Overlaps for Microsoft LAPS.

Melber indicated that attackers enumerate Active Directory with PowerShell to analyze active control lists (ACLs), group members, and user rights. He recommended that you secure privileged users and service accounts as well as computers – for example, hardening AdminSDHolder. If you’ve moved to cloud-based Exchange, you may not have removed the right to change permissions from Exchange administrators. Review who has rights in AdminSDHolder and edit or delete those groups or users that no longer need this ability.

Another misconfiguration Melber recommended that you review is AD delegation. Unsecure Kerberos delegation gives an entity the ability to impersonate you to any other chosen service. He recommends using AD review tools as it may not be obvious what adjustments you need to make. One such tool is Microsoft Azure AD Secure Score if you have hybrid AD and a Kerberos delegation test. If you have on-premises AD, use the investigation tool Tenable.AD to identify weaknesses and misconfigurations.

Kerberoast golden ticket attack

Kerberoast is another attack sequence threat actors use. No logging is done in the domain to document the attack until the attacker has a golden ticket and the game is already over. Match up the requests for golden tickets with a prior ticket-granting service (TGS) request. If there is no prior ticket-granting ticket (TGT) request within a window of time, the non-matching TGS request may be related to a golden ticket attack.

Active Directory is not going away, nor are attacks against it. It’s time for AD administrators to do some homework and ensure you are doing more than just patching.