Not all DLLs are called up inside of an actual program themselves.
Now I know that we started off with the explanation of DLLs and the libraries
and the previous skill,
and we had mentioned that DLLs and the libraries that they contain,
in fact, are code to supplement the actual program overall to shorten the
actual length of the
executable. That's true. But for whatever reason inside of Windows, there is
the ability to run
DLLs free and clear of actual programs that may or may not call upon it. Now
this can be done for
test system evaluators or testers to be able to check their libraries to make
sure they run correctly,
or can be used by folks like us to be able to call upon the crafted DLL to be
able to do what
we need to do in the background. This command is run DLL32.exe. And often there
are DLLs that are
created for specific purposes and legitimate that use run DLL32 to be able to
supplement things
that need to be ran inside of Windows. You may see this being run sometimes
during Windows
updates as an MSI is unpackaging and needs to call upon a library, but not
specifically to that MSI
executable that's within. There are many different reasons, but we're going to
be using it for
evil purposes. And that takes us over to our actual lab itself. And I want to
point out here
that run DLL32.exe is inside of the actual C drive Windows system 32 folder.
This is good and
bad. Well, good in the sense that it's a system file that's inside of a
protected system folder.
And if this was manipulated, then it would actually trigger the operating
system and security features
to say, Hey, something's going on bad in the sense that as you can see, we have
our DLL called up.
And I'm going to explain that here in just a second. That whenever this is
executed through our
backdoor channeling, it's going to be in the directory that that run through
run DLL32 is in.
So C drive Windows system 32, which is where all the system files are among
other things.
So as I zoom out and I show you here, I have the evil dot DLL on the desktop of
in the shareholder of our host VM. I copied it over to C drive Windows. I put
it in there because
it's a protective folder. And as we saw, there was no errors that we got. And
as long as we don't
do anything to obscure Windows will kind of overlook this as being a security
vulnerability
until definitions for things like Windows firewall and other security endpoint
protection is updated
because we sent this to places like fires total. Well, inside of our command
prompt here, we have
the run DLL32.exe file. And we're addressing it to point to run evil DLL, which
is in C drive
Windows. Now I'm going to have the command for this below. But if we simply
just run this and I'm
going to go back into Cali for a second, because we have our listener going, I
'm going to move it
over for us real quick. If we just go ahead and run this, and I'm going to
press enter on it,
you'll see that our listener does not start automatically. And you can see that
I have the
zoom in for you here real quick that C drive Windows system 30 went to the next
command line.
It executed and it ran and it didn't connect to the actual listener that we
have in our Cali box.
Now you may be wondering why is that? Well, just because we have the ability to
use run DLL32.exe
to execute some of these DLLs, it doesn't necessarily know where in the system
process that it needs
to be put in there. So you can tell it front, middle, and chapter three,
chapter 42, book three,
wherever you want to place it, but you do have to address it. And the way you
do this is by simply
putting a comma right after DLL and just stated wherever it is you want to go.
Now, in order to
really dive deeper into understanding what to put in here to avoid detection
requires a deeper
understanding of programming languages like C++ and the crafting of these DLLs.
So I would tell you
that in the course of this skill and course, we're not going to go that far in
the weeds,
we just want to put something in there that sounds legitimate, such as entry
point, capital E,
and then capital P. And the reason that we do this is that when you examine the
running processes
and memory of the system itself, something like entry point does not raise any
red flags.
You could name it whatever you wanted. You could put in MSF venom if you wanted
, but something like
that would set off an alarm bell here and there because why is this popping up
in our processes,
because that's a malicious program. Now moving it back over and I'm going to go
ahead and press
enter on it and you could see on the right side there that our listener not
only responded but also
answered the call of that DLL. And again, the entry point, the comma entry
point on this is just to
identify when this process is running, that it's basically given an entry to
the logging system of
DLL. So you'd be able to browse the logs, the event logs on Windows for this.
And more importantly,
you now are able to see a process ID. Well, before we go into the actual MSF
console to
fart around, I do want to show you here real quick inside of the Windows here,
that if we go into the details and go into the processes, there is a run 32 run
DLL 32 process
opened. I'll zoom in for you here real quick. It is process 556 0 and you could
dig into this even
further and get more information about what DLL is calling and things like that
. But as you've
noticed so far, Windows hasn't really come back with any kind of warnings
whatsoever into what is
it doing. Now let's say for instance that you are not too sure about that
process ID and communication.
You could always do a net stat - you know, and you could see, I'm going to stop
it right there
because it's going forever. As we scroll back out to the top that we do have
communication going out
right on a highlighter before we go in on 4444 and this is our communication
from the host V
M to the actual listener within Kali and it is established and it does identify
the
PID that goes with it 556 0 which lines up with what's inside the task manager.
Well inside of our Kali system again we have our MSF console up and Metapreat
ers up so we have a
reverse shell to that target system using the DLL. How do we know? Well we
could just simply type
DIR and come up with a directory listing of everything inside of that folder
that the executable is
running at. So I'll show you here real quick that we did get our directory
listing right here.
But I also want to type in PWD to show you the present working directory and
that's where the
alarm starts to come up as a blue team person. We're in C drive Windows system
32 which is actually
the core of Windows itself. So in order for this DLL to run somewhere else you
would have to have
either run DLL32.exe in another directory or inject this inside of an
executable or some other
library call for another program. Now there are different ways to do this and
we'll cover those
momentarily because you could just well we'll cover them now. You could just
essentially rename it to
an unsigned DLL that we discovered in the previous skill. So if you want to say
I want it to tie into
Adobe and whenever Adobe opens it'll call that DLL up. The concern with that is
is that it may
raise red flags because now you're overriding a library that's needed to run
Adobe whatever it is
you can do the same. And that the code that we have inside of evil.dll that we
've renamed to
legitimate file name does not contain that same code so Adobe would crash. That
being said you
would still have that backdoor connection as we have here established inside of
our Kali system.
And we also need to understand who we're running as because run DLL32.exe is a
system level file.
So these are all good things to take into consideration and give us the basis
of being able to craft a
DLL and have it run inside of the Windows operating system. Now I do want to
close out with one tidbit
here real quick. Let's say that you don't want it to mess with any of the
programs and you just
want it to run just like we did with run DLL32.exe. How? That's simple. You
would just go in and have
either a macro or a file injection or whatever command let to run or you could
just modify the
registry for that run once or run on startup. There are many different ways to
be able to do this.
The point of this skill was it's giving you the tools to be able to implement
that DLL execution
and hide it as best as possible so it doesn't look as suspect to the operating
system or that blue
team out there.