[MUSIC PLAYING]
Welcome to the clearing your tracks section of this course.
This is going to be the final section of this course.
And within this section, we're going
to be covering the process of how
to clear your tracks on both Windows and Linux.
And this is a very, very important section,
and it's coming at the end of this course
primarily because this is where it belongs.
And I'm going to be explaining a few important things
to actually keep in mind as you actually go about clearing
your tracks, right?
So let's get started with how to clear your tracks on Windows.
Now, before we explore a practical demonstration,
I need to explain a few things.
So the exploitation and postexploitation phases
of a penetration test will typically involve actively
engaging with target systems and the data that
is stored on these systems.
Now, this is very important because if we
use an example or an analogy and the example,
I'm going to be using is let's say you have been contracted
to perform a penetration test on a small to medium-sized
business or company that has maybe about 20 systems, right?
And within the rules of engagement, the client
and yourself or your company that you represent agree
upon specific guidelines regarding
the interaction of you, the penetration
tester, with the client's systems
during and after exploitation-- so
during the exploitation phase and post exploitation phase.
And what the client will essentially stipulate is that
there are certain things that you can and cannot do.
And of course, you might have a good idea as to what this is.
This is all pertinent to the operation of these target
systems and the data that is stored on these target systems.
So if you're performing a pen test on 10 or 15 systems
and these are systems that are used by employees--
they could be servers that are hosting web applications
and business-critical applications-- then the client
will essentially tell you, hey, once you gain access
to the target system, I don't want
you to manipulate anything.
I don't want you to create any user accounts.
I don't want you to modify anything
pertinent to the operating system,
so I don't want you to delete or modify the Windows Registry.
And essentially, I don't want you
to do anything that could jeopardize
the integrity of the operating system
and consequently lead to that operating system failing,
which would consequently lead to data loss.
And this also applies to the web applications or applications
that are running on that operating system.
And so this the process of clearing your tracks
and the postexploitation phase of a penetration test
really needs to be in alignment with the rules of engagement
that you have agreed upon with the client, right?
And this is something that you will
get an understanding of before you begin the penetration test.
So as a result, you may be required to clear or undo
any changes you have made to the target systems you have
compromised based on the guidelines specified
in the rules of engagement.
So in certain cases, a client could tell you, OK,
once you gain access to a target system,
you could create another user account just
to showcase what a real attacker would do
or an adversary would do.
However, when you're done with your penetration test,
you need to go back to all of these systems
and you need to delete those user accounts.
That's just an example.
So again, keep the rules of engagement
in mind before you begin the penetration test,
and make sure that you refer to them
at every step or every phase of the penetration test.
So if you've transferred any files to the target systems
that you have compromised, keep track
of where they have been saved or stored
so that you can remove them or delete them when you're done.
And as a good practice that I actually
recommended during the transferring files
section of this course is to store all your scripts,
exploits, executables, and binaries
in the operating system relevant temp directories.
So if you've exploited or gained access to a Windows system
and you want to transfer some files onto it,
don't just blindly upload or transfer the files
to the desktop of a specific user account
or to the downloads directory.
Store them within the temp directory.
There's two reasons why you should be doing this.
Firstly, you'll know where everything
that you've transferred is saved,
so you know that whatever you transferred onto the target
system is stored within the temp directory.
So there's a singular, centralized location where
you're storing everything.
Secondly, in the context of defense evasion,
this will essentially-- storing your exploits and scripts
within a temp directory is a good practice primarily
because it is not a frequently-accessed folder
and users will not really be able to tell
whether the system has been compromised because all
the files are stored within a directory
that they don't really or frequently access.
And the same goes for Linux, right?
If you are transferring files or scripts,
exploits or binaries transfer them
to the tmp directory, which is just
the temp directory for Linux.
So do keep that in mind.
And as I said, if you've done this
and you follow this good practice,
then once you're done with your penetration test,
you can easily go back to the temp folder and delete
everything from it.
And that's it.
All the artifacts or all the files
that you transferred onto that target system are gone.
Now, it is also important to consider the exploitation
framework that you are using.
An example of this is the Metasploit framework exploit
or postexploitation framework-- whatever you're using MSF for.
Now, MSF-- or the Metasploit Framework--
is notorious for generating and storing
artifacts on the target system when using exploit
or postexploitation modules.
So you might have seen within this course.
When we used a specific exploit module or postexploitation
module, after running it, it may tell you
that that module was unable to delete
the artifact or the script that it transferred to the target
system.
And as a result, you need to delete it manually.
And it provides you with the path to that particular file.
So whenever you're running Metasploit framework exploit
or postexploitation modules, pay close attention
to the output generated by that module when you run it
as it will tell you whether it's generating any artifacts.
And if so, where they can be found
if it is unable to delete them because some well-developed
Metasploit framework exploit and postexploitation modules
are actually very, very useful in that
once they have transferred a script or an executable
onto the target system for the purpose of gaining access.
So for example, if it sends a stage in order
for you to obtain a Meterpreter session,
if they're well-developed, it may actually
go ahead and delete it for you so that you
don't have to do it yourself.
Now, this is not a rule.
This is the exception.
So as I said, the Metasploit framework modules
or the Metasploit framework itself is something
that you need to take into consideration for your pen
tests.
And you need to be very good at understanding what
these modules are doing in the context of transferring files
onto the target systems and what or whether or not
they're interacting with specific Windows or Linux
features that you probably or might not
have the permission to do.
So for example, if a Metasploit framework exploit
or postexploitation module is interacting with the Windows
registry and the client has stipulated
within the rules of engagement that you are not
allowed to interact with the Windows registry,
then do not use that module because, again, you're
going to end up making changes to the Windows registry that
could be very difficult to delete remotely
or through your Meterpreter session.
So keep that in mind.
Now, again, coming back to some well-designed MSF modules,
some of them will provide you with instructions and resource
scripts that provide you with information regarding
where the artifacts are stored and how they can be removed.
And in the context of resource scripts,
some well-developed MSF modules will generate a resource script
that you can run on that target system
to undo whatever the module did in the first place.
So for example, if we're using a postexploitation persistence
module on Windows and it creates a new service
and a new executable and all of that data is transferred
onto the target system, that is quite a messy situation
to deal with.
And as a result, it generates a resource script
that you can run on the target system,
and it will delete the payload or the executable that
was transferred.
It will also delete the service, et cetera, et cetera.
Now, one additional thing that you'll typically find,
especially when it comes down to Windows,
is that a typical postexploitation technique that
is pertinent to clearing your tracks
is to delete the Windows Event Log.
So this is not-- this is something
that I have covered in the Metasploit framework course,
and I did that to showcase how it can be done.
However, in the context of a penetration test,
this is something that should be avoided completely
because the Windows Event Log is essentially a database of logs
pertinent to the system, the security,
authentication attempts, et cetera.
And this information or the data stored within the Windows Event
Log is very, very important to the company
as it gives them an idea as to what
has been done on that system, the ability
to identify successful and unsuccessful authentication
attempts, or so on and so forth.
So again, this is something that will and should be stipulated
within the rules of engagement.
So you need to agree--
you actually need to sit down with the client
and agree upon what you can do in terms
of clearing your tracks.
And on the client's perspective or from the client's
perspective, this is something that they will typically
refuse you to do because that information is very important.
And if you're performing a red team operation
or you're trying to emulate a particular adversary
and one of the techniques that these apt teams or adversaries
use is to delete or to clear the Windows Event Log,
then the company might agree to that.
However, it's something that I would not
recommend that you do primarily because the data stored
within the Windows Event Log is very important.
And that event log is rarely cleared
because it sort of gives the company or the person
using that system a very good historical overview
of everything that has been done on that system from a security
perspective to a system perspective--
so what users logged on, what programs were installed,
what updates were installed, what commands were executed,
was a PowerShell command executed, et cetera.
With that being said, this video has a lab environment
attached to it.
And it's not really going to be that practical.
I'm just going to be showcasing a few examples of what
this would look like or how to clear your tracks on Windows.
And the techniques that we'll be highlighting
will essentially abide by what I've stated within the slides,
all right?
So I'll fire up the lab environment,
and I'll see you there.
All right, so I'm back within the lab environment.
And you will be provided with a target IP address.
And of course, in your case, it's going to be different.
All you need to do is just copy it.
So what we're going to be doing is
we're going to be simulating exploitation
and postexploitation.
And we'll be keeping in mind the artifacts
that we're generating.
And I'll showcase a few examples of how they can be cleared.
And we're going to be utilizing the Metasploit
framework for exploitation and postexploitation.
So we'll just perform a quick Nmap scan on the target system
to identify the vulnerable service that is running.
So I'll say Nmap SV.
And the vulnerable service is running on port 80.
I'll paste in the target IP, and I'll
give this a couple of seconds.
All right, so the Nmap scan is complete.
As you can see, port 80 open.
And we have BadBlue version 2.7 running on it.
We already know that there is an exploit module
for this specific version of BadBlue.
So we'll open up MSF console here,
and I'll just search for that particular exploit module.
So I'll say search BadBlue.
And the one we want to use is this one right over here.
So that has an ID of one, so I'm going to say use one.
And let's show this particular payload
or this particular module's options.
So if I say options, you can see that it's utilizing
the following payload.
So it's using the 32-bit Meterpreter payload,
which makes sense because we don't really
know what the target operating system architecture is.
We then need to set the target IP, so I'll say that Rhosts.
And I'll paste that in there.
And if I show advanced, this will
show me advanced options pertinent to this particular
exploit module.
Now, this is something that's very important because it will
essentially-- these advanced options
give you a better understanding as to what this module does.
And in the context of clearing your tracks
and getting rid of artifacts, this is very important.
So again, the objective here is to try and identify
whether we can find an option that sort of is
pertinent to whether or not this module generates
specific artifacts and whether it automatically deletes them.
So we can also show info to get an idea of what
this module does.
So you can see that this module exploits a stack buffer
overflow.
And the PassThru functionality in the external DLL file
in BadBlue version 2.72b and earlier.
All right, so if we type in exploit,
this will provide us with access to the target system
as you can see here.
So it sends the stage, and it gives us a Meterpreter session.
So if we say sysinfo, we can see that the target operating
system is Windows Server 2016 and the architecture is 64-bit.
OK, so let's migrate to Explorer.exe.
But before we do that, let's check out our user privileges.
So get user ID.
We currently have access to the target system
as the administrator user.
So we'll say pgrep Explorer, and we'll migrate
to that process ID-- so 4032.
And we'll give this a couple of seconds.
There we are.
If I say sysinfo, this should be a 64-bit Meterpreter session.
All right, so let's take a look at the first recommendation
that I made within the slides.
And that is pertinent to where you transfer or store files
on the target system.
As I said, it's always recommended
to store them within the actual temp directory.
So if I say LS, you can see that this
is the root of the C drive.
The temp directory is typically stored in the root of the C
drive on Windows.
And you can create it if it doesn't exist.
So I can say, make directory temp.
And if I navigate into the temp directory,
this is where you should be storing all your files.
And so if you want to transfer or upload a local enumeration
script, this is where you should upload it to.
If you uploading a binary like WinPEs or an exploit binary,
a privilege escalation exploit, upload them
to the temp directory so that you know that everything
is in one centralized location.
So for example, I can say--
if I wanted to upload a file, so I
can say Upload share user share Windows binaries,
and let's find an example that we can use here.
Let's say we wanted to upload Netcat.exe,
I'll upload it to this directory.
And when I'm done with the pen test,
I can just navigate to the temp directory
and get rid of all the files that I transferred.
So remove Netcat.exe and that is done.
All right, so that's the first recommendation.
The next recommendation ties in to the Metasploit framework
exploitation and postexploitation modules.
So during the Windows persistence section,
we utilized a couple of persistence modules
that generated a lot of artifacts, right?
So an example of this would be a module that--
the actual persistence service module
that generated a persistent service.
And I'll just put this in the background and showcase how
that would work.
So I'll say search and persistence,
and I'll say platform Windows.
And this is the module here.
Let's see if I can find it.
There we are-- persistent service.
So I'll use module two.
And this is a postexploitation module,
so I can say show options.
And I'll just change the L port to a different one
because port 4444 is running.
So I can set that to 4433.
There we are.
And we can then set the session ID.
So I'll say set session one.
Now, this module is a good example
of when you need to actually delete or get rid or clear
your tracks because this is a postexploitation module that
will, again, generate an executable,
transfer it over to the target system,
and then create a service--
a persistent service.
So if I say show info, you can see
that this module will generate and upload
an executable to a remote host.
Next, it will then make it a persistent service.
It'll create a new service, which
will start the payload whenever the service is running.
So again, persistence is something
that is very important.
However, it leaves a lot of artifacts on the target system.
And as part of the rules of engagement,
when you're done with a pen test,
you need to get rid of all of this.
You cannot have this running on the system that you have
compromised because if an attacker--
a real attacker finds this running,
then they could potentially exploit it.
And then, you will be responsible for that company
or for your client being exploited.
So never leave anything that could
be useful for a real attacker or adversary on the target system.
So we can run this.
I'll just say exploit.
And you'll see because this is a well-developed postexploitation
module, it'll give you some very, very important resources.
So you can see that it'll, again,
run the module against the target system.
The Meterpreter service executable
is written to the following directory.
So keep this in mind.
Always note this down.
In this case, it stored the executable
under C Users administrator appdata local temp,
and this is the name of the executable.
So let's actually see whether this is the case.
All right, so I'll navigate to the root of the C drive.
I'll say CD users, CD administrator, CD appdata,
CD local, CD temp.
And?
If we list all the files within this directory,
you can see that that is actually there.
And this tells you where it's written,
so you can remove it manually if you want to.
However, because this is a well-developed module,
it will tell you that it's generated a cleanup Meterpreter
resource script file.
A resource script, as I've already
highlighted within the Metasploit framework course,
is a script that is used within the Metasploit framework
to automate a specific task that you want
to perform with MSF console.
In this case, this resource script--
if we can actually copy the path to it here--
and that's very important, so also note that down.
I'm just going to open up a new tab,
and I'll cut the content of that resource script.
You can see that when we run it on the target system,
it will stop that service that was generated--
the persistent service.
It will then delete the service.
It will then utilize taskkill.exe to essentially
kill that particular process.
And it has the relative string or the name of the process
or service for that matter.
And then, it will also delete that particular executable
for you that was transferred to the target system.
So this is extremely useful because you
don't need to do it manually if a resource script is generated
for you.
So the next question is, how do I use this particular resource
script?
Well, firstly, you need to use it or you need
to run it on the target system.
So this is the actual persistent service Meterpreter session,
so I'll just exit from it.
And you can see we still have session one running,
so I'll say sessions one.
And in order to run a resource script,
you simply say resource.
Let me type that in correctly-- so resource if I can actually
type it correctly.
And then, you specify the path to the resource script.
So I'll hit Enter, and you will see that this will clear up
everything for you.
So firstly, it'll tell you that it'll execute the-- it'll
actually stop the service.
It'll then delete the service.
It'll then kill that particular process or service.
And in this case, it tells us that the process
has been terminated and this one as well as been terminated.
And then the file--
the executable that was transferred,
that was stored under the administrator user directory
under appdata local temp has been deleted.
So we can actually confirm this and see
whether this is the case.
So I've navigated to that particular directory.
And you can see that file has been deleted.
So that's fantastic.
All the artifacts that were generated
and the services that were created have all been deleted.
And this is something that is very, very, very
important, especially during a real penetration test.
So again, this was one example of how to closely identify
the actual output or artifacts that
are generated by a Metasploit framework module,
whether it be an exploitation module or postexploitation
module.
And in the event that it provides you with a resource
script, that's how to use it-- a cleanup resource script--
how to use it.
And in this case, we have been able to confirm that we have
essentially undone what we did.
And in this case, we got rid of the persistent service.
All right, now, the final recommendation
that I made within the slides was, of course,
pertinent to clearing the Windows event logs.
Now, Meterpreter has an in-built command
that will clear the entire Windows Event
log on the target.
It's called clear EV.
As I said, this is something that I recommend you stay away
from until you know what you're doing because if I hit Enter,
this is going to clear the entire Windows Event
log on the target system.
So let me just show you this.
This is for the sake of demonstration.
I'll hit Enter.
And you can see it's going to wipe
165 records from the application logs,
764 records from the system logs,
and 2,558 records from the security logs.
Now, this is something that is really not
useful for the client because, again,
as I said, unless you're performing adversary
emulation-- which is part of Red teaming-- then,
if you're performing a standard pen test,
then you don't need to do this.
You can simply highlight that an attacker within your pen test
report, you can highlight that an attacker could potentially
do this.
And that's something that the client needs to be aware of.
So, yeah, that's really all that I wanted to cover.
As I said, most of this section or this phase
of postexploitation will tie into your understanding
of what you're able to do.
And that, of course, needs to be in accordance
with the rules of engagement.
And furthermore, keep track and keep
a note of where you're transferring files to.
Understand that the Metasploit framework modules also
generate files and artifacts, and they need
to be deleted once you're done.
Do keep a note of what modules you're using.
And of course, be very cognizant of the fact that you
can potentially damage a system by interacting
with specific, in the case of Windows,
specific Windows features like the registry,
et cetera, et cetera.
And of course, never be in a position where you need to--
you run an exploit that could potentially cause the system
to shut down or to cause the kernel
to go into a kernel panic.
Primarily because that could lead to data loss.
So that is going to conclude the practical demonstration
side of this video.
All right, now that we've explored
the process of clearing your tracks on a Windows system,
we can now move on to how to clear your tracks on a Linux
system.
So I'll be seeing you in the next video.