Hi, in this video lesson, we're going
to talk about lateral movement with the local administrator
account, well we're going to focus
on the local administrator.
This really is an issue that will
exist with all local accounts that have the same password set
across multiple devices, we're going
to focus on the local administrator account simply
because this is the most common case,
and because this account actually
existing environment by default that half an enterprise
version of Windows.
So what is the problem.
The problem is that an account ends up
having the same passwords store across all workstations,
and potentially across all servers,
I've seen a common approach where workstations might have
one password, and servers might have a different password,
but all servers will have one password across all of them.
And all workstations is just different.
And that is not really fixing the issue.
And so the main issue, here is that if we
compromise one workstation, take workstations for example, let's
assume that the password is used across workstations
and servers for simplicity to understand the problem here.
If we compromise one workstation,
or if an attacker compromises one workstation,
and gains administrative privileges on that workstation.
They will have the ability to extract the password
hash of the account court administrator
because password hashes of local accounts
are stored in the registry hive on the local machine.
So compromise is one machine, this access compromise one
machine escalating to administrative rights
we'll give you access to go and extract this special hash.
Now in many organizations the escalation part
is going to be needed because many users furnace
administrators by default. And there
is a massive, massive, massive mistake as well.
You should not let your normal users
have direct administrative rights,
if they need to do that.
There's many solutions that you can use instead,
which will elevate you for one minute, for five minutes,
or some customer time span that you might like
to set for your environment.
We can even provision a second administrative account.
Where users, if they require to be administrators
for one reason or another, they need
to log into their second administrative account
and use that one to perform the administrative tasks,
but not do it with the normal account
that they use on a daily basis, they read emails,
they read the Internet and so on.
So the issue with the password hash that you can extract here
is that--
Well, the first one is obvious.
You can go and try to break that password hash.
You can use better tracking tools, such as Hashcat
or John the Ripper.
You can go try to crack the password hash
and get the plaintext password of that hash.
If they have the plaintext password,
you can connect remotely to other machines.
But the caveat here is that you actually
don't need the plaintext password
to connect remotely to other machines,
you can use the password hash as is.
And that is a technique known as Pass the hash.
So by compromising one workstation,
in theory, and extracting the password hash from the Registry
Hive, in theory, you can connect to any other system
in your environment.
And that sounds absolutely crazy.
Because compromising someone in any department--
Let's bring up HR, because HR are people who are normally
targeted in targeted phishing attempts,
and they're probably also my favorite when we're
doing Red Team Engagements.
If you compromise an HR person, that person's device
will give you access to the rest of the environment.
And of course, we should not have this.
The exposure is too massive.
We can't have one device being single point of failure.
And definitely not just a regular workstation.
So here's an example of how we can abuse this.
We are running on a machine called WS10-001.
I'm assuming this stands for workstation 10,
referring to Windows 10, 001.
The next step is, we're downloading Mimikatz,
or the partial version of Mimikatz called Invoke
Mimikatz, into memory, and then executing a custom command
lsadump::sam.
This custom command will locate the Registry Hives
from the computer and extract the password
hash of all local accounts into text.
And in this case, what I have highlighted
is the password hash of the account administrator.
It's really that simple.
Getting a tool, such as Mimikatz, running it,
and then you have the password hash.
And if anyone is not familiar with Mimikatz.
This is probably the most common hacking tool,
which I'm just assuming that everyone is familiar these days
with.
But other than this capability, it became really famous
because of its ability to extract plaintext passwords
directly from the member of the computer.
Or essentially, these passwords are stored into the process
LSASS, that Mimikatz debugs and locates, extracts
and then gives to an attacker.
But in our case, we're getting the hashes.
Now we have these hashes.
They're available to us.
We can point them to any other system,
authenticate to it as the account local administrator.
And why would we do that?
Well, first we want to--
Or, not we, but an attacker would
want to go and identify what files and data is
stored in those systems.
But potentially, they'll also want
to perform or utilize to Mimikatz again, especially
on servers, and try to extract more privileged credentials
from those servers.
And most likely, the credentials that they'll be looking for
are those of domain administrators.
And of course, that is really bad.
Because from one system, you might end up
into a position to move laterally
across your environment, and essentially
perform credential theft to obtain
credentials of higher privileged users, such as domain admins.
So here's an example of using a tool called crackmapexec, where
we're specifying the user administrator and the password
hash that we have just obtained.
The X parameter specifies the command
that we want to execute, in this case it's hostname.
We just want to run hostname.
Then we are specifying that we want
to authenticate with the local user towards the remote server,
so that this is the administrator account that
is local to the system, and not the account administrator that
is part of the domain.
And what we can see in here is that the tools--
One of the messages that comes to us in a different color
is Pwn3d, which identifies or outlines
that we have successfully connected
remotely to this machine and we executed the command.
The command returned Server01.
So we actually successful connected to Server01
with the account administrator and executed
this hostname command, which returned Server01 back to us.
Well, there are multiple solutions to this issue.
Some of us, or some of you, might simply
disable the account called administrator
because it's not being used.
But one of the concepts that we're
going to be discussing in a future video
is Active Directory Tiering.
And if we implement the tiering model,
this local administrator is going
to be extremely handy to prevent credential
theft in our environment.
But what we want to achieve with this account administrator,
is that we want it to have a unique password
for each device.
And some of you might have already created some scripts
that will perform this.
Microsoft came up with the solution, which
is a tool called LAPS, it stands for Local Administrator
Password Solution, and it can set
the password uniquely for each device in the entire Active
Directory.
And it will manage the password by occasionally setting it
to a unique value on a predefined time base, by you.
It will change and it will set the password
on an ongoing basis.
Normally, I'd recommend this to be on a daily basis,
because there's no reason really to keep
the password for more than one day,
and one day is the minimum.
So LAPS is one of those really good solutions in this case.
It's very easy to implement.
It does require a change into the Active Directory schema,
because the passwords that each computer is going
to have set to it's administrator account
is going to be set actually in Active Directory.
So what LAPS is going to do is, it
will create a new attribute for each computer object,
and then store the password inside there.
By default, only domain administrators
will be able to read this password,
but you'll be free and able to perform any kind of delegations
you like.
To give, for example, service desk
or any other person of interest access to these passwords
as well.