External Penetration Testing Basics Webinar

Watch to learn how you can get the most out of an external penetration test, as well as what to expect from an external penetration test.

What to Expect During a SecurityMetrics External Penetration Test

Get ready for your next external penetration test.

James Farnsworth (Senior Penetration Tester) and Garrett Adler (Senior Penetration Tester) will discuss how you can get the most out of an external penetration test, as well as:

  • Why You Need to Perform an External Penetration Test
  • How to Improve Your External Network Security
  • What to Expect from an External Penetration Test

This webinar was given on October 19, 2023.

Transcript

Hello, and welcome. I'm James Farnsworth, and I'm joined by Garrett Adler. We're both senior penetration testers for Security Metrics. Today, we're doing a webinar about external penetration testing. This webinar is for anybody who's interested in how we do what we do, the types of things that we find, and kind of the process that we go through when we do external penetration tests.

This webinar is definitely for you if you wonder about, hey, What could somebody do with our external attack exposure and what is possible? Because that's what we're talking about today. Just a reminder that this webinar is being recorded and being sent out after the fact. As you have questions, please remember you can interact with us on the website, so please submit your questions. If somebody doesn't get to you, we will be reaching out after the webinar to make sure that we answer your questions. So, Garrett, super good to have you here with us today.

What are we talking about?

Yeah, James.

Looking forward to chatting with you. We are talking today about, external penetration testing and what a malicious threat actor could do with the infrastructure that you have exposed to the global Internet.

Cool. And in current events, can you is there is there something that sticks out to you as something that's happened recently that could be like a a good thought of, like, hey. This service ties to, like, this current event.

Yeah. Absolutely. As always, there are, headlines in the information security space, about happenings. And the the big one recently was with MGM, a large casino in Vegas.

Threat actors social engineered their way in and then escalated privileges within the internal network, eventually dropping ransomware throughout the MGM network.

Before that was Caesars, another large casino and resort in Vegas. And other headlines you could think of in that same vein are, like, Uber, a year ago, same situation, social engineered their way in and then escalated privileges.

Nice. And I think every time we talk about because this is the second time we're doing this. And every time, it always comes back to me like, yeah. Those are the headlines.

And I think that people who are adjacent in those spaces can have questions, but also I think it generates questions for people like, we're not a big casino. We're not these huge tech companies. Like, how does it apply to us kind of a thing. And that's always something that, like, I'm always super interested in answering, like, when we start doing these tests because, like, a big question is basically this huge, unauthenticated attack surface.

Because sometimes when people do pen tests, we start from, like, a privileged environment and then go, here's what we can do. And so one of the things that I thought was interesting when you were talking was this idea of, like, hey. We start like, these attackers will start and just see what they can do with either what's available with the technology or they'll see what they can do when it's like, hey. We actually social engineered your employees, and with that access now, this is what we could do internally.

So when we're transitioning to this idea of, like, how does it apply to maybe more small to medium businesses as opposed to these huge, huge, like, tech conglomerates or these huge Caesar's palaces, those kinds of things, Can you think of, like, some things that are interesting that you've done recently in tests that you've had?

Yeah. Absolutely. And I think just because you're not a, you know, multibillion dollar organization such as MGM or Caesars, these attacks are still valid against your organization.

An attacker doesn't really care what your footprint is. Your data is still good on the on the Internet, and they can still package up your data and sell it. So just because you're a small mom and pop shop doesn't mean that there aren't threat actors actively targeting you.

Absolutely.

But as you mentioned, you know, things that we've actually done, you know, when we're doing our external penetration testing, You know, like I mentioned, we can social engineer our way, and an attacker would totally do that. They'd call the help desk. They would, you know, use, social engineering to get credentials or to get passwords reset or, you know, whatever that will trick people into doing something that the attacker wants them to do.

We might do a phishing attack, send an email, get you to click a link, disclose your credentials, and then log in to a to a VPN.

We've done that recently and had success. It was very similar to those big headlines. We were able to grab credentials, log in, multifactor was not enabled, and we're able to escalate our privileges because the principle of least privilege was not enforced in their network.

There's threat actors will look for credentials that have been included in data breaches through tools like DHash or Hunter dot io, and they will attempt to reuse these breach credentials. So we will test that your users are, you know, following best practices and following those trainings that you've supplied them with that say, don't reuse credentials. Don't use a bad, you know, easily predictable password. Use a password manager, and all these things have multifactor enabled.

I think that's really cool because, like, when you're talking, one of the things that I think about with, like, externals and one thing that's, like, fairly interesting to me is is this idea of, like, this extern external attack exposure is actually, like, very, very personal to these, like, businesses where it's like, we integrate with this third party, and we have web interfaces for this, and we have custom applications, and we have basically, like, our third party SaaS for our email and, like, all of this different stuff. And it's all tied usually in a lot of ways with, like, SAML SSO, those kinds of things, OAuth.

And it's always, like, very, very interesting to me because when one of the things you were talking about was was essentially, like, breach data and those kinds of things, where it's funny because people will, like, you reuse passwords. And so when we're doing, like, phishing engagements, it's always this question of, or even just, like, when we're looking for dumped credentials or, like, in in, like, breached information.

It's this question of are people still using those weak passwords, or are they using this password that we phished from them to, like, integrate with your active directory, like, all of those questions. And I think that it that's one of the things that is, like, so it what makes external so interesting to me is is how this blend of, like, hey. We're tying all of this information together creates this this very unique signature for companies for how we can now tie exploitation together.

I like that, that phrase used, like, this unique attack exposure. The the really interesting thing about the external pen testing is that, like, that attack surface is so large, and I can't remember who it was. It's like an old ex military guy who had this quote that said that it's not if an attacker gets into your internal network. It's when and how do you react to that. And that's really what we're trying to do is simulate your response when an external unauthenticated threat breaches your perimeter.

Yeah. And I actually really like that because one of the things that's really interesting when we engage with companies with phishing and they're like, oh, we already use, like, our know befores and different stuff to run phishing campaigns.

