Privileged accounts are regarded as critical components in IT infrastructure. Those who fail to address the major risks or adequately protect their privileged Windows accounts – domain administrators, for instance – are exposing their infrastructure to the growing threat of cybercrime. But we are still seeing negligent behavior in the field. Where particularly privileged accounts are exposed, an attacker often needs to do little more than compromise the “right” client to gain control over a complete infrastructure.

In theory, protecting privileged accounts is not complicated, with just a few principles to bear in mind. In practice, however, various factors have to be taken into account to ensure adequate handling and management. Here there are several quite practical measures for minimizing certain risks, and these are very quick and easy to implement. This article discusses these measures while also looking at some more advanced concepts around the issue.

Exposed privileged accounts

When are privileged accounts exposed? A simple way of answering this would be to say that the “nearer” a privileged account is to the internet, the more exposed it is. So logging on to a standard client with domain administrator rights exposes this account. The view of an attack is usually from the outside in, for example:

• Attack on a client from the internet
• Attack on a server from a client
• Attack on a sensitive server (for instance, domain controller, databases) from another server

A common assumption in IT security is that a client has been compromised. Below is a rough sketch of how an attacker might proceed:

1. Access to a system through infection from malware (social engineering, spear phishing) or direct physical access (e.g. internal/external staff), mostly with non-privileged users
2. Privilege escalation to local administrator rights by exploiting vulnerabilities or other techniques
3. Creation of NTLM hashes, or reading hashes of users logged into the system (Mimikatz, responder.py, network sniffing e.g. with ettercap)
4. Lateral movement with the collected hashes or tickets (pass the hash or pass the ticket, etc.) to launch attacks on other systems (Bloodhound)
5. Repeating steps 3 & 4 until the attacker gains the rights required for the target network
6. Attack on the target system (e.g. payment server) and carrying out malicious actions (e.g. making fraudulent payments)

The above steps can be very slow to execute. Attackers must go about their work cautiously and “silently” to avoid detection. The first five steps of the attack may take several months.

Below are some examples of exposed privileged accounts from real-life practice:

• For publicly accessible systems, e.g. an internet PC in a hotel, domain administrator credentials can be found in an unattended.txt file
• If the user of the infected system already has local administrator rights, the NTLM hashes can be read without privilege escalation (developers, superusers)
• In the best-case scenario for the attacker, a user is logged in with domain admin rights (IT administrators, superusers)
• There are “service principal names” for personal users with domain administrator rights that can be used to deploy Kerberoast attacks
• Standard users with de facto domain administrator rights through nested AD groups. This requires not just a Member Of relationship, but also relationships like GenericAll and AddMember.

Defensive techniques

Below are just some of the concepts and practices that may serve as a starting point or give you some ideas for securing your own privileged accounts.

“Privileged accounts” not only include administrators and domain administrators, but also many service users as well as standard accounts with access to sensitive data (executives and management, finance department, etc.).

Processes and internal directives

The following principles and concepts should be included in security policies for identity and access management (IAM) in general and in privileged account management (PAM) in particular:

• Know your data and your users (data classification and user concepts)
• Principle of least privilege
• Segregation of duties principle
• Multi-factor authentication for all privileged access
• Strong password policy (e.g. 24+ characters for users with domain administrator rights)
• Logging of activities by privileged users (session recording and logging)
• Ban on use of privileged accounts by multiple users (account sharing)
• Stricter audit processes for privileged accounts
• Automated IAM processes (deletion/deactivation of privileged accounts when staff leave, change departments, no longer require access, etc.)
• Avoiding hard-coded passwords in applications
• Don’t forget privileged access by external partners

If your goal is to implement a usable security policy for access management, you can try access controls AC2, AC3, AC5 and AC6 from the catalog of the NIST Cybersecurity Framework.

Where internal directives and policies are already in place, these must be implemented and enforced – otherwise “security” only exists on paper. Consequently, they should always include processes for the enforcement and monitoring of directives as well as resources for implementation and operation.

One unpleasant necessity is defining what to do in the event of violations. You may have IT staff who have become accustomed to their domain administrator rights over the years and are reluctant to give them up or who don’t wish to work with multiple accounts. But “old habits” like this can greatly increase the risk and the exposure of privileged accounts.

Windows Active Directory

Microsoft offers comprehensive and practical documentation under the title Best Practices for Securing Active Directory. It includes several chapters that address securing of accounts and privileged accounts.

You can find further Microsoft resources under the following links:

• Privileged Access Management for Active Directory Domain Services
• Securing Privileged Access

We recommend studying these resources. The Microsoft documents touch on a number of intriguing issues:

