[AUDIO LOGO]
Automating Linux local enumeration.
In this video, we will be exploring
the process of how to automate local enumeration on Linux
through a combination of both Metasploit framework,
post-exploitation modules for Linux,
as well as a Linux automated enumeration
script that will essentially automate
local enumeration for us.
The objective here is to essentially automate
all of the checks that we performed within this section,
and of course we also explored how to do this with Windows.
So, again, in this video, we're primarily
focused on how to automate Linux local enumeration,
and we're going to be doing that through a couple of Metasploit
framework exploit or post-exploitation modules
as well as a local enumeration script.
Right?
So, why do we need to do this, or why is automating
local enumeration so important?
Well, while local enumeration techniques or commands
are important to know as a penetration tester,
you will need to be time-efficient.
The reason I say that is when you're performing a pen
test, the primary variable that you're going to be looking
at as you perform your assessments
is the actual time frame that you have been allotted.
Right?
And you actually have to ensure that you are efficient when
it comes down to performing whatever stage of a penetration
test you are performing.
In the case of the post-exploitation phase
of a pen test, you actually need to be really efficient
as you're gathering a lot of information.
The great thing about this phase is primarily
because you're essentially focused
on gathering information.
You can utilize various automation
or automated enumeration scripts to do the work for you.
Now, this doesn't mean that you throw away
all the manual techniques that you've learned.
Those are still important.
However, when you want to be time-efficient or productive
for that matter, then you can utilize these Metasploit
framework post-exploitation modules in conjunction
with some automated enumeration scripts.
Right?
So the way the scripts work is that they're primarily
designed to identify privilege escalation vulnerabilities
because that's really why you're performing local enumeration.
Again, it's not really limited to privilege escalation,
but all of this information really
becomes important during the privilege escalation
phase of post-exploitation.
In addition to automating the process of enumerating
information like system information, users, and groups,
et cetera, these automated enumeration scripts
will provide you with additional information regarding
the target system, like privilege escalation
vulnerabilities and, in addition to that, locally stored
passwords, et cetera, et cetera.
Right?
In this case, we are going to be utilizing the following Linux
local enumeration script.
It is called LinEnum, which, again, is just an abbreviation
for "Linux enumeration."
This is a simple Bash script that automates common Linux
local enumeration checks in order to identifying
or in addition to identifying privilege escalation
vulnerabilities.
So what it does is it essentially
automates everything that we've done
so far within this section.
So it enumerates user information,
system information, group information,
network information.
It enumerates services and cron jobs, and so on and so forth.
The GitHub repository for this particular script
is linked to this slide, and I'll be showcasing or taking
you through the process of how to copy it over
or how to copy the script content over to the lab
environment, as the lab environment does not
have an internet connection.
In this video, we're going to be utilizing a different lab
environment to demonstrate the process of how to automate
Linux local enumeration.
So we're not using the same lab environment
that we've used in the previous videos within this section.
The lab environment is attached to this particular video,
so all you need to do is just start it up.
We're going to start off by gaining access
to the target system.
After we've gained access to it, we
can then walk through a few Metasploit framework
post-exploitation modules, and then
take a look at how to utilize the LinEnum script to automate
Linux local enumeration.
So I'll see you within the lab environment.
All right, so I'm back within the lab environment.
In this lab environment, you will
be provided with a graphical user
interface in terms of accessing your Kali Linux system.
You'll not be provided with the target IP address,
but that can easily be identified
by opening up a terminal, and let me just zoom in here.
And you can type in ifconfig and take a look
at the interface ethernet 1, and of course we are
looking at the inet value here.
In your case, this is going to be different
based on your region.
The only thing you need to know is that the Kali Linux IP
address is the second IP within this subnet
and the target IP address is the third IP within this subnet.
As I said, in your case, the subnet
is going to be different.
It really doesn't matter.
All you need to do is just copy this value,
change the 2 to a 3, and that's the target IP address.
All right.
The next step will of course involve
performing an Nmap scan on the target system
in order to identify a vulnerable service that
is running that we can then exploit to gain access
to the target system.
So I'll just type in Nmap, and we'll perform a quick service
version detection scan.
I'll paste in the IPI copy, then I'll change the 2 to 3,
and we can hit Enter.
We'll give this a couple of seconds to a couple of minutes
to complete, and that should tell us
what services are running on the target system.
As you can see, the Nmap scan is complete,
and it looks like we have a web server running on port 80,
and the web server is Apache HTTPD 2.4.6,
and of course we know that it's running on a Linux target
system.
So we can actually just copy the target IP there
that we specified during the Nmap scan,
and we can open this up in the browser.
And let's see what is being hosted on this specific web
server.
So we open up the target IP address.
You can see that we have an under construction landing
page, and it looks like the website is displaying a timer,
telling us that the website will be online in 0 days,
23 hours, et cetera, which is very interesting because this
doesn't look like it's being rendered
or it doesn't look like it's statically-generated text.
We can view the page source to get--
we can actually just highlight the page here
and view selection source and/or rather the page source.
And if we take a look at the content of the web page,
you can see that under the JavaScript section
it looks like it is essentially executing a particular CGI
script.
In this case, the target system or the instance of Apache
that's running on the target system
is vulnerable to the shellshock vulnerability.
Now, I've already covered the shellshock vulnerability
in depth in the system and host-based attacks course.
So if you want to learn more about it
and how it can be exploited both manually and automatically
with Metasploit, you can actually
take a look at that course.
For now, the way it works is really very simple.
We can see that we've identified the CGI script being executed,
and the shellshock vulnerability essentially
allows us to inject specific system commands
into the HTTP headers that will then essentially get executed.
Right?
So if we try and access the CGI script--
so I'll just go back here, and we can then
access the CGI script.
You can see that this particular CGI
script is called "gettime.cgi."
So it looks like it's essentially displaying a timer,
and the command specified within the CGI script
are being executed by the system.
Right?
Now, there is a Metasploit framework
exploit module that can be used to exploit this vulnerability,
so I'll just fire up msfconsole, and I'll just
copy the target IP there as we'll need it,
and I'll just hit Enter.
We'll give this a couple of seconds.
All right, there we go.
I'll just search for the actual shellshock vulnerability
or exploit.
So I'll say search shell shock, and we
are looking for the exploit module right over here.
So exploit multi HTTP Apache mod CGI bash environment exec
Again, we'll just copy this, or we can
specify the actual exploit ID.
So we can say use 5, and I'll hit Enter.
And if I show the options for this particular exploit module,
you can see that the options we need to specify firstly
is the target IP address, which I will actually set it.
So I'll say set RHOSTS and paste in the target IP address.
Make sure that you set the correct target IP address based
on your own lab environment.
We then need to set up the target URI.
So this is the path to the CGI script
that we will be targeting.
So we're going to set the target.
We're going to say set target URI to get time dot CGI.
Right?
Because that's the CGI script that we
are going to be utilizing.
We can hit Exploit, and this should provide us
with a Meterpreter session.
There we are.
After a couple of seconds, we obtain an Meterpreter session.
So I'll give this a couple of seconds to start up,
and there we go.
Again, I've already covered the individual Meterpreter commands
that you can perform when performing
local enumeration on Linux.
So let's start off by exploring a few post-exploitation modules
for Linux that can be used to automate
the enumeration of various types of information
from a Linux target system.
So I can put this in the background
by typing in "background," or I can use the keyboard
combination or key combination Control and Z. There we are,
and I'll just put this in the background.
If I type in "sessions," you can see that it's still
running in the background.
The first module is one called enum configs, so
search "enum configs."
I'll hit Enter, and you can see this will essentially
gather configurations or, for lack of a better description,
Linux gather configurations.
So we can say use 0, as that is the model ID.
And if we show the options, because this
is a post-exploitation module, we only
need to set our session.
In in this case, we have a Meterpreter session.
So I'll say set session, and I'll
set the ID of the Meterpreter session.
So I'll say set session 1, and I can hit Run,
and you'll see the information that this will enumerate.
This module enumerates all configuration files.
Now, you can see that in some cases it'll actually fail,
but the information that we're looking for specifically
here is going to be the host name, which in this case
is victim 1.
It looks like it's running Ubuntu 14.04.6 LTS,
and the Linux kernel is 5.4.094, and of course it
is a 64-bit kernel.
Right?
So it'll try and access some frequently
utilized configuration files for various packages
or pieces of software like Apache, Nginx,
so on and so forth.
It looks like it was able to enumerate
the list of shells installed on this Linux target system.
It also obtained the sepermit configuration file, the RPC
configuration file, LDAP system control configuration
file, et cetera.
It also provides you with a path to where this information can
be accessed locally.
For example, I can copy the path.
If I wanted to get an idea of what shells
are available on the Linux target system,
I can just copy the path where this particular information has
been stored locally, which is under the root user's home
directory under MS4 under loot, et cetera.
So I can then say cut and paste in that there.
I hit Enter, and you can see that the information that we're
looking for or that is pertinent to the shells that
are available on the target system are the following.
So the command that was executed was at etc Shells or the file
that was accessed was called shells,
and we can see that on the target
we have the Bourne shell We also have bash dash and rbash,
and you get the idea.
All right?
The next module that we're going to be exploring
is the enum network module, which, as the name suggests,
enumerates network information.
So I'll say search enum_network, and I'll say use 0.
And if we show the options, again, we
can set the session to session 1, and we can then type in run.
This is going to gather all network information, so, again,
it gives you your standard system information
here like the version of Ubuntu, the distribution name,
distribution release version, as well as the kernel version
and architecture.
You can see that the network configuration is stored here.
It also got the routing table, the DNS configuration,
the host file, as well as the listening ports and the if-up
and if-down commands, which are essentially used
to enumerate the interfaces.
Again, as I said, all of this information
can be accessed by again just cutting out
the content of the file where this information was saved.
So, again, I can just say cat, and in this case
we're essentially identifying the network configuration
that was identified.
In this case, it looks like it enumerated the interfaces, so
ethernet 0, IP VTI 0, and the loopback address
or the loopback interface.
Let's take a look at the listening ports.
If we wanted to identify that information,
we can do that as well.
So I'll say cut and paste in the path to the file there.
You can see that we only have a couple of services, or really
just one service that is running.
In this case, it is the web server running on port 80.
Again, the reason why these post-exploitation modules
are so useful is because it actually
stores all of this information for you
so that you can always go back to it
and get that information if you need it.
You can see that it was unable to get the firewall
configuration.
And let's take a look at just one more here.
Let's take a look at the routing information,
so let's see if I can find that there.
So the routing table that we all just copied the path
to that file, and then I can say cut and paste the other path
there, hit Enter, and that is the routing table.
So that gives you the default gateway, et cetera, et cetera.
All right, so we can also take a look at another module
called enum system.
So I'll just say search enum system,
and that will essentially gather the system and user
information.
So this is another very useful module.
So I'll say use 0 and set the session to 1,
and I'll just type in run.
It'll essentially start gathering all that information.
As you can see, it's got quite a lot of information.
Firstly, it'll give you your system information,
and then the Linux version is stored under the following file
or under the following path.
User accounts, installed packages, running services,
cron jobs, disk information, log files, set user ID,
and set GID binaries, so on and so forth.
For example, if I wanted to know what installed packages are
on the target system, I can just copy the path to the output
file, then cut the content of that file, hit Enter,
and these are all the packages that are
installed on the target system.
So these post-exploitation modules
are very, very helpful in essentially automating
the process of enumerating the information that we've
been able to enumerate manually throughout this section.
We can also utilize another module--
and I'll just search for it here-- called a check VM.
And we also checked the Windows equivalent
of this particular module and essentially tells you
whether the target system is a virtual machine.
So we're looking for this module here.
Because the target system is running Linux,
we need to use the other platform-specific module
because there's one for Solaris and one for Windows as well.
As you can see, this will essentially
gather the virtual environment, or it'll essentially
tell you whether the target system is indeed
a virtual machine.
So I'll say use 0, set the session to 1,
and I'll type in run.
You can see that the target system appears to be a QEMU KVM
virtual machine.
There's a few other post-exploitation modules
that you can utilize to gather information,
but these are more specific to identifying privilege
escalation vulnerabilities.
And that's something that we will
be exploring when we get to the privilege escalation
section of this course.
With that being said, we can now take a look
at the LinEnum script.
So if I just list out my sessions here,
I'll just interact with session 1 here,
and my current working directory is under opt/apache/htdocs.
So I'll navigate to the temp directory.
Just like Windows, whenever you're transferring scripts,
exploit files, binaries, always make sure
that you transfer them to the temp directory.
The reason we're doing this is primarily
because you never want to upload or transfer your exploit files
or scripts to directories or folders that are frequently
accessed by users on the system, because if they
discover a file, then that is an indicator of compromise.
So always make sure to store your files and scripts
in a location that is not frequently accessed by end
users on the target system.
So I'll navigate to the temp directory,
and you can see it already has a few files within it,
but these are not really pertinent to what we're doing.
What we now need to do is head over to the LinEnum GitHub
repository.
This lab environment doesn't have access to the internet,
so I'll just switch over to my main system in my browser,
and I'll show you how to copy over the script
and how you can transfer it over to your lab environment.
All right.
So I'm currently within my browser here,
and I'm on the LinEnum GitHub repository,
which I linked on the slides.
You can easily access it by just searching for LinEnum.
Again, this GitHub repository essentially just
contains the Bash script here, and the script
is called LinEnum.sh.
So the actual readme file on the GitHub repository
provides you with documentation regarding how to utilize it.
Now, as I said, in addition to automating local enumeration
on Linux, it also can be used to check for specific privilege
escalation vulnerabilities.
But as I said, that's something that we'll be exploring
when we get to that section.
In terms of the actual usage of the tool,
it really is very simple.
For now, we can disregard the additional options that
are specified here, and we can just
run the LinEnum script now.
So, how do we transfer this Bash script to the lab environment?
Well, we just click on the LinEnum script there,
and you just want to click on Raw,
and you then want to highlight essentially all the content
here of the Bash script.
So I'll just highlight it all and copy it,
and now we can switch back over to the lab environment,
and I'll show you how to paste it in.
All right, so I'm back within the lab environment.
To paste in the content of your clipboard, what
you want to do on your keyboard is press
the following keys in order.
So Control, Shift, and Alt, and that'll
bring up the actual clipboard option for you
for the lab environment.
Within the clipboard, just paste in the actual script content
that you copied just like so.
Once that is copied, you can then exit from this
by again utilizing the Control, Shift, and Alt keyboard
combination.
So it's now within the lab environment clipboard.
We're going to create the LinEnum script,
so I'll just open up the text editor here,
and we can then paste in.
Just right click and say paste or Control and V,
and the actual content that you copied from your browser
will be pasted here.
This is a Bash script, so we will save it,
and I'll save it within the desktop folder here of the root
user.
And we will just call it LinEnum, so LinEnum.sh,
and it's saved.
All Right.
So now that is done, we can actually close that up,
and we can utilize the inbuilt Meterpreter
command to upload that script into the temp directory.
So I'll say upload, and I'll specify the actual path where
I saved the LinEnum script.
In this case, it was on the root desktop and LinEnu.sh.
That'll upload it, so I can now open up a shell session
or a command shell session.
So I'll just type in shell, and it's now
going to provide us with a Bash session right out of the box.
So we can say bin/bash i, and then we are.
So we can see that right out of the box this user is not
a privileged user because we have gained access
to the target system as the daemon service account.
And the hostname of the system is victim 1.
So if I say ID--
let me just type that in correctly-- you can
see that is displayed there.
I can also say who am I. I'm only the daemon user,
and if I say cat etc password, that'll show you all the user
counts on the system.
The reason I said we currently have access
to the target system via a service account
is right over here.
You can see that no default shell is specified
for legitimate authentication.
In the case of this system, we would
need to elevate our privileges, but, as I said,
that's not what we're interested in right now.
So if I list out the contents of the temp directory,
you can see we have the LinEnum script here.
Before we execute it, we need to provide it
with executable permissions, so I'll say chmod plus x
and then specify the name of the script.
So LinEnum.sh.
I can then execute it as follows.
So LinEnum.sh, and I'll hit Enter.
So this is going to begin the actual enumeration process.
So give it a couple of seconds to a couple of minutes.
All right.
So once it's done, it should just take a couple of seconds.
At the bottom, it should say "scan complete,"
and it's obtained quite a lot of information that
is very useful to us or for us.
So let's scroll to the top of the output here,
and you'll actually see the breadth of information
that this tool will enumerate for you.
So there we are.
So it starts off.
I'll give you a description as to what this tool is.
So it's the local Linux enumeration and privilege
escalation script.
It will then, of course, show you
whether you've enabled thorough tests, which
I said we will be exploring during the privilege escalation
section.
It'll then tell you when the actual scan was started.
It'll then start displaying the actual system information,
starting off with the kernel information,
then the actual additional information regarding
the kernel, and then the specific release information.
This will contain the actual distribution and name as well
as the release version and additional information
regarding the Linux distribution that is
running on the target system.
It also enumerates the host name.
It then enumerates the current user and group.
Again, as we were able to find, we
are currently the service account daemon, and then users
that have previously logged on to the system.
You can see that there are none, and of course this
is pertinent to legitimate authentication,
not through an exploit.
Who else is logged on?
No information is displayed there.
It'll then display the group memberships,
as you can see here, and you can now
start to understand how powerful these scripts are because it
is essentially automated everything
that we have done manually throughout the entirety
of this section.
Right?
So it's enumerated system information, the users,
and groups.
It's also identified users that are currently logged on,
users that have previously logged on,
et cetera, and then of course it'll also
display the contents of the etc/passwd file.
Then it'll tell you your superuser account,
so that's obviously going to be the root user.
It can also display other user accounts that
are part of the root or pseudo group,
and then of course it'll display permissions
on home directories that are lax.
This is primarily a privilege escalation vulnerability
or check.
It'll then enumerate or display the environment variables,
so you can see this is for the daemon user.
It'll then essentially display the environment variables
for the daemon user.
Then, of course, you have the path information here
to display all of these paths here.
Available shells, we were able to get
that information, and then of course
the password and storage information.
So the maximum days, so this is essentially
this will tie into the password policy of the company that
owns this particular target system and the actual duration
they want to specify based on when users should change
their passwords, et cetera.
Then under jobs and tasks, you can
see that it will enumerate a list of cron jobs
that are currently running.
Right at the bottom, you can see the crontab contents,
and in this case you can see that we don't
have any cron jobs running.
It then enumerates the networking information, which
we already know how to perform, the ARP history, name servers,
the default route, the actual TCP connections,
UDP connections or services, and then it'll
also display the list of running services.
And this is sorted based on the user,
process ID, CPU and memory consumption, and then of course
the command that is being executed.
It'll then essentially display the process binaries
and associated permissions.
So all of the binaries that are currently being executed
will essentially display the path
to these binaries or scripts and their permissions in regards
to who can modify them.
And then, of course, this is where
it starts displaying the init system binary permissions.
That's not really important at this stage
in terms of understanding what that is checking.
It'll also check for based on the init system that is
installed on the Linux target.
It'll then check for the configuration file permissions
of that init system.
In this case, the init system is systemd, and then at the bottom
it'll display the version of sudo
that is installed on the target, a few interesting files
like netcat and the GNU C compiler That will also
be displayed here.
The list of installed compilers-- this
is very important when you want to compile C code on the target
system.
Files that you can read, write, or make changes to-- that's
also displayed here.
SUID binaries-- that's something that's
very important during privilege escalation,
as well as set group ID binaries as well.
Then it's going to search for all configuration files which
we were able to enumerate with the Metasploit
post-exploitation module.
It'll also check for any interesting mail
that's stored under var/mail.
And then of course the final check which is very important
is that it tells us that we're running inside a Docker
container.
So this will actually give you a good idea of what
you've just compromised.
So when we ran the check VM post-exploitation module,
this is the Metasploit post-exploitation module.
It told us that we are indeed a virtual machine,
but it really didn't specify what type of virtualization
is actually set up and is essentially
handling this virtual machine.
In this case, it's able to confirm that we are indeed
a Docker container or the target system
is indeed a Docker container.
So the LinEnum script is extremely useful,
and the output is very succinct, and it
keeps everything nicely sorted.
So, again, you can copy all of this information
based on the information that interests you.
Again, it's sorted out really, really well
in a very human-readable format, which
is why I personally prefer utilizing this script
to perform local enumeration.
When it comes down to identifying privilege
escalation vulnerabilities, there
are a few other scripts that are extremely important as well.
So that is going to conclude the practical demonstration
side of this video.
All right, so that concludes the Linux local enumeration section
of this course.
By the end of this section, you should have the ability
to perform local enumeration on a Linux target system
both manually and automatically through the use
of various automation scripts, as we just
explored in this video.
In the next video, we're going to be
moving on to the next section, which will essentially
cover the process of how to transfer files
onto target systems that you have compromised.
In the event you have compromised the system
and you have not obtained a Meterpreter session,
you have just obtained a standard conventional session.
How do you upload a file to a target system,
so on and so forth.
So that's what we are going to be focusing on
in the next section.
So I'll see you there.