You are here

How Safe is Your Active Directory?

We recently returned from the 25th annual DEF CON (one of the largest hacking conferences in the world), and wanted to share with you about a workshop called “Attacking and Defending Active Directory.” This workshop covered different attack vectors and remediation efforts for the attacks. Here at Wolf, our IT group performs internal penetration tests at numerous clients throughout the year, and Active Directory (“AD”) is always a network segment we are engaged to try to exploit. This particular DEF CON workshop explored weaknesses in the NTDS.DIT file and the Kerberos and reinforced the need for strong security controls and hardening tactics to reduce the likelihood of an AD network compromise. 

Attacking the NTDS.DIT File
What is the NTDS.DIT file? NTDS.DIT stands for NT Directory Services “.” Directory Information Tree, and it is a database that contains, among other things, all of the password hashes for your organization’s domain. Essentially, if an attacker can access these password hashes, they are one-step closer to extracting them, cracking them, and acting as any user on the domain.

An attacker cannot simply copy this file to an external source as it is constantly being used by AD (tampering with this file may crash the Domain Controller). An attacker may though access the hashes though in the Volume Shadow Copies.  In addition, they can potentially also grab the encryption key from the registry.  This provides the ability for the attacker to work on the file offline to avoid raising any alarms. 

How can this attack be prevented?
An effective way to reduce the likelihood of a successful attack is to limit what a user account can see in AD. Do all of your users really need to know every object in AD? Additionally, you should limit who can log onto Domain Controllers, including commonly protected groups such as Domain and Enterprise Admins, Print Operators, Server Operators, and Account Operators.

Lastly, a security information and event management (“SIEM”) could be configured to alert and potentially prevent users from retrieving files from Volume Shadow Copies.

Kerberoasting is a play on the term “Kerberos,” which is a network authentication protocol used to identify devices on a network. Kerberoasting is a set of tools designed to take advantage of how service accounts leverage Kerberos authentication with Service Principal Names (“SPNs”). A SPN is a unique name that identifies an instance of a service; this is tied to a user account under which the service is running.

An attacker can request a service ticket (“TGS”) by specifying a service account’s SPN value. The attacker would receive an encrypted ticket from the AD that can be cracked offline. If successful, the attacker then would have access to the service account and could use this to pivot on the network.

How can this attack be prevented?
There are a few preventive measures and a detective measure to assist in reducing this type of attack. All service accounts should have long (at least fourteen characters) complex passwords; this makes cracking the passwords very difficult. The passwords should also be changed regularly (at least every 60-90 days); however, this may cause issues with services running on your network. Alternatively, event log notifications can be configured if an account is logging into a workstation or server that it should not be, or is operating outside of business hours.

You can also use a SIEM to detect abnormal account usage. For example, is a particular service account logging into a different system that is outside of the norm? Additionally, you may be able to configure your SIEM to monitor for service ticket requests and identify unusual spikes in those requests.

Check out our related article, Insight from DEF CON: Are You Prepared for the Next Generation of Botnets?