Clearing your tracks on Linux.
In this video, we will be exploring the process of how
to clear your tracks on Linux.
So again, we're going to be following the same methodology
that we used during the clearing your tracks on Windows video.
The main objective here is to, again, follow the best
practices that I outlined in that video
whereby if you are transferring files onto a Linux target
system, transfer them into the temp directory.
Furthermore, if you are utilizing the Metasploit
framework for exploitation and post-exploitation,
do actually keep your eye on the actual artifacts that
are generated by those modules and identify where
those artifacts are stored.
In the event that a Metasploit exploitation
module or post-exploitation module
provides you with a clean-up resource script,
do keep or essentially note down where that resource script is
stored so that when you approach the final phase
of post-exploitation, you know where it's located.
And you can use it and run it on the target system
in order to undo what you did or to undo
what that particular post-exploitation
or exploitation module did.
So again, we're just going to be following the same methodology.
And I'll be highlighting a few important techniques
that you can run or that you should be performing on a Linux
system.
But as I said, do keep in mind or do consider the rules
of engagement and the actual stipulations that are
highlighted within it in regards to what you can and cannot do
on a target system irregardless of the operating system.
So this video has a lab environment attached to it.
We're going to be exploiting the target system.
And then we can explore a few techniques
pertinent to Linux that are very useful in clearing your tracks.
With that being said, I'll see you in the lab environment.
All right, so I'm back within the lab environment.
And the first step is to gain access to the target system.
We can identify the target's IP address
by typing in ifconfig and taking a look
at the interface ethernet 1.
So this is the Kali Linux IP.
The Kali Linux system is always going
to be on the second IP within the subnet.
So all you need to do is just copy this value here.
In your case, it's going to be different.
But just copy the value and change the 2 to a 3.
And that's the target IP address.
All right?
So let me just copy that there.
And in this case, the target system
is running a vulnerable version of samba.
So we can actually confirm that by running an Nmap scan on 445.
And I'll paste in the target IP.
I'll change the 2 to 3 and hit Enter.
And you should see that it's running samba version 3.
So we'll give this a couple of seconds.
There we are.
You can see that samba is indeed running.
So we can fire up the Metasploit framework console
and load the appropriate exploit module that
will provide us with a command shell session on the target
system.
So I'll give this a couple of seconds.
I'll firstly set the global variable for the RHOSTS option
to the target IP address so that whenever we load a module,
the RHOSTS option or value is specified for us so that we
don't have to specify the target IP whenever we load a module.
So I'll just launch a search for all samba-related modules.
And the exploit module that we are going to be using
is this one right over here.
So that's the is_known_pipename exploit module.
So I'll say use.
Paste that in there.
And if I show the options, you can
see that the target IP is already specified for us.
The target port or RPORT is specified correctly
as port 445.
We don't need to specify the SMB_FOLDER
or the SMB_SHARE_NAME.
We can type in exploit, and this should provide us
with a non-interactive command shell
session, which we can then upgrade
to a semi-interactive bash session.
As you can see, that is the case.
So I'll say bin bash -i.
And in this case, we gain access to the target system
with root privileges, which means we do not
need to elevate our privileges.
All right?
So now that that is done, we can actually
explore the first guideline or best practice.
And that is whenever you are transferring files
onto a Linux system, always store them
within a centralized directory.
And as I mentioned in the previous video,
the best directory is always the temp directory.
In the case of Linux, the temp directory is called temp.
In the case of Linux, if I navigate
to the root of the file system, the name of the temp directory
is called tmp.
And in most cases, a Linux system
will always have the tmp directory available.
So I'll navigate to the tmp directory, and there you are.
And you can see, it doesn't have any files in it.
Now, do keep in mind that the tmp directory is exactly
that on both Windows and Linux.
And that once the system is restarted,
all files within the temp directory will be deleted.
So while I do encourage you to transfer files
to the tmp directory, be aware of the fact
that if you are performing a penetration test over a couple
of days to a couple of weeks.
Then whatever files you have transferred
into the temp directory will be deleted
once the system is rebooted.
So do keep that in mind.
And that's also another good thing
because no traces or artifacts that you have utilized
or you have transferred over to the target system can be found.
So again, as I said, if we wanted
to upload a file to this directory,
we could either through the manual technique of setting up
a web server and utilizing the wget utility,
or we can utilize or upgrade this command shell session
into a Meterpreter session and upload files
directly using the upload command that Meterpreter
provides to us.
The next-- and this is a very important,
which I will not be showcasing because it's not really
relevant now--
is going to be the Metasploit framework
exploit in post-exploitation modules and the artifacts
that they generate.
Given the fact that I've already explored
how to utilize the clean-up resource scripts,
I'll not go through that.
But again, what I wanted to point out
is that most of these modules will
generate quite a few artifacts.
And in the case of Linux, there may
be an issue with cleaning them up,
so you may need to clean them up manually
instead of relying on the resource scripts.
Now, let's talk about Linux-specific techniques,
right?
So one of the cool things with Linux--
and let me just navigate to the home directory of the root
user.
If I list all the contents of the root user's home directory,
you will see that in this case, we
have the bashrc, which is the bashrc file, which is
a configuration file for bash.
It essentially stipulates how bash should work.
And then of course, you have a few other dot files and folders
for the configuration of services,
like the ssh directory, which we already explored.
Now, in this particular system that we have just exploited,
the bash history file is not configured, right?
This particular version of bash on this target system
has been configured to not store a history of commands
in the bash history file.
Now, on most Linux systems, you will typically
find a bash history file.
So the file will be dot bash underscore history.
And that file stores a history of all commands
that you have typed into bash from whenever the system was
installed, right?
And again, this can be limited or customized
to only display the commands that were written or typed
in over the last one week or one month, et cetera.
And this is typically used by system administrators
as a security mechanism to see what users have been doing.
So every user account within the home directory
has a bash history file.
Now, as I said, in this particular case,
the way bash has been configured on this system
is that whenever a user logs in and logs out,
the bash history file or the history for that session
is deleted.
So I'll give you an example here.
Let me type in a few commands, right?
We can say cat /etc/passwd.
And I can type in uname -r, for example.
There we are.
So we have typed in a series of commands.
Now, from an attacker's perspective,
you might be thinking to yourself,
does anyone know what I'm typing in?
Can this information be identified at any time?
After we've compromised the system, or when
an administrator is or an incident responder is trying
to identify what was done on the system, the answer to that
is yes, they can.
They can easily identify the commands
that have been inputted or essentially keyed
into the system via bash by taking a look at the bash
history file.
Now, as I said in this case, we do not
have a bash history file, which works to our advantage.
However, on most Linux systems that you compromise,
you will find a bash history file.
All right?
Now, you can access or essentially
view the history of commands that you
have typed in for the root user within your current session
by typing in history--
the root history.
You can see that it displays a list of commands
that I've entered chronologically
from the time I logged in.
You can see I navigated to the home directory of the root
user.
I run the /etc/passwd command.
I listed out the contents of a few directories here and there,
et cetera, et cetera.
And if I ever exit or log out from this session,
in this particular case, this history will be deleted.
Now, on most Linux systems, this will not be deleted.
This information will be stored as is in the bash history file.
All right?
So what you typically find is within the user's home
directory, there will be a file called bash history.
And a good measure or rather technique to use--
and this is not really important in the context of a pen test--
is to delete the specific commands from the bash history
file that you typed in or that may
indicate to an administrator that the system has
been compromised.
For example, if they see a command whereby
we are utilizing wget to download
an exploit from a server, then that's something that could
essentially set the alarm bells, essentially
light them up on fire.
And that is an indicator of compromise.
So instead of deleting the contents of the bash history
file, I would always recommend that you
delete the specific commands you know that you typed in.
That way, it looks or actually, it
doesn't look like someone is actually cleared it up.
So an example of this would be-- and I
don't think that we have a text editor on the target system.
So if I type in nano and vim, for example,
you can see that it's not installed.
But what I could do is I can just create the file.
So I'll say touch.
And this is how the file would look.
So bash history.
And as I said, if I list all the contents of the home directory,
this is how the file would look.
You can see, it doesn't have any data within it.
And if I echo, for example, I can just
specify a test command here.
So let me just type in history.
And I can say echo.
Let me just try and show you what this would look like.
I can say 1 and cd, for example.
Let's say someone navigated to the tmp directory.
And I'll say I want to output that into the bash history
file.
So what an administrator will typically
do is if they kept the contents of the bash history file,
they'll be able to see a series of all commands,
a list of all commands that have been typed in.
And in this case, they'll be able to see the commands
that you have typed in.
So there's two ways of clearing the bash history.
As I said, you can go in and delete individual lines
or commands that you typed in, or you
can type in the history hyphen C command to clear the history.
So when I type in history now, you
can see that it's only displaying the history command.
So this is something that I recommend
that you do after you're essentially done on the Linux
target system.
It's just a good security measure to perform.
Now, as I said, in the case of Linux,
the process essentially mirrors the process on Windows.
The most important thing to note or to keep in mind
is whether or not you're using the Metasploit framework
for exploitation and post exploitation.
Secondly, if you're transferring files,
have a centralized location for them, that in a directory
that is not frequently accessed.
And a good example of that is the tmp directory.
And of course, when you're done with the system,
make sure to essentially get rid of any traces
that you were on the system.
So that involves modifying or deleting the bash history file
or just clearing the bash history itself.
As I said, in this case--
let me type in a few commands here.
I'll just try, and I'll just type in a few test commands.
And if I type in history, you can see
that those commands are logged.
However, if I exit--
and let me just terminate this session.
And let me try and gain another command shell
session once again.
Let's see if it provides us with the command shell session.
There we are.
So I'll say /bin/bash -i.
And if I type in history, you can see
that data is still persisted.
And this is something that can be very dangerous or very
detrimental during a pen test, especially if there's
an active blue team on the other side that
are trying to identify any indicators of compromise.
So whenever you're done, just clear out your history.
And if I now exit once again--
let me just exit.
I'm just going to run the module once again.
I'll just say exploit.
And I'll just open up a bash session once again--
/bin/bash -i.
If I type in history, you can see that in this case,
for some reason, the actual history file is not
being cleared.
But that is primarily because--
let me navigate to the root of the C drive here.
If I take a look at the bash history file now--
and this is something that I didn't think
would work primarily because it was disabled.
But you can see that once I created the bash history file,
it's now storing all of the commands
within the bash history file.
So as I said, if you want to get rid of the history now,
what you can do is you can say cat /dev/null.
And you can then clear it out and specify
that you want to redirect that to history or to the bash
history file.
So if I now say history, it's still displaying that.
And if I say history clear--
let's see.
History once again.
Yeah, there we are.
So that's cleared now.
And cat bash history.
It should only be showing the commands that I typed in.
So there we are.
So that is how to clear the bash history.
As I said, in this case, there was a bit of an issue
because I created the bash history file.
And that consequently made bash essentially use that file
for storing the history.
And once we cleared the history then
and got rid of the content within the bash history file,
the history was essentially cleared.
So as I said, this was an unorthodox example.
In most cases, the bash history file will already exist.
In that case, you can run the following command
to essentially clear it.
And you can then run the history clear command as well.
So that is going to conclude the practical demonstration
site of this video.
All right, so that concludes the clearing your track section
of this course.
And that is the final section that we
are going to be covering within this course.
So now that we've essentially gone through all the course
material and the labs, we can move on
to the final video within this course, which
is going to be the course conclusion, where we'll
essentially be taking a look at what we've learned so far
and essentially comparing our learning objectives that we
highlighted in the introduction to the course
and seeing whether we have essentially
hit all of those marks.
With that being said, I'll be seeing you in the final video.