Hi, in this video lessonn we're going
to talk about plain text passwords, which
are stored in Active Directory.
And we're not referring about the passwords stored
in Active Directory NTDS, but simply
passwords that may be stored in scripts, or user attributes,
or anything else in Active Directory in plain text.
And that is something that usually
is left behind certain administrators,
in often cases due to lack of policies, in other cases
just negligence.
But it is something that happens in real life
and unfortunately happens too often.
It is probably the most common way for me
to escalate on penetration testing engagements,
by finding on a share exposed passwords.
And you would be surprised if I told you
how many times it is a password of highly
privileged account, most cases domain administrator.
So the first product we're going to talk about
is passwords that are stored in scripts
that are located in shares.
So what would normally do is I would recommend
using an offensive tool, part of power
exploit, called Invoke-Share Finder,
which is a partial script that you can
execute in your environment.
It will scan every single computer
and identify all the shares which
are exposed to that computer.
And what is really interesting about the specific tool
is that it will also list shares which tend to be hidden.
So it will also show hidden shares.
What I normally do is there are multiple approaches for this,
of course, some automated tools, some are more manual.
I would rather prefer taking the manual approach
because I want to also look into other data, not just the one
that the script identifies, while browsing through certain
shares, especially those shares that contain software
or installation scripts.
Common ones usually are [INAUDIBLE] and net logon
because administrators tend to put a lot of logging
scripts in there.
And then, they usually specify an account
that they want those scripts to execute with.
And then, the password on that account
is stored into the logon scripts.
My current approach is that to use the findstring command,
[INAUDIBLE] arguments to it.
Specify the word that I want the findstring command
to be looking for, and put it in the strings.
In this case, the word is pass, which stands for password.
Of course, this would be replaced
with PW and any other variations,
maybe something different in your language
if it's different than English.
And then specify the location of the share
that you want to scan.
So if you take [INAUDIBLE] for example,
on the second line of the command,
we'll see that the command to have specify is findstring,
I'm looking for the word pass, and I'm
looking at the share fileserver01,
into the folder Scripts.
And I'm specifying any name for the file that ends with
the extension .ine.
Sorry, ini.
While ini is not really the only extension
that we'll be interested into, here is at least
the very basic list of those that you
may consider quite interesting.
So that would be .conf, .config, .cmd, .bat, .vbs, .ps1.
Maybe .cs, .js, depending on what kind of [INAUDIBLE]
in the environment.
But these are really the core basic ones.
And I tend to find them to be most fruitful providing you
with some passwords.
What I see in many organizations is
that medium or large scale organizations
where they have multiple users being administrators
on many servers, there's usually a problem,
or one administrator who creates a few scripts,
puts them in a folder called the script programming [INAUDIBLE]
or something.
And then at a later stage, another administrator
might put software in that-- actual software
for installation, that folder.
Then create the folder as a share.
And that share will stay essentially
until someone turns it up, which in most cases really is never.
So that will not only expose the software, which is therefore
installation, but also the previous scripts that
may contain these credentials.
And here's an example of if we're
in the command and look for batch files,
it will identify that a batch file in the directory
called Scripts is identified.
And it contains slash password.
And in this case, what you're going to notice is that
the password for this service account is with [INAUDIBLE] is
rather--
to some extent lengthy and hard to guess as such,
that is service user for running web stuff--
Service user running web stuff.
It contains uppercase, lowercase, numbers,
and [INAUDIBLE].
But because exposing plain text an attacker
can essentially just go grab it out and use it as his.
So that is the following here.
The other problem that is often encountered
is credentials start in Active Directory object attributes.
For example, in this case on the picture,
you'll see that the password is stored in the description
of the account.
So in this case, I'm using a offensive tool
called Sharp View.
And I'm passing up a parameter or an argument, getdomainuser,
when specifying some account name to [INAUDIBLE]..
So it will extract information regarding the [INAUDIBLE]..
And for those of you who are more familiar with the Active
Directory command getaduser, this
is the equivalent in the hacking term, which is created
with LDAP in the back end.
It doesn't require the Active Directory module to be
installed to use this command.
You just need the executable or the partial version of it.
So in this case on the screen, we
can see the description contains pass,
and the password being welcome123.
Now, this is wrong in many ways.
The first one is that plain text password is exposed.
And of course it's indicated with the word pass.
Often discovered passwords also into the information attribute,
but also in some group descriptions.
So someone creates a group called ISS Users.
And then in the description of that ISS User group,
you'll put the names and plain text passwords of the ISS user
accounts.
And of course that is really about as well.
This information is available to every domain user,
and that is the main issue.
It's not only domain admins who can go and read it.
If you have a domain user, authenticated user in fact,
which will be a computer or a user,
you can go and extract all the information about all users
in Active Directory.
Which will contain these plain text passwords as well.
I have provided two links at the bottom, which might go to,
so to speak, which are normally used
to scan for this issue in User Attributes,
to scan both a description and the info
for containing pass, PW, and some different variations
of those.
You can add, of course, custom ones
if your language is not English, or if you
think that users might have different ones other than pass.
[INAUDIBLE] makes to you.
You can really customize it to your liking.
And at the end of this slide, I will
create a small demonstration.
We'll just show how we can execute the script
to identify these issues in the environment.
Now, it's really hard to prevent these passwords being
stored in scripts and Active Directory objects.
First, because maybe they exist there for so many years
that everyone has forgotten about them.
We need to go actively scan our environment,
and check whether we have any of these being exposed or not.
Then, it's very hard to change the mentality of someone who
has been a system administrator for 20 years
to not do something.
It's really built into a person.
We can give him many trainings and many sessions,
likelihood of a person being a person is still very high.
So really, what we should be doing
is scan your environment as often as you can.
I'll suggest maybe once a month would be a good interval
to look and try to identify any of these issues.
Because in reality you shouldn't have any of them,
and if any of them are detected, you
can create alerts, such as automated email
or messaging-- a lot of the messaging applications.
Anything that you might desire to indicate
that there is some issue that need to look into.
So of course, even though we might not succeed,
we should anyway go and try to teach our employees
to not store plain text passwords, because some of them
will actually listen to this.
And it would at least decrease the likelihood of this issue
existing in our Directory.
So let's move in the environment,
and we'll just execute one of the two scripts
which I showed earlier.
Just to show you how easy it is to execute it, and try
to identify these plain text passwords that
may be stored in the Directory.
I'm not going to the environment.
And I'll show you how we can execute the PowerShell script
from the slides really easy.
So first we'll perform invoke expression,
and just use any hacker threaded commands
that we can in our benefit as well.
This is a very common technique to get, for example, tools
such as [INAUDIBLE],, which you can run them directly
into the memory.
And the likelihood of them triggering [INAUDIBLE]
is very unlikely.
Of course EDR products and next generation anti
viruses are kind of different.
So they will probably detect that something's touching
[INAUDIBLE] at least.
But because this will run into memory,
if it's a traditional antivirus product you have,
it's most likely not going to detect anything happened.
Although in this case, the script
is not going to reflect this malicious.
So to execute the command, we'll do
New-Object net.webclient.downloadstring.
This is a command which will download whatever is located
into the URL that we provide.
I had already copied the URL of the searchuser.ps1 file.
And I'll just go forward and download it.
So it downloads and takes you [INAUDIBLE]
directly out of the blue, for us, which is ready.
And it actually comes back stating
that it found one user called Slavi,
that had description containing pass,
that it was set to welcome1.
It was really that easy to go and scan those user accounts.
It could be that some of your users,
you might have legitimate reasons to contain the word
pass, like in passthrough or some other wording.
Where you can actually whitelist those into the script,
and then just output the ones that you're really interested
in.
So if something new pops up that you're not aware of.
So one of the things we didn't discuss into the slides, which
I really wanted to outline is how bad it actually
is to use passwords such as welcome1.
Because I think with high confidence
I can predict what's going to be the next password the user is
going to set.
It's most likely going to be welcome2.
So having this pattern, and it might really
end up being quite a disadvantage
in defending our environment.
You shouldn't teach your users into using
weak passwords such as this one, which are not just guessable,
but they're increasing with the number.
We'll talk about passwords a lot at a later module.
So I'll leave everything for there.