It's at this point, I kind of want to ask you, who are you?
Do we really know ourself?
Which is a great question whenever we gain access to a system because we're
not logged in with our account that we use to get into our Cali box.
See, in our labs, we've been logging into Cali with Cali in a password of Cali.
But whenever we make a connection to another system that's our target, we're
actually on that system, whoever is logged into that system at the time.
So let's say a regular user opens up our dummy.exe and does that reverse
shell for us to be able to create a session inside of MSF console.
Basically, we have the same permissions as that user.
Now, this allows us certain pieces of information and the ability to kind of
browse around as that user and maybe even start doing some
enumeration based on those permissions.
But it's important to know that whenever you do gain access to a remote system,
one
of the first things that we need to do is understand who we are and how that
actually affects the permissions of that system.
So let's take a look at what we're talking about here.
Now, inside of our lab, we already have the remote session open to our actual
post hyper V lab environment, the share folder, if you will.
So we have the session, a session connected and set up already.
And as you can see, I've already staged me looking at the sessions that we have
and we're going to take a look at who we are.
Now, there's a couple of different ways you can do this.
Understand that whenever you send a dash C for command, it's going to try to
run it
in command prompt.
Now, yes, Windows does a lot of stuff in PowerShell and we will be doing that
because we can pipe commands to PowerShell from here.
But let first, let's see if we can do a who am I?
If I can start typing inside of their force real quick and we need to identify
the session that we're on dash I with a one.
Now, this is a very simple command and allows us to be able to go through and
see
that, yes, when we run this session dash C, who am I for our first session that
we
have connected, host dash VM learner.
So we're logged on as the actual learner themselves.
So now let's take it a little bit further and see if we can identify
what are the learner since we're posing as them on that system.
What permissions do they have?
Now, as you can see here, I've run the command again for sessions and we did a
dash
C with quotation marks and this is because I'm using commands that have spaces
in them.
And in the command prompt, if you don't include this in sessions, sometimes it
thinks that it's trying to do multiple commands that aren't syntax correct for
MSF console. So sessions that see net local group administrators and it returns
back with who we have as administrators, alias, they have administrators.
And then right below it, you can see that we have members learner.
So at this point, we are a local admin on this particular system based on the
fact
that we know that the windows, which is our target, is responding back with who
's
all in the actual administrators group.
Now it's good to point out here that even if you're not an administrator, let's
say
learner is just a regular user, you can still run this command and get a return
back on who the actual administrators are and find out what other groups there
are.
Now we ran this with net local group.
Now understand that there are commands in the net command that allow us to be
able
to do this for actual domains as well.
But we're going to be getting into domain enumeration in a different skill.
Where we actually go through and do queries against the LDAP and active
directory itself.
So really, we're just taking a look at a local system for a second.
And there's a couple of points I want to make here.
This allows us to be able to see all the different groups that are in the
actual
windows system itself. In fact, some of these may not be listed because they're
like service groups or things like that.
For whatever reason, they're all displayed.
You can actually go through here and see that there are many different groups
on this
particular VM and based on the net commands, we can identify who it is.
We are what other users are on the actual system themselves and digging a
little
bit deeper into net commands for windows forces here on CBT nuggets.
You'll be able to go through and identify those different users.
Now, this brings in a question of lazy administrators and I'm guilty of it
myself
because whenever I was in charge of an environment that required multiple
systems and we use like the windows deployment WDS, we always had a
standardized
user name and password for the actual administrator accounts.
So being able to take a look at those administrator accounts and figure out who
are allows us to be able to have access to potentially break that user
and password on one of those systems.
And if we can do that, we can potentially go to those different systems as that
administrator. So like follow me here, windows is very faulty about this
because
if you are logged in as an administrator with the same user name and password
that
another system has as a user name and password for that admin account, you just
addendum the actual computer name that you're doing the remote session from.
So the standardized configuration that a lot of organizations use, even DoD,
allow pen testers like us to be able to go in and manipulate the fact that we
are
in that user and it may be the same across the board if it's a local user
account.
Even if those systems are on the domain and you just happen to pop one that is
in the local administrator for whatever reason,
this is an opportunity for us to be able to expand and say, now we have at
least
local administrator rights on some of those systems.
Now, keep in mind that most times we're just going to have a user inside of
that
particular system, whether it be a local user or domain user with just regular
user
permissions logged into that system anytime that we're able to do a session
like we
just did. But this goes into being able to elevate rights and mess around with
Windows and that's something we're definitely going to get into when we get to
that Windows Active Directory skill, which is coming.
But I just wanted to point this out first as an introduction to our skill
overall
to make sure that we understand that whenever we do break into a system,
it's imperative that we identify who it is that we're actually logged in under,
because those permissions vary based on who is the actual person that we're
piggybacking off of for that session.