Customized Exploitation Avenue
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *
Already have an account? Sign In »
13 hours 9 minutes
Hello and welcome to another penetration testing execution standards discussion. Today we're looking at the customized Exploitation Avenue within the exploitation component of the Pee test standard. So a quick disclaimer
pee test videos do cover techniques and tools that could be used for system hacking. So
anything that we demonstrate or discussed should be researched and thoroughly understood by the user.
Police research your laws and regulations regarding the use of such tools or techniques, and you're given area to ensure that you don't get into any trouble with the law. So what are the objectives of two days discussion?
Well, we want to describe what a customized exploit is we're going to do. Just grab a few examples.
We're going thio, Look at how do we go about tailoring? Exploits were publicly available and just a little touch on exploit modification again, just describing everything in a high level and making you aware of how these things should look.
So what is a customized exploit? Well, every attack is typically not the same and how the Exploitation Avenue occurs. So in order for us to be successful, we have to provide tailored and customize exploits based on a scenario. And so if we're doing wireless testing
and we've got a specific technology in use,
then there needs to be an identified attack type based on the technologies that are in place. And so having an understanding of the same areas were looking at and the applicability of an exploit
is one of the most important expect aspects of this particular phase within the penetration test and so on. Exploit is specific to Sisko Wireless device
and the wireless devices in question. Are Netgear some other type of device?
Chances are they exploiting what work? And so it doesn't make sense for us
to attempt to use that exploit. And so this is pretty much what we're looking at here is that we're looking at the exploits that are tailored to and specific to certain patch levels. Certain service types.
There may be a way that we could modify some of the code within the exploit, provided Thio fit and work against that system, but that would require again additional testing and thinks that nature and so some examples of exploits
that air specific like there's Apache strut. So this is all exploit BB and things of that nature that we look through. And so Apache struts 2.3 point five. And so this is specific Thio these particular versions of Apache
and anything outside of that. It would likely be that this would not functional work because the vendor has likely patch this particular issue. Same thing with this Windows seven remote desktop.
So this is specific to Window 7 32 bit.
And even after you go in and read more on this exploit, it's specific to a particular patch level of Windows seven. And so again, you're gonna have to do some research and understand where you may be able to make modifications to Taylor. These exploits to fit your needs.
And so how do we go about tailoring and exploit
well in a number of occasions? Again, exploits are publicly available, and so you may have to do some work. So if it's designed for Windows X P Service, Pack two and
we're attacking Windows X P service pack three systems,
the exploit may not work. We may need to make some modifications,
and so we should have some knowledge in place to be able to customize and exploiting the ability to change on the fly in order to complete an attack.
So if you know that the clients running at a specific service pack of Windows X p like service pack three,
it's likely that you can do research on that particular service pack and likely find exploits. It would be available for it instead of having to spend ah, lot of time tailoring the exploiting, customizing it again. If time is of the essence
and we don't have the capability or the No Hall, how are the ability to make these modifications? Then we'll need to seek, you know, other vectors that are available to us
and so again, within exploit DBS. You can see here this is just a snippet from the site.
It's just got as some titles of exploits here some dates. So if we're looking at this from left to right, you'll note that we've got a date here, whether or not it was validated, the title of the Exploit, the type, the platform and the author. Now you can search by C V E
here and using the filters. And so if you need to find exploits that Air Force specific CV,
you can do so now. remember,
exploit A D B may not be all encompassing, so you want the source that from multiple sites. And so here's a quick example of a snippet.
So essentially you can see they do provide some directions in modifying exploits, providing the appropriate information. So the Port four Rdp in this case, maybe something other than 3389 So we may need to make a change there. The host I P, is going to need to be different.
You always want to ensure that you replace the shell code in an exploit, especially for exploits that are not
validated. You could, you know, make a connection or provide ah connection out to an actual attacker system, depending on the circumstance and and where you get the information from.
And so if you can't look at this and make a determination on where you need to make modifications, you need to proceed with caution, and you need to work through the particular exploit code and ensure that you understand all the different components of it. There may be something stuck into it that
is meant to provide additional information on your system or a connection to your system. or it may pull a payload to your system.
So always keep these things in mind when you're modifying, exploits and, uh, you know, trying to make those fit into your particular scenario. So a quick check on learning true or false, you can typically find and run and exploit without any modifications to the exploit.
Well, if you need additional town, please pause the video. But in this case, this is a false statement. In most instances, we will need to make it least minor modifications to exploit code and order for it to run. In some cases, you may not. If you're using, like a medicine boy,
exploit where is built into the framework, but it will ask for parameters up front, which it will then put into
the backend exploit codes. So even in those cases modifications are made, an information must be provided.
So in summary,
we described what it customized exploit is. We looked at some examples. We described how we could go about tailoring those exploits as far as looking at publicly available information and a few step. It's on just modification and things that we would want to look for
again at a high level. This is really to help you get started to help you understand what you should be looking for in doing within your testing.
And so, if you already have a process for this, already have a team that handles these things, then you're definitely ahead of the curve. So with that in mind, I want to thank you for your time today, and I look forward to seeing you again soon.