If you use Kali Linux as your OS,
CME will come preinstalled and is accessible through the terminal.
However, before we dive into the program,
let's make sure there aren't any updates on the package
since it was included in the image.
Now that we have confirmed that there are no updates on the software package,
let's run it for the first time to allow it to create the working
directories it requires to operate correctly.
CrackMapExec will set up the working directories in a
hidden directory in your home folder.
Do note that some functionalities of CME require you
to run it with elevated privileges.
Therefore, I will be running the tool with sudo during this demonstration.
To make it a little easier or myself, I will create an alias.
In some cases,
I have noticed that certain functionality of CME is not working correctly.
This is why the maintainer nowadays recommends to use
the packaged version of the tool.
Let's do a quick check if everything is working as it should.
It seems that one module is not working correctly,
as it seems to be missing the pylnk3 package.
As a matter of fact,
I know that this package is installed on the system and
that it must be missing a link to it.
There are several ways to fix this issue.
However,
my preferred way is to reinstall the package through the Python Pip
manager so I know I'll have the latest version.
Pip for Python 3 does not come installed by default with Kali Linux,
so let's install it and upgrade the pylnk3 package.
Now that the package has been relinked and it seems to be at the latest version,
let's rerun the command to see if this has resolved the issue.
Luckily, this has resolved the issue.
Before I will show you the basic usage of the tool and explain what
the command did that I issued to find the error,
let's first have a look at files and directories it
created when it was run for the first time.
As I am running the tool with sudo,
the directory is created in the home folder of the root user.
In the hidden cme folder, we will find a few folders and a configuration file.
The configuration file lets you set the connection details to
your preferred post‑exploitation framework,
as well as configure some options of the basic behavior and look of the tool.
The subdirectories will be used to store data generated by the tool.
One directory in particular I would like to look at is the workspaces directory.
This folder holds all the data that is collected about the
target network during the use of this tool.
It is stored in SQL format and can easily be accessed with a tool called cmedb.
Currently there is only one workspace, default,
and it holds five SQLite databases.
Let's run cmedb and configure a new workspace for our demonstration.
Remember, if you are using CrackMapExec through sudo,
cmedb also needs to be run that way to be able to access the correct data.
All right, cmedb is rather poorly documented; however,
it is not hard to get around.
By typing help at any point,
you can obtain short bits of information of what commands
are available to you during that stage.
From the start, you will have the following three options,
exit, proto, and workspace.
As we are currently in the default workspace, let's create a new one.
According to the help function,
we should be able to get information about the workspace
command by typing help and the topic.
This, however, is not yet documented.
As the functionality for workspace only consists of two commands,
let's run it and create a new workspace.
As you can see, we have directly moved to the new workspace.
Let's switch back to the default.
Currently, there is no way to remove workspaces from within cmedb,
so after we have looked at the proto command,
we will remove the workspace the old fashioned way.
The proto command gives you access to where all the data is which
has been gathered during the use of this tool.
You can select the proto corresponding to what you
have been using in CrackMapExec.
Remember the five different SQL databases?
These are the protocols you can choose.
Let's take the SMB protocol, for example,
as this is the most extensive part of CME and the protocol which
we will be using during the demonstration.
Typing help,
you will find the commands available to you for this part of the database.
All gathered information of our demo will be stored here.
Currently, it is all empty,
but during the attack on the network we will get back to this
tool and see how it filled up with information.
All right, with basic navigation of the database done,
let's remove the workspace we just created and move on with CrackMapExec itself.
Let's leave the elevated status and issue our cme command.
This will print the general usage of CrackMapExec.
Running the program with ‑h also gives you the same help information.
You can see here the protocols available in the tool,
which also correspond to the SQLite databases we've seen just a moment ago.
By running cme with the protocol and ‑h,
you will find an extensive description of what can be
done with that specific protocol.
Let's start with the target.
This can be anything from an IP address to a range or even a subnet.
However, depending on what commands you want to use it with,
this becomes a lot more noisy, for example,
password spraying a whole subnet.
Even though it is the last option for the usage syntax,
I would recommend starting with it,
as it might conflict with arguments that have optional values.
Next, we have the optional arguments which allow you to specify a username,
password, additional connectivity information,
or modules to use, and also password attack settings.
Remember the command we used to check if all functionality was
working correctly during the installation?
This command lists the modules, in this case, for the SMB protocol.
By replacing SMB with any other of the available protocols,
MS SQL, WinRM, etc., you can get a list of what is available for those.
The next section contains the different options you have for credential
gathering through dumping of processes and files.
The mapping, enumeration,
and spidering sections are what we will use the most during this demonstration.
It allows you to tap many information sources within the AD.
The last few sections allow you to upload and download files,
execute commands, obfuscate PowerShell scripts and clear them,
and even allow you to bypass AMSI with your own custom bypass.
A subset of all these commands can also be found at the other protocols.
There might be some protocol‑specific options; however,
the majority is the same.
Now that we have seen the standard functionality of CME,
let's look at what external tools have been added as submodules.
As this tool is created for the use of SMB,
you will find that the list of submodules for the
other protocols is less extensive, if they are there at all.
You can bring them up by replacing the SMB protocol with
any of the other protocols as before.
As we will be focusing on the SMB protocol,
we'll leave the others for what they are.
The modules range from enumeration and gathering scripts to
connecting to external programs like BloodHound,
Empire, and Metasploit,
but also ways to inject executables into memory and keylogging,
to name a few.
So now that we have seen some of the features in this tool,
let me show you how it actually works.
Let's start off by looking for hosts that are available in our
network which don't require SMB signing,
and go from there.
The gen‑relay‑list switch requires an output file to write the
hosts to that don't require SMB signing.
All responding hosts it finds will be added to the CME database.
As for the IP section, you can input a single IP or range like I did,
a whole subnet by using the short notation,
or a combination of any of them.
Now that the command has completed,
we find that there are three hosts currently available in
our test lab which meet our conditions.
The output of this scan shows us the host IP,
what OS they are running, what the hostname is,
if they are joined to a domain, and, maybe the most important thing of all,
if SMB signing is enabled and the use of SMB version 1 is permitted.
Now that we know what hosts are available to us,
we can make the scan scope more narrow.
This will shorten the query time and, with that, make less noise on the network.
Let's see what information we can discover by using the
credentials we have from our compromised finance user.
First, we will gather some information to populate our CME database with domains,
users, and groups.
Enumerating the users, we see that besides Bob,
there are users called Alice and Frank in this domain.
With the groups command you can not only get all the available groups but
also specify a specific group to get users assigned to it.
For example, we just found out that Frank is part of the domain admins.
Let's continue and enumerate the shares on the network.
Let's also add back all the IPs we discovered and adjust the
switch once again to search for shares.
As a domain user,
we have access to the NETLOGON and SYSVOL folders on
the domain controller by default, so let's investigate those in a bit.
The IT machine seems to have an IT‑sensitive share we cannot access.
Might be something of interest there.
The Finance machine has a folder called yearly.
As we are not interested in financial records, we'll leave it for what it is.
Depending on your goals, you can investigate all these shares.
However, I will just be looking to further my access to the network.
Let's see if there are any passwords available in the files in
these shares by spidering the content of them.
It looks like we've got a hit.
There seems to be a password in the Groups.xml in the
SYSVOL share on the domain controller.
Let's extract those credentials with the module that has been created for it.
Look at that.
It seems the domain administrators have added a LocalAdmin
user to the workstations and forgot to remove the group
policy rule after adding it.
Now that we have these credentials,
let's quickly have a look at what has been added so far in the CME database.
Running cmedb, we end up where we left off, in the SMB protocol database.
Just as a reminder, the following commands are available to us.
Let's have a look what we discovered.
As you can see,
we have all the information regarding the hosts and also if there are any
credentials we have discovered that gave us admin access.
At the time, unfortunately, we have not.
The only things that are left out are if SMB signing is enabled
for a given host and if SMBv1 is permitted.
This, however,
is displayed on screen every time you connect to a particular host.
Let's see how the shares database has filled up.
Shares shows us all the shares in the domain with any comments,
how many credentials we possess that have read and write access.
Lastly,
let's see the credentials we have discovered by viewing the creds database.
You see here that it logs all the users it discovers,
as well as any passwords we found or used.
You might also have noticed that all entries have an ID.
Be it CredID or HostID,
the ID can also be used within CME instead of the
user password combo or host IP.
Okay, so in the last step,
we discovered that the administrators of the Contoso domain use a
local account for administration of workstations.
This might indicate, if the domain was set up by a really incompetent admin,
that the User Account Control restrictions for
remote use might have been adjusted.
Let's try it out and see if we can access the shares
with our LocalAdmin user remotely.
With the ‑‑local‑auth switch,
we can force CME to authenticate to the localhost instead of the domain.
It seems that we are in luck.
Not only did we find a LocalAdmin account, we can also use it remotely.
If the UAC was not adjusted, we can still use these credentials.
However,
we would have had to log into the workstation with known domain
credentials to be able to fill out the UAC pop‑up.
Anyway, now that we have full access to the IT‑sensitive share,
let's scan that one for potential confidential material like passwords.
We will rerun the command we previously ran and adjust it to function
locally on the IT host with our LocalAdmin account.
Ah, it seems there is another password in that share.
We could connect to the share directly and read the file,
download, or read the file through the command line.
To showcase that we can easily run commands from CME,
we will try and locate the file on disk.
To do so, let's run a search command to locate where it is.
Okay, so this gets blocked by the antivirus.
Let's try another way by running the command through the command
prompt instead of directly into PowerShell.
We can change the use from PowerShell to cmd by exchanging the capital X
to a lowercase x and adjusting the command a little.
There we have to path.
Let's cancel the search process and continue with
reading the file to get its content.
With this new credential in our possession,
let's query the AD to find out if there are any users with
Kerberos pre‑authentication disabled.
We can do so with the following command.
Again, we will use the SMB protocol, type in the IP of the domain controller,
and use our newly gained credentials to query the AD.
Our Frank user seems to have this specific option enabled.
How lucky for us.
Before we execute the attack through a module included in his tool,
let me explain a little about this attack to give it
a general idea of how it works.
The Kerberos protocol is very reliant on timestamps.
With pre‑authentication enabled, which it is by default,
the user initiates the AS REQ, or authentication server request,
by sending over a timestamp encrypted by the password.
This does two things.
First, verification by the Kerberos Key Distribution Center,
or KDC, that the user is who he says he is,
as he knows the password, and secondly,
verify that the request with the timestamp is within a
few minutes of its own server time.
This makes sure that the user is not just replaying a
recorded authentication request.
When everything is in order, the server will respond with the AS REP,
the authentication server reply.
This reply contains a Ticket Granting Ticket for the client and
some data encrypted with the client's password.
Now,
the configuration issue here is that the
pre‑authentication has been disabled, and due to that,
the client is not required to send an encrypted timestamp
to the Kerberos Key Distribution Center.
A plain authentication request is sufficient for the KDC to send us an AS REP,
which we can then use to brute force the section of data which is
encrypted to try and retrieve the client's password offline.
Now that we know a thing or two about the attack we are performing,
let's switch protocol to LDAP and use the built‑in
functionality to roast this Kerberos.
First,
we will bring up the help section to search for the command we are going to use.
In the Retrieve hash section, we find our reproast command,
which takes a username as parameter.
Let's build up the commands and try to retrieve our hash.
Once again,
we will build up our CME commands now using the LDAP
protocol and our ASREPROAST switch.
With the authentication server response successfully retrieved,
we can begin our cracking offline.
You can feed the hash directly into Hashcat with type 18200 or adjust
it a little bit to be able to crack it with John.
We will, however, feed it into John,
so we'll need to remove the $23 just before the
username to make it compatible with John.
I created a word list based on passwords that were in use in this domain,
so we might be able to crack it fast.
And there you have it, the password to the domain admin.
With it,
you now have the keys to the kingdom and a great feeling of owning
the network with the tool called CrackMapExec.