In the previous video,
we ran through a couple of enumeration techniques by
making use of PowerShell scripts.
Those are great, however, you kind of need to know how to build those scripts.
PowerSploit, on the other hand,
is a tool that has been developed to enable you to make use
of PowerShell to perform various tasks.
These tasks range from reconnaissance,
persistence all the way up to exfiltration,
and the best part of all is that it makes use of PowerShell.
How awesome is that?
Well, with that being said,
remember that these tools might not be OPSEC‑safe due to the
possibility of them being detected by EDR components.
However, they are still pretty useful because you can,
of course, bypass EDR, but that is not the point of this set of videos.
So for now, we're going to assume that we have bypassed EDR,
and we're going to go ahead and make use of PowerSploit in
various components of it in the next set of videos.
I will show you how we can run this off a Windows system that we've
already compromised and we've got remote access to.
I'll also show you later that this can also be done
within a Meterpreter session.
So let's get started by making use of the local machine that we have access to.
This machine is the attacker machine,
and this is the one that's already part of the domain,
and we're going to make use of this to go ahead and
perform our various techniques.
So we're going to get started with reconnaissance,
and within the reconnaissance directory of PowerSploit,
we have access to PowerView.
To import PowerView into PowerShell,
all we need to do is make use of the Import‑Module command
followed by the location of PowerView.ps1.
Once this is imported,
we can now go ahead and make use of PowerView for reconnaissance.
Let's get started by first discovering the domain controller.
The command to do that is Get‑NetDomainController,
and as soon as I hit Enter, I get information about the domain controller.
Here I can see critical information such as the Forest,
the OSVersion of the domain controller, the domain,
the IP address, and the various roles that this domain controller is running.
The next phase would be to discover the current set of
users that exist within the domain.
I'm going to use the command Get‑NetUser,
which will now give me all of the users in the domain.
This demo environment does not have a lot of users,
but if you had to run this in a real production environment,
the output could be overwhelming.
So to make this a bit more easy on the eyes so that you
can read the output a lot better, we can make use of the Get‑NetUser,
which was the same command that we used before,
but this time we're going to pipe the output to a grid view.
Now,
I've got a grid that I can manipulate in order to view the
different attributes of these user accounts.
I can go one step further and limit the output based on certain
types of search criteria that I'm looking for.
For example, if I use the command like this,
looking for just the name,
I will get all of the names of the users that exist in the domain.
I can also achieve the same results by making use of a pipe,
followed by select, and then the criteria that I'm looking for.
For example, looking at the common name would give me the same results.
I can append this by adding additional fields into this command,
for example,
adding in the lastlogon timestamp will now give me both the common name
and the lastlogon timestamp of the users in the domain.
I'm going to start expanding a little bit further,
looking for when the password was last set for the users.
Now let's look at the groups that exist within the domain.
Using the command Get‑NetGroup,
I have a list of all of the groups that are
currently configured within this domain.
And as the results came in, there's a lot of data to go through.
So let's go ahead and filter this a little bit further.
I'll start with the common name,
which will allow me to see very quickly what groups are currently configured.
From the list of groups, there are a number of groups that are the defaults.
There are also two groups that look really interesting.
Those are the Sensitive Users and the Super Secret Users.
I want to do some additional filtering and I want to start looking
at who the members are of these various groups.
So I'm going to add in the member criteria,
and now I've got a list of the members in relation to
which domain groups they are part of.
So we now have identified who the domain admins are,
who is part of the Sensitive Users Group,
and that looks like it's a nested group because it's nesting the Super Secret
Users group of which the Domain Admin is part of that group.
We also have information about the Helpdesk group and who is a
member of that group; which in this case,
is a user by the name of RonHD.
So as we note on these various fields,
we can start to build our layout of Active Directory knowing
which accounts are key to be targeted and which accounts will
enable us to escalate our privileges.
Now if I wanted to view the members of a specific group,
apart from performing the filtering like what I've just done,
I could use the same command, but this time provide the group name.
For example, looking at the Helpdesk group,
I now have information about the group itself,
what type of group it is, and we can see that this is a security group,
and then I can see the members of the group.
The same would apply for the rest of the groups, for example, Sensitive Users.
Now let's look at discovering the active computers on this domain.
By making use of the Get‑NetComputer command,
followed by ping,
PowerView will go ahead and extract all of the computer
names within the domain and then perform a ping on those
names to see which ones are active.
From the results we have a list of the various machines
that are currently active in this domain.
You can perform further filtering,
like what we've done with the Get‑User command,
to filter out various criteria that you would like to look at.
So now that we've identified the computers that exist,
we've identified the users,
one thing that we did not check is which of those users are actually disabled.
PowerView can help you do that by using the command Get‑DomainUser,
but this time performing a filter looking for ACCOUNTDISABLE.
Filtering the results,
we now have a list of all of the accounts that are disabled.
Some of these are the default accounts, but we've got one that seems interesting,
which is called Globoticket‑Migration.
I'm going to note this down because there could be a possibility
that this domain has a trust with another domain.
So as I conclude this video,
by using PowerView I was able to enumerate quite a bit of information.
We started by looking at the domain controller,
identifying the domain controller's name and its operating system.
We then looked at the various user accounts that exist,
identifying which of those are part of privileged groups.
We were able to look at the different groups and the memberships,
including any sensitive groups that were created.
We've also looked at the computers that exist in the domain,
and we've also looked at any user accounts that are disabled.
In the next video,
we're going to take this enumeration phase a little bit further by starting
to discover various configurations of the domain itself.