Now just like with everything in the world of IT, there is more than one way to
slice this carrot.
DLL injection is just one of many ways to even go through Incons Havoc on a
target system.
What I want to do now is cover some of the different methodologies that will be
skimming over throughout the rest of this skill.
That way if I cover these now, you can pick up on, as we continue through our
attack phase,
what it is that we're actually doing. Are we using DLL injection? Are we
actually going through and doing DLL hijacking?
What's the difference? And are we just going through and just causing abuse
against unsigned DLLs?
Well, I'm glad you asked all these questions. Let me explain DLL injection.
It's a technique used by attackers to inject a dynamic link library, DLL, just
in case I haven't spilled that out yet,
into the memory space of a running process, much like the explorer.exe that we
saw.
By doing so, the attacker can manipulate the behavior of a target application
and execute whatever code they want within its program and process.
This is typically achieved by forcing the target process to load a malicious D
LL through methods like create remote thread.
That's getting into the actual programming of the process. Once injected, the
malicious DLL can perform a range of malicious activities,
such as stealing data, executing other executable files out there, or
escalating privileges.
It is commonly used in malware attacks, such as key logging, back door access,
or disabling security software.
DLL injection is usually the first and fore front of DLL attacks as it is
inside the hacking world.
Now, if it's definitely a favorite of the hackers, it's definitely needing to
be a favorite of the pen testers.
Because this is where we start getting into that gray area of pen testing and
saying, "Are we the goodies or are we the baddies?"
Well, we're the goodies, but sometimes we use baddie ways to be able to do
things.
And it's all good so long as we report everything and tie it into the actual
pen test itself and stay within the scope of what it is that we're supposed to
be doing.
DLLs offer us a large variety of methods to be able to go in and mess inside
the system,
because the overall service that's running, that's calling upon that library,
is the trusted source inside the actual operating system,
whether it be proprietary to Windows or some other third party application out
there.
DLL hijacking is an attack where a malicious DLL is placed in a location where
a vulnerable application will load it instead of the legitimate one.
This occurs because many applications search for DLLs in a specific order,
often loading them from the current directory before system directories.
What's going on here is that if you were to go back into previous skill and
take a look at Proctmond,
you could get a more detailed view, and we may cover this later in the course,
of DLLs in order.
Also in the dependency walker, it's really good about showing it.
It says which DLL is requested to be loaded first inside of the actual
executable or process.
The reason that there is an order to this is because you don't want to call up
a random DLL into the program and operating system and just have it sit there
in waste space.
You want things to load as quickly as possible and execute like it's supposed
to with a little time in between function calls.
The DLL hijacking is where we take a fake DLL, replace the original one, and go
through and know based on what order or what program is going to call it, that
it gets pulled into the operating system.
Now inside of that DLL programmed in the Refine to C++ are different methods
for us to be able to do some of these malicious attacks like backdoring into a
netcat session.
In programming in there we can pile it, we inject the code like we did in
command injection.
And that works true inside as we hinted in command injection inside the
libraries.
We can make legitimate code and have it pushed into a existing DLL, hence hij
acking, and have our process be the one to be able to run that command
underneath from the DLL.
Now DLL themselves are not executable based on the file extension inside of
Windows.
And if you change the DLL to an exe it's not really going to do anything
because there's no magic number at the beginning to tell it to actually execute
.
So what you have here is as a library with a bunch of commands and supporting
code in there,
dependent upon a process to call upon it to run that execution for us, which is
the most pristine form of command injection.
We also have unsigned DLL abuse and this occurs when an attacker exploits the
lack of digital signatures, hand-hand-hand-nudge-nudge, we covered this in the
last skill.
And they do this to bypass security mechanisms and inject malicious code into
the actual running process.
Boy, I hope that sounds familiar because that's definitely something we covered
previously.
The reason this happens is because the DLLs that are not signed that we
discovered in the last skill,
they don't have a definition file or a hash inputted into any endpoint security
software out there unless it's manually done.
Even then, the DLL itself is not signed, verified by Microsoft or another third
party issuer that has a trusted root inside the Windows Security certificate
database.
So if we have an unsigned DLL within the operating system somewhere, which we
know we do have plenty of those,
we could just simply go in and replace the DLL file with another one that we
made and then just wait for the process to be able to call upon it from its
order.
And we're going to see throughout this skill how we can make some of those the
actual DLL files and set them up for either getting called into a program if we
attack
the through running through it unsigned and just replacing the file or if we
tried to do an injection session.
Now, all this ties into the last one, which is really dangerous.
And I don't know why this hasn't been addressed by Microsoft in a better manner
yet of run DLL 32.exe.
This is actually a legitimate Windows system utility that allows users to run
function-storted DLL files.
It's commonly used by applications and system processes like the other programs
on the system to execute functions inside of those DLLs.
Now, all this really should sound familiar because up to this point, everything
has to have a process or an executable to run said library, correct?
Well, this is where we can take DLLs that we craft on our own, be it unsigned
and have run DLL 32.exe run it for us.
So let's say that we have a DLL that we've crafted, we don't exactly know where
or how to place it in the directory structure for another program to use it.
Well, for whatever reason, Microsoft has this ability to where you at home can
make your own DLLs and have this run DLL 32 executable run those for you.
And it's as simple as basically going to the command line and saying run DLL 32
.exe space malicious DLL.
And code like that can be placed into the registry for like a startup, script
or tying it into something else like a macro that we covered previously.
And you can use run DLL 32 to run at different levels of escalation on the
actual system itself.
Now, we're just going to show in this skill how to put all this together and
get it to run.
And as we continue throughout the course, we'll definitely be honing back in on
some of these previous skills to tie everything all in together.
I just wanted to introduce the different ones first so that way we knew kind of
what was going on and what to expect here.