Generally, like, with interfaces where it's like, hey. We use a turnkey solution where we can set up our own phishing and stuff. It's not always like, the discovery process isn't always, like, as exact as what we're going to do because when we go through and do these externals, like, a lot of, like, what we're looking at is what is your attack surface, what domains do you have, what IPs do you own, what services are on there. And then also, we start, like, enumerating all of that different stuff, and it becomes very, very tailored to the point where when we do these phishing engagements, one thing that's really, really interesting to me is we actually get to see how people are going to react.

And that's not to say, like, we're just gonna send it and fire it off without saying, hey. We're doing testing from this date to this date because, like, we will communicate that because, obviously, somebody at that company is gonna need to know. Right? We're gonna have to communicate with them.

But one of the things that's been interesting in, like, the last two phishing engagements was to see how the different processes, like, happened and how people escalated those incidents. And so that's definitely when when we're talking about phishing and, like, when we engage with customers, one of the questions is just like, well, we already do phishing. Like, why would we do that? And it's because generally when you're using those turnkey solutions, you stop at one point.

It's like, we got this many clicks. It wasn't like, oh, like, this click led to, like, a remote code execution or this execution or this click led us to that level of user's access and what could that user do. And so that's why I like what you said because, like, once we get those clicks, once we get those passwords, once we get those passwords, we see where are those passwords valid. Like, where what can we use with them?

And then also, generally, that leads to, like, an internal foothold that then we can now see what can this user question of what impact can we make? Can you talk to me a little bit about, can we make? Can you talk to me a little bit about, how we determine to, like, prioritize what we're doing once we get those footholds?

Yeah. Absolutely.

So once we have footholds, once we've breached your external perimeter, we want to see what a low privilege user can do within your environment. We wanna ensure that the principle of least privilege is being enforced throughout your network.

And what that means is that users have the least amount of privilege they need to do their job for the for their role to continue to function, and they have no more. So a low privilege user should not be able to access your domain controller.

Yeah.

We are also trying to validate that multi factor authentication is in use throughout your network. If a threat actor scrapes breach credentials off DHash and they log in to your VPN, they shouldn't be able to just do that. They should have a second form of authentication that restricts that access. And the same goes for social engineering.

If we call someone, there should they should not just take your word that you are who you say you are. They there should be a second form of validation or authentication. I'm having use of air quotes there. But they should be, you know, it's that old saying trust but verify.

They should be verifying who you you are, who you say you are.

Yeah. We are going to validate your password policy. Right? If people are clicking on our phishing links and putting in password one over and over again, we're gonna say, well, that's not a very good password policy. You need to train your employees about something, ideally, password manager, something else, and then back to multifactor.

Yeah. And that's all that all sort of goes into, like, the human side of things, but external is also technical. So we are going to validate that you have proper patching policies in place, that the services you have exposed to the Internet are patched to their secure versions. There's no known vulnerabilities.

There's, you know, there's not people actively exploiting known vulnerabilities. When we find stuff, we are actually going to look and see, like, are we the first ones here, or are there a thousand shells on this system?

Oh, I was just gonna say one of the things that I liked about what you're saying is in both of those instances, we're starting from this perspective of, like, either no authentication or, like, a low privileged user. And so when I think about, like, what have like, how does it apply to the people that we've done? Like, we've seen anywhere from, like, people clicking on phishing links and then escalating from there, but also when you're talking about what we'll review the technical side. One one of those one of the things that I thought of was, like, one of our testers found, like, a Jenkins server and then could register a user, and then that Jenkins server didn't have, like, very strong configurations, and it led to, like, remote code execution.

And then, like, now now we can say, okay. Like, this is all the kind of stuff that we can do. And I guess looping back to, like, how do we prioritize what we're doing? Because you had mentioned, like, a lot of different things where it's, like, strong password policies and basically, like, how do you respond to those incidents and least privilege and basically, like, a bunch of really good, like, hey.

These are things that will help. But it's also, like, in addition to that, when we give those recommendation, it's also very based off of, like, the objectives that people will have when they come to us, which is super, super neat because in a lot of instances where it's where people do have such big exposures on the outside and where there are so many different types of attack that we can do, one of the big focuses is it's like, why are you coming to us? Like, how can we tailor fit this to what you need from an external perspective?

Because if we with when we have that in mind, then it helps us prioritize, like, okay. These are the suggestions based off of your concerns that for, like, what you can do. Right? So I I definitely really like that. And I guess tying into this idea of, like like, best practices that people can implement, what are like, if you had to give us, like, five things to basically say, hey. This could really, really help your external security posture. What would they be?

Yeah. So keeping a, like, a good track of the assets that you are exposing to the Internet is, I think, step one. Like, you need to know what is out there and what is exposed.

And then along with that, you need to know what versions of that software are out there. Like I said, like, we are gonna test that you have a patching process in place, but you need to also ensure that you are doing the due diligence with your system administrators to routinely audit the software you have exposed and pass it to its latest version.

And that's sort of, like, the technical side. Right? Like, you mentioned, like, the Jenkins server. Like, if they had known they hadn't exposed Jenkins server where you could authenticate, like, they probably wouldn't have allowed or maybe if they'd known the the the implications of that, they probably wouldn't have exposed that, but they didn't.

And that's, like, where we come in as the penetration test. It's like we are looking at this from a threat actor's perspective, and we can say, like, yeah. Yeah. Maybe you knew you had this Jenkins server, but did you know you could register a user and then use the groovy scripts to get a shell?

Like, that's a feature of Jenkins.

Yeah. You need to lock that down.

Lock that down. Don't do that. Yeah. Absolutely. And something you had also mentioned that that in there so, like, if I had to sum up basically a bunch of the stuff that you've said, like, five takeaways you said, basically, like an asset inventory. Then once you know what you have, basically, patching and making sure that everything's up to date. You had also mentioned, like, basically, password policies where there are longer passwords or even passphrases.

