Hi.
Welcome to this video lesson in which
we're going to be talking about passwords
and different password policies.
Let's begin by looking at the agenda.
First, we will look into general what passwords are
and common passwords We'll talk a little bit
about different password policies that we can create
and the ones that we should definitely
have in our environment.
We'll move into fine-grained password policies
or how we can implement, practically,
the different policies that we can create in our environment.
We'll demonstrate how to create one
of those fine-grained password policies.
Then we will look into a tool called Get-bADpassword.
Or B, the naming convention is rather interesting.
Which can scan the environment and showcase weak passwords,
leaked passwords, and also users who share passwords,
and a lot of different information about passwords.
And that is purely based on the password hashes in our AD DS,
in our Active Directory.
We'll also demonstrate how this tool works.
So let's look at the top 10 passwords for 2020.
What we can see here is absolutely shocking
because we're based in 2020.
We're at the end of 2020.
And the most common passwords haven't really
changed over the years.
The most common password being the numbers,
sequentially, 1 to 6.
Well, it's rather crazy that even passwords that are six
characters are still allowed.
And the fact that it's six characters
is just crazy because six characters, breaking it,
from a password protection perspective,
takes a fraction of a second.
So this list is really shocking to me
and we really need to find a way to move away from this.
You can see some of them are numbers.
The other ones are only lowercase letters.
But the important part here is that they're all
very short passwords.
So let's define the different password types.
We have weak passwords.
And that would be a password that you can guess,
or it's also a password that doesn't
have any complexity enabled.
As you can see in the example here.
We have only a password that's only a number or only lowercase
letters.
There's no mix.
There's no uppercase, lowercase, numbers and so on.
And that brings us to the next definition
that a password can actually be complex but at the same time
still weak.
An example of that is "Password1"
which contains uppercase lowercase and a number.
But again, it's very easy to guess.
It's a weak password.
Same thing with "Winter2020", that
would be one of the first passwords an attacker
is going to try to guess.
It exists in every dictionary.
There's no protection against these passwords.
And if you look into "Winter2020",
that password is nine characters.
It's complex, but again, it's weak.
It's guessable.
So we really need to move from creating passwords
into creating password phrases.
And that is something that will have increased length
because more length makes cracking significantly harder.
And as an example, I added a complex phrase in here.
In which I have uppercase, lowercase letters, and also
numbers.
And the phrase in here is something that would be easy
for me to remember.
And I don't need to put effort into coming up
with something that is random.
So coming up with a phrase of something common
in your daily life could actually
be much better than creating a password, which
is just "password".
Right?
So in this example, I have given a password, which
is "DailyCoffee4EarlYbirdz".
And if you're a coffee person this
could be just a great password for you.
And of course, you like waking up in the morning.
But the idea here is that it's easy to remember, the phrase.
It's long and it's even complex.
And when we talk about long passwords.
Complex is not necessary.
It's just good to have.
So our goal is to get users to think
into creating a passphrase compared to having a password.
And we have really failed to ensure that our users have
good passwords.
So passphrase is really the way forward.
Now why are we talking about policies?
Is there something much more here?
Well yes, because we have different users
in our environment.
And we need to categorize those users
and create different policies based
on what these users have access to or what they can manage.
So regular users are the first group.
That will be the most normal employees with normal accounts
with no privileges at all.
They only have access to email, to their workstations, and very
few business applications, that they
need to work during the day.
So an example password policy in here is shown on the slide
currently.
Where we define that, we want to remember
24 the previous passwords.
And the choice of 24 here is because this is the maximum.
We don't want users to repeat the same password.
Then we have increased the password age to 180 days,
as opposed to the 90 days which used to exist in the old audit
scripts.
And audit companies were checking for that.
There really isn't any need to change your password every 90
days, maybe not even 180 days.
Maybe 360 days, once a year, would be a good indication.
Once we come at the point where we're
looking into pass phrases, unless there's a reason
to believe that the password is compromised,
there should really be no reason for changing that password.
So increasing the password age, not
making it an infinite as some companies
have recommended recently, but expanding this,
giving some buffer space for users,
because we're increasing their complexity and length so we
can actually increase the days for which they
have to remember that password.
It's a good trade-off for us, as security professionals,
but also for the users as well that they don't have
to change the password at all.
What we have also defined here is the minimum password age
of 1 day.
The reason why we define this is because if this is not defined,
a user will be able to go and change their password 24 times
consecutively, in 24 seconds, and they'll
end up with the same password that they
used to have before that.
And we don't want passwords to be repeated.
With having 1-day password minimum age
we really prevent a user having the same password again.
Unless they change their password every day,
but that would be just absolutely crazy.
And even if they were doing that,
the password would still be a massive passphrase
that they would hopefully create.
We also said the minimum password length
of 14 characters.
And 14 is a really good number here because it
will, just by default, get rid of all these weak passwords,
such as Password1, summer2020, Winter2020.
A user will not have the ability to set those passwords.
So they need to think big.
Of course they have the option to do summer20202020
or summersummer2020, but we will have this,
you'll see in a little bit, ability to actually take
these passwords and either force users to change their passwords
again, or at least notify them that,
give them a crash course on how to create a passphrase.
And you have the knowledge that users
will have these bad passwords.
And the amount of them is going to be significantly less, as
opposed to having a password policy which
is eight characters.
In this password policy we will also enable the complexity.
And we do not store passwords with reversible encryption.
We want to store only the password hash.
Of course, we don't want to be able to reverse
the original password of the user.
So that brings us to the next policy
and that would be administrative accounts.
Should administrative accounts have the same policy
as regular users?
I mean, by definition this doesn't make sense,
because regular users are not administrative accounts
and administrative accounts have way more access.
Some of them will have complete access for our environment.
We need to protect these accounts better.
And one way to do it is to have a different password
policy for them and require them to have a password length
of at least 20 characters.
Then we'll have a service accounts in our environment.
So should we have these special policies for service accounts?
Should they apply it as they are?
Well, not really.
The thing about service accounts is that, first of all,
if you can use group Managed Service Account
you should totally do it.
The password is meant going to be 127 characters.
It's going to be random.
And it's going to be changed regularly
by Active Directory itself.
So if you need to create an account
to start a service, which is not supported group Managed Service
Account, and we need to create our normal service user
accounts, then the password of these accounts,
we should really increase it significantly.
Because in most cases, this is a password which you enter once
and you don't have to ever use it again, nearly,
in your lifetime.
Or in the lifetime of rotating service account
passwords, which might be a year or two years in the future.
It's not something that you'll be typing every day.
So the recommendation here would be
that you need to set a password, which is
at least 100 characters long.
The maximum password which can have in active directory
is 127 characters.
So I'm leaving you a buffer zone between 100 and 127
so you can choose the exact length yourself.
And in that way we don't have an attack
that you have a password length of certain size.
If I tell you that your password length should be 100 exactly,
then attackers will be cracking passwords exactly 100 size.
While that might be impractical, they might still try to do it.
And that is impractical with the current computing power
but it might be practical in the future.
You never know.
Although it sounds crazy if you look into the cryptography part
of that.
Now there is an issue with service accounts
in hundreds or more characters passwords, because some of them
are used in services which do not support,
themselves, that long a password.
And in that case, I would normally
suggest that you can have a second service account password
policy which is 32 characters.
So you default for hundreds or more.
If you need a service account for services
that doesn't support the hundreds or more characters
password then you can create it with 32 or more,
depending on what the service supports.
Then we can also have different password policies for VIP,
management, executives.
It depends on your own organization,
how you want to approach this.
Usually, I would recommend at least 20 characters
for these accounts as well, similar to the administrative
accounts So this is a different password policy
that we can create.
And you can expand the list as much as you want,
but these are the ones that you really have
to have in your environment.
Now fine-grained password policies,
it's a way to create multiple password policies
within the same domain.
And it's really unique because they will be independent.
And the way that you distribute them is you
send them to a group interactive directory.
So as long as a user is a member of a group
they will inherit this password policy
that the group is applied to.
One caveat with this is that it can only
be applied to global groups.
So you cannot use it for local domain groups for example.
Now let's move into the environment and, as an example,
just create a fine-grained password policy
for administrative accounts.
Now I'm connected to our domain controller.
So I will start Active Directory Administrative Center.
Which is where we can create these fine-grained password
policies.
It's important to mention that you
need to have administrative access to be
able to modify these values.
So I switched into tree view just
because I find it slightly better
for me to follow on the screen.
And we need to go into System and Password Settings
container.
Now in here, we'll see that the screen is completely empty.
There's nothing defined.
This is the container which will contain
the fine-grained password policies.
So we can go forward, press New, and new Password Settings.
Now this is where we create the definition for our password
policy.
So we'll create, we'll set a name
and we'll set it as "Password Policy Admins".
We'll put a Precedence of 1.
We'll enforce a minimum length of 20,
as we discussed, password history of 24,
Password must meet complexity.
We do not store using reversible encryption, minimum password
age, 1, maximum password age 180.
And we actually want to lock the user accounts.
So if there's more than 3 consecutive failed login
attempts we want these accounts to actually
get locked out until someone unlocks the account itself.
And this is important, because this
might work in one environment but it might not
work in other environments.
And you should be careful with this setting.
If you want to go this way you might
want to adjust this value to maybe 5 or 10.
But in a small environment, such as the one
that I have currently in here, 3 it
would be more sufficient because the users or administrators
would have longer passwords that most likely they'll
just copy/paste from password managers.
So we don't even expect failed login attempts
to occur in this environment.
Now I'm also going to set the "Reset failed logon attempts
after", and in case someone mistypes their password,
I'll just set here the value of 3 hours.
So if someone tries to brute force the passwords
on the network.
It will make it impossible for them to actually
have a dictionary against our other accounts.
We can put a Description for our password policy if we desire
and the last part is to select who does it apply to.
And in this case, since it's a administrative password policy
I want this to apply to everyone who is in Domain Admins.
So I'll set the Domain Admins group
to be the one that is going to inherit this password policy.
But actually, this should be all your administrators
in the domain regardless of which tier they're located.
So this is a great thing here.
What we could do is, let's take an example where
I would just create one group.
And we can use it as an example, called Fine-Grained Password
Policy Admins.
It will be a Global group of type Security,
because this is the one that we can assign
fine-grained password policies.
We created it.
And now everyone who is a member of this group
will make it so they automatically inherit
the new password policy.
So I'll just add one member who is not a Domain Admin.
But this user is an admin on workstations.
To apply this password policy on this account,
I'll just have to add this group in here as well.
That was FGPP_Admins.
Now these two groups, Domain Admins and FGPP_Admins,
will automatically inherit this password policy
which we just created.
And now we can see it here as well.
So the process of creating this password policies it's
rather simple.
But they're really effective.
And we can go forward with more for service accounts,
one for 100 characters, one for 32 characters,
a VIP, regular user, and so on.
We can create a bunch of fine-grained password policies,
as many as we desire.
The next thing that we're going to discuss in this video lesson
is the tool Get-bADpassword.
Now, this image might look confusing and trust me it
really isn't.
There are three things that you need to look into.
So the tool itself is a simple PowerShell script.
What it does is it loads a list of predefined password hashes,
and those password hashes are of known weak and bad passwords.
They come from places such as Have I Been Pwned?
You can also add custom lists.
You can create something that is directly
associated with your company.
So you can have yourcompanyname123 or the year.
You can create all these custom passwords as well
and add them in the solution.
So this PowerShell script will get those known bad password
hashes.
At the same time, it will extract password hashes
from Active Directory and then just compare
known bad with the current passwords of users.
And it will just generate a report.
That is showcased in this diagram.
It might look complex but it really isn't.
The top part defines that the script
is looking into Active Directory to extract hashes.
The middle part is loading the list of bad passwords.
And the bottom part is showing that it's outputting the data
into different reports.
So one thing about the reports, which
I'm not going to showcase in the demonstration which
is coming up, is that the tool can send
an email with all the results.
So you can schedule this to run as a scheduled task.
And then once a week, or once a month, whatever you desire.
Once a day If you want.
It can run and generate this summary for you
and send you an email.
It's a really easy way for management,
or your CISO, or head of security
to track passwords over time and see how they progress.
But also it's really nice for us, as security professionals,
because we will know the strength of our users'
passwords without having to break them ourselves.
And if a password exists in a leaked database
then we know for sure that this is a bad password.
Now let's move into the environment
and see how this tool actually works.
I will be running this tool on the domain controller
simply because this tool requires
to extract Active Directory database so it
needs high privileges.
If it runs on a domain controller
it needs to run as the system user or domain admin account.
If it runs on a separate server, which
is what I would recommend to have
a separate dedicated server for this tool,
then the account which is running this tool
needs to have the directory replication
changes permissions.
Essentially, the account will be doing the DCSync attack.
I have downloaded the tool already
and installed the prerequisites that are required for it.
So we don't have to go through it together.
One of the things we had to do was to manually download
this BIN file, which contains the password hashes of all
the weak passwords.
I have also created the common bad password lists.
They can be created with this PowerShell scripts which
come as part of the tool.
I can just show you, as an example,
what is common bad passwords.
So this is the word "test" in different variations
with different endings.
We have "QWERT" words.
We have a lot of variations of different "password" spelling.
We have "welcome", "start".
Now these common things that people may end up using.
And they actually do use them quite often.
We also have weak passwords based
on English words which includes days, months,
and just common phrases.
Now to run the tool we need to start our shell
as administrators.
And we need to execute "powershell -exec bypass".
So we can bypass the current execution policy
to allow us to run unsigned PowerShell scripts.
So it's really as simple as just running the script itself.
Before running the script itself,
there are some prerequisites that
need to be configured inside.
I will just open it to show you what I had to configure.
And that was the information about the domain,
that my domain name is "prod".
And the naming context is prod.local.
And at the very bottom, you need to define
where should the email be sent.
I have simply commented out this part.
So I'm not going to receive an email.
I'll just get the summary on the screen.
And that's just good enough for me
to demonstrate some of the ability of this tool.
Because since it's a PowerShell script,
you can go forward yourself and modify it in any way
that you desire.
For example, you can configure that it will automatically
require users to change their passwords next time they login
if they have a weak password.
That could be one action.
But I can think of many reasons that your users might
be unsatisfied if this happens, and especially
if they're traveling.
So be careful with how you want to approach this.
The most common approach I've seen at companies
is they'll send an email to that user
with a short memo of how they should create
a new passphrase, a strong password, and asking them
to actually change it within a certain amount of time,
for example, within the next two days or so.
Now let's run the script itself.
It will take some time depending on how big your environment is.
Since I have very little, very small environment
with very few users it runs almost instantly.
It loads the lists and then it just compares the data back
to me.
Now while it's working it shows information
that it finds users who have weak passwords
and in here it says, I found the user
whose password is in the list weak-password-common.
Now it's not going to show me the password itself.
I don't really need it.
We should never really need it, even
though the tool has a switch where
it will save the passwords in plain text of the users whose
password was discovered to be part of these lists.
Now I get the list of all the users
that were detected to have bad passwords
and that's quite a bit.
You can see that we have users from normal tiers,
from different tiers, privileged users, service accounts.
And this is what you'd normally expect in a large organization.
You would see that many accounts would come back
with weak passwords.
And the next part that we'll look into
is an outline that shows which users shared the same password.
So the users on this line, all of them,
they have exactly the same password set.
So this gives me so much more insight
into the users who are saving this password.
And primarily because, if you look into my account
I have an account which is "t1_maro" and I have "t0_maro".
This is telling me that the maro user
has the same password across his different accounts
in different tiers.
And this is effectively bypassing our added security
by having multiple accounts in multiple tiers.
We shouldn't have users having the same passwords
across different tiers.
And this is what this tool is going to discover here.
It will showcase us this administrative account
who is actually bridging the gap for us.
We also have a list of two other users
who are sharing passwords.
But this password is different.
So the tool is going to output the users per line that
are sharing passwords.
And there was also a summary that there was only
two share passwords that the tool discovered.
Now, I really hope that this small demonstration gives you
a good overview.
And you can see the benefit of having something
like this constantly running.
You can identify users, and service accounts,
and everything that is having weak in your environment
and try to improve it before an attacker has
the opportunity to abuse
it.