Last updated at Thu, 20 Jul 2017 20:26:48 GMT
As we know, attackers leverage legitimate credentials to move through systems, escalate privileges or get access to data.
Managing privileged accounts such as administrator accounts, shared accounts and service accounts is a difficult problem to solve.
Even if service account passwords are managed securely, they still remain at risk of being compromised through exploitation of services using them, lack of support for encrypted configuration files on some systems, pass-the-hash attacks, or the ability for a systems administrator account to read them in memory.
Luckily, Windows comes with granular permissions that are easy to configure and that can help us reduce the attack surface, improve general IT hygiene and obtain important log information when attempts to use these accounts improperly happen.
The same can be said of administrative accounts used by humans. These accounts have high levels of privileges, but should never be used to perform automated tasks, run services or be saved into configuration files, for reasons ranging from obvious security concerns to simple IT availability management.
Who hasn't seen a service crash when an administrator's password was changed?
Where to start
Looking at every single user right that can be configured in Windows can be overwhelming. Depending on the version of Windows being used, there are roughly 50 different rights, controling everything from permissions to change the system time, shut down systems or take ownership of files and other objects.
Luckily, Microsoft provides decent default configurations in Windows 2008 and later, and provides better configuration options in its Security Compliance Manager tool.
We recommend that you start your hardening efforts with the proposed values from SCM, customized for your organisation. You can also leverage well known configuration guides from organisms such as NIST, the NSA, FDCC, CIS Security and more.
Their proposed values for User Rights Assignments are not bad, but will obviously need to be customized with real groups and accounts from your environment, which no guide written by someone else could ever hope to cover.
One of the advantages of using SCM is its ability to output your configuration both in a *GPO Backup* format, easily restorable in AD, as well as a *SCAP* file, easily loaded in many vulnerability scanners and configuration auditing tools.
OU Structure
An OU structure that is well defined, hierarchical and simple will make the deployment of GPOs much easier.
This structure will be based on how systems are used in your organisation, but could look similar to this. Some organisations use a geographical breakdown, which can also be used, and would simply require different GPO links.
With such a structure, an organisation can create and use the following GPOs:
- A server configuration baseline. This baseline should be more restrictive than permissive. Microsoft Security Compliance Manager (SCM) can be used to generate hardening GPOs for your baseline. This is applied on *Servers*. All OUs under *Servers* inherit configurations.
- Role GPOs for different servers. Again, Microsoft SCM can be used to create those policies. Think of these policies as ways to enable the required functionality on those servers. If the baseline disables the print spooler, the Print Server Policy would enable it, for servers in this OU.
- A similar hierarchy for workstations is also possible, and if needed, Group Filtering can be used if the OU structure is not flexible enough at your organisation and cannot be changed.
No matter what your OU structure is, remember the main goals: repeatability and ease of use. The right structure will allow you to control a great majority of parameters in as few GPOs as possible, and allow any systems administrator or security operator to easily understand the resulting configuration on servers.
User Rights to configure
Now that we have a flexible OU structure, some baseline hardening policies for our servers and workstations, we must look at which User Right Assignment will be customized further.
What we are trying to achieve with them is simple: prevent humans from logging in using ways that systems and services do, and prevent services from logging in using the ways human use.
Example: Service accounts should never be able to perform Remote Desktop Connections, and humans should not be able to log in as a batch job or service.
To perform such a configuration while retaining flexibility, we will leverage positive rights (allow), and supplement them with negative rights (deny) to explicitely block access when it might otherwise be granted by another level of privileges, such as a service account that has local administrator privileges.
To succeed at configuring these, using Active Directory Groups is essential.
For each of these critical rights, create an Active Directory group, which will be granted access. In most cases, you will be able to grant a right only to one local account or group (ex: administrators), plus one domain group.
The granularity of these groups is important. You must chose a level of granularity that will allow you to configure servers properly, while allowing for some level of customization when needed.
The two extreme levels of granularity would be:
* An extremely broad group, granting access to the same right on all servers.
* An extremely precise group, used for one right, on one server only.
As these are both impractical, due to lack of flexibility or increased complexity (and even Kerberos ticket size issues in some cases), an option that lands roughly in the middle of these two extremes is often the most appropriate: **
For each of these critical rights, create an Active Directory group, which will be granted access. In most cases, you will be able to grant a right only to one local account or group (ex: administrators), plus one domain group.
The **granularity** of these groups is important. You must chose a level of granularity that will allow you to configure servers properly, while allowing for some level of customization when needed.
The two extreme levels of granularity would be:
* An extremely broad group, granting access to the same right on all servers.
* An extremely precise group, used for one right, on one server only.
As these are both impractical, due to lack of flexibility or increased complexity (and even Kerberos ticket size issues in some cases), an option that lands roughly in the middle of these two extremes is often the most appropriate: One group per right, per server role.
Ex: A group that allows logging in locally on print servers.
Nesting
If you picked our recommended level of granularity, you will be creating roughly 10 AD groups per server role. While this seems like a lot, it can actually be automated quite easily when introducing new roles.
To keep the management overhead as low as possible, which not only helps optimizing operations but also reduces complexity and reduces the odds of human error, group nesting will be required.
Group Nesting will allow you to create "role" groups, which will themselves be members of the appropriate User Rights groups.
By creating such a structure, you will be able to easily grant access to all servers, to all servers in a role, and single server exceptions can be managed separately.
We highly encourage you to use such a structure to control which domain groups are local administrators on systems. Remove Domain Administrators, and if necessary, use one AD group per server. This will allow you to control local administrator privileges directly in AD, all the time, meaning you have a centralized database for it, that local groups will not be filled by unresolved SIDs as accounts are deleted, and more.
Since we are going to use deny rights, it is important to nest groups into the appropriate deny rights AD groups.
From this diagram, we see that granting Mario access to manage print servers only requires making him a member of the general Windows Admin group, while Luigi can only manage Print Servers, as he is a member of a more specific Print Servers Admins group.
These groups result in both of them being granted 5 rights on the servers: 3 allow, 2 deny. They can now log in locally or remotely, but are unable to start a service or a batch with their own account.
In some cases, a level of granularity can be removed by granting the deny rights at a higher level, since they are usually broader concepts. This is especially useful for service accounts, where we mostly want to deny specific logon types, on all servers.
Nesting Service Accounts
Service Accounts can obtain privileges the same way a regular account can. The rights that will be granted will obviously be different, and will often be the opposite of what a human would receive.
As GPOs are re-applied periodically, any change in configuration will be corrected rapidly. This can lead to software being installed, looking functional and then stopping a few moments later, as the local privileges are stripped from the service account. To avoid this issue, ensure privileges required by services are well understood prior to installation. Your testing environment and Windows Security Event Log are your best friends when troubleshooting permission issues.
Exceptions
Every company, no matter how small, has at least a few IT exceptions to deal with. It could be an obvious one, such as a web server requiring access to "log on locally" due to how Windows is built, or it could be some kind of crazy service actually leveraging Remote Desktop to perform some action.
Precise exceptions can be granted with the model we've built.
Simply create an exception GPO (ex: "GPO to Grant CrazyHackJobService the right to perform a remote desktop logon"), ensure it gets applied only to a security group (ex: "Group of computers running CrazyHackJobService"), then link it on your "Servers" OU or equivalent. Make sure this GPO is applied last (on top in the GPMC interface), to override any configuration coming from other, less specific GPOs.
This will allow you to reconfigure the specific user right(s) required for this service to work properly, deploy these configurations only to specific servers and do so without having to create a special OU structure. Remember that groups are flexible, but OUs are not. A server can be in many groups, but will always be in a single OU.
Note: While applying new GPOs does not require a reboot, if you've just made a server a member of a group, a reboot might be required to refresh tokens that will then give it access to the filtered GPO.
Logging
As User Rights Assignments are linked to specific logon types, the information generated by attempted logons can be extremely useful to your security monitoring efforts.
Assume a service account's password is somehow obtained by an attacker, using a variety of methods from pass-the-hash to memory extraction or the good old "found a word document with passwords" technique. As the attacker attempts to use this account to connect to systems, the odds of an attempt being performed using one of the denied logon rights is high.
The security logs, when the username and password are correct but the logon type disallowed, are very precise, and will allow you to detect malicious activity happening with a service account quite quickly.
The same is also true for administrative accounts being used to install malicious services or scheduled tasks using domain credentials. Use these logs to your advantage.
Example prompt of a user "EPaw" attempting an interactive logon where not allowed:
Associated log entry:
Conclusion
Without spending any extra money on tools, by using this technique, customized to your environment, you will not only have reduced the attack surface of your Windows environment, but you will force it to become self-documenting when it comes to User Rights granted to service accounts, as all the information has to be stored within Active Directory.
The additional data generated by failed attempts is now ready to be ingested by your security monitoring tools, and the next attacker who will attempt to log on using Remote Desktop to one of your servers using a service account will have to be noisier and work harder.
If all this configuration and refactoring of the placement of your systems seems too difficult, remember you can start small, configuring only a few settings on existing systems, while you apply a more complex set of rules on newly provisioned systems.
Links
Security Compliance Manager (SCM)
Group Policy Management Console (GPMC)
Advanced Group Policy Management (AGPM)
Center for Internet Security (CIS)