And then basically, like, even if we fish you, the next thing you can do is enable multifactor.

And then the last thing is, using least privileged accounts in in in that.

As we're as we're going along, how do we because, like, now that you know right? Because there's this give and take in security, especially, like, a big part of our jobs is, like, helping people validate, like, what's going on.

After they after after those, like, five principles are implemented with, like, the asset inventory, service discovery, long pass are implemented with, like, the asset inventory, service discovery, long passwords, multifactor authentication, and least privilege, how do we help in that process of applying, basically, like, good security practices?

Yeah. I think we talked a lot about this in, like, the last time we spoke about internal penetration testing, but a large part of our role here is to validate the assumptions that you're making about your your your network.

And so you can do, you know, all that work, those those five takeaways. You can go through the process and you can do do that cyclically. You can repeat it. But we're only human. We make mistakes. And Yep. An attacker is going to capitalize on those mistakes, and our role here is to identify those and help you in resolving those before, ideally, before an attacker.

Yeah. I do. And and I think that that's one of the things that I like, basically, like, the verifying these biases that we have or making sure that those assumptions are taken care of, and that's a big part of it. The other thing too, like, in there is we help you prioritize based off of, like, the exploitation.

So a lot of, like, what we're doing isn't just let's find every single instance of every single thing that we can find. It's also, like, how does that impact you? Because, like, a lot of the suggestions that are gonna be there probably aren't gonna be amazingly tailor fit where it's like, oh, like, on this web interface, like, you should be sanitizing information so there's no SQL stuff. Right?

Like, the suggestions for how do you fix it is probably gonna be fairly standard based off of vulnerability.

But where it becomes tailor fit to, like, our customers is all of this external side that we're seeing where it's like, this is your environment. This is what we now have access to. This is how we can actually use that. So demonstrating, like, the impact or the risk associated with that information is also how we can help. And through that, it also helps us establish a priority.

So my question, I guess, that comes after now that we've kind of talked about, like, here's what happens in, like, current events now that we've talked about, how does it apply to, like, customers that we've seen and basically, service or sorry. And not and that we've talked about, like, some good principles that people can apply.

How, like and we've talked about how we help with that. Can you put into terms for me, like, what service offerings do we specifically have, like, within, like, an our exploit external penetration tests that we offer?

Yeah. Absolutely. And had sort of mentioned that, like, we can tailor fit this to you, and we can also do that with your threat profile. So we can work with you to identify your threat profile and come up with a list of objectives or perspectives that match that threat profile.

And so through that, we can offer phishing. As we've mentioned before, we've, we don't just send, you know, an email to everyone in your organization and document who clicked it and who didn't. We Yeah. We attempt to identify where an attacker could, you know, coerce someone to click a link, disclose their credentials, and where we can take that further.

So all of that is just a starting point. Once we have those credentials, we are going to see how far we can go with that.

We can do, so, like, asset discovery against your exposed services, your your footprint.

And so we we're going to attempt to identify sub additional subdomains, additional services that maybe you didn't know about, forgot about.

Like, in the Jenkins example, we're gonna identify services that maybe you knew about, but you didn't realize the implications of exposing those.

We are going to, you know, enumerate breached databases, look for exposed credentials, see what an attacker can do with that. And then any vulnerabilities we found, whether it's a known vulnerability in an exposed service or an issue with your authentication protocol, you know, what what have you, we are going to exploit that in an ethical manner. So similar to how an attacker would, but without, you know, breaking too many rules.

Sure. Absolutely. So, basically, if I'm gonna go through and say, okay. Like, this is the general template that we're using in our externals.

You had mentioned discovery, identification, exploitation, and phishing is in there as well. Because previous in the conversation, we had also mentioned, like, we're gonna focus on the human factor, and we're also going to focus on, like, the technical factor where when we're looking at the technical factor, maybe there's like, oh, after we've enumerated this, we're really interested in this service because we feel like it'll help us here. And so maybe we craft a phishing campaign to, like, get access to that service. So those are the kind of, like, the phases of the external.

And as we go through and we kind of already touched on this question or this idea of, like, how does our fishing differentiate, which is basically, like, we tie it based off of what we discover and the objectives that you've given us. So it's more more tailor fit, and you also get to see the impact of how do we use those credentials or now that we've actually gotten somebody to execute something and we have a foothold, like, how can we move forward with that? So other than, I guess, phishing, like, an internal VPN credentials, is there, like, another example that you can think of that we've had that where we found success with that that demonstrated that kind of idea of using an objective and and tailor fitting it based off of the discovery that we used?

Yeah. So you mentioned how we are, like, tailor fitting this to an organization.

We recently had a test where the organization's threat profile included several WordPress implementations, and they knew for sure that they had gotten popped at some point through one of their WordPress servers.

They didn't really know how, so they wanted us, for the objective of the test, to identify a path which an attacker could take to gain shell access to one of these WordPress sites.

And so during our discovery phase, you know, we enumerated their sites. We enumerated the valid users for each site. We, enumerated, you know, breach information for those users.

And through that discovery, we also identified a vulnerable, plugin for one of these WordPress sites. However, the site with the vulnerable plugin did not allow for username enumeration. It didn't allow for some of that discovery. So we use their other exposed services to build a, an attack profile, which we could use against the vulnerable WordPress site.

And through that, we looked at, again, bridge databases and usernames, and we were able to build a a targeted attack against that WordPress implementation where we could take users from other sites and credentials belong to those users of other sites and attack the vulnerable WordPress implementation. And while we didn't perform phishing on this engagement, we could, at this point, perform a phishing attack, which is targeted against a single user, which we know is valid against this WordPress site, and potentially take these small components of each exposed asset and put them together to build a very targeted attack that would allow us to get shell access.

