Now I know what you're thinking. We haven't had any demonstrations yet and there's been a lot
of discussion about memory exploits. Well I'm glad you asked because here we are.
Inside of our lab I want to show you a couple things real quick as we start off.
I am in the Windows 10 BWAP system and this is going to be our targeted practice here.
But I also want to point out that I am logged in as I send the all control delete command here.
Oh don't see it in there. I'm logged in as Eric and the password for Eric is password.
The reason that I've done this is because quite simply I wanted a regular user on the system
and not an administrator for us to pick with. Because I want to get as far as we can using
that regular user and making sure that we can exploit memory corruption in the stack or the
heap and basically kind of keep this as a real world example. Now I want you to see right off
the bat that we already have dummy.exe going and I put it on the desktop here. Now that should
already tell us a couple of things. First of all dummy doesn't require to be in it. You don't have
to be an administrator to run dummy and that's why when we create packages using msfvenom using
the specified file types they can be a little bit dangerous when you start sending them around to
organizations that aren't prepared for this. So like a pentest and that's why there is always
things like cybersecurity training, cybersecurity awareness, CompTIA security plus here on CBT
Nuggets. But this allows us to be able to connect to the actual system itself because I have created
another connection over here. Let me get rid of that for a second and show you that I am in the
session for Eric and I am right there. Session two. Now you may have seen already that I had a
couple of things pulled up but we're going to start by doing a quick search. Now I will be
jumping through this because there's a lot of waiting for something like this to happen
and what we're going to be using here and all the codes below this video is doing an exploit search
on the actual system itself. Now I know as I've mentioned already in the text above this video
that we've already completed vulnerability scans as part of our recon process and always going back
to that as we go through the pentesting lifecycle. But this is no exception because once we have an
open reverse shell to the system in this case through meter printer that we're going to do a
little bit more recon and see if there's any exploits that are shown through Metasploit
and that may be because let's say the vulnerability assessment tools that we're using
don't necessarily show this as an actual vulnerability on the system. In fact I went
back in some of the previous skills in between the last set of videos and this one and did a little
bit of digging inside of OpenVAS scans and I didn't see this in the reported scan against the actual
BWAP system. So this is something to keep in kind of your hip pocket because once you have an
established session you can actually run this. And in order to do it again codes below we're
going to be using the post multi-recon local exploit suggester and when you hit that you're
going to go into the sub menu for it. Now you could go through and set all the different options
by hitting show option but I'm going to jump straight to the point here and just go to set
session two and that will basically throw everything to session two in order to be able
to say hey what are we scanning session two is what we're scanning. Now just in case you're curious
show options let's go ahead and go in there and see that and see that there aren't many in here.
Now the exploit that we will be running does require us to have an option set up
uh here momentarily but once you already set the session id or in this case two you just simply
hit run. Now this is going to go through a known database inside of Metasploit so this is why we
always try to keep our pen testing systems up to date. And right now as of this recording there are
2,570 different individual vulnerabilities that Metasploit knows about in order to be able to
search for. You can kind of disregard some of the traffic that you're seeing here on the actual
system itself even though it does say that you have a couple that appear to be vulnerable to
that system. You're going to get a printout here momentarily right there to let you know what is
and what isn't popping up as a good vulnerability. Scroll up to the top and skip all the ones that
you don't see. Basically all the ones here numbers one through five and I'll zoom in for you here
real quick are the ones that we're taking a look at. But the one in particular that we really want
to focus in on is number four and that is CVE-2024-35250ks driver. Now why am I picking on
this one in particular? Well wouldn't you know that this CVE is actually a high one very critical
inside the Windows world and as you can see in our BWAP system before that's a Windows 10
workstation. So this is actually predominantly found in workstations of the Windows variety
specifically in Windows 10. And there are known patches for it but if you remember like we were
talking about with the vulnerability assessments this never really came up. Now I haven't gone
through and patched Windows 10 inside of our lab environment. You may find on your own system if
you run Windows 10 that this vulnerability does not exist. Now that being said what's going on
here? Well when this module is ran on a targeted system like what we're doing here especially a
compromised Windows system that has this vulnerability we're taking a low-level user
account like Eric and we're trying to exploit Windows through a driver that we make have
access to system on the actual operating system. So trying to make it the highest admin possible.
Now this does not use any kind of buffer overflow or tag in case you're doing memory analysis but it
uses a very weird technique called arbitrary write. And this is usually because it has an
untrusted pointer difference. And so what does all that mean? Well this is actually a memory
attack for the heap itself. And it's using excess memory that's not being properly allocated
or properly assigned statically for programs being ran and for that we would normally use
for buffer overflow attacks. Now with that being said now that we're on this targeted system over
here we're going to go ahead and use that particular exploit on the system. And that's
as simple as going to use exploit and I'm just scrolling up because I had to make sure that this
vulnerability did exist on the target system. And again codes below you'll see use exploit windows
local cve yada yada. Now when you do this you will need to check your show options on this one
because even though we do have the ability to tie to a session this will need a local host in order
to reach back to i.e. us. So the only thing that you'll need to do here is first set session
uh excuse me singular not plural to and then set local host to 192.168.0.53 i.e. the
Kali box that we're using in this demonstration. And then once that's done I want to show you so
that way you know what's actually going on. In particular I want to make sure that we are
focused on right here uh learn my alphabet a little bit better down at the end area.
So the reason is is because the last time I ran this it opened up notepad and it should still
open up notepad but it should do it at a different level. And so we see nis serve serve.exe as being
our only in for the alphabet. Let's go ahead and go in here to Kali and say run.
Now we've injected you can see here that we've done a DLL injection and notepad was ran at PID 9208.
All right well let's go over to our Windows system here real quick. Yep there it is.
Now it is ran as me but does this give us admin privileges or can we do anything else?