Exploit Failed. Now What?

Key Takeaways

we all get into situations where our exploits fail and today we're going to run through a checklist of things that you can do to make sure that your attack is successful I often find myself in a similar situation even on live stream where I've made a small mistake or sometimes I'm just simply tumbling head first down a rabbit hole but the first thing to do in this situation is to work methodically through our troubleshooting list which I'm going to share with you today and of course you can use this as a starting point for your own and you can expand this over time I've split this video into three sections the first is troubl shooting reverse shells the second is getting public exploits to work like those found on exploit DB and finally we'll take a look at troubleshooting web attacks as always if you enjoyed the video then don't forget to like And subscribe and let's dive in keeper security is a vendor that we've used for password and secrets management at TCM for quite some time what's awesome is they also do privileged access management and it's way more affordable than some of the big name vendors which if you know us you know that we're all about affordability it was an easy yes for us when the partnership conversation happened and unlike Legacy Pam Solutions keeper is fast and easy to deploy agentless and clientless and has no implementation fees plus keeper is fed ramp authorized so if you're looking for a new solution to protect your organization check out keeper. i/t CCM and schedule a quick demo with their awesome team so let's take a look at the dreaded failed reverse shell and we'll talk through some checks that we can do to start with we need to look at the basics and these are essentially sanity checks so verifying the IP address used in our attack checking the connectivity with ping or rescanning a service to make sure that it's alive and that we haven't accidentally crashed it checking that traffic can actually flow over the port that we're using and check checking for firewall rules or making changes to our attack for example changing to different ports to indirectly test these rules after that we need to look into our listener setup so is the listener actually running once again do the ports match up I often make changes to my payloads and then forget to update my listener and if we're still experiencing no call back and we've checked all of these things so far then we can start thinking about the payload itself so some of the things to consider here uh is the payload configured with the right values and are you using the correct syntax to run it is the payload compatible with the target systems architecture and operating system do we need to obfuscate the payload and if all else fails we could look at alternative shells so we might try a bind shell instead of a reverse shell maybe using a web shell to gain an initial foothold and then spawn a full TTY shell from there it's also worth noting that if you're doing a CTF or boot rout machine then resetting the box is often a good idea when our exploit fails or more likely the exploit that we found somewhere on the internet fails there are a few things that we need to check so first up we should think about validating our exploits does the exploit match the version of the application or service that we're targeting are there any comments or information in the code that might tell us how to use the exploit specifically does the file contain quirks like a mixture of tabs and spaces that are causing errors upon execution this is particularly common with exploits written in Python does the exploit need to be compiled in a particular way and generally asking these sorts of questions and checking that these things are in place is going to help us hone in on the problem and allow us to make some kind of progress after we've asked these questions and checked that everything is as it should be we can continue to look at the Target configuration now of course this depends on what your target is the level of access that you might already have so for example you might be doing a prives technique and therefore have some level of access already to check the target configuration but otherwise you might be attacking from the outside and unable to do this so the configuration of the Target or service we're attacking might need to be checked as our exploit might require some certain conditions it's worth checking for extra information or blog posts on the exploit that you're using to uncover this kind of information if it's not readily available next up we have checking for security mechanisms that might need disabling or bypassing before our exploit will work and finally if we've done multiple attempts make sure that the target service is still running you might have popped it on a previous attempt so the box or service would need restarting after this we could consider if there are alternative exploits available I tend to use Google to find more stable exploits than the original that might just be a p and they're often available on GitHub otherwise reading the exploit and understanding the steps and replicating them manually can also be a good option many exploits will require modification for example they might have hard-coded paths that need updating or some custom shell code that fits the Target and has all the right information about where to send a shell back to lastly any dependencies need to be checked and I previously had some issues getting print nightmare working for a while because my dependencies were not the correct version and if we're really stuck we may want to set up a local test environment to ensure that our exploit is working as expected against a known Target where we can actually control the configuration and then we can continue troubleshooting after that finally we have an exploit failing against a web application and the Assumption here is that you found an endpoint that's probably vulnerable or at least showing symptoms of being vulnerable to something like SQL injection or maybe youve found template injection but you can't get it working in a way that you want to fully demonstrate the impact so first up we need to think about the information that we have and the behavior of the application are there error messages giving us some information are there delays in the response or information in the body of the response that shouldn't be there thinking about what we have in front of us and why it might be there is a really good place to start next we can consider our payload and how we might modify it for example we might try a variation of our payload or a different one entirely we might try encoding our payloads or even just simplifying it if we think that we need to bypass something like a WAFF then maybe nesting or combining attacks or using things like parameter pollution to get a successful delivery could also be key and if we haven't already we should also consider the teex stack of the target so going back to our template injection scenario we might send a number of different payloads to identify what templating engine is being used first or we might try some different SQL injection attacks to identify the backend database and sometimes this can be really important and the more information you have at your disposal the more likely you're going to be able to pull off a successful attack and finally if you haven't already then we can start fuzzing the Target and making sure that we haven't Mr payload that brings us success so before we wrap up here are some bonus tips that should help you out when you're stuck and I'm just going to list them out and hope that you find them useful so first up take regular breaks I've talked a lot about this in the past but every breakthrough that I've ever had was due to taking a break making a cup of tea or just getting up from my desk for a minute or two second which is kind of the same as taking a break but move on from what you're doing and come back to it later work on something else or some other part of the application and cycle back to it later on this is particularly useful during practical exams and can help you avoid wasting time falling into rabbit holes third always read error messages the number of pings I get with screenshots where the answer to the issue is clearly stated in the error message is quite frankly astounding and fourth use Google and chat GPT obviously don't leak sensitive information but if it's a generic error message drop it into Google and if you think you have an issue with some code that you don't quite understand let chat GPT try and spot it or explain the code to you I often use chat GPT to troubleshoot my code and it saves me a lot of time now if you have other tips that you want to share then of course let us know down in the comments below and if you didn't already don't forget to like And subscribe subscribe and I will catch you next time