That's that's awesome. And I think one of the things that's really cool with what we're talking about, because one of the questions if you can just think about if we're just doing identification and finding, like, as many issues as possible, it'd be really hard to identify the priority and what's actually feasible. And so even though that customer was like, hey. We don't want you attacking our employees, it still provides this ability to say, okay. Like, we found this employee. We've know that this account is basically being used on this WordPress site. Like, we've done research on that employee, found other emails that they have, their personal emails, and can build custom word lists and those kinds of things to increase, like, the chances of that happening.

And, also, like, even though they had, like, protections and those different types of things on the on the one WordPress server, the other one didn't, and we could do, like, more effective brute forcing based off of different WordPress magic where they leave open an interface that just lets that server do all of the work instead of making a bunch of network connections. So definitely really, really cool.

As we're going through, can you we've talked about basically, like, the phases of the the external kind of how we're tailor fitting that with objectives, those kinds of things. And we've also talked about, like, user discovery, asset discovery, and breach information.

Can you now tell me about, like, why certain people would choose to do externals or common scenarios that, like, people will approach an external because, like, obviously, in an ideal world, we'd be able to test everything under the sun, but sometimes, like, we can't. So can you speak to maybe how like, why this external service is beneficial to when cost becomes, like, a question?

Yeah. So you mentioned cost becoming a question. Right?

That's a big reason a lot of bills do an external with us is, it can get very expensive to do an exhaustive test against a large number of web applications.

And so maybe you wanna skip all that asset discovery and all the stuff that we sort of talked about now, and you'd wanna provide us with credentials and, like, ten web applications.

Well, that's we can do a nonexhaustive test against those web applications, which are authenticated in a shorter amount of time by doing it as an external test, which is to say that we will test for vulnerabilities in those web applications, which would allow a maybe low privilege attacker to either exploit vulnerabilities elsewhere on your externally exposed network or gain access to your internal network through that web application. And so we might not look for a lot of vulnerabilities you'd see in, like, a web app test, like, say I don't know. A cross site scripting which has zero implication. It doesn't allow you to, you know, take over sessions. It doesn't allow you to, like, exploit maybe, like, a c cert or another, like, you know, very low severity cross site scripting. You're probably not gonna report that. But a SQL injection that allows us to execute commands through, say, like, XP command shell and get remote code execution, that's something we're gonna be looking for.

Absolutely. And I the reason I like what you're talking about there was because, like, a lot of customers that when they're like, hey. We have this black box test that we wanna perform where it's like, okay. We really wanna know, like, what is the potential of things that are happening.

That's what allows us to answer that question where also it's it's like, hey. Either we have, like, this huge exposure with a bunch of, like, web applications like you were talking about, where, basically, when we want, like, a good idea of what's possible, and if somebody started from an unauthenticated or low access, like, that's generally where externals, like, shine is because there are those moments where you had mentioned, like, a SQL injection. And, like, one of my other favorite ones is somebody was like, hey. Can you do a black box?

And your starting point is, like, this web application. And when you, like, put in a user's the username, the API would go out to the server and basically put in the API key for the admin to check if it was a user. And then, like, if you were listening for that traffic, it basically gave you a foothold into, like, all of that company's data without having to authenticate it all. And it's one of those things where it's like, okay.

Like, basically, I guess it's this question of how do I know if, like, externals are a are a good idea for me? And, like, some qualifiers are basically, like, you have a very, very large attack surface, and you wanna know what's possible. And that can render in, like, we had our example was applications because that's something that happens where somebody's like, hey. We have a lot of applications, and we we just, like, wanna make sure when we give you this objective, like, this is what we're concerned about.

Can you use these applications in tandem to do it? So, basically, large large attack surface. And then, basically, like, if you're concerned about low privilege or unauthenticated attackers, what can you do? And then, also, like, if you're concerned about, like, the human element of, like, how could our users or our employees be exploited in order to, like, gain access, and what could you do with that access?

Those are all really, really, really good options.

I just wanna loop back really quick to for one statement for, like, the application specifically.

We do also have, a service where we specifically test applications, and that is a more exhaustive and more in-depth where you had mentioned, like, on the external. If it's, like, a self cross site scripting, we're probably not gonna report that or, like, work towards that. And that would fall more into, like, if you wanna know, like, exhaustively the types of, like, issues that are more specific to, like, specialized web application pen test. Like, that's something we also do.

I don't wanna get, like, super sidetracked and be like, now this is what we do for those. But just as a, like, an aside for people, I don't wanna be like, hey. We only do this on this side. Like, that's something we also do over there.

As we're talking about, like, externals in this unauthenticated perspective, can you think of some like, when we engage with a customer, we're gonna ask for certain things that are gonna help us with that time variable. Because when we're talking about, like, external stuff, in an ideal world, we'd have all the time in the world to find every asset and enumerate every user and to find all of the breach credentials. So when we start queuing up these phishing engagements or these externals, what are some common things that we'll ask for in order to help set both of us up for success in order to save time and reduce cost?

Yeah. Because, you know, as with any pen test, it is time limited. And while an attacker has unlimited time and resources, we do not.

So Sure.

We're gonna do what we can to be more efficient.

So as far as phishing goes, we might ask for a list of email addresses for users that you want targeted with the phishing attack.

We can obviously go through the open source intelligence gathering and build this list on our own. It just takes time.

It's not that hard. It but it does take time. And so it's beneficial for you to provide that to us. It eliminates all that time. It allows us to spend more time looking for vulnerabilities in your network. We might also ask for login panels, places where those people are actively logging in, and that goes back to your objective.

If you want us to get into your internal network, we're probably gonna look for something where active directory credentials are being enforced over LDAP. And so that might be your Office three sixty five. It might be, you know, whatever implementation you have that relays over LDAP.

But if you don't care, you just wanna see, you know, who's clicking links and what their credentials are, then we might ask for something that's not gonna potentially lock users' accounts.

So that might just be whatever homegrown application you have.

It might be WordPress. You know? It goes back to your threat profile and what your objective is. But that's gonna save us time. We can obviously, like I said, do the intelligence gathering, identify those login panels, but you could also just provide it to us, and we can spend more time building a a believable pretext.

