Active Directory is at the core of most Fortune 1000 companies’ security solution. It helps administrators organize and manage users and computers on an organization’s network. However, its popularity among developers also makes it a juicy target for cyber extortion. Some Active Directory disasters are the result of human errors, which are quite often easily avertable, if users exercise prudence. In this blog, we discuss three quick wins of the Active Directory and three quick fixes that address these issues.
Password Reuse Across Local Machine Users
Oftentimes passwords turn out to be the weak link in an organization’s security posture. Users tend to favour convenience over safety, which results in the reuse of the same passwords for different platforms. In the case of Active Directory, domain users as well as local users have been noticed to reuse passwords. It becomes a huge concern when administrators do not monitor activities, and let passwords to be set on a local admin. Cybercriminals who gain access to local admin privileges shall also have access to all areas in the network, allowing them lateral movement.
Saved Login Credentials
Once attackers gain local administrator privileges, they query saved credentials inside the LSASS process memory. In such instances, the attackers also crack domain admin hashes and take over the domain controller.
These malicious actors also leverage post-exploitation tools such as Mimikatz to extract passwords and hashes from memory. Once the actor obtains local admin access to a machine in the local environment, they can run Mimikatz to find out details of the domain admin, including the domain hashes. The following image is a demonstration of this instance, where initially local admin access is gained through user “Bwayne” in “ARNAV.local” domain:
Kerberoasting is a type of attack, wherein threat actors extract Kerberos hashes for Active Directory user accounts, with the help of Service Principal Name (SPN) tickets. In this form of attack, threat actors can decrypt hashes offline, without being detected. Most kerberoastable accounts are also domain admins which when combined with a weak password makes it extremely vulnerable.
Here’s a demo of a kerberoastable account in a local environment, same as the one used in the example above. In this instance, however, we use a kerberoastable user “abd” which is also a part of the domain admins group. We extract the hash using Impacket’s GetUserSPNs.py:
Once we obtain the hash, we decrypt it offline. We use Hashcat and Rockyou.txt to bruteforce the hash:
As you can see in the image above, we successfully decrypted the password as “iloveyou.” In real life, a threat attacker just got access to the complete environment through the domain admin user “abd.”
Reusing passwords for multiple accounts makes it easier for malicious actors to compromise all your accounts on different platforms. Use strong passwords and resort to Local Administrator Password Solution (LAPS) to manage local user passwords.
Saved Privileged Account Logins
This one is a little tricky as it relies on the luck of the attacker. To be on the safe side, do not log into privileged user accounts on any machine unless absolutely necessary. Instead, use accounts that have normal user privileges.
Strong Passwords to Tackle Kerberoasting
Set up service accounts with extremely low and use strong and complex passwords to avoid brute forcing or kerberoasting.