Original link: https://windowssecurity.ca/2020/03/23/mitigate-credential-theft-with-administrative-tier-model/

Introduction:

A lot of organizations have a credential hygiene problem without knowing that they have it. It’s one of the common reasons why attackers are managing to obtain Domain Dominance so easily in a corporate environment, because credentials are everywhere.

High-privileged accounts with the likes of Domain Admins & Enterprise Admins are login on every system. Spreading their credentials across the entire environment, because in most cases. IT Admins are the one’s with DA/EA privileges to perform administrative tasks on workstations and servers. It has always been like that.

Lets first understand the problem, before we’re diving into all the technical details.

It is very common for organizations to run Active Directory as their identity service to manage thousands of users. AD uses Kerberos as the default authentication protocol and Kerberos supports Single-Sign-On (SSO).

Single-Sign-On (SSO) is an authentication process that allows users to access multiple resources with just one set of credentials. This eliminates that users needs to re-enter their credentials all the time when they want to access a resource.

What people might forget is that Active Directory provides SSO as a main feature, but to do this. Windows needs to cache the credentials and store in the local memory or otherwise users would have to authenticate against everything.

This means that when an attacker has obtained admin privileges on a workstation or server. All the credentials with the likes of the local SAM database, NT(LM) hashes, and Kerberos tickets can be exported from memory.

And lets say that a Domain Admin was recently logged on a compromised SQL server. It would mean that every (local) admin on that server can obtain the credentials of the Domain Admin and move laterally with it.

This is not a vulnerability in SSO itself, but it’s how the functionality has been designed, so that’s why attacks like Pass-the-Hash & Pass-the-Ticket are still being used to attack corporate environments. It is leveraging the functionality on how SSO is working. Credentials needs to be stored in the local memory, and attackers are taking advantage of it.

Privileged Access Workstation

A privileged access workstation is a separate physical hardened workstation to perform administrative tasks on. It’s a workstation that is managed by a separate account of an IT Admin.

This workstation is completely locked down, which means that it doesn’t has internet access, Outlook, and so on. However it does contains the tools to perform administrative tasks with the likes of Microsoft Remote Server Administration Tools to manage Active Directory.

A Privileged Access Workstation (PAW) needs at minimum, but not limited to follow the following criteria:

• A separate physical hardened workstation to perform administrative tasks on
• A separate account to manage the privileged access workstation
• Remote Server Administration Tools (RSAT) to manage Active Directory
• No internet access available, but you can whitelist a few URLs if you’re managing Azure and Office365 as well.
• No Outlook installed
• USB drives are blocked
• Inbound network connection is blocked
• Each IT Admin manages his or her own PAW.

All the hardening settings can be configured through Group Policy.

After you have joined a PAW to an Active Directory domain. It’s just the beginning, because there’s a lot of other work to do as well.

Administrative Tier Model

Microsoft Administrative Tier Model is a security reference model that is designed to mitigate credential theft.

This involves that you need to categorize your IT assets into three different tiers. Based on the business value it has. The reason that you have to do this is, because if an attacker has compromised one Tier. It would be difficult to compromise the other Tiers, because they are in a different zone. Not saying that it isn’t impossible. It just makes it incredible difficult for an attacker to accomplish it.

Administrative Tier Model is an effective security measure to mitigate lateral movement, because a higher Tier can’t log on a lower Tier, and a lower Tier can’t log on a higher Tier. Makes sense?

This means that the credentials of a Domain Admin would never be exposed on a SQL server or a lower trusted workstation for example.

This is how the Tier model should similar look like when implementing it in Active Directory. An OU structure needs to be created to separate all the resources.

This is an list of all the all OU’s and the resources that belongs to it. It’s not necessary to name them exactly like this. It’s up to you to decide if you feel that they should be renamed.

• Tier 0

Tier 0 admins manage the most critical assets on the network with the likes of Domain Controllers, AAD Connect, ADFS, and so on. These are usually your Domain Admins & Enterprise Admins. Everyone in Tier 0 can’t log on a Tier 1/2 zone and vice versa.

All of them need to have a separate account to perform administrative tasks, so you can create an ”Adm” account for all your Tier 0 admins and put it in the Accounts OU.

Second thing you need to do is after you have joined all your PAW’s to an Active Directory domain is by placing them in the Devices OU.

Third thing you have to do is add all the AD groups that belong to a Tier 0 zone in the Groups OU.

All your service accounts that have Domain Admin or equivalent privileges needs to be placed in the Service Accounts OU.

Tip: If you have a service account with Domain Admin privileges running as a service on a member server. You need to treat that member server as a Tier 0 asset. Because if an attacker has compromised that server. DA credentials can be dumped from memory, which means that the attacker could completely own the entire domain.

Last, but not least. You need to place all the server accounts in the Tier 0 Servers OU. All the computer accounts that are stored in this OU are the critical servers, that needs to be protected at the highest level. I would keep all the Domain Controllers accounts in the Domain Controllers OU. Don’t move these.

What we now need to do is clean up the local Administrators group on all the Tier 0 servers. Remove all the users and groups that don’t belong to a Tier 0 zone.

After you have done that. Look what kind of GPO’s are linked to the Tier 0 OU’s. Who can modify those settings? It should only be Tier 0 admins.

• Tier 1

Tier 1 admins are managing important servers, but they are not immediately business critical. Tier 1 admins are usually Server Admins, Application Owners, DBA’s, and so on.

Everyone who’s part of the Tier 1 zone can’t log on a Tier 0 & Tier 2 zone, and vice-versa.

This is an example of all the Tier 1 admins that have a separate account as well. All the accounts are stored in the Accounts OU.