Yeah. Something that's also really interesting about what you were saying there is, like, we can do that stuff. And for some of our customers, they are like, hey. We will give you a starting point where it's like, here's our company domain or something just as a as a, like, confidence builder for us so that we know that we're, like, focusing on that customer that's engaging with us. Because, obviously, like, we don't wanna attack everyone under the sun.

So that, like, starting point is important. But, also, one of the things that's interesting about what you said is customers may come to us, and we may ask for that stuff, and they may be they may only give us, like, a small piece of this piece of it where it's, like, like, here's some starting IPs and some starting domain and may not, like, give us a list of tons of users and stuff just to say, I wanna see what kind of information you can get. And that may be their objective. And I think that comes back to, like, we don't wanna lock our customers into objectives.

It's very driven by, like, what they want. It's just when customers are like, hey. Like, I am very concerned about this. I'm very cost conscious about, like, hey.

I wanna get the most out of this that I can. That's generally why we're asking for those login panels, those IP address, those domains, those list of users, that kind of stuff because it definitely helps us go, we definitely can do that. We've had a lot of success with finding that information out there. Lots of people have lots of success with that.

But if your focus isn't about, like, what can you find and it's more about what can you do, then, obviously, like, that's where that comes into place.

As we're talking about that type of thing and we kind of have mentioned objectives throughout this entire thing where objectives will dictate basically our actions and priority because there is so much that you can do externally.

If I'm a customer and I'm engaging with us, can you tell me a little bit about how I, as a customer, could get the most out of my pen external penetration test?

So the big one is approach us with an objective. If you already have an understanding what your threat profile is, you can we can work with you to build an action plan that, you know, gets the most out of your objective.

Also, if you come to us with a really constrained scope and you say, you just wanted to test this one IP address, it's probably not gonna be a very effective pen test. So if you allow us to target rather than one IP address, we might target, say, your entire organization or a range of IP addresses or, you know, just a wire scope. The more you allow us to target, the more effective it's gonna be.

And with that being said, right, if you come to us with a huge scope, we're gonna probably need a starting point. So it'll help if and this goes back to objective, if we can work with you and say, like, okay.

Yes.

We would like you to target everything in our organization, but these, you know, handful of endpoints are really, like, a a big concern to us or something we want you to focus on, that's gonna be great. It's gonna give us a starting point. It's gonna aid in building that objective.

And then, finally, just be there, you know, as a, as a contact. Right? If we have questions, be responsive, be willing to work with us. That goes so far, and it it really can make your life better because if we're worried that maybe we're gonna start locking accounts or we're going to impact your business, it's easier for us to just hop on a call and be like, hey. Should we stop testing here or is this okay? Do you want to see where this goes?

It's a lot easier to have a conversation than to break something and then ask for forgiveness.

Absolutely.

Yeah. And just to restate, basically, you said come with an objective.

Give us as much scope as you can because even if your objective is very concerned about, like, your crown jewels or you have servers that you're specifically worried about, there's a lot of trust relationships that go into those servers. So open ended scope, a starting point, basically, and then, like, being responsive.

And the thing that's interesting about all of those that I find is, like, there's this underlying principle in there where it's just communication, essentially. Like, when you communicate with us, when you have concerns with us, you're gonna have concerns all the way through the process if you're a customer. Right? Like, you just will.

And so one of the biggest drivers is, like, when you're starting out, if you have concerns about why I don't know how much a pen test is gonna cost, or I have a very specific tight timeline where I have to get it done, but before, like, the end of the year like, right now, that's, like, a big thing when we engage with our customers is, like, hey. I need that done before the end of the year kind of a thing. Like, you're gonna have concerns all the way throughout. And and one of the things that makes me better as a tester, you better as a tester, is this ability to communicate with our customers.

Because if we're just, like, insulated from our customers in this entire process of, like, this pen test, we aren't gonna improve because we don't know what your concerns are. Right? And then they'd like, you're probably not gonna get as much out of the pen test as you want, like, if you're not willing to communicate with us as well. And so whether it's, like, cost concerns or timeline concerns or even just like, hey.

Like, I need to know what's happening in regards to, like, I came with an objective, and I have these real world concerns of what can an attacker do. Like, communication is super important. So the first step in all of that is just start the conversation with us. And I I guess, like, here's a plug for our awesome we have awesome people all throughout the pipeline of, like, dealing with, like, setting up your pen test and helping that or wanna listen to your concerns, wanna listen to what you need.

So please either, like, call and ask questions. There's a lot of a lot of places where you can engage with us on the website, our our general support helpline, like, all of those. So communication is a really, really big thing, and and we wanna hear from you. So please communicate with us all throughout the process.

Now that we've said, okay. Like, communication is the starting process, and that can be kind of a, like, ambiguous if it's like, hey. Just, like, come with us with your concerns.

Like, there is a framework that we can apply to help help you go through. And then as we start doing that, things like conversation pieces will come out. So, Garrett, can you talk to me a little bit about, like, what the general process of setting up this external penetration test looks like?

Yeah. So the starting point is you are going to make that call that you mentioned. You're gonna call Yeah. Someone.

Someone will reach out to you and have a conversation about defining your scope. What do you need? Whether you know, that's where you're gonna decide, do you want an application layer? Do you want a network layer?

Do you want an internal? Do you want an external? I mean, someone is gonna work with you on figuring out what is going to fit your needs the best. And then once we've decided, okay.

We're doing an external pen test. We're gonna define the scope. What's the starting point? What is the objective?

What is in scope? What do you not want us to touch? Maybe it's a, you know, dangerous, it's important for your business, it can't come down, maybe it's just not valid for your threat profile, you know, we're gonna have a conversation. Someone is gonna work with you to figure out what that scope is.

After that is decided, we will send you a questionnaire.

It's just gonna be questions that get more information about the jobs that we're gonna be performing, and it's gonna go deeper into probably topics that are touched on loosely in the scoping call.

