When you create a new forest or new domain, you use the Domain Admin credentials. Through the use of the “Administrator” account you can control each and every workstation and server. You can install Exchange, System Center products and much much more. But Microsoft is probably thinking twice now about the framework they have chosen wherein the Administrator is master of your infrastructure.

As the Administrator account is so powerful, it’s a sweet spot for hackers, the target to get. And that’s probably why many people rename the administrator account to Guest (and vice versa) or something else. Many others keep the Administrator name but change the password to a very long one including special characters, but even that seems futile, by the discovery of an advanced hacking technique called Pass The Hash.

The pass the hash technique for breaking into systems is a particular nasty one. If you want the full technical details you can go to the shortened Microsoft.com/pth url. The short URL just below the Microsoft domain already indicates the severity of this hack.

So how does it work in high-level? Say a user works on his workstation or laptop, on which he has administrative permissions to do his/her work. He browses to a website or receives malware through an email attachment.

Because the user is a local administrator, he is capable of requesting all the hashes of logged on people including service accounts. How would you ask? Well as an administrator the user has the rights to dump parts of the memory where these hashes are stored. If the system uses centralized service accounts such as for SCCM, the attacker now has the hash (read not the password) of the SCCM account. But by making connections using the NTLM the attacker can now provide the hash of the user instead of the actual password.

In short, as the attacker now has the SCCM account, he can connect to any laptop/workstation that uses the same account. Usually the SCCM account has administrator privileges and thus the attacker owns all the workstations.

While workstations make connections to servers, it is fairly easy for the attacker to connect to workstations too. If only one workstation uses administrator credentials to connect to a server, the attacker now also has the server admin privileges. If SCCM is setup as I usually encounter, the SCCM service account is actually the same for all workstations and servers, and thus, only the domain controllers remain to be seized.

So the next hurdle is the domain controllers. Would it be hard to get to? One might ask. Well if you are a “normal” organization, not really. Domain Administrator accounts are widely used by applications or users from their normal workstation or server. Do you have a stepping-stone server to get to your servers and domain controllers, well, since the SCCM account (or any other service account) is widely used (normally) even the steppingstone server can be taken, and thus all the backend servers. Remember, if the attackers have full administrative privileges on workstations and servers, they can install their own RDP-like software or even have the machines call to them over http/https.

So what’s the way to secure this? First of all, ready the PDF’s in the Microsoft link to fully understand the problem. Just changing passwords is not going to be enough. If an attacker had domain controller ownership, he owned and still owns everything. You never know what software was installed where, which accounts have been taken and it’s quite possible the attacker got to the Kerberos distribution center and got himself what’s called a Golden Ticket with a 25 year lifetime which allows him access at any time.

In order to protect against these types of hacks, administrators need to divide their resources in smaller chunks. If you review the attack in a picture it goes like:

On step 1 the attacker gains local administrative rights and is able to retrieve all the hashes of logged on users on the system. This includes service accounts used on these systems. Once the attacker is in, the next step is to find a workstation which has administrators logged on to it (2). This can be the domain admin workstation for example. You can imagine that some attackers will immediately install software to catch password changes and if privileged accounts are used (3). Once an administrative account for servers is found (say for example the Exchange Administrator account who has rights to logon to the Exchange server) the attacker is now in the member server section. And who never logged on with a domain administrator account to member servers. The last step (5) is to log on to domain controllers and have full ownership.

[side note: if you have a single service account for all systems, the attacker owns everything within minutes]

Lessons learned

So what can we learn from this? You might say we want a patch from Microsoft to stop this behavior, but this is not just a Microsoft problem. It’s a systems problem that applies to Microsoft, Linux and Unix. The problem is that the hash is saved in memory as services run in the background or if someone is logged on to for example connect to a share. While the method of retrieving the hash has been patched by Microsoft, hackers still have found many ways to circumvent the problem and still get to the hash. So closing it from hash retrieval side is not going to work. The next best thing is to try and make the walk from client to domain controller as impossible as we can.

1: Remove Local Administrative privileges from workstations – Consultants are telling it for years now, Microsoft have said it since, well, since they created Windows NT. Local Administrative privileges is where it all starts. If an attacker cannot gain administrative privileges, he has no access to the hash and has to put in a lot more effort into breaking into a system, perhaps making it too much effort for his liking.