Now the painful part is the PAW, because it really depends how big your organization is. Every Tier 1 Admins needs to have a separate workstation as well, so that means that in this example. We need to have nine PAW’s, because we have nine Tier 1 admins. All the Tier 1 PAW’s are stored in the Devices OU.

All the AD groups that belongs to the Tier 1 zone needs to be stored in the Groups OU.

All the service accounts that are running as a service on a Tier 1 member server needs to be stored in the Service Accounts OU.

Last, but not least. All the server accounts that represent a Tier 1 server needs to be stored in the Tier 1 Servers OU.

If you don’t want to store all server accounts in one OU, which is understandable. You can create a Child OU under the Tier 1 Servers OU to separate all the servers from each other.

Here is an example where I’ve placed all the SQL servers, Exchange servers, and other servers in a separate OU. They all still belong to a Tier 1, but it gives me more of an structure in managing my OU’s.

Tip: After you have finished Tier 1. Take a look to see who’s in the local Administrators group on all the Tier 1 servers and remove users and groups that don’t belong there.

• Tier 2

Tier 2 admins are managing the workstations of all the end-users in your organization. These are usually Helpdesk folks and Workstation Admins.

This is the last part of the Tier, so it’s basically the exact same thing that we did before as well.

All the Helpdesk folks and Workstation Admins are under the category of a ”Tier 2 Admin”, which means that they also need to have a separate account to perform administrative tasks. All of these accounts are stored in the Accounts OU.

As discussed before, they also need to perform their administrative tasks on a PAW, which is stored in the Devices OU.

The Tier2 AD group that is a local admin on all the Client’s workstation. This group needs to be stored in the Groups OU.

Service accounts that runs as a service on the end-users their workstation is stored in the Service Accounts OU, but don’t forget that service accounts are not allowed to run a service on a PAW.

Last step is all the Client’s workstations from the end-users. This includes the normal workstation of all your IT Admins as well. Client’s workstations are stored in the Workstations OU.

Tip: Remove unnecessary users and groups from the local Administrators group on the Client’s workstations. Only Tier 2 Admins should be a member of the local Administrators group.

• Denying logon access – Tier 1

We now need to deny logon rights, so we need to create a Group Policy where we deny that a higher Tier can’t log on a lower Tier, and vice-versa. We’ll start with Tier 1 first.

First we are going to take a look at the AD groups that are stored in the Tier 0.

Here we can see that Tier-0-Admins is an AD group that belongs to the Tier 0 zone, which means that it has access to the critical assets of a business.

All the members in this group should not be able to log on a Tier 1 & Tier 2 zone. Besides of our own custom-delegated group. We also have groups with the likes of Domain Admins and equivalent. All the members in those groups should be treated as a Tier 0. Members in those groups shouldn’t be able to log on a lower Tier as well.

Create a Group Policy with the following name: Tier1-DenyLogonRights

Edit the Group Policy and configure it with the following settings:

Tip: Most organizations only think about Domain Admins & Enterprise Admins, but there are other groups as well that have escalation paths to AD Admin. You can think of groups like Backup Operators, Server Operators, etc.

Now verify that you’re Group Policy looks something like this.

Now we need to link this GPO to the Devices & Tier 1 Servers OU that are located under the Tier 1 OU.

• Denying logon access – Tier 2

We now need to create a second Group Policy, but there won’t be much of a huge difference. We have a list of groups that we previously denied logon access. All those groups were part of a Tier 0, but they aren’t allowed to log on a Tier 2 zone as well, so we need to include them.

First we need to get a list of all the AD groups that belongs to the Tier 0, which are the following:

Now we need to get a list of all the AD groups that belong to the Tier 1 zone, which are the following:

If we combine all of them together we’ll get the following result:

Create now a Group Policy with the following name: Tier2-DenyLogonRights

Configure it with the following settings:

Check the Group Policy settings before applying them.

Now we need to link the Tier2-DenyLogonRights GPO to the Devices & Workstations OU that is located under the Tier 2 OU.

• Test phase – 1

In this test phase we are logged in as a Tier 0 admin, and we’re trying to connect to assets that are located under Tier 1.

Lets see if we now can connect to a Tier 1 asset.

First we’re going to try RDP against the Tier1-PAW1 host.

As expected, we got denied, because we are not allowed to log on a lower Tier.

Now we are going to do the same thing, but instead of RDP. We are going to use WinRM to see if we can connect to the SQLServer that is locate under Tier 1 as well.

Access is denied, so we can confirm that we’re not able to log on the Tier 1 zone.

• Test phase – 2

We are still logged in as Lee Johnson that is part of Tier 0, but we’re going to see if we can RDP to a Tier 2 asset.

Here we are trying to RDP into the Tier2-PAW1 host.

We get an access denied, because we are not allowed to log on a lower trusted Tier.

Last, but not least. We are trying to RDP into a Client’s workstation, but we will get denied as well.

• Test phase – 3

We can’t log on Tier 1 & Tier 2, but as a Tier 0 admin. We do still need to access our own assets that belongs to our zone. Can we still do that?

Yes, we can!

Here we have established an RDP connection to the Domain Controller, because this asset belongs to Tier 0.

Conclusion:

Microsoft Administrative Tier Model is a great security measure to mitigate against credential theft attacks, because higher Tiers can’t log on lower Tiers, and vice-versa.

This means that the credentials of a Domain Admin would never be exposed on a lower trusted Tier, like for example. A print server or a client’s workstation.

Reference:

Why Privileged Access Workstations can help to secure your organization

Securing Privileged Access Reference Material

[招生]科锐逆向工程师培训(2024年11月15日实地，远程教学同时开班, 第51期)