Once the questionnaire has been received, we'll get you on the calendar. We'll do the pen test.

You're gonna get assigned someone from our team. It might not be James and I, but it'll be someone to do your pen test, and you'll have a dedicated point of contact within our organization that'll be working with you throughout the process.

They're awesome.

Then we will we'll do our pen test. We'll write a report. We'll send you the report.

And then once you have validated the findings, it's worth mentioning that the report is gonna have, you know, vulnerabilities, steps to reproduce those vulnerabilities, and guidelines on how to remediate those vulnerabilities.

Everyone's environment is different, and, potentially, we're not gonna be able to give you a step by step, like, click this box, do this, whatever to fix the vulnerability, but we're gonna do our best to get you there. But after your your vulnerabilities are, remediated, you will work with your dedicated point of contact and get a date set up for your pen tester to do retesting, where they're gonna go in, they're gonna validate your efforts to remediate those vulnerabilities. And if need be, they'll give you further advice on how to remediate them, fully. Maybe they're not you know, maybe it's still vulnerable. The steps to exploit might be different, but there might still be potentially a vulnerability there. So we'll we'll work throughout the process to get these vulnerabilities fully resolved.

Awesome.

So just to restate back at you because I like restating, I guess. Basically, we'll define the scope. We'll We'll send you questionnaires after we've agreed. We'll do the actual test, and you'll have a point of contact to interact with. We'll give you a report, and then we'll do retesting essentially once you've had a chance to remediate the issues that we found.

One question I have while you're going through that if I'm approaching, I have this big question of timeline and how quick and all of that different stuff. And, obviously, like, I'm gonna give a qualifier of every test is different, and every timeline's probably gonna be a little different based off of some factors. So to talk about, like, the scope question, essentially, a lot of that is dependent on when you engage with us. Like like, if you don't call us, like, it can take a while to get that started.

Right? But, like, once you call us, there's gonna be stuff on, like, a customer side where it's like, okay. This we have this call to to scope, and we have this question. And now on our side, it's also like we have to send you out those documents and and schedule that question.

And so the two limiters on that side really are our availability and how quickly it takes to come to, like, an agreement of what you want us to test.

It it really just depends on that. So that can be kind of like a hard thing to guess at, but, like, once you engage with us, we're really quick to make sure that we can get you on our schedule to speak with our salesman so that we can get you scoped out and then start that process.

I've been on some of those sales calls, and they're really, really good to make sure that they get those documents out to you that after you've defined what we want, now you can look at it internally and and go through it. So we we try and make sure that you're not waiting on us to make those decisions.

As far as, like, questionnaires go, again, that can sometimes take a minute to go through when you're saying, okay. Here's your starting point, and here's all this information, and here are users. But, again, like, usually, like, we're very able to, like, match however quickly you're willing to move in regards to that. So once we get you on the calendar and we're waiting for those, usually, we're able to process those very, very quickly and make sure that we can get you in in a streamlined way.

As far as, like, the test goes, that's defined basically on the number of days that we've agreed for the scope that you have, and so we'll give you a a precursor for that. And, usually, those will go from anywhere from, like, three to ten days for, like, this specific type of job. That's not to say that we don't have customers who are like, hey. We're engaging with you for, like, several weeks because they say, okay.

Like, here's the external. We evaluate from there. Internal, like, those kinds of things. But, usually, like, from, like, an external perspective, that's generally the range you're looking at.

The reporting, usually, that will take about, like, after the test. I think it's, like, three to six weeks usually. And that's not to say, like, we can't get it in sooner. Again, like, that just, like, depends on, like, the QA process, making sure that we don't have other jobs that we're doing for you because of report delivery.

And then as far as retesting goes, like, we leave a window for you for three months in order to do that retesting, in order to make sure that you have enough time to remediate those and work with us, engage with us, and make sure that, like because in some instances, it's not like we only give you one retest. It's like you have three months. So if you either piecemeal and you're like, hey. I fixed this issue.

Can you test it? Or, hey. I fixed all of them, and it's like we validate it. And it's like, oh, man.

Like, maybe we didn't fix one. Like, it's not a, like, a one and done. It's like you have those three months to interact with us and make sure that that's what that's how we're going through it. That's everything that we had for today in regards to the content that we have prepared.

Now we're going to deal with some questions that we have. Please keep in mind that on the website, you can submit your questions, so please write to us. We wanna hear from you. If we don't get to the question that you submit, someone will reach out to you in order to answer the question that you have.

Please also keep in mind that that's not the only way that you can engage with us. We definitely have salesmen and support reps that wanna hear from you as well.

Customer service and interacting with you is a big part of what we do, and it helps us improve our process. So, please, whatever is easiest for you, email, on the website, calling in, please make sure to reach out. And, again, just to state, if we don't get to your question, someone will reach out to you directly.

Alright, Garrett. The first question that we have sent to us is what are the individual steps of an external pen test? And I know we kinda talked about this a little more in-depth. So just you can just, like, list them out, and that will probably answer what we need.

Cool. Yep. So we did we touched on this just a couple minutes ago, but, yep, you're gonna call us to define the scope of work. We're gonna send you the questionnaires.

You'll fill those out, get them back to us, and then we can get you scheduled. Once we've received those questionnaires from you, we will do the actual test, and we will go through the process of identifying and exploit vulnerabilities and reporting those vulnerabilities. We will issue that report to you, give you up to three months to remediate those issues, and then we will do retesting to confirm your remediation efforts.

Awesome. Very succinct. I loved it. Our next question that we got into us is how much does an external penetration test usually cost?

Yeah. So this one is, you know, complicated. It obviously depends on, your needs and the size of your environment.

That being said, on average, you know, historically, an external pentest runs anywhere between around five and fifteen thousand dollars.

But reach out, please. We'll get you over a personalized price.

Yeah. And yeah. And I think that's really good because, again, like, the size, obviously. So if if you have really, really big, like, it's probably not gonna be five thousand. So I like that you put in those two qualifier of your need and then also how big of an organization you have. The next question that we had come into us is how quickly can we get someone to perform a penetration test?

