A common occurrence within a Windows Active Directory environment is the existence of more Domain Admins than are really needed. This opens the door for confidentiality, integrity, and availability issues within the domain due to human error (unintended consequences of actions), account takeover, etc. This is a well-known risk . . . and not what this post is about :).
Another less-commonly identified circumstance that introduces quite a bit of risk is the inclusion of Domain Admins in the local Administrators group on all or many domain-joined systems (workstations and servers). This is almost always done for convenience sake, understandably, as it allows IT administrators the flexibility to quickly provide remote assistance or remotely connect to workstations or servers and/or perform any task necessary without further elevation of privileges. The unintended consequence of this activity, however, is that each account login to a Windows machine leaves behind some artifacts that can be used to compromise that account. For example, credentials (password, Kerberos Ticket) are stored within the LSASS process in memory in a variety of forms used to facilitate single-sign of domain services. Passwords may also be stored within the computer’s SAM database.
Specialized penetration testing (or hacking) tools, such as Mimikatz, can be used dump those credentials from memory or from other storage locations. While such tools need to be run with administrator privileges, many organizations struggle to remove local workstation administrator privileges from end-users and at least a subset of users have them, so a simple phishing email is all it usually takes to compromise a machine and get local administrator privileges. From there, Mimikatz can be used to dump memory or probe storage locations and grab passwords; and if a member of Domain Admins has logged in, his/her password may be compromised, effectively compromising the entire Windows Domain! Results may include a significant data breach, ransomware, malware, persistent compromise, etc.
There are ways to prevent this, such as disabling wdigest, preventing the storage of LANMAN hashes, preventing the caching of credentials, using AD “Protected Users” or using Credential Guard for newer systems, but many of these have business tradeoffs that organizations cannot or may not be willing to make. A process-based way to deal with this is to restrict Domain Admins from logging on to workstations (and many servers) and use the local built-in Administrator account for administrative activities in conjunction with a tool like LAPS to create unique passwords per local Administrator account across devices. Additionally, IT administrators should have separate “every-day” use domain accounts. This way, accounts that are members of the Domain Admins AD group are much less likely to get compromised, when an employee gets phished and attackers are less likely to be able to move around in the network after stealing employees’ credentials.
If you’re interested in learning more or finding out how Cadence can help protect your information and enterprise, including Windows Active Directory and Domain Security, IT Security Risk Assessments, Vendor Risk Management, Security Program Management, CISO for Hire, Penetration Testing, Business Continuity and Disaster Recovery Consulting, SOC, PCI, ISO, FedRAMP, and other service, contact us!