• Privileged Access Management (PAM) solution in AD DS
  • Tool for managing privileged access
  • Minimizing the risk of pass-the-hash
  • Isolation and scoping of privileges
  • Multi-factor authentication
• Just Enough Administration
  • PowerShell tool for minimizing the number of privileged accounts
  • Allowing specific administrative tasks (that can be carried out with PowerShell) without a privileged account

This Microsoft documentation is highly comprehensive and wide-ranging, so here are just a few tips you can implement straight away (quick wins). The Microsoft guidelines linked above can be implemented in detail in a later phase.

Consistent process compliance

• Establish a process for review of administrator groups in AD and locally on clients/servers. Usually there are too many users who “require” high-level rights only temporarily or for convenience. These should be consistently and regularly removed. Here it is also important to remember the nesting of groups.
• Always carry out daily tasks on clients without privileged accounts. This primarily applies to developers, IT administrators and IT support staff.
• Do not allow support work with domain administrator rights on clients/servers
• Enable access to sensitive data/servers as well as work with highly privileged accounts (e.g. domain admin) from a dedicated admin jump host, or at least not from a client that is exposed on the internet
• The built-in local administrator user on servers and clients should be deactivated and its password should be unique on each client/server. The LAPS tool from Microsoft can be used for this.

Password policy

Very strong password policy (complex, non-dictionary passwords, min. 24 characters), for the following users/groups at least:

• Domain administrators
• Enterprise administrators
• Schema administrators
• Account operators
• Backup operators
• BUILTIN\Administrators
• Service accounts for software installations and updates
• Service accounts for security scans and anti-virus software

Client and server hardening

The following group policy logon rights restrictions prevent many lateral movement techniques:

• Deny access to this computer from the network
• Deny logon as a batch job
• Deny logon as a service
• Deny logon locally
• Deny logon through Remote Desktop

Further hardening guides:

• Windows 10 Client Hardening
• Windows Server Hardening

Use of the Bloodhound tool for AD. This allows you to quickly gain an overview of which users are logged into which system with which rights. This allows you to detect potential attack vectors and any non-compliance with internal directives as well as vulnerabilities that need to be patched.

Logging and monitoring

Finally, there’s the issue of logging and monitoring of privileged accounts:

• Always activate advanced audit policies
• Centralize security log monitoring with a tool such as Graylog
• The cheat sheet section of malwarearchaeology.com is a good place to get started in figuring out what you should be logging and alarming, and why
• Microsoft offers an expanded list of important event IDs, which can be useful in analysis and alerting

Not included in the above list is network segmentation, at least between the client and server population. If this isn’t already in place, it can take some effort to implement. But isolating servers from clients exposed to the internet is one of the fundamental pillars of a modern security concept.

Conclusion

In current practice, privileged users are not sufficiently protected across the board, making it easier for attackers to gain access to the infrastructure in question. If the system further lacks appropriate security logging and monitoring, instances of compromise may go undetected for a long time. In some cases, the entire infrastructure may be recklessly exposed.

Microsoft has responded to the common attack vectors with its current software and addressed them in comprehensive documentation. The company also provides functions and tools that make it harder to exploit privileged accounts, for instance. However, some companies are still unaware of the risks and solutions. While the topics covered here are not exhaustive, the concepts and tools can serve as a starting point and offer up some ideas for common AD environments.

About the Author

Dominik Altermatt is working since 2003 in the IT business and was responsible for Data Leakage Prevention at a Swiss bank for many years. Besides traditional penetration testing he is also focusing on the introduction and improvement of IT security management processes. (ORCID 0000-0003-4575-4597)

Links

• https://blog.stealthbits.com/complete-domain-compromise-with-golden-tickets/
• https://blog.stealthbits.com/passing-the-hash-with-mimikatz
• https://docs.microsoft.com/en-us/microsoft-identity-manager/pam/privileged-identity-management-for-active-directory-domain-services
• https://docs.microsoft.com/en-us/powershell/jea/overview
• https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/appendix-l—events-to-monitor
• https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/best-practices-for-securing-active-directory
• https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/monitoring-active-directory-for-signs-of-compromise
• https://docs.microsoft.com/en-us/windows-server/identity/securing-privileged-access/securing-privileged-access
• https://github.com/SpiderLabs/Responder
• https://nvd.nist.gov/800-53
• https://pentestlab.blog/2018/06/12/kerberoast/
• https://vuldb.com/
• https://www.cisecurity.org/benchmark/microsoft_windows_server
• https://www.ettercap-project.org/
• https://www.graylog.org/
• https://www.malwarearchaeology.com/cheat-sheets/
• https://www.microsoft.com/en-us/download/details.aspx?id=46899