Yeah. So it it sort of depends, again, on how quickly you, you know, hop on the call, get started with us, and then how quickly you're able to get those questionnaires and those documents signed. But, typically, with around a week, seven to ten days, we can, get a call a kickoff call scheduled once those contracts are signed. And then, the standard scheduling after that, like, once the questionnaire is received and once we're getting you on the calendar to have your test done is around four to eight weeks.

But if you have, you know, pressing needs for a test or you have a strict deadline, you know, whatever, work with us, and we can attempt to get, like, an after hours test scheduled or something that is gonna fit your needs before that four to eight weeks.

The next question that we have come in is who should I coordinate with internally to make sure that a pen test goes smoothly?

So, obviously, you know, someone in your environment needs to know we're doing a pen test and needs to be prepared for that.

So whether that is, you know, system administrators, the people who understand your your exposed assets from a technical standpoint, whether that's project managers, people who understand, you know, why things are exposed and, whether or not it needs to be. You know, I think I think you need to coordinate with a suite of people, whether that is system administrators, project coordinators, or development teams or IT personnel.

Yeah. It depends on your your infrastructure.

Sure. And just to highlight, basically, like, what we found when we do pen tests, so there are about, like, three domains that people will work through of of people for that suite of people you were talking about. One that you had mentioned was the technical. So, basically, like, we are gonna ask you questions about scope, and if you can't answer technical questions for what type of subnets do you have externally, what kind of ASNs do you have, what domains do you have, what kind of technologies you're using, it's gonna be really hard to find success in that.

The next one you mentioned was basically like business operations, right, where you had mentioned project managers. Another one is like data owners, those kinds of things where it's like, hey. I'm in regards to this. These are the systems that I touch in order to make sure that we drive the business forward.

So, essentially, anything from a business logic that can also mean, like, we also engage a lot with, like, c suite people that are there. And it's like, hey. Like, this is from a high level. Usually, like, objectives will come from there.

So, again, like, if it's just like the technical side and they're and we're not getting the business side of what's driving the pen test, why do you want it, that can be kind of tough. And then the last one that I'd kind of, like, loop in is basically, like, your compliance or, like, incident response stuff. Because if something does happen, you also wanna make sure that they're aware so that we can save you work effort on your side or so that you can see if we did have an incident, how would we actually respond, what would we see, those kinds of things. So those three, IT, business, and then also, like, compliance.

The next question is, how will an external penetration test impact my environment?

We we said this a lot in our last talk Yeah. Maybe a month ago, but we strive to never impact your your business. Right? We're never gonna degrade the availability availability of your services, or at least we're gonna strive not to. Right? Right. Especially with, like, known vulnerabilities in software, exploiting those always contains a risk, and we will make the judgment call as to whether that risk is too large.

The same goes for when we are attempting to authenticate over VPNs or anything that goes over LDAP if you might have an active directory environment. We're gonna really try not to lock users' accounts. We're not gonna try to, you know, impact them in a way that they're not able to do their job.

Accidents happen. We're only human, but we're striving to never let that happen.

And we're also not gonna try to degrade the security. We're not gonna leave, you know, web shells out there on your exposed services that anyone on the Internet can access. Right? We're gonna we're gonna be following operation security best practices, and we are going to do this in a safe way.

Absolutely. One of the things that I also thought about, again, from our side our side and making sure that we are better testers and that we can improve our own craft that, like, we're doing this because we like it. Right? Like, and we're doing this because we wanna make the world, like, a safer, better place where people are empowered to be confident engaging with these businesses where it's like you're protecting my data, you're doing your due diligence, those kinds of things.

And so from our side, this entire time, we've kind of been saying, like, communication is, like, the undertone of what we're doing. It's not just communication from, like, a customer to us. It's also bidirectional. Right?

Like, it's not one direction. And so that piece also, like, objectives can come into to play where it's like, how is it gonna impact my environment? And it's like, if we find something you'd hinted at this, we're gonna make that call. But a lot of also making that call is engaging with our customer.

If if it's something we, like, we feel like this is gonna achieve the objective, we know there's risk associated with it.

And then we can engage with our customers and say, are you okay with that risk, or do you just want us to note it in there and we can, like, resolve it and we won't fully explore the impact? So, again, it's very based it's very based off of, like, the needs that you have and that type of stuff where, like, we're gonna make sure we're communicating with you. And, also, if we do feel like, like, we make that judgment call, like, it's too risky to do. We but, but, like, we feel like it'll do the objective. It will also generate communication with us, which comes back to the, how do I get the most out of my pen test? Be responsive.

Because if if we found it on the on, like, closer to the end of the contract and you're not responsive, we may miss the opportunity because without the green light and if it's risky, like, we're not gonna do it. So the next question that we got in is what qualifications do security metric pen testers have?

Yeah. So we hold various certifications, notably the OSCP, which is from offensive security, which is a known certifier within the industry, from TCM security. We have the PNPT, which is the practical network penetration tester, and the PJPT, practical junior penetration tester.

We hold, certified red team operators. So if you're looking for a more sophisticated, maybe more closely tied to a advanced persistent threat targeting your organization, we have people who are certified to do red teaming.

Basically, like, we just we have a lot of certs from a lot of organizations. So you had mentioned PortSwigger. We had mentioned offensive security. We don't just have, like, the OSCP.

There are other certs that are also involved there with, like, the OSWE. And, again, that comes, like, back to web application stuff. One of the other big ones that we have, because because we understand that technology isn't just like a silo, is there like, our department also has CISSP people involved because there are business logistic things that go into that. And then also these concerns of of essentially maybe, like, more compliancy type things that are going on.

And so, like, obviously, we wanna make sure that we're delivering a fully fleshed solution for people so that it's not just, like, just focused on the technical side and we didn't communicate well or couldn't speak to the impact or risk. So it's not just technical certs, like, more technical certs that you may have that are specific to hacking.

