Hi.
Welcome to this video lesson on group policy preferences,
where we're going to discuss one of the vulnerabilities which
exists here that could be exploited by attackers who have
gained access to our network.
Group policy preferences is a policy maker
of some sort with one of its most useful features
being the ability to store and use credentials.
Some examples of when GPP is useful
are schedule tasks, mapping drives, or changing local user
passwords.
Now, scheduled tasks and changing local user passwords
are interesting because the password to be set
will be stored in group policy preferences, the domain
SYSVOL folder.
These passwords are encrypted with AES-256 bits.
However, this encryption key, which
was meant to be known only by active directory
was potentially unwittingly released on Microsoft's MSDN.
The problem here arises that since every domain user can
read GPP files, they can use this key
to decrypt encrypted data in them.
From experience on different penetration tests,
I have seen very privileged domain credentials
being stored in here, and in many cases, those
who are of service accounts that were members
of the domain admin's group.
If you look into the next slide, on this image,
we can see an example of a file containing encrypted passwords.
That is indicated in the cpassword parameter.
There are many tools now that exist,
which will automate the process of searching and decrypting
the cpassword parameter.
These tools make it trivial to exploit,
because all they require is to run the script or program that
has this capability.
The approach on the slide is a bit more
manual to outline the decryption step
by using Get-DecryptedCpassword on the bottom image, which
returns the plaintext value once decrypted.
As you can see on the image, the last value
is the decrypted password.
When we talk about protection, well, Microsoft
released a patch back in 2014 which
will prevent administrators from being able to store credentials
in group policy preferences.
And while that is really great because it will not
happen in the future, they didn't really
release anything that can take care of credentials
which are currently exposed.
And it's really up to you to go and scan your environment
to find out whether there are any credentials
such as these ones being exposed in group policy preferences
files or not.
And the interesting thing here is
that if you find the credentials being exposed,
they must have been exposed in those files from at least 2014.
That's a massive gap that we're looking at right here.
So what you really have to do now
is go and scan your environment.
Utilize any of the available tools.
You can start using just find string,
a basic Windows command to scan XML files in group policy
preferences that contain the parameter cpassword.
Or use one of the automated tools,
whether it's a partial script or a different tool.
A partial script that comes to mind is Get-GPPPassword.
And a tool that can do this is PingCastle.
We'll look into PingCastle in detail in a further module.
But for now, it's very important to ensure
that there's nothing that is being
exposed in your environment.
And again, this can be local credentials.
It might as well be domain credentials as well.
We need to clean them ourselves and make sure
that this patch is installed so that no passwords are
going to be stored in this location in the future.