Hi.
Welcome to this video lesson on Active Directory Tiering.
This one is the first of two parts,
in which we will only focus on the theory behind this model.
In the second part, we will go and practically implement
the model in our environment, where
we can showcase how it works.
Our short agenda includes, first identifying what is the problem
and why do we need this tiering model, what
does it solve for us.
And the real problem here is the credential theft
that often occurs at endpoints, and we will demonstrate that
just in a second.
And the second part of the agenda for this video
is the model itself.
So we really drill down into the model
and go through different parts that
are really important to implement it correctly.
So the problem itself is credential theft.
What happens is that, when you connect remotely or physically
at a Windows machine, your credentials
are going to be stored in the LSASS process.
And tools such as Mimikatz, have the ability
to debug that LSASS process and extract credentials out
of that.
And these credentials can be both plaintext passwords,
but also password hashes.
What you can see on the image currently of the side,
we can see that it would display the username,
which is Gentil Kiwi, and also the password waza1234/ This is
the plaintext password.
But what we can also see, just above that,
is that it will also contain the NTLM password hash.
While this is correct in some occasions,
in newer systems, which are Windows 10 and Server 2016,
we should not be seeing new, or at least plaintext credentials
being stored.
But unfortunately, that is sort of being
controlled by a registry key.
So an attacker who had gained administrative access
to that endpoint, may be able to just flip
the value in that register key and start caching
credentials in plaintext.
But, to be honest, the truth being told,
it doesn't matter if the credential is in plaintext
or not.
The password hash will be more than sufficient to actually
utilize it to remotely connect to other systems,
unless other [? preventures ?] are in place.
So what we're going to demonstrate now
is, we will perform credential theft
and using that new identity in our environment.
So let's just switch to that.
Now, I am connected to the environment
where we are going to showcase the credential theft.
I have already downloaded two tools which you need,
which are Mimikatz and Rubeus.
And to set the scenes, let's assume
that we are an attacker who has compromised
a user in our environment.
And one of the perks which we will just
go forward with and assume that we have,
is that the account or the user which we have compromised,
has local admin rights.
Now, let's go into Mimikatz and start with this tool.
I'm going to go forward and start
PowerShell as an administrator.
Now, the first thing that I want to show in here,
is that my user doesn't have any privileged access
towards the domain controller.
So if I try to list the C drive of the domain controller,
I'll get that there's access denied,
so I can't see anything in there.
Next, I was just start Mimikatz.
And inside Mimikatz, we will execute debug--
Sorry, privilege::degbug, which will assign us debug rights
on this machine, so it can debug the process LSASS and extract
credentials out of it.
Then the command that we need to execute to get those
credentials out is sekurlsa::logonpasswords.
By doing this, the tool will go locate the LSASS process
and extract all the credentials back to us
in a human readable, understandable format.
And because this is a Windows 10 machine,
we don't expect to see any plaintext passwords.
And what we are looking at in this output
is any user or credentials of something
that is more privileged.
So what we can see in here is that the account administrator
must have logged in, but nothing is stored from that session.
Then we will continue scrolling up.
We can see that there is a login from Slavi.
In this case, we will see the NTLM password hash.
And continue scrolling through the output.
Going up, up.
And actually, if you look in here.
Now we will see that there is the administrator
and the password hash is also available.
Now, this is interesting, because this is really
what we want to achieve.
Actually, extract these credentials.
So essentially, we have the password hash
for the account administrator of the domain PROD.
Now, it's time to use our second tool, which we have downloaded,
and that is Rubeus.
I will just start Rubeus in a separate window,
so we can keep track of which window is doing what.
Now, in Rubeus, I will specify the parameter asktgt, which
will create a Kerberos ticket.
But now, this ticket will also specify the username
that we want the ticket to be created for,
and it is administrator.
And we are going to specify the NTLM password hash
of this account administrator.
So Rubeus will obtain a Kerberos ticket
for the account administrator by just
utilizing this special hash, without knowing
the plaintext password.
And the next parameter that I want to provide
is PTT, which is passing the ticket.
The Kerberos ticket that Rubeus is going to extract,
it would just automatically inject it
into this PowerShell session.
So in this session, I'll be running as the administrator
account, if this succeeds.
So running the command will get the actual ticket,
and it's being injected.
It's notified by this message here that the ticket
was successfully imported.
If I do klist, I will see that there is indeed
a Kerberos ticket in my PowerShell session
for the account administrator in this production domain.
So if I perform the initial step again,
by trying to execute the ls command against the C
shared drive of domain controller,
now we will actually see the content of it.
We are, essentially, the administrator account.
We have successfully compromised this account.
And what is crazy is that we never
even knew the password of it, we only had the password hash.
And this is the credential theft that we
want to really prevent against.
And one of the main reasons why this is possible,
is because privileged users, such as this administrator
account, are allowed to log into non-secure or often compromised
devices, such as endpoint workstations.
Now, let's go back to the slides and talk
about the model which will try to prevent this credential
theft.
The Active Directory Tiering model
is designed to provide protection
of stealing highly privileged credentials by implementing
buffer zones.
In other words, these buffer zones or tiers
are categorizations of assault. By creating
this categorization, we will enforce
an amount of restrictions in our organization
that will prevent privileged users from accessing
non-privileged, or rather, less trusted devices.
By doing so, we will effectively mitigate
the risk of low privileged users from performing
credential theft against a highly privileged user.
The default model introduced by Microsoft,
contains three tiers, which are tier two, representing
workstations and their users.
It also includes groups at this level.
Both for regular users, but also administrative groups
for those users who perform administration on workstations,
such as help desk personnel.
Tier two represents regular member servers
in the domain and their associated users,
groups and applications running on them.
Tier zero is defined as the most critical infrastructure,
such as domain controllers, PKI, and so on.
It, again, includes the users endgroups
who operate at this level, such as domain
administrator and similar.
In this next slide, we are representing
the different actions that are allowed to occur in our tiers.
Tier two administrators can only manage and control assets
at the tier two level.
These users are forbidden from accessing
any of the other tiers.
Tier one administrators can manage and control assets
at tier one and tier two levels.
But as we'll see later, these users
can only login interactively to tier one systems.
Finally, tier zero can manage and control assets
at any level.
An example I often give, is to think of GPOs.
If you are on a domain controller,
you can create or modify GPOs that
can be applied to devices on all tiers.
Now that we have discussed the control part,
let's take a look at allowed logins.
I suspect that there's no surprises here.
In short, a lower tier is not allowed to access higher tier.
For example, a tier zero count is not
allowed to access a tier two workstation.
And this is really what the entire model is about.
If privileged users cannot access untrusted systems,
then there will be no credentials to be stolen from
them.
For this model to be effective, I
have listed some requirements that you really
should consider implementing.
The first one is rather obvious, that servers
should be domain joined, otherwise
we can't really talk about a tiering model of a domain.
Then I recommend that administrative users,
especially those at tier zero, are members of the Protected
Users group, to benefit from all of the protections
that this group provides.
Of course, unfortunately, they will also
inherit all the problematic perks
that this membership brings with it.
So extensive testing before adding users in this group
is definitely required to verify that no critical systems are
breaking or access to those system is being blocked.
Next on the list is LAPS.
And this is here because, if LAPS is not installed,
then there may be tier one servers
who have the password of the local administrator
account being the same as the password of the same account
in a tier zero server.
That would directly breach and break the model,
as compromising tier one server would provide access
to tier zero systems.
Patching is also really important.
If we don't patch our systems, then adversaries
may have the opportunity to compromise tier one or tier
zero unpatched servers from a tier two endpoint device.
Of course, we do not want this to happen.
So effective patch management should be in place.
And note that the recording of this is in 2020,
and we are still talking about patching being a problem.
So let's hope that the future will bring better days.
The final bullet I have outlined is workstation and server
hardening.
I can't recommend enough to implement better protection
to endpoint devices by really limiting the [? attacked ?]
servers to them.
You should really implement some features
such as Credential Guard, AppLocker, BitLocker,
the Windows Firewall, especially for blocking
incoming connections, and also restricting
the execution of PowerShell for regular users.
Something additional on managing systems
is the usage of the principle of least privileged.
Having as little as possible administrator,
of about two or three, is key driver
to reducing lateral movement in the environment.
Also, privileged delegation all over the place
is really not necessary, especially when
it's not controlled.
Tools, such as Privileged Access Management,
are really good at this, because escalated access can
be provisioned only for a short time
and automatically removed afterwards.
Also, privileged delegation all over the place
is not necessary, especially when it's uncontrolled.
Tools, such as Privileged Access Management,
are really good at this, because escalated access can
be provisioned only for a short time
and then automatically removed afterwards.
On the next slide, I have a table taken directly
from Microsoft, which is found on the link that
is at the bottom of the slide, in which Microsoft showcases
their recommendation on operation practices.
These are all very relevant and should be
considered to be implemented.
What I wanted to outline especially,
is the Manage Risk of Credential Exposed section.
While you can see that what we discussed previously
on least privileged is also mentioned here,
and Microsoft also flags as mandatory that tier zero
accounts should use a strong authentication,
such as smartcard token, or other type
of multi-factor indication will also
suffice under the assumption that administrators have
long and complex passwords.
Now, for the credential exposure part,
we need to have a separate administrative accounts.
General Internet browsing and reading emails
is not allowed on administrative workstations.
These workstation that I'm referring to
is known as privileged access workstation,
and we will discuss this in detail at the later model.
But for now, just think of it as a separate device
that administrators use to access tier zero
and tier one management systems.
There is also a mention of administrator logon practices.
And to describe this in better detail,
I created the following table to outline allowed and forbidden
logins.
In the table, the different categories
which I have provided are practices
for remote logins, for physical logins,
and what should not occur across the different tiers.
Let's take, as an example, just tier two.
In here, we allow Remote Assistance
over Skype or other screen sharing tools,
as well as RDP, only when Remote Credential Guard is used.
We also allow administrative access to the workstation
by using the administrator account managed by LAPS.
In many cases, this will be the built-in administrator account.
For physical logins, we allow only usage of LAPS account.
And finally, we forbid login with administrative domain
account, and we do not perform any normal RDP connection
with a privileged domain account towards these endpoint devices.
By following this table, we are really
limiting the exposed credentials that will, at any point,
reside at an endpoint.
It may seem that this model sounds
complex and hard to follow, but trust me,
once you understand it, it's very easy.
And in this video--
I'll stop it here--
we are wrapping up the theoretical part
behind this tiering model.
While in the next video, we will look
into the practical implementation of this model
and how we can actually achieve these forbidden and allowed
logins.