Okay, so let's make some sense out of this real quick. Why does this DLL go
under the radar?
Because if we injected it inside the command, there should have been some flags
coming up,
some security systems going on. There's all sorts of stuff that seems wrong
with this, right?
Well, in actuality, there's a lot under the hood here to examine. The notepad
EXE that we have,
or excuse me, the SVC host that we're exploiting here is already being ran
under services
by the system. We can look at that right here at process ID 752.
And this tells us that the SVC host is actually running at system level
permissions, meaning
admin rights, right? The EXE has already been called into system. We're not
dealing with the
signature file of this. We're not making any changes to the executable itself.
What we're not even changing any of the DLLs inside of the system overall. None
of this is
being changed. The only thing that's been changed here is the fact that we've
injected evil2.dll
in the executable inside the run of memory. We've parted inside the actual
addressing of the RAM
itself and said, "Hey, make room for this. This is a library that you
absolutely need."
And the system overall accepted it. Now, a part of this is that the DLL we've
already gone through
and proven in the previous skill that it did not need to go through all the
checks and balances
because it's looked at one as a library file and two, the definitions haven't
been updated
for this DLL to flag any kind of endpoint protection or IPS/IDS system.
Otherwise,
we would have seen the errors inside of our skills up to this point. And since
that didn't
happen, an SVC host.exe is trusted and signed within the operating system of
Microsoft. Well,
by putting all that together, nothing should be out of the ordinary. Even
though we know that
that evil2.dll is a backdoor communication channel and we know that it's not
there for anything
other than just to mess around, it's for all intents and purposes a trusted
file with inside
of Windows until otherwise updated through patching or security definitions.
Through things like
directory traversal, file, and inclusion attacks and even working around with
Office inside of
the macros that we were messing with, we've found many ways that we can send
this DLL along with
many other files and file types to a targeted system. This right here, DLL
injection is just a
way for us to be able to invoke a backdoor channel to us and also later on in
this course,
be able to escalate privileges, pivot, and also do some enumeration attacks. I
just wanted to point
all this out because if you have a keen eye for this and you're worked on the
cybersecurity defense
side of the house, a lot of these should have triggered some of the alarms and
everything.
And you can go through and check out the host VM that we're using and see that
everything's
basically at default when it turns into Windows security. In fact, if we go
back over here for a
second and open up edge, you can see this is the same link that I have inside
the skill where I
downloaded the executable file. And when I did the actual download itself, the
only thing that I got
as I zoom in was I got a the DLL injector.exe program that I used to inject was
the only thing
that flagged as being potentially malicious. But I was able to override that
just as a regular user.
Now, that's not to say that this won't flag on any other system. But what it is
say it is is that
DLL injection and the ability to use trusted and verified files that are
already in the running
process along with DLLs that are unsigned to inject inside of that running
process is one of the
big gaping holes inside of Windows and a very go to attack if it's able to get
pulled off.
It's taken us three skills to get where we're at right here. So you could see
that this is bit of a
challenge when it comes to doing proper DLL injection attacks. Now part of that
is if we take a look
at the actual C code for the actual executable that we're using, you can
actually go in and see
where it's actually going in and using some of the Windows API exploits to be
able to make this happen.
Thus, why this is actually becoming a very difficult type of attack to do
because really,
the stars have to line up. But once they do, we can make those stars stay lined
up for things
in the future. Now, as we zoom in on this, you could see that it we have on
line 11, the handle
process where we're actually looking for an open process inside of the actual
operating system
itself. We're going to be calling upon that based on the process ID. And as you
scroll through
here, you can see a lot of API calls for those more familiar with programming
inside of Windows
with C. You could see like we have the virtual allocation, EX, and then we also
have more Git
proc addresses and everything like that. So basically, this program is going
through examining the address
spacing that the executable in that's running has or holds inside of the actual
memory itself.
And then says, where is an open slot that I can possibly slip this inside of?
Now, it doesn't
matter the size of the DLL that we create. And it doesn't matter, you know, how
long we need it to
run. The point that I'm making here is is that we're carving out a opening for
us to be able to
shove this into. And however, that opening needs to be depends on how big the D
LL is that we've crafted
to be able to do this.