Hi.
In this video lesson, we're going
to talk about the DCSync attack.
The DCSync attack is trying to impersonate a domain controller
and perform Active Directory replication.
By doing so, you can extract the entire Active Directory
database, which will include usernames and passwords as
well.
But before you can do this, there
are certain privileges which are required.
And the two ones are Directory Replicate changes
and Directory Replicate Changes All on the domain object.
If you have these two permissions,
you can essentially become a domain controller.
And the outcome of that is that you
could utilize a tool such as mimikatz that has the command
lsadump dcsync, where you can specify
the user account of the user whose password hash you want.
And as you can see in the picture currently,
we'll get the hash NTLM value for a specific account.
And you can do this for any account in Active Directory
as long as you have these two permissions.
And while there might be some reasons why
you want to delegate these permissions to some users,
you should really keep this to the bare minimum.
Because if an attacker obtains these privileges,
it is literally game over for your entire forest.
So what can we do to protect against DCSync attack?
And what I want to outline here is
that DCSync is something which we performed
when we were talking about Kerberos delegation
in the short demonstration we did there.
We managed to obtain the Kerberos ticket of the domain
controller, and then we performed DCSync.
Even though we did not impersonate the domain
controller, we became the domain controller in that point.
The most common abusive way for attackers
is to gain access to an account that has these premises
and use it.
And the most common account that requires these permissions
is the Azure [? syncing ?] account.
If you have password sync to Azure AD,
that account will have these permissions.
So protecting that account is really important.
And if you have a separate server that
is used for password synchronization with Azure,
that account or that server has to be really, really tightened.
The security of it has to be very protected.
So how do we protect against DCSync?
Well, really, you should just not
assign the two rights which I just mentioned.
If you need those rights, the accounts
have to have very long passwords,
and computers where these accounts are logged into
should have a very limited amount of administrators--
really, only the people that actually need to log in to them
to perform some kind of maintenance or something
of that sort, and not just because they
have a group that a server administrator also has.
There are very limited amount of people
that actually have business need to be on those devices.
While protecting against DCSync is
really hard, the detection is much easier,
because every time a domain controller replication
is performed, an event is going to be logged,
and you can look into that.
If the event comes from a non-domain-controller machine,
then you are certain that an attacker
is trying to perform this attack on your network.
Here is an example.
On the top image, we have a query for a CM system
where we are looking at the event ID 4662
and where the username does not end with dollar sign,
it is not AUTHORITY, or the username is not Window.
So by doing this, we're going to get rid
of noise of known things that will occur and only
get alerts on those that are really suspicious.
And what we're going to see into the event--
I do not [? reflect ?] on the picture--
is exactly that.
There's an account which was used
to perform Directory replications,
and it was not coming from the main controller.