Data Transfer with SSID
This concrete threat comes from privileged Windows accounts
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.
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:
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:
Member Ofrelationship, but also relationships like
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.).
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.
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.
Very strong password policy (complex, non-dictionary passwords, min. 24 characters), for the following users/groups at least:
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:
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.
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.
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.
Our experts will get in contact with you!
Our experts will get in contact with you!
Further articles available here