Watch to learn how to get the most out of your penetration test
In this webinar, Terrill Thorn (Director of Penetration Testing) and Garrett Adler (Senior Penetration Tester) will discuss:
Speaker 1 (Terrill Thorn): Hi, and welcome to a SecurityMetrics webinar. Today, we're going to be talking about Penetration Testing 101. My name is Terrell Thorn, and I'm the director of the Penetration Testing Department.
Speaker 2 (Garrett Adler): I am Garrett Adler, a senior penetration tester on the penetration testing team.
Speaker 1: Today, we're going to be going over some high-level penetration testing information. Specifically, we're going to be covering an introduction to penetration testing, what offerings we have here at SecurityMetrics for penetration testing, the process we go through during a pen test, the benefits of choosing SecurityMetrics for your pen testing, and then at the end, we'll have some time for a question-and-answer session. To lead off, we're going to talk a little bit about what penetration testing is. So, Garrett, why don't you field this one: In a nutshell, what is penetration testing?
Speaker 2: When we perform penetration tests, we will be essentially acting as a threat actor would on the internet, trying to identify and exploit vulnerabilities within your external network, your internal network, or your web applications.
Speaker 1: Just like Garrett said, we're basically just trying to pretend to be an evil actor and access your systems without proper authorization, and see what a real bad actor would be able to do if they were attacking your system. The next thing is: Why should you get a penetration test? There are a lot of different reasons or situations where you could get a penetration test. Garrett, help me out if I forget any, but a very common one is to meet some kind of compliance standard: PCI compliance if you're in the credit card space, or HIPAA compliance, or other government regulations are very common situations. Also, if you're just looking to improve your overall security of your company, it is a great reason to get a penetration test.
Speaker 2: I've heard customers are planning to get a pen test because they did have an active breach or a threat actor compromise one of their systems, and they were unable to determine its root cause. They were hoping to get some insight into their security and figure out what someone may have been exploiting.
Speaker 1: Great point. We do occasionally get customers who have hopefully fixed the issues that allowed a threat actor in, and they just want to do a double-check by having us simulate an attack and seeing if their fixes actually hold up against a real-world attack. So there are a few different types of penetration tests. We're going to cover each of them at a high level. We go into more depth in other webinars that you can check out. But, Garrett, what are the different types of penetration tests?
Speaker 2: As I mentioned, talking about what pen testing is, we cover external penetration testing, which is essentially an unauthorized, unauthenticated person on the Internet targeting your organization and the services that you have exposed to the Internet and just seeing what damage they can do there. To take that one step further, we offer internal pen testing, which means the threat actor is now on your internal environment. How can they escalate privileges or identify and exploit vulnerabilities on the services that are not exposed to the Internet, but could be exposed to either an insider threat or someone who has already found their way onto your internal environment? We offer web application pen testing, so that's exactly what it sounds like: custom web applications that your organization has built. We will either do that as an unauthenticated, remote attacker or with credentials and become authenticated with the application and see if we can't escalate privileges or take a vulnerability in that web app and get into your internal environment that way. Finally, we offer mobile pen testing, which is just like web apps, but for mobile apps instead.
Speaker 1: When I come to get a pen test from you, what are the deliverables? What can I expect as the customer at the end of the pen test?
Speaker 2: Of course. You'll get a report of all the findings, which includes steps to reproduce the finding and then steps to remediate, at a very high level. Obviously, we are not the experts in— let's say, it's a web application—in your code. We'll do our best to give you verbose steps to remediate any identified issues. We will also have an executive summary of everything that we did, whether successful or not, during the pen test.
Speaker 1: Great. So, a report with the executive summary of the story of the pen test, and then evidence showing what vulnerabilities we were able to identify and exploit, in addition to screenshots or other things, to help the company recreate the issue that we were able to find so that they can fix it. We already talked a little bit about the SecurityMetrics pen test offerings, with external and internal pen testing, web application, and mobile application. Let's talk about each one of those a little bit more, and discuss what the scope or objectives of an external penetration test might be.
Speaker 2: For the external scope and objectives—and really, the objective comes before the scope—we like our customers to come to us with a realistic objective—something they're worried about or something, let's say, they're being driven by a compliance standard. We can then take their objective, and using a compliance standard as an example, as you did with PCI, they may say, "These are all of our systems that deal with cardholder data or cardholder information." And we can say, "Okay. That's an easily defined scope. We just need to include all of your devices and services that are externally exposed and handle cardholder data in the scope, and that's what we'll pen test against." A more nebulous objective might be, “we are worried about remote attackers getting on the internal network” Okay, let’s target your organization as a whole. At that point, we’ll do some reconnaissance against your organization we are going to try to build a footprint of everything you have that is externally exposed and then with that data we’ve gathered, we’re going to try to identify and exploit any highly impactful vulnerabilities that may allow an attacker to gain access to your internal environment. We will then document everything that we find, including what we find in that reconnaissance phase. So, let's say you have subdomains exposed that you were unaware of; that will all get captured in the report, and it will give you a really good insight into what you actually do have exposed externally.
Speaker 1: On an internal penetration test, as Garrett said before, we're simulating an attacker that's already gained access—some kind of foothold on your internal network. So this typically comes through a compromised employee account. Maybe someone in your organization clicked on a bad link, and now they have opened the door for an attacker to get in, and they have at least a small foothold on your network. With those internal pen tests, we like to have some kind of objective to help us define what the scope of the test should be. Common objectives for internal penetration tests, if it's an Active Directory internal environment, oftentimes we're going for domain admin access within the Active Directory environment. Can we escalate our privileges from just the lowest level basic user in the organization within Active Directory, and are we able to maneuver our way through and escalate all the way up to domain admin? Other things, just as with external pen tests, there might be sensitive data stored on a database somewhere or on a server somewhere in your internal environment, and you would like us to try to be able to see if we can access that data. Alternatively, you may just want to see what vulnerabilities exist and if you can move around in our internal network and pivot from machine to machine to expose any sensitive data. So all those can be great objectives for your internal pen test. Similarly on the external, we're going to do some reconnaissance on your internal network to see if there are systems we can access that you weren't expecting. Then, we're going to move through and try to exploit and elevate privileges and take advantage of services that might be running within your environment, all with the goal of accessing that data or escalating our privileges, getting domain admin—those types of things within your internal network. For web application testing, we're specifically targeting a web application. For web applications, they're a little different because the scope is limited just to that web application. But on our side, we try to cover as much of that web application as we possibly can. We try to click on every link and uncover every nook and cranny of the web application. There, we're looking for, again, what we can exploit. We're thinking about, can we do specific injection attacks into form fields that we're able to get data out or inject something that lets us go a little bit further into there? Are we able to take a normal user and access another user's data within the organization? Or if it's a multi-tenant application and I have one organization, can I access a whole different organization's data within there? We aim for escalating privileges, both horizontally and vertically, any way we can.
Speaker 2: I think you covered it pretty well. Many people ask if we follow any web application testing frameworks, and we do follow OWASP quite closely, but not just the OWASP Top Ten. As with any of our offerings, if we identify a vulnerability, even if it doesn't exist in the Top Ten, we're still going to exploit it to the best of our ability, and we are still going to include it in the report.
Speaker 1: Even sometimes, within that, we're able to access the web server, for example, and execute commands and code on the web server. That can be a way for us to get a foothold on the internal network, using that web server. So, we try to focus on things that are exploitable within your web application as well. As Garrett mentioned earlier, we want to make sure that we're giving you actionable items that actually pose a threat or could pose a threat to your organization. And finally, mobile penetration testing is similar to web application pen testing but you’re doing on a mobile device.
Speaker 2: Yes, the process of the mobile test is very similar to the web application. Mobile applications, at their core, are very similar to custom web apps. So, we will crawl the mobile application. We'll capture all the API requests that it's issuing. We will see if we can't perform some sort of injections there or access data we're not supposed to, or do all the same things that we discussed with the web application. We then take it a little bit further; the mobile application can be decompiled. So, we will decompile it. We will look for sensitive data stored within the application's code and attempt to use API keys or credentials stored in there and see how far we can take those. But, at its core, it's more or less an API layer pen test with a mobile front end.
Speaker 1: Awesome. Now, let's jump into talking about the process of a penetration test or what it looks like when you engage us for a penetration test. The process for a pen test might differ between companies. But here at SecurityMetrics, we typically start off with a call, typically run by a sales representative. A lot of times, we'll have a representative from the pen test team on the call with you to help define that scope. They're going to be asking you general questions about your environment: Are we looking at an application? Are we looking at external, internal, or network services? What is it that we're trying to pen test? We can also help define those objectives for you while we're on that scoping call. Once that call is finished, and the contract is assigned, that will get handed off to a member of the penetration testing team. We have some project managers on our team that will send out questionnaires to gather specific information about the jobs we're performing. So, things like the URL for the web application that we're going to be testing, or the specific IP addresses for an internal or external network test that we may be running, the code, the information, anything we might need for a mobile test—all of those specifics will be gathered through that questionnaire. and We'll record that for the penetration tester who's going to be performing that manual service. Then, we will transfer that and use that data for the actual manual penetration test. So then, the actual pen testing occurs. This has two phases. There's an automated phase where, at the beginning, before anything kicks off, once we have the specific data, we're going to run automated scans against your environment. Then, we're going to hand it off to someone like Garrett, who will do your manual penetration testing, and actually have someone take a look at the automated results and run some tools and do some manual work on their end to see if there's more information that could be gathered about the services or IP addresses or anything like that that's running in your system. Once the manual portion is complete, we're going to deliver the report that we talked about earlier. Once you have the report, if you feel like you've fixed some of the issues outlined in the report, we also offer ninety days of retesting, in addition to the purchase of the penetration test. So, you have a decent amount of time to be able to examine the report and remediate issues. You can come back and forth a few times if you want to focus on a single issue at a time, or if you want to try to knock out all the issues at once. That's up to you.
Speaker 2: When you're talking about us running automated scans and then doing manual pen testing on top of that, the nice thing about the way we do this is, that when you purchase a three-day pen test all of that automated scanning is being done ahead of time, and you're getting three days of fully manual testing with a pen tester having their hands on the keyboard, walking through your application and environment. So, you're getting a lot of bang for your buck that way, and you're not paying for someone to run a bunch of automated tools and call it a day.
Speaker 1: Great point. Thanks for calling that out. Once you've gone through that, there are some steps you can do ahead of time to get yourself ready for a penetration test or get the most out of your penetration test. What are some ways, Garrett, that you can think of that a customer could do beforehand to get the most out of their pen test?
Speaker 2: One of the really easy things you can do is have automated scanners already running within your environment that are going to pick out that low-hanging fruit—those really easy wins that an attacker's going to have. Then, when we get in there to do your pen test, we can go straight to the really complicated scenarios that automated scanners are going to miss and get the most value out of having a manual person doing a manual pen test. So, we don't have to dedicate as much time to documenting and reporting those low-hanging fruits. That's just going to make the entire process more efficient. Another thing would be to have an objective in mind. So, if you are able to work with your project manager and the person that's helping you scope your pen test and you have a really solid objective, then when your analyst gets in there to do the pen test, they are going to be able to look at that solid objective and really streamline the vulnerabilities that they're trying to exploit so that they can achieve that objective.
Speaker 1: One of the things that came to mind, as you were talking about preparing—coming with an objective—is coupled with the objective: have a starting place in mind. So, the domain names, the users, IP addresses—all the information that you want tested—the environment. Knowing what you're after and what the environment looks like when you have those conversations about your pen test, can really help dial in the scope and make sure that you're not underpaying for something and you're not overpaying for something. It can really help us know what we're chasing down. The other thing is just being open to having us do our work on our side to see if there is more available than what you think there is. So, Garrett mentioned reconnaissance in the external penetration test, looking at externally available sources to be able to see if there are more IPs or more services running on a given host that you didn't expect, and being able to exploit those services, things like that. Just being open-minded and having an open-ended scope, where it's not just limited to one specific thing, but allowing us to look at anything, any way that an attacker might be able to get in. That's going to help you get the most for your money as well, because if someone's really attacking your website, they're not going to limit it only to just this page on your website or just this IP address that's associated with the website. They're going to look for anything and everything they can find, any little crack in the armor. They're going to try to exploit and use that to expand into your network. The last thing I would say is, sometimes when we're preparing for the penetration test, members of my team are going to reach out and have questions for you. Sometimes it happens during the actual testing. If someone from the pen testing team does reach out to you, being responsive to those questions can really help out and just help us be more efficient with the time that we have. We're always time-limited with a penetration test, and making the most of that time is our number one goal. So, when we send over questions that we might have or issues that we've run into, the quicker we can get a response to those and get those resolved, the better your pen test will ultimately end up being.
Speaker 2: As you were talking about the external scope and being open to expanding it beyond just a single page in your application or just the devices that handle cardholder data or something like that, you had mentioned that an attacker isn't going to just limit their task to that. They're going to target your organization as a whole. IF your objective is PCI, being willing to let us go beyond just the cardholder or the card transaction services, things that process payment data, things that house payment data, stuff like that, and open up the scope of the external test so that we can target this random web application that you have that you maybe didn't realize was exposed. If we're able to get on the internal environment, we might be able to pivot back into a system that does house cardholder data. By allowing us to target you as an organization rather than the three things that handle payment data, we're probably going to identify more vulnerabilities that are going to keep you safer, and it's going to be more realistic to what an attacker is going to do on the internet.
Speaker 1: Thanks for bringing that up. It's a great point. So, why should you choose SecurityMetrics penetration services over someone else out there? Garrett, why don't you give a couple of your thoughts on this, and I'll add in.
Speaker 2: Of course. There's one that we mentioned already, which is we do almost exclusive manual testing. We do run automated scanners, but that's just the beginning of our services. A lot of vendors will run Nessus, Zap, Burp Suite, and just report on those findings and call it a day. That's just the beginning for us. We then take all those findings and build upon them and have hands-on keyboard within your environment or your application. On top of that, any vulnerabilities that we do identify, we will exploit to prove the most impact of that vulnerability. So, if we can access sensitive information, we're going to show you just how sensitive that information is and tell you what the worst thing an attacker could do. Or, if we have a SQL injection, we're going to try to get code execution from that, get on your internal environment, and then pivot internally from there.
Speaker 1: I was just thinking while you were talking about that. Not only are we trying to exploit to show you how far an attacker could take it, but also there are certain situations where we might identify a vulnerability or an issue, but then when we go to exploit it, there might be some other compensating control in the way that actually prevents it from being exploited. So, you may have already blocked access to a thing, even though it appears to be a vulnerability. If that's the case, we don't want to make more work for you by asking you to fix something that really isn't going to cause any damage to your organization, and you've already taken care of it in a different way than what we were expecting.
Speaker 2: That's right. I'm glad you brought that up because we see that all the time where we find this vulnerability. We're like, "This is going to be huge. It's so critical." Then we go to actually exploit it, and it's like, "It's not that big of a deal." We're still going to tell you about it, but we're not going to wake you up in the middle of the night to have you start implementing a patch or something like that. The other benefit of SecurityMetrics that we talked about a few minutes ago was the risk mitigation and these steps, or high-level steps, that you can take to remediate the vulnerabilities that we identify. We're going to do our best to make your job as easy as possible and give you as much information as we can about a vulnerability and how you might be able to resolve it. That's all included in the report.
Speaker 1: Fantastic. We also mentioned compliance requirements. Our testing methodology meets all the common compliance objectives for PCI or HIPAA or other compliance objectives like that. You also have a dedicated person on SecurityMetrics' side, one of our project managers, that if you are seeing something on your end that you're wondering, "Is this a pen tester, or is this something that you guys are doing, maybe something unexpected?" you can reach out to them anytime, and they'll be able to respond to you very quickly. So, you have a dedicated contact person that you can reach out to with any questions or issues during the penetration test and after the pen test. And then, also, generally enhancing your security posture. We want to partner with you. We're not here just as a one-and-done. We're interested in your business and your well-being and enhancing your security posture. SecurityMetrics is great at partnering and working with you and your company as a partner. Anything else that comes to mind for you, Garrett?
Speaker 2: The only other thing that we didn't talk about is the retesting. So, we do offer ninety days of retesting that's included in your pen test. It's no additional cost, and you'll get the same analyst that did your pen test, or an analyst that does pen tests if you can't get the same one, to go back in and try to reproduce every identified vulnerability. If it's still vulnerable, we'll tell you why. If it's not, we'll tell you what we did and how we confirm that it's no longer vulnerable.
Speaker 1: Great point. And we should also mention that within that ninety days, there's no limit to the amount of times you can come back and have us retest. So, being able to come back again and again to make sure that all the issues that were in the report are fixed and remediated, that you've buttoned up all the holes that were identified during your pen test. Before we jump into the Q&A portion, I thought it might be interesting if we have Garrett share a war story—a pen test that stood out to you, Garrett—and just talk a little bit about how you approached it, what problems you faced, and the ultimate resolution, what was delivered to the customer.
Speaker 2: Absolutely. We can share a recent story that shows our strength in every offering that we have. So, we had an external perspective, which included a custom web application with credentials. We were actually able to show with that application how an unauthenticated, unauthorized person could gain access to the application. So, they could become authenticated within the application even though they're not supposed to be, and then how they're able to escalate their privileges within that application. Once they did so, they were able to identify some critical functionality from the application that is reserved for administrative users, which they were basically getting unauthorized access to. With that, they could get code execution on the back-end server, allowing them to get on the internal environment. Once they did that, they had a low-privilege domain-joined user on the internal environment, and we were able to escalate our privileges through a variety of misconfigurations within Active Directory and gain domain administrative level to the environment. At that point, I believe the objective of the pen test was PCI. But once you're a domain admin, you have the keys to the kingdom. We could access all the SQL servers where the cardholder data was stored. We could access the payment processors. We could do really anything we wanted to, and we were able to show not one, but a handful of ways that a low-privilege user could escalate their privileges within that environment. The beauty of that is that not only did the customer figure out vulnerabilities within the web application and these critical issues that, when chained together, would let an unauthenticated person on the Internet have internal access to their environment, but this was an external layer, and they got all of these findings on their internal environment as well, which was just more value for what they had purchased. They were critical findings as well. A low-privilege user shouldn't be able to escalate their privileges easily. Now, at least in their environment, it should be a lot harder for a low-privilege user to do that.
Speaker 1: I think that's a great illustration of some of the things that we were talking about earlier with being open to extending the scope of the penetration test. This was an external penetration test to start with, but then you were able to get onto the internal network. Because the customer was open to exploring more, we were able to take it even further and do some privilege escalation, exploiting on the internal network, and get all the way to domain admin. That's a great example. Thanks, Garrett. Now, let's jump into some questions that we have. The moderator has posted several questions for us. So, the first one that I see here is, "What are the individual steps of a penetration test?" I would say at a high level, there's a cycle that we follow in pen testing. First, we start out with some reconnaissance, looking at the targets, the environment, seeing what we're dealing with, and just getting a lay of the land. Once we have an idea of what we're dealing with—what we're looking at, the number of IPs, the application, whatever it might be—then we're going to identify vulnerabilities within that application or within that network, seeing what might exist, what are likely points of entry for an attacker. Once we've identified some of those vulnerabilities and issues that might exist in the environment, then we're going to move on to exploiting those issues. We may run into some dead ends there in exploitation, but ultimately, as we've already talked about, we'll try to exploit as many of those issues as we can. If we're able to exploit an issue, then we're going to look to set up persistence so that we don't have to necessarily rely on the configuration. Sometimes customers are patching things while we're working. We don't want to lose access to a system that we just gained access to. So, we're going to look for some way to set up persistence into that environment, and then we're going to start the process all over again. In the example that Garrett gave just a few minutes ago, he was able to get on the internal network. We had a list of targets on the external side, where he'd done some recon, identified some vulnerabilities, exploited those, and set up some persistence within that. Now he's on the internal network, and he doesn't have any information. So, the cycle starts all over again, and he starts doing recon and scanning and seeing what is out there in the environment, and starts looking for vulnerabilities, exploiting those vulnerabilities, and then just cycling through that again and again until you either can't take something any further or until you get to the point where you're some kind of admin—a domain admin—you have access to everything that you would want. So, that's at a high level, the steps we would take on any penetration test, to cycle through those again and again. Let's see. Another one is, "How will a pen test impact my environment?" Garrett, why don't you talk about that a little bit?
Speaker 2: Of course. A big concern with pen tests is always: Are we going to degrade the availability of any of your services, or are we going to open you to more security vulnerabilities? For the first one, we're going to do our best to never impact the availability. We're not exploiting denial-of-service conditions. We're not trying to exploit any sketchy vulnerabilities that are going to take a service offline or anything like that. We're trying to act as safely as possible. The caveat with that being, we are acting maliciously and exploiting vulnerabilities, and it's impossible to say for sure how a service is going to react. But anything that even borders on sketchy, we're usually going to have a conversation with you first before we try to exploit it, and then we can go from there. The other side of that, which was, "Are we going to open you to additional vulnerabilities or anything like that?" We can pretty confidently say we won't do that. For example, If we upload a web shell or something to your application, we're going to use a very restricted, hardened shell that only we can access, and we do that in a variety of ways. But we take a lot of measures to ensure that a real-world attacker out there on the Internet isn't going to come across something like that and suddenly have code execution in your environment.
Speaker 1: Great. Thanks for that. Let's see. Another question we're getting is, "How much does a penetration test cost?" When it comes to cost, it really depends on the scope, the complexity of your environment, what you're looking at there. So, it's hard to give an exact number. But on average, I would say, the average pen test goes anywhere from five thousand to fifteen thousand dollars, which is typically what we see. If you need a more personalized price, feel free to reach out to our sales agents. We can have some conversations and talk to you about what that would look like for you and your specific environment. Let's see. The next question we have is, "How quickly can we get someone to perform a penetration test?"
Speaker 2: Typically, once you reach out to our sales representative, they're very good; they can typically get back to you within just a few days. Once you've had a call to identify scope and signed the contract, we can usually get a kickoff call scheduled within seven to ten days of signing a contract, and then you'll have a better idea of when the test is actually going to be performed. Typically, it's at least five weeks out, just to give you and us plenty of time to prepare for the penetration test and take a lot of the necessary steps, and gather all the data that you might need. But, again, this is going to depend on some of the scope and complexity of your environment, and the logistics that we may have to deal with in setting up a pen test. Our standard scheduling is usually about five, sometimes even up to eight weeks out from when you sign contracts.
Speaker 1: The next question I'm seeing is, "Who should I coordinate with internally to make sure the pen test goes smoothly?" Garrett, do you want to try to take this one?
Speaker 2: All product owners of whatever it is that we're testing are made aware of those testing efforts. So, if it's a web application, developers and product owners of that are aware. If it's internal, your SOC and NOC should probably be made aware. We're not doing a red team engagement. We're not trying to evade those defenses. So, they should know what's happening so that if they're seeing a lot of alerts, they could react appropriately to those alerts. End users that might see malicious things start to pop up within the application should be made aware. So, let's say it's an internal application that you use that we're doing a test on, and we start putting cross-site scripting payloads or something in there. We don't want someone to freak out when things start happening. So, they should be made aware that testing efforts are coming.
Speaker 1: Next, we see, "How do I know which type of pen testing that I need to get done?" Again, that's going to depend on your environment. Take a look at what data you're trying to protect. Is it, again, like a PCI standard where you're taking a credit card over a website, a web application? Then you probably want to have that web application tested. With PCI, are there other internal systems that might touch that? Then you'll want to take a look at those internal systems as well. If you're just more interested in general security, then, again, ask yourself questions like, "What data am I trying to protect?" Or, "If an attacker were to get access to X data, how devastating would that be?" Or to ask another way, "What is the thing that if an attacker got a hold of for us would be devastating to the company?" So, whether that's just defacing the website or whether that is, "We keep all this Social Security number information in this database. So, if an attacker were able to get access to that database, that would be devastating for us." Things like that can help you determine which type of pen testing you may need. We also have penetration testers on this side and sales agents on this side that can help answer those questions for you. So, if you're not quite sure, reach out, have a conversation. We can help guide you in the direction that makes the most sense for what you're trying to accomplish. The next thing I see is, "What qualifications do the SecurityMetrics penetration testers have?" Garrett, you're going to have to help me out here because there are a bunch of different industry certifications that our pen testers have. But I would say, generally, the PNPT from TCM Security is one. The Burp Suite Certified Practitioner is another one, and those are network and application pen testing respectively. OSCP is also one that most of our guys have. I know a lot of our team has the Certified Red Team Operator certification. Let's see. We have some individuals who have the Certified Web Expert from Offensive Security. What else am I missing, Garrett?
Speaker 2: We have members of the team with, you mentioned CRTO, the Certified Red Team Operator. There's a follow-up to that, CRTO2, which a lot of people on our team have. The nice thing is we could probably go on and on about certs because there are a lot of them out there, and various people on our team have various certs. But the nice thing that we could say about our team is that every single person on the team has the PNPT that you mentioned, the Practical Network Penetration Tester from TCM Security, which should give you some confidence in them testing your internal environment. Everyone on the team has the Burp Suite Certified Practitioner. So, within your web applications and externally exposed applications, everyone should have the skills necessary to test those. The majority have some of those other certs that you had mentioned. So, we're very well certified.
Speaker 1: Thank you. Garrett, I'm going to let you actually field this last one that we have time for today: "What is your favorite issue to exploit during a penetration test?"
Speaker 2: For me, personally, SQL injection is very near and dear. I worked as a full-stack developer for a long time, but was very in the weeds with our SQL databases and a lot of that SQL code. So, I have a history with SQL, and I understand when I start getting those SQL exceptions within a web application, I have a pretty good idea of what's happening. I love that SQL injection is critical by default. You have access to the backend SQL statements, and you can probably start enumerating data from that database. That's critical. You've got access to data you shouldn't have. But there are so many ways to impact that and make it more critical. With MS SQL, you can almost always get code execution from that. Or if you can't get code execution, you can start leaking NTLMv2 hashes, and you can start exploiting linked queries and pivot between SQL databases in the backend. Even if you can't get code execution, there's a lot of impact to be seen there. With MySQL, you can maybe upload a web shell, or there are so many ways with SQL to do more bad things other than just enumerate the database, and that's already bad enough. So, I just think it's such an interesting vulnerability and where you can go with it.
Speaker 1: It opens a lot of different potential avenues or doors to attack from. Exactly. Awesome. If I were to answer that question, I don't get a chance to do much penetration testing. But my favorite vulnerability to exploit is the one that you guys are excited about in the moment. I love hearing about the stories of someone getting domain admin, or, "Hey, I was able to do this new exploit that I read about." We get that all the time because the security world is constantly changing and evolving, and new exploits are cropping up all the time. It's really rewarding to see when you all have researched a little more about a topic and found a new potential way to exploit a thing, and it works in the wild while you're on a pen test. Those are my favorite stories and things to hear from the team. So, thanks for sharing that, Garrett. In conclusion, common questions are, "Where can I learn more about penetration testing?" or, "How can I request your help?" I would say reach out to the SecurityMetrics.com website, and you can schedule a call with one of our sales agents. They can pull us in if they need to, but they're very knowledgeable as well. You can also learn more about pen testing through several online resources. We've done several of these webinars at this point, about the specific different types of pen testing, whether it be mobile or external application. So, you can reach out and watch those webinars as well. With that, I think that will conclude our time for the day. Thanks everyone for attending.
.svg)