Again, there's also people have degrees, like like soft like software engineering or, like, IT or cybersecurity, like, those types of things we also have. And then there are also just general keeping up on, like, what's going on. So as far as, like, qualification goes, like, when we talk about, like, what's new in the industry, it's usually, like, reviewing research, and there may not be, like, certifications or those things that go into it. But there's a ton of, like a big part of, like, every week is is we have a meeting where it's like, what did you find this week?

What did you see this week? What's in the news? What's and so it keeps it it also keeps, like, the historical knowledge that you have in those certifications or in those basically degrees basically, those degrees as well. And then also, like, in order to keep current on what's going on, we review, like, research or breaches or different things that are going on to stay up up to date on techniques that we can use to make sure that we further your business goals.

The next question that we got in is what value can I get from performing an external penetration test? And the qualifier for that that they put in is basically, like, what kinds of remediation recommendations have we offered? So classes of vulnerabilities or that type of stuff.

Yeah. So we're going to identify, like like you said, classes of vulnerabilities, and we're gonna show in our report steps to identify, but also steps to exploit the vulnerability, which is gonna show you not just, like, the vulnerabilities that exist in your environment, but why they're important, Why do you care about this vulnerability? What can an attacker do with it? And then to that qualifier, steps to remediate, each vulnerability within the report is going to include guidance on how to remediate within your environment.

And like I said earlier, then we may not be able to tailor fit it perfectly to your environment because we are an outsider looking in. We don't know all of the, you know, moving pieces within your environment. We're gonna do our best, though. We're gonna try and get you as close to remediate remediate as we can.

And then as part of that, we're gonna do that retest that we offer, and we're gonna validate that your efforts to remediate it have been successful and that an attacker can no longer exploit that vulnerability.

Absolutely. And that's that's a lot of stuff in regards of, like, types of things that we've we've given, and those are really good answers. And, usually, all the stuff that you talked about comes back to three questions that usually can be answered. One of them is basically, like, what can an unauthenticated low privileged user do?

Base and then also, like, what what is available out there coming back to the discovery piece of subdomains or physical infrastructure or even, like, credentials in regards to, like, breach information or stuff that your employees are putting out there that you're not aware of. And then the last one essentially is, like, how can you use that information and what could like, based off of, like, your objective. So that type of stuff is what that those classes of vulnerabilities will be used to answer. And usually, white people will engage with us because it's like, I don't know what an authenticated low privileged user could do, or I don't know what's out there or any of those. And those are just, like, the most common. Obviously, there are more questions that we can answer with the information that we provide or the findings that we have.

The next question that we had come in is, how do I know which type of penetration testing I should perform?

So that's gonna come back to just giving us a call and having a conversation with someone who can, you know, look at your environment, look at, you know, your objective, look at those concerns that keep you up at night, and aid you in making an educated decision on what's going to provide the most value to you.

Absolutely. And I I was I'm very the the webinars we've been doing seem to have a theme. The last one obviously had one, and this one seems to be communicate with us, engage with us, because I liked your response where it was like, how do I know? And it's like, obviously, a mixture of your concerns and the type of services that we offer are going to decide what you need and drive that forward. The other thing that also is, something that will probably do that is how much time are you willing to invest into what we're doing.

And then the last question that we had come in is, how do I prepare for an external penetration test?

I mean, Beyond just giving us a call and getting the conversation started.

You know, know what you have exposed. Do that asset discovery.

Know what services are exposed and what their associated versions are.

Train your users on password policy. You know, make sure that they're using a password manager, that they're not reusing passwords, that they're not using predictable patterns, that, you know, all these things are in place, that would make an attacker's life difficult.

Yeah. And while you're talking, I also had one thought was basically, like, if you've made it to this question, you've started it. Right? Like, you're preparing well.

Like, consuming content that we create is is something that is super, super important to us and coming back to, like, we have really, really great people that are working. Basically, we have teams internally that are all they're trying to do is make sure that we have content that answers the questions that you have. So if if there's a type of content that you want to hear from us or the other questions that you have, again, that's why it's important to please engage. Give us a call, engage with our website, ask those questions on our website, email us in, and we'll make sure that they get to those teams so that they can create content that you're interested in consuming.

Also, I'm just gonna give a quick plug where it's like, how can I prepare for a test is also, like, coming back to that content is there are lots of of different things that we're doing to make sure that you can prepare in very gentle ways or kind of set your own expectations?

Our podcast is one of them. Super huge. We put a lot of work into that to make sure that it's up to date information and and very applicable to the types of things that we're doing as a company. Blog posts, we send those out.

Emails telling you about upcoming events that we have or that we're putting on or different things that are that we're interested in. Webinars, these types of things. So just engage with us, and you'll find a lot of that stuff on our website. So if you have a question of how can I prepare, we do a really, really good job of making sure that we take those questions that you have and make sure that they're in the form of repeatable content that you can consume?

And, again, also coming back to, like, we're recording this webinar. So if you, like, have this you watch this and you're like, man, I really that felt like that was, like, a really good explanation of what this company does. Please feel free to share it, because there are other people who have questions about how can I prepare? They have maybe anxieties about, like, I'm looking for a pen test, but it seems like a really big thing because I've never done one before or maybe I, like, I've had a bad experience and it gets it it's a way of of of helping us interact with each other to get a feel of, like, who we are as testers and then also who we are as a company to help address some of those concerns or even just to put our name out there.

So I guess what I'm trying to say is thank you for taking the time today to make sure that you engaged with us. And it and and that's the last question that we had come in that we have time for. Again, if we didn't get to your questions, someone will be reaching out to you. And if you want maybe a more expedited way, please just feel free to email, call, engage with us in whatever medium makes sense for you.

Thank you for your time. This is James Farnsworth and Gary Adler signing off.

Interactive Penetration Testing Timeline Checklist

Download

Get Quote for Penetration Testing

Request a Quote