Now we've seen up to this point that multiple libraries can be shared across
multiple types of different programs.
And one in particular that we're focusing in on right now is NTDLL.dll.
And this is where we start getting into understanding that the library has a
digital signature attached to it.
Bear with me.
We're going to be taking a look at this from the terminal point of view,
because that's probably where we're going to be accessing systems in a remote
manner more than anything else.
Unless you just steal a laptop for some reason using magic.
But going into the actual system itself, and I'm going to catch up here for a
second, we could see where we ran our script talking about NTDLL.dll and
understanding what all programs that it's associated with that are currently
running in memory or in the processing tree.
Well, now that we know it's tied in and a very valuable target, we need to see
if it's either signed or not signed.
And one of the first tools that we're going to use is a simple SIG check, short
for signature checking.
And this is inside of our folder here for library tools in the SIG check folder
.
And I have in the command prompt ready for us.
And code below it also in the script file.
We're simply just going to go to that folder and run it from where the
executable is.
SIG check 64.exe and the path of that DLL that we want to inspect.
And what this is going to do is just simply run and tell us the signature
details of that DLL file so that way we can further inspect and see if it's
either signed or not signed.
And we'll dive a little bit deeper into what that signature means here
momentarily. But as you can see here, NTDLL is in fact signed.
We have verified signed the date that it was signed. Who, what, when, where,
why and how.
And this doesn't give us like the hashing or anything like that. Just, just
tells us if that DLL is in fact signed or not.
This matters more importantly when we're wanting to do DLL attacks or
potentially do anything to alter that DLL because now if anything's moved
around in that file, it will change the digital signature of this particular D
LL.
Hashing is all about the contents of the file and not necessarily the file name
itself.
So if anything inside changes, the hash changes and then the hash of the file
doesn't match the digital signature. If the digital signature becomes invalid
and the endpoint protection of that particular system that we're attacking
alerts of the user and says, Hey, this file is being attacked and came crippled
the system.
Now, if you want to do a DOS attack, this is probably one of the best ways to
do it. Just inject some code in a highly used DLL file. Boom.
There they go, because now the DLL can't be invoked by all those other
processes. Now, we can take a look here in just a second about more detail of
the signature.
Attached to that DLL, but we do have some scripts inside of our script text
that allows us to be able to get more of an understanding of which DLLs are
signed and not signed on the actual system overall that we're attacking.
And for the first one, we're going to be using check all DLLs on a system to
verify valid signature certificates.
So we'll copy this, go into our PowerShell and just simply paste and let this
run. Now, what's happening here is I'm going to control C to break it.
You go back up to the top and then scroll down. I'll get there. This goes
through and looks at all the running DLLs and the processes that they're
assigned to and running memory.
Well, really on the system overall and tells us simply whether it's signed or
not signed. And as you can see in the first line, a depth labs utils.exe is not
signed.
That's a target, but it's an exe and does not really have a library that we
know of attached to it. We'd have to do some digging from earlier in the skill.
ntdll.dll is the first one that pops up and of course, it's valid. The valid
meaning that it does have a valid digital signature that's signed by somebody
recognized
in the certificate management of our window system, be it root intermediary,
whatever the case may be, it's signed and trusted.
So if we alter these DLL files, something's going to get alerted and it's going
to let us know.
Do keep in mind also that if windows uses a shadow volume that there could be a
backup of these files. And if you altered the DLL, it may work for that one
session. But if you invoke the shadow volume and do the file backup, it could
just revert back.
Now the next one that we're going to take a look at is see it if there are any
unsigned DLLs on the actual system. See, it's all well and good that we can go
through and check all the DLLs like we did in the previous script.
But we are looking for the ones that are not protected as well. So that way
they can be the focus of our attack and see if they are associated with
anything that's running.
So we're going to copy that. I'm going to do a clear screen on that PowerShell
real quick and then paste in that.
Oh, sorry. Clear screen and paste in that script for us. Go ahead and run that.
And this may take a second. So you may see a frame jump. Now, one thing I do
want to point out here is that sometimes you get errors and it's just because
the script itself is not perfect. Feel free to take a look at it. But this
generally lets me know if
it can go through and check everything out. You see that there's a lot of path
invalid in here. That's OK, because as you scroll down, you start to see that
like system ni.dll
right here. And then I'm going to zoom in for you.
That's not signed and it's in C drive windows, a simply native images. So now
we start to see that there are many, many DLLs on this particular system that
are not signed. And those could potentially be
a target for a library attack later on in this course. So going back to the
first script we ran and taking a look at the actual DLL that we found in T
DLL dot DLL. It was signed and we got a lot of information when we ran that
script. I want to show you how it correlates inside the actual file viewer.
I haven't pulled up inside of here and see drive windows system 32. We're going
to go to properties for us. And as you can see here.
Right next to general, there is a digital signatures tab. This is where all
that information is being pulled from
and inside of our digital pull it up inside of our digital signature. You can
see that we have a digest algorithm of shock 256 meaning that this was
generated using that hash algorithm.
And you can further go into details and get all the info you want about this
digital certificate. So if you're attacking in T DLL dot DLL
and alter the code inside of it, you would definitely have to find some way to
be able to get this digital signature certificate attached to that DLL
afterwards
to make it valid for the operating system to recognize it and run it because if
anything changes inside of it, native things like
Windows system, the default Windows system protection will flag this and say,
Hey, this is not the original file. There may be something corrupt in there.
Further, you can actually take these certificates and the hashing for them and
go into resources that we discussed earlier in this course like virus total
and go and validate the actual signature and of the certificate itself to make
sure that it is in fact valid.
Because there can be alterations done, but we're talking about standalone
systems and we're trying to attack over the actual network itself.