This blog post is for anybody who's interested in external pen testing basics, the types of things found when pen testing, and the process that you go through when completing them.
This blog is a summary of the SecurityMetrics’ Webinar “External Penetration Testing” hosted by Garrett Adler and James Farnsworth. Check out the video webinar here.
This blog post is for anybody who's interested in:
If you’ve ever wondered about what your business might look like in the wrong hands or what a malicious threat actor could do with the infrastructure that you have exposed to the global Internet, that's what we're exploring today.
Everyday it seems like a large company or organization is facing similar breaches to their security. Attackers always seem to social engineer their way in.
An attacker doesn't really care about your footprint if you’re a massive company or not. Your data is still good on the Internet, and they can still package up your data and sell it. Threat actors will still actively target you.
Threat actors will look for credentials that have been included in data breaches through tools, like DHash or Hunter.io, and they will attempt to reuse these breach credentials.
A big part of our external pen tests involve your users, seeing if they are following best cybersecurity practices and trainings. It's also a question of whether your people are still using weak passwords, ones that we phished from them to integrate with your active directory.
It's not if an attacker gets into your internal network, it's when, and how 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.
The discovery process isn't always exact when we go through and do these external pen tests. What we're looking at is:
We also start enumerating all of those elements, and it becomes very tailored to the point where when we do these phishing engagements, we get to see how people are going to react.
But we always communicate with the company the dates that we’ll be testing.
One of the things that's been interesting in our last two phishing engagements was to see how the different processes happened and how people escalated those incidents. Especially with phishing. And it's because, generally when you're using those turnkey solutions, you stop at one point of protection, and it leaves gaps that only explore the number of clicks instead of how a click led to a remote code execution, or how this click led us to that level of user's access and what that user could do. After all that, we have an internal foothold.
Once we have footholds and breached your external perimeter, we want to see what a low-privilege user can do within your environment. We want to ensure that the principle of least privilege is being enforced throughout your network. What that means is that users have the least amount of privilege they need to do their job for their role to continue to function, and there is not an ounce of extra privilege beyond that. So, a low privilege user should not be able to access your domain controller.
We are also trying to validate that multi-factor authentication is in use throughout your network. A threat actor shouldn’t be able to scrape credentials off DHash and if they log in to your VPN. They should have a second form of authentication that restricts that access. And the same goes for social engineering. If we call someone at your company, they should not just take our word that we are who we say we are. There should be a second form of validation or authentication. They should be verifying that you are who you say you are.
Part of our process is to validate your password policy. You need to train your employees to use something like a password manager and then back to multifactor. That all goes into the human side of things, but external is also technical. We’ll also validate that you have proper patching policies in place and that the services you have exposed to the Internet are patched to their secure versions. There can’t be any known vulnerabilities.
When we give recommendations, we respond to the issues we find, which are often based on the objectives that people will have when they come to us. There are instances where people have big exposures on the outside and there are a number of different attacks that we could do. We always tailor our fit to meet your needs. If we have that in mind, then it helps us prioritize.
Keeping good track of the assets that you are exposing to the Internet is vital. You need to know what is out there and what is exposed.
And along with that, you need to know what versions of that software are out there. As we said, we are going to test that you have a patching process in place, but you also need to ensure that you are doing your due diligence with your system administrators to routinely audit the software you have exposed and pass it to its latest version.
And that's where we come in as the penetration testers. We are looking at this from a threat actor's perspective. You need to lock things down.
After those five principles are implemented, you should keep up with them cyclically.
But we're only human. We make mistakes. An attacker is going to capitalize on those mistakes, and our role here is to identify those and help you in resolving those mistakes before an attacker.
The suggestions we’ll offer in our report about the vulnerabilities we discover will be fairly standard.
But where it becomes tailor fit to our customers is what specifically is found in your environment. This is what we have access to. Demonstrating the impact or the risk associated with that information will help you establish your remediation priorities.
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 through that, we can offer phishing engagement.
As we've mentioned before, we don't just send an email to everyone in your organization and document who clicked it and who didn't. We attempt to identify where an attacker could coerce someone to click a link, disclose their credentials, and where we can take that further.
All of that is just a starting point. Once we have those credentials, we see how far we can go with that.
We can also do asset discovery against your exposed services. We’ll attempt to identify additional subdomains and additional services that maybe you didn't know about or forgot about.
We can also identify services that maybe you knew about, but you didn't realize the implications of exposing those.
We can enumerate breached databases, look for exposed credentials, and see what an attacker can do with that. And then any vulnerabilities we find, whether it's a known vulnerability in an exposed service or an issue with your authentication protocol, we are going to exploit that in an ethical manner. Similar to how an attacker would, but without breaking your system.
We’ve mentioned focusing on the human factor with social engineering, but we're also going to focus on the technical factor.
As we go through phishing, we tie it based on what we discover and the objectives that you've given us. So it's more customized, and you also get to see the impact of how we use those credentials, and now we have a foothold.
We recently had a test where the organization's threat profile included several WordPress implementations, and they knew for sure that they had gotten breached 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.
During our discovery phase, we enumerated their sites, the valid users for each site, and the 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 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 targeted attack against that WordPress implementation where we could take users from other sites and credentials belonging 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.
And, also even though they had protections on the one WordPress server, the other one didn't, and we could do 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.
When we're doing our external penetration testing, we can social engineer our way in the way an attacker would by calling the help desk. By using social engineering, we get credentials or reset passwords; whatever will trick people into doing something that the attacker wants them to do. We might also do a phishing attack, send an email, get you to click a link, disclose your credentials, and then log in to a VPN. It was very similar to those big headlines. We were able to grab credentials, log in easily because multi-factor authentication was not enabled, and we were able to escalate our privileges because the principle of least privilege was not enforced in their network.
Obviously, in an ideal world, we'd be able to test everything under the sun, but sometimes we can't. A large reason is related to cost. 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.
That's where we can do a non-exhaustive 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 a web app test.
A lot of customers will request a black box test to explore the potential of things that are happening. If an attack starts from an unauthenticated or low access point, that's generally where externals shine.
Your starting point is a web application. When you put in a user's 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, if you were listening for that traffic, it basically gave you a foothold into all of that company's data without having to authenticate it all.
There’s a common question: “Are externals a good idea for me?” And some qualifiers are basically, do you have a large attack surface, and do you want to know what's possible?
We also have a service where we specifically test applications, and that is a more exhaustive and more in-depth service.
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?
We're going to 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, 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 Office365. It might be whatever implementation you have that relays over LDAP.
But if you don't care and you just want to see who's clicking links and what their credentials are, then we might ask for something that's not going to potentially lock users' accounts. So that might just be whatever homegrown application you have. It might be WordPress. It goes back to your threat profile and what your objective is. But that's going to save us time. We can obviously 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 believable pretext.
That starting point is important. Everything is very driven by what customers want. Whether they have specific attack concerns or cost concerns.
We want you to get the most out of this that you can. That's generally why we're asking for those login panels, those IP addresses, those domains, those lists of users, and that kind of stuff because it definitely helps us know what we can do. 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 what you can find and it's more about what can you do then obviously that's where that comes into place.
As we're talking about that type of thing, we have mentioned objectives that will basically dictate our actions and priorities because there is so much that you can do externally.
One of the best ways to get the most out of your external pen test is to approach us with an objective. If you already have an understanding of what your threat profile is, we can work with you to build an action plan that gets the most out of your objective.
Also, if you come to us with a really constrained scope and you just want to test one IP address, it's probably not going to be a very effective pen test. The more you allow us to target, the more effective it's going to be. And with that being said, if you come to us with a huge scope, we're going to probably need a starting point. So it'll help if and this goes back to objective, if we can work with you and establish certain things. It's going to aid in building that objective.
Give us as much scope as you can because even if your objective is very concerned about 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 have open-ended scope, a solid starting point, and then be responsive.
If you have concerns about how much a pen test is going to cost, or have a very specific timeline, you're gonna have concerns all the way throughout. But one of the things that makes things so much better as a tester is our ability to communicate with you consistently. The first step in all of that is to start the conversation with us. Come to us with your concerns.
There is a framework that we can apply to help you go through things smoothly.
The starting point with setting up an external penetration test is to make a call to us. Someone will reach out to you and have a conversation about defining your scope with the following questions: What do you need? Do you want an application layer? Do you want a network layer?Do you want an internal? Do you want an external?
Someone is going to work with you on figuring out what is going to fit your needs the best. And then once we've decided that we're doing an external pen test, we're going to 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 dangerous, it's important for your business, it can't come down, maybe it's just not valid for your threat profile, regardless we're going to have a conversation. Someone is going to work with you to figure out what that scope is.
After that is decided, we will send you a questionnaire.
It'll just be questions that get more information about the jobs that we'll be performing, and it's going to 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’ll 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.
Then we'll do our pen test. We'll write a report and send you that report.
And then once you have validated the findings, it's worth mentioning that the report is going to have vulnerabilities, steps to reproduce those vulnerabilities, and guidelines on how to remediate those vulnerabilities.
Everyone's environment is different, and, potentially, we won't be able to give you a step-by-step, but we'll do our best to get you there. After 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'll go in and validate your efforts to remediate those vulnerabilities. And if need be, they'll give you further advice on how to remediate them, fully. The steps to exploit might be different, but there might still be potentially a vulnerability there. So we'll work throughout the process to get these vulnerabilities fully resolved.
Two limitations are our availability and how quickly it takes to come to an agreement of what you want us to test. It really just depends on that, but 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.
As far as the test goes, that's defined on the number of days that we've agreed for the scope that you have, and so we'll give you a precursor for that. And, usually, those will go from anywhere from 3 - 10 days for this specific type of job.
The reporting can take 3 - 6 weeks usually. A lot of that depends on 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, we leave a window for you for 3 months, to make sure that you have enough time to remediate those and work with us, engage with us, and make sure that you’re all set.
It's definitely not a one-and-done thing. You have those three months to interact with us and make sure that you’re happy with how we're going through it.
We touched on this just a couple minutes ago, but: you'll 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 then 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.
This one is complicated. It obviously depends on your needs and the size of your environment. Historically, an external pen test runs anywhere between around $5,000 - $15,000.
It depends on how quickly you 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, within a week, or 7 - 10 days, we can get a kickoff call scheduled once those contracts are signed. And then, the standard scheduling after that is around 4 - 8 weeks.
Someone in your environment needs to know we're doing a pen test and needs to be prepared for that.
So whether that is system administrators, the people who understand your exposed assets from a technical standpoint, whether that's project managers, people who understand why things are exposed and, whether or not it needs to be. You need to coordinate with a suite of people, whether that is system administrators, project coordinators, or development teams or IT personnel. It depends on your infrastructure.
We strive to never impact your business. We'll never degrade the availability of your services, or at least we'll strive not to. Especially with 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'll really try not to lock users' accounts.
Accidents happen. We're only human, but we're striving to never let that happen.
And we'll try not to degrade the security. We're not going to leave web shells out there on your exposed services that anyone on the Internet can access. We'll follow operation security best practices, and we are going to do this in a safe way.
We hold various certifications, notably the OSCP, which is from Offensive Security, 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 an advanced persistent threat targeting your organization, we have people who are certified to do red teaming.
Basically, we just have a lot of certs from a lot of organizations. Many of us also have software engineering, IT, or cybersecurity degrees.
We're going to identify classes of vulnerabilities, and we'll show in our report steps to identify, but also steps to exploit the vulnerability, which will show you not just the vulnerabilities that exist in your environment, but why they're important. Answering questions like: Why do you care about this vulnerability? What can an attacker do with it? Then, to that qualifier, there are steps to remediate each vulnerability within the report, which is going to include guidance on how to remediate within your environment.
Bear in mind that 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 moving pieces within your environment. We are going to try and do our best, though. We'll try and get you as close to 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.
So that will come back to just giving us a call and having a conversation with someone who can look at your environment, look at 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.
Beyond just giving us a call and getting the conversation started? 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. Make sure that they're using a password manager, that they're not reusing passwords, and that they're not using predictable patterns.
If you’d like to get started with pen testing, use our penetration testing pricing calculator and find out how much to set aside. You can also talk with one of our experts to see if a pen test is right for your organization.
.svg)
