Privileged Windows Accounts - The Concrete Danger of Critical Components

Privileged Windows Accounts

The Concrete Danger of Critical Components

Dominik Altermatt
by Dominik Altermatt
time to read: 10 minutes

Keypoints

This concrete threat comes from privileged Windows accounts

  • Privileged Windows accounts are critical components
  • Companies continue to neglect the issue
  • Windows 10 and Server 2016 offer many new features to deal with it
  • "Old habits" can present a risk
  • Privileged account management should be prioritized if not already in place

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:

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:

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:

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:

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

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

Password policy

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

Client and server hardening

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

Further hardening guides:

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:

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

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

You want to bring your logging and monitoring to the next level?

Our experts will get in contact with you!

×
I want a "Red Teaming"

I want a "Red Teaming"

Michael Schneider

Human and AI

Human and AI

Marisa Tschopp

Vehicle forensics

Vehicle forensics

Michèle Trebo

Isn’t business continuity part of security?

Isn’t business continuity part of security?

Andrea Covello

You want more?

Further articles available here

You need support in such a project?

Our experts will get in contact with you!

You want more?

Further articles available here