2: Never logon to a workstation with Domain Admin Credentials – Ok this one is easier said than done. Or is it? In the chapters below we are going to show a very simple technique to have a dedicated workstation administrator that does not have access to any other server in the environment. The attacker might get to all the workstations, no server has been compromised yet as any administrator used on workstations is not an administrator on any server.

3: Use dedicated server admin credentials – There are very few moments when a user needs to logon to a member server and thus, use dedicated server admins. Server admins NEVER have local administrative privileges on workstations and NEVER have domain admin credentials. If a server is directly attacked, the logged on administrative users cannot logon to workstations and cannot logon directly to domain controllers.

4: Use dedicated server role administrators – The next step would be to diversify your server farm. Why would all servers need the same administrator? Are you an Exchange administrator? You only get to logon to Exchange servers. Are you a file server administrators, there is no need for you to logon to the Exchange server.

5: Use of service accounts – What about the next level, as we’ve seen the attack happens also through service accounts running in the background. So who ever thought the backup account used to secure your data is actually imposing a huge risk to your security and data integrity. If you can, create multiple backup accounts (preferably one per server) or use a backup application that can use non-domain accounts for backups (and make sure that each account has a different password). And use the same technique for other service accounts. Above all, service accounts are NEVER domain admin.

5: Domain Administrator roles – The number of domain administrators in almost every organization I’ve seen is too high. What is too high you would ask? Well, if you have more than 2, it’s too high. How would you work then? The answer is DELEGATE every task you can. There is absolutely no need for each administrator to be able to logon to a domain controller just to open AD Users & Computers and create an account. Account creation, modification, password resets etc, can all be done from a regular Admin user account that has these privileges delegated. In bigger companies, account management is handled by IdM systems. So just assign these systems these rights. No-one else.

The next step would actually be ESAE, the Enhanced Security Administrative Environment that basically ensures no-one in your production domain is a domain administrator. The ESAE environment is a fully secure built environment (forest & workstations) just for administering your production forest. The environment is built using (preferably) Windows 8.1 Embedded (with Unified Write Filter) so that changes on administrative workstations cannot happen under normal circumstances. Connections to the administrative forest (domain) is based on Certificate based IPSEC so other workstations cannot be joined to the domain to ensure integrity. If you want to work from home, you can’t. Thinking of remote logon, you can’t. The ESAE environment is completely isolated. Connections to the production domain are again based on IPSEC secure channels. It’s a big task to setup, but you remove the attack surface and reduce the risk of an attacker gaining full domain ownership, and losing all your assets all at once.

Compartmentalize

On step 1 the attacker gains local administrative rights and is able to retrieve all the hashes of logged on users on the system. This includes service accounts used on these systems. Once the attacker is in, the next step is to find a workstation which has administrators logged on to it (2). This can be the domain admin workstation for example. You can imagine that some attackers will immediately install software to catch password changes and if privileged accounts are used (3). Once an administrative account for servers is found (say for example the Exchange Administrator account who has rights to logon to the Exchange server) the attacker is now in the member server section. And who never logged on with a domain administrator account to member servers. The last step (5) is to log on to domain controllers and have full ownership.

[side note: if you have a single service account for all systems, the attacker owns everything within minutes]

The next best thing we can do is compartmentalize. Ensure that we make containers that are only used by those who actually use it. It’s not fully domain isolation, it’s much more. Think of your organization in terms of who uses what with which rights?

Is there a need for a domain administrator to logon to a workstation? (Hint the answer is NO!). Does a regular user need to logon to a server with administrative credentials? (Hint the answer is NO!) Does a Domain Administrator need to logon to a member server? (Hint the answer is NO!)

So how do we prevent this from happening? And here come our friends back into play: Group Policies, Delegations and budget. The first thing we absolutely need is separate administrative workstations. Remember, the attacker comes into the system using fly by website malware, or email or other attack. As soon as the attacker is in a system it’s easy to gain access to hashes. So to avoid the hacker to be able to receive the administrative hashes, an administrator should never logon to any regular workstation. With the budget problem out of the way, the next thing is the basic compartmentalization we are going to setup.

As you can see the domain administrators have dedicated workstations (if they have them at all). In an ideal world domain administrators only logon to domain controllers and nothing else. But if Domain Admin workstations are used, these domain admin workstations will not be able to connect to member servers. Domain Admin accounts will not be able to logon to member servers.

You might wonder why the yellow line however is displayed allowing workstation admins to connect to servers. In some cases it will be required or very easy to have workstations admins to be able to do some work on servers. For example if an image or application requires direct input the workstation admins may receive delegated rights to a server. However, this should NOT include the rights to logon directly to a console, run as batch job or run as a service rights.

Framework

Before we are going to start setting this up, let’s review the delegation framework. Within this framework we need to ensure that administrator roles cannot be mixed together and to ensure that these rights are automatically added to any administrator.

In order to avoid mixing these rights, we are going to use DENY permissions. Deny permissions take precedence over allow permissions. We state that workstation administrators cannot logon to servers (deny logon locally). We also apply the right that server administrators cannot logon to workstations. When reviewing the group policies (described later-on) we get the bonus that IF an administrator adds his account to the other group, access to both services is denied. Take for example the srv-john account. That account can logon to servers through the group that is delegated access to the servers. As DENY logon is set for workstation admins to the servers, as soon as John assigns himself workstation admin rights, the deny on the server group policy would exclude him from the servers too. Forcing him to see another colleague to explain what he has done.

The next security measure we are introducing is that administrators are within a different Organizational Unit within Active Directory. This OU has delegated rights so that only particular administrators will be able to manage users and groups.

In the picture above we have 3 groups defined: GDEL-OU-Administration-Full Control, GDEL-Workstation-Admins and GDEL-Server-Admins (A). The GDEL-OU-Administration-Full Control group has delegated rights to the administration OU (B). Members of this group have the power to decide which user is an administrator and to which groups they belong to perform their administrative duties. The GDEL-Server-Admin and GDEL-Workstation-Admins groups are used to delegate their rights in the group policy for server admin workstations (C) and Helpdesk admin workstations (D). These groups are also used to delegate the rights to the other OU’s within the Active Directory used for Servers and the Company OU which hosts all the (regular) user workstations. Note that the workstation administrators and server administrator groups are also used in the servers and company group policies (not shown).

Since we cannot mix multiple roles into a single account now, we indeed require multiple accounts per administrative user. If my role is Domain Admin, and I am also responsible for all the servers in my organization and workstations, I indeed should have AT LEAST!. 4 accounts, my Domain Admin account which I use to logon to Domain Controllers only (rest should be explicitly denied), one server admin account; only to be used on member servers. I also have a helpdesk/workstation admin account I use to install software and perform maintenance on workstations. Finally I have my regular user account which also has email linked to it and which I use if I do regular office work (like Word, Internet, Etc). To make it easy for myself, I use prefixes for these accounts;

AccountName	Usage
ADM-james.bond	Domain Admin Account
SRV-james.bond	Server Admin Account
HLD-james.bond	Helpdesk Admin Account
James.bond	Regular User Account

Implementation

So let’s start securing at the workstation level. First order of business is to remove the ability for domain administrators to logon to the system. So we need to create a group that allows the manageability of workstations. After creating this group we create an administrator for just workstations. In my example this account starts with hld- to indicate a helpdesk account.

Next we also create the server admins group and a server admin account.

The next thing is to remove the domain administrators from each workstation and add the GDEL-Workstation-Admins group to each member. In order to do this we can use Group Policies. Through the use of restricted groups or group policy preferences. Now the difference between the two are big. When using restricted groups, each current member will be removed completely and replaced with whatever we put in the attribute field. When using preferences we can just add the GDEL-Workstation-Admins and remove Domain Admins from that group, without touching any other member. During implementation you might want to go Preferences first to allow local system accounts to still be a member (although we want to avoid that too!).

[Side note: while we all understand the need to remove local administrative privileges, it seems the implementation of the actual rule is usually quite hard in any organization. Applications might use service accounts that require administrative privileges to function or to have continued support from the vendor. The goal here is to remove Domain Admins initially.]

After we’ve removed them from the groups, it still means domain administrators can logon to the workstations but are not local admin anymore. And our goal here is to avoid having domain administrators (or server admins) logon to the workstation at all.

So to do this, we go back into the same group policy (that applies to all workstations) and go to the User Rights Assignment under \Policies\Windows Settings\Security Settings\Local Policies\User Rights Assignment

Here we have the following rights that we wish to review:

Right	Description	Members
Allow Logon Locally	Who can logon to the system through the console	Domain Users
Allow Logon through Remote Desktop Services	Who can logon to the system using RDP	GDEL-Workstation-Admins
Deny Access to this Computer from Network	Who cannot contact the computer from the network	Domain Admins Enterprise Admins GDEL-Server-Admins
Deny Logon Locally	Who cannot logon to the console	Domain Admins Enterprise Admins GDEL-Server-Admins
Deny Logon as a Batch Job	Accounts that cannot be used for batch jobs (like scheduled tasks)	Domain Admins Enterprise Admins GDEL-Server-Admins
Deny Logon as a Service	Accounts that cannot be used as service accounts for local services	Domain Admins Enterprise Admins GDEL-Server-Admins
Deny Logon through Remote Desktop Services	Accounts that cannot logon through RDP to the system	Domain Admins Enterprise Admins GDEL-Server-Admins

 

As you can see from the above list, Server Admins, Enterprise Admins and Domain Admins have no business being used on an end-user workstation. Hence they are not allowed to even connect to these systems remotely. This ensures that these accounts cannot be used on these workstations and thus that their HASH is never stored. It also excludes the use of any service account that gathers these rights.

The same type of security is set on server admin workstations. In that case, the following table is used:

Right	Description	Members
Allow Logon Locally	Who can logon to the system through the console	GDEL-Server-Admins
Allow Logon through Remote Desktop Services	Who can logon to the system using RDP	GDEL-Server-Admins
Deny Access to this Computer from Network	Who cannot contact the computer from the network	Domain Admins Enterprise AdminsGDEL-Regular-Users
Deny Logon Locally	Who cannot logon to the console	Domain Admins Enterprise AdminsGDEL-Regular-Users
Deny Logon as a Batch Job	Accounts that cannot be used for batch jobs (like scheduled tasks)	Domain Admins Enterprise AdminsGDEL-Regular-Users
Deny Logon as a Service	Accounts that cannot be used as service accounts for local services	Domain Admins Enterprise AdminsGDEL-Regular-Users
Deny Logon through Remote Desktop Services	Accounts that cannot logon through RDP to the system	Domain Admins Enterprise AdminsGDEL-Regular-Users

 

(GDEL-Regular users represents normal user accounts, not administrative accounts).

When looking at the server part, the same principle applies, except that GDEL-Regular-Users does require access to the servers (else they would not be able to connect). But they do not require the right to logon locally for example. This means that the following right is the only one that is different:

Deny Access to this Computer from Network

Who cannot contact the computer from the network

Domain Admins Enterprise AdminsGDEL-Regular-Users

 

But wait you might say, what about my backup solution, or that service account of the application that does require domain admin rights to function? I say: There is NO application that requires FULL domain admin rights to function. You can delegate 99.9% of all tasks, but there is no reason for an application to be able to install a domain controller through a service account under normal conditions.

So the last one are the domain controllers. Who should be able to logon? Domain Administrators. And everyone else off course through network only. In my opinion, no one should also be able to logon through RDP (why even have a console?) but it seems the market (read YOU ADMINISTRATORS) is not ready for this yet. So lock-down the RDP rights to Domain Admins also and (try to) never use it.

Summary

The security within your Active Directory is highly dependent on the rights given to users and the use of privileged accounts. Domain Administrators (and Enterprise Admins) groups are to be secured as much as possible, as by default the Domain Admins group has administrative rights to each and every system. By default, the Domain Admins group can control everything, which makes things really handy and easy to work with, but it highly undermines any security mechanism put in place. If someone holds the Domain Admin credentials, security in any form is no longer present (unless if you count disconnecting everything). So it is important to discontinue the default settings and remove Domain Admin privileges throughout the environment and replacing them with delegated permissions that are fitted to each task. In the chapters above we’ve seen how to remove the domain admins group from workstations and servers. And as this group is removed from every workstation, it is easy to downgrade the number of domain admins too.