3 Fundamental Pen Tests Every Organization Should Run

Introduction

1. Presenter's Background 

- [Bob] Today we are going to talk about three fundamental pen tests that we feel every organization should have be running. My name is Bob Erdman, and I will be the presenter today. I'm the senior product manager here at Core Security for our cyber threat division. So in that capacity, I work really closely with both our customers and our engineering teams to make sure that we are building the products and the features that help you make your IT simple and make your IT lives better. I work in both our offensive and our defensive solutions. So everything from our pen testing and threat hunting tools to our anti virus in our SIEM solutions.

2. The Purpose of Pen Tests

So when we're talking about pen tests, you know, what we're really talking about is an attempt to evaluate the security of our infrastructure. Really by safely trying to exploit vulnerabilities and flaws, and these vulnerabilities can exist in operating systems, services, or applications, and they could even be things that we're trying to test against like improper configurations or risky and user behavior. And we're really using these pen tests to validate the efficiency of our defensive mechanisms, as well as how tightly our end users might be adhering to our security policies. And typically, pen tests, you know, they're being performed either manually or with automated technologies, and we're systematically trying to compromise servers and endpoints, and web applications, maybe even wireless networks or mobile devices. So we're looking for potential points of exposure.

Once these vulnerabilities have been successfully exploited in a pen test on, and then we can go to other subsequent exploits, try and get to other internal resources who might be pivoting and trying to get to a specific system or a specific outcome for the enterprise. And we're really trying to incrementally keep achieving these higher levels of security clearance and elevating our privileges and getting deeper access to the assets and the information. You know, so we wanna basically get into a system, we wanna escalate our privileges as high as we can go, we wanna move laterally around the network as much as we can and try and gather all of the information that we've been tasked with gathering. And it might be helpful to think of pen tests as trying to see if someone can break into your house by doing it yourself. I mean, it's a really simple example, but instead of checking the windows and the doors, you know, pen test is going to check servers and networks and web applications. Any information about any of these security vulnerabilities that are successfully exploited in these pen tests, is typically aggregated and presented to IT and network system managers, and that way we can help those professionals make strategic conclusions and prioritize what they're going to be needing to remediate. The fundamental purpose really of this testing is to measure the feasibility of systems or end users being compromised, help us evaluate our risk, what kind of consequences might occur if we have an incident so that we can take proactive action.

3. Vulnerability Scanner's Role in Pen Tests

So if somebody is able to compromise system X, what is the risk of damage to our enterprise? What might be our monetary outcome if somebody was to get from that system to another system, to our critical data? And one question we get asked here at Carlisle is, is what's the difference between pen testing and vulnerability scanning? Aren't they kind of the same thing? And really they're not. Vulnerability scanners are automated tools that examine an environment and kick out a report of all the vulnerabilities that they uncover. So often you'll see these listed as CVE identifiers, information on known weaknesses, and you may uncover thousands of vulnerabilities across an enterprise. You know, there may be tons of severe ones that need further prioritization, and scores don't necessarily account for risk of each individual asset. And that's really where penetration testing comes in. So I may get a huge list of vulns, all these things I see that you should have patched last week but really what's the risk to the business? Which of those systems is the most risky to us? Which one do I need to prioritize? If I can't barely get through the level 10, nine and eights, what about all the seven, six, five, four, three, two, one levels? You know, which of these are really important to me and how do I help to prioritize out?

Vulnerability scans can provide a really valuable picture of what are the potential security weaknesses in the organization, but penetration tests that can then add that additional context, seeing which of those vulnerabilities can be leveraged to get access within the environment, and help you prioritize your remediation plans based on what's the most risky tier environment, not necessarily what's the highest score on a CVSS chart because priority 10 on CVSS that can't be exercised is not going to be nearly as risky to you as maybe a priority six that is easy for an outside attacker on the internet to exploit, and then from there pivot deeper into the environment. So we can really think of the difference between vulnerability scans as kind of a read-only versus read-write method. You know we're scanning for vulnerabilities with the vulnerability scan, and we're not acting on them, we're just reading, determining if there's a potential vulnerability kicking out a report. We're pen testing, we're going to be more of that read-write type method. We're going to be going in, attempting to exploit those vulnerabilities and then maybe having to take additional actions if we're successful against the target, which could result in remote code execution. It could be privileged escalation, it could be pivoting and moving laterally to another set of systems or another set of networks, and then repeating those same exercises to help identify where that big risk potential is for the vulnerabilities that have been seen.

4. Survey Responses: Most Common Concerns & Reason for Pen Testing 

In all these, earlier this year we conducted a pen testing survey with nearly a thousand respondents from across the world, and what we saw coming up as the most common concerns were phishing, misconfigurations and poor passwords as entry points, and pen testing was a really desirable way to test for those risks related to that kind of you know, user error, people getting tagged with phishing or people just not following good security hygiene with things like poor passwords and poor configurations. And about 35% of the respondents also were concerned about lost or stolen devices, and orphaned accounts and some other things, and these results really align closely with what we hear on a daily basis. Phishing continues to be the most common and effective way for attackers to gain access to systems. And while there are tools that can help prevent some of these things like identity governance for stolen accounts, a lot of this stuff needs to be solved through training and showing the importance of retaining, retesting, making sure that our efforts are effective. You know, like with phishing, for an example, people are getting phished continually. Now with work from home people are getting phished on their home network as well as your corporate email accounts. All of these things are potential areas of compromise that we need to train our users against. And we saw a pretty even balance about why people are running pen tests. 70% reported that they performed for part of a vul management program.

So what we just talked about, I wanna take my identified vulnerabilities and get a better understanding of where the risk lies within that report. And almost the same amount for increasing their security posture and for compliance reasons. And with many organizations, you know, they're pen testing for multiple reasons. So we had almost 100% indicating the pen testing was at least somewhat important to their security inside of our survey. And misconfigurations can also happen in many different circumstances. For admin practices, lack of change management procedures, many times what we'll see is things are deployed with default settings and simply people forget to go back and adjust those after things are set to go live. And, you know, we're not trying to knock on IT teams, they are buried right now. It's even worse than it was now that everybody's working from home and we're trying to light up VPNs. We're trying to expose more services to the outside so our users could have easier access to our corporate environment. And with all of these software upgrades and migrations and new implementations, it just creates situations where, you know, accidentally we might forget an attack factor, and that can be utilized by an attacker to gain access to our systems. And that's where we see again penetration testing gives us a way to exercise all of these different things. And then we can come around and make sure that we're testing for our unpatched vulnerabilities, making sure our password policies are good, and, you know, we can't be susceptible to brute-forcing or dictionary tax.

So the purpose of our penetration testing is to better understand where all these potential vulnerabilities lie that may not be related to a patch. So we're going to test, we're going to see if we have missing patches. I can exploit you 'cause you didn't put patch X on your system in time, but I can also exploit you because you had poor password practices, or you forgot to lock down this port in your configuration and you left it open where I can now exercise that and get into your system. And, you know, it's really tempting sometimes when we look at this pen testing engagements to just say test for everything. And a lot of times what happens then is that you scratch the surface on a number of different things and you sacrifice getting deeper into some of the more important things. Getting more in depth with a few areas, clear objectives in mind, and we wanna make sure that we can achieve really good objectives and pinpoint our weaknesses, and there's many different types of pen tests out there. You know, as we look at the things that we work with, you know, web application testing, network security, cloud environments, hybrid cloud, people fully up in the cloud, IoT is one that gets missed a lot. All of the things that are now interconnected into your environment. Routers, security cameras, smart devices, if you have users that went home now and are now working from home like most people have, now they have their home Wi-Fi router that they are connecting through to your network. That IoT router is now essentially becoming an edge device on your network when they VPN in or when they're coming in and using your exposed services in your devices.

Three Important Pen Tests to Consider

1. Overview 

So there's a variety of these tests that can fall within all of these different categories. And today what we wanted to do was focus on what we see as, you know, three of the most important ones based upon the experience that we've had with organizations over the years. You know, what are the ones that we really take? If you haven't done anything, at least you should be looking at doing these three things to help protect your organizations. And the ones that we really believe that we should be prioritizing are vulnerability scan validations, web application testing, and there's tons of ways that we wanna test our web apps, OS, top 10 and others. We're really focusing on SQL and command injections, and then doing phishing against your employee work base to make sure that they are prepared to not click on malicious phishing examples.

2. Vulnerability Validation 

And vulnerability validation is a great starting point to begin testing internally. And the reason is that we're going be connecting identified vulnerabilities with the exploits that may exist for those vulnerabilities. And that's going allow those vuln management teams to determine if the scanning data that they're relying on for patching remediation, number one is accurate. And then this can help them prioritize their patching program while we're also understanding what those risks are within our environment. Web application, you know, testing can be difficult, it's definitely necessary though. Applications can lead to data loss that can give us entry point into the network. Many times these applications are public facing and they have databases with critical information tied to them on the backside, and this can create a situation where, you know, malicious inputs can be used to harvest information from those databases, or possibly even a misconfigured web application or web server can lead to remote code execution and take over of the servers themselves. And then of course, there's all of the things related to phishing. We know we're continually getting spam with phishing emails, malicious attachments, malicious links, it may be malicious forms trying to harvest users typing in their credentials. All of the different ways people are trying to target our end users to get access to our systems. And when we're thinking like an attacker, you know, we're really identifying likely attack paths to our crown jewels. And hopefully, we've already gone through an undertaking and an effort to identify what are our most valuable assets and data, because we wanna know what's most valuable and important for us to protect. You know, if an attacker comes after us, what are they going target? How might they reach the systems? And you know, what data would then be the most value to them? And attackers may target externally facing systems and then use them as footholds to pivot deeper into our environment.
 

And vuln scanners are able to identify a variety of systems running on the network, clients, physical and virtual servers, databases, devices, printers, et cetera. And those identified systems are then going to be probed for different attributes, what OS would open ports, seeing what software might be installed, how systems are configured, and then that information is used to associate what those known vulnerabilities are on those systems, so the ones that we scan for. And in order to perform that, those vuln scanners then have a huge database that contains a list of all of these publicly known vulnerabilities. And we can really greatly enhance those through penetration testing. So these scanners can cover thousands of possible vulnerabilities, and then we wanna make sure that we're not just prioritizing our remediation based on simply us, rating system. You know, scores can help with efforts but they don't really show the true risk posed by any given vulnerability. It's going to depend on some additional factors that are generally out scope for those risk ratings that are coming through those scanners. And so we may see a vulnerability that only has a moderate risk score, but if I can use that as a pivot point and then get to other vulnerable systems or resources, it can really have significant consequences on our organization. So moderate vulnerabilities may be just as dangerous. If not more so than one rated severe, that's much harder for an attacker to exercise, and we can get that vital context by using pen tests.

So once we have identified those vulnerabilities, we need to decide what to do with them. Are we going to remediate them? Are we going to mitigate them? Or are we just going to accept the risk? You know, as we kind of validate with the pen tests. So if we take a tool like Core Impact in part a vulnerability scan into that, and then pivot and try and exercise those different vulnerabilities by exploiting them, you know, we can know those true risks that they pose and, you know, is that vulnerability really true or false? Vulnerability scanners are pretty good. But the false positive rate is not zero, there are occasional false positives. We wanna make sure that we really know is this something that could be directly exploited? Can it be exploited from the internet, from outside? Can it be exploited from a malicious person inside? How difficult is it to exploit this vulnerability? If it's a super hard to exercise, you have to have a whole bunch of very specific factors in place. For me to exercise this, that may not be as higher priority for us as something that is very easily exploitable, it can easily be used to pivot into our network. What is going to be the business impact if we expose this vulnerability? That vulnerability out on the edge web server in the diagram may not show as a super big deal to us in our scoring system, but I can use that now to get to the database, I could use the database to get to the print servers, I can use the print servers to get to the PCI. Because people use the same password on the PCI and the non PCI side of the network and we do see that all the time, where I can pivot from one enclave to the other and now I'm in the critical data. So we need to know where are our ways to get to these different types of systems and what kind of risks do they pose. And that's why we think vuln scan validation is a very important part of people's overall security and security exercises.

3. Web Application Testing 

The next one we wanna talk some about is web application testing. Accessing the security of our web applications by targeting pages, targeting URLs, and this can be fairly complicated to do, and not every organization has people with the knowledge to do this. The ones we really wanna focus on SQL injection or SQLi by targeting vulnerable software interfaces where servers either receiving or responding to requests. A very simple SQL injection context is down there at the bottom. When you're prompted as a user ID and I'm expecting one, two, three, and then I'm going to kick back all the data coming corresponding to the user with one, two, three in their ID field, if I'm not protecting myself against additional things being entered in that field, I may enter something like one, two, three or one equals one. What happens now is that the backend service, when it runs its command to the database says I wanna look for ID one, two, three, or I've just wanna look and see if one equals one. Well, of course one is always going to equal one and now we have successfully matched everything inside of the system. It's a very simple example. There's other things that might be done there. If we're looking at OS command injection, I may see something like one, two, three, and then cut your password file. So dump out a list of all the users in the password stashes or different things like that. So we can tag this additional information into these fields, get the backend system to process it as if it was a valid command, and this may be administrative, it may be to deny service through the system, it may be to do an admin command on the backend database sub-system to maybe take it down or take it offline, or maybe to gain control of the web application server itself.

What we're really doing is simulating unauthorized attacks internally or externally to see if we can get access to sensitive data. If a program or service can be accessed from the web server, it can be a target to then. So CRM systems, e-commerce, websites, you know, many times these are tied to critical data through backend database service, which makes them very valuable targets. And we wanna identify unknown vulnerabilities in those systems, check the effectiveness of our security policies and controls. Make sure our developers have thought about this and that you can only enter a user ID of a valid type and a valid size and we can't add additional information on the back. Test for publicly exposed information systems, like firewalls routers and DNS services, they may have admin sites. You see it in the news happening occasionally even on cloud systems. Somebody stands up a management console, accidentally exposes it to the internet and now somebody can come in and try and brute force credentials on a management console and then come in with access to the systems like an administrator. And this helps us determine what are the most vulnerable routes that an attacker might take, what are the attack paths and what problems could be out there that would lead to data theft from our systems.

Typically, we see these application, web application testing scenarios done by someone that focuses solely on that type of testing. We do find, you know, there are unicorns out there where individuals that can do all these different types, but often pen testing teams will even have a focus member just for web applications, you know, instead of like network testing. And the reason being is a lot of skill needed to perform these web application testing. And that's where we think tools come in very handy for us because a lot of these techniques, you know, our program knowledge type basis, you need to know how to do SQL queries from the databases that becomes really front and center because we're breaking through a misconfigured or well-designed database through the web inputs on the applications. And there are a lot of generic inputs, generic techniques that can be performed on these inputs as well as things we can do inside of the URL fields. But a lot of organizations just don't have people with those skills or resources in house to perform those advanced techniques. So we can test these applications with external software stacks. We can do things like SQL injection consisting of query parameters via input in a program like Core Impact as an automated tool to help bridge those skills gaps.

So if we're going in and running exploit activities based upon these targets, we can collect them during network scanning and then we can go out and exercise them with automated machine techniques that know how to go in and run all of these different types of things. And there are even focus vulnerability scanners for web application side testing, and tools like Core Impact and others can even import those. So if you're running maybe a Burp Suite or an Acunetix, we can get beyond just SQL command injection and pulling other techniques from the OS top 10 and test all of those security risks. So cross site scripting, broken authentication, bad access controls, or input something from a web vuln scanner, like Burp Suite, and then pivot on that, just like we would a network vulnerability scanner, and trying to exploit the identified deficiencies to see where we can get. So again, we just wanna make sure that we're exercising all of these and what we see a lot of times these days as well as, you know, as everybody has moved so much remote, more and more of these services are being exposed to the internet, either for our customers or many times now even for our employees. If we don't want every employee in our organization hugging a VPN for everything that they do all day, we're exposing additional web services to allow them to connect directly from their outside systems or we may be enabling more mobile web application type access to that. Our customers and our clients can have easier access to, you know, our products. And again, that exposes more attack paths and more external services that these malicious people can be going after.

4. Phishing 

And then we run into phishing. Phishing near attempts are nearly impossible to block from every inbox. You know, they're incredibly common way that attackers are gaining access to employee credentials and organization system. And when we, as we mentioned earlier in that survey, you know, better than 70% of our respondents noted that phishing was a top security concern. So organizations are getting to be really aware of the risks that these attack strategies can pose to us. And what we really like to see is that people are running phishing on a regular basis. Phishing simulations can be run to see what types of phishing attacks are tricking your employees, which employees are most susceptible to them and use these as part of social engineering pen tests as a valuable tool for education and awareness. And, you know, our primary prevention methods for our end user employees with phishing is really training. You know, we all deploy systems to try and strip out as many of these things as we can, but we know that they still get through. We know they still get through because we're seeing them in our inboxes and we're seeing breach notifications in the news on a regular basis.

There's a lot of different reasons you know, why we might be doing phishing. We might be doing it as part of a pen test. So I am trying to use this as a dedicated channel to compromise my organization as I test to see where I can get to, what information I can gather, or really for a different manner, which is for training our employees. And when we surveyed people on how often they're doing training, you know, we see a good number of people are doing on a regular basis, but almost 45% were doing it once a year or never. And we really don't think that that's often enough, we need to have a dedicated program in our organizations to do phishing training with our employees. There are lots of tools out there. Our Core Impact 10 testing tool can be used for phish training and awareness or for social engineering pen test to do this. But if you have not done any phishing training yet, we do have an e-course, multiple chapters to let you walk through getting started. Some of the things you need to be concerned with, what some of your options are and what we see as some of the best ways to do these phishing campaigns to be beneficial to your employees, 'cause there's a lot of things to consider. You know, it's fairly easy when you're trying to do it as a pen test. I'm going to go out, I'm going to try and gather all the options, gather all the emails, use my open source intelligence, and then make some targeted campaigns. But we wanna be a little bit careful in how we're doing that and what we're doing inside of our organization. You know, I can probably get everybody in my organization to click on an email. If I spoof my HR vice president or my CEO, and say it's some kind of a critical update that they need to read, they're all going click on it. That may not be very beneficial to the organization or to me to do that type of a test. We do not wanna be adversarial with our end user base, we want them to learn and get better with this.

So generally what we'll see is that we'll start using... If we're not doing a lot of Phish training today, you know, use something fairly to get. Let's do some training, let's teach people what to look for, hover over links, make sure it's not a doppelganger URL, you're not going somewhere that's not correct. You know, and then send them a test and see who clicks on it, see how they go. Using a tool we can then see who opened an email, who forwarded it to security, who clicked on the links, or put in some credentials that they shouldn't have. And then we can step up that knowledge. So the next time we run a test, we're going make it a little bit harder to catch. And the next time we run a test, we're going to make a little bit harder to catch. And then we have to also think about if we're doing this as part of a training simulation, you know, what happens if somebody does click on it? So if Bob clicks on three phishing emails in a row during the tests, then what happens? Is he going to remedial training? Am I just send him to a link that has a little PowerPoint to watch? Is he going to get auto-enrolled into the phishing education class that we're going to have on the next Thursday? You know, whatever the case might be, we need to also be prepared, you know, for what is happening on our consequences side? You know, we see people do fun shaving sometimes, a lot of times when we were all still in the office, you know, whoever failed the phishing test had to get donuts or had a pay for happy hour, things like that. You know, terminations probably not the best path. You know, that's really excessive, it has to be something pretty egregious if we're going to be looking at that. We really wanna educate our employees 'cause they are our best line of defense. If things get through our spam filters, they're going to get to our employees. Our employees need to understand and recognize what they are. And if we're using a tool then to go out and run these kinds of tests, you know, it's a great way for us to exercise these social engineering pen tests inside of our environment in a very low risk fashion for us because we control what's going on and we use all the same methods that our attackers would.

So I'm going to go out and I'm going to scrape from open source intelligence, like LinkedIn, and discover.org and other places, gather an email list and then I could send targeted messages to all my users, to specific users. I can do different things within the tools to try and exercise different paths, like getting them to click on a malicious document or getting them to click on a malicious link, or maybe I'm going to spoof a credential page and try and get them to enter credentials where they shouldn't have been entered and capture those. If I'm doing this as part of a larger pen test in my org, then I can take those captured credentials and it get someone to use, and I can spray those back into the environment and see where else an attacker might've been able to get to using those credentials. Where can I pivot now, based on Bob's logging information that he gave me in the fake form, and then where can I escalate from that to get deeper into the environment? So it gives us a lot of ways to make use of these things. If somebody clicks on that malicious document and they now gave you control of their PC 'cause we can essentially take over their browser, then drop a key log on their system, wait to see them log into a critical asset. Now see if we can harvest those credentials, pivot deep into our environment again. So giving tools that can do these types of things enables your security and IT staff to be able to do these types of tests continually rather than having to wait and rely on a third-party engagement possibly once a year or twice a year. You know, what happens in the intervening time between when my last pen test was run by another party and when they're going to come back and run one again? All kinds of things change in our environments. They're changing on a daily basis, sometimes on an hourly basis and we need to be able to keep up with these things.

5. Rapid Tests for Beginners, Manual Tests for Experts 

So that's why we think these are some of those, you know, really, really important tests that we wanna run. Vulnerability scan validation, you know, phish testing, phish training, and testing our web applications to make sure that we are staying as safe and secure as we can. And we believe we have a really great tool for that. We have market-leading Core Impact, gives us these multi-thread surfaces where we can use commercial grade exploits built in-house to test our networks, test our vulnerability scans, do our client's side phishing and client side testing, all in one tool set. Do security training and security awareness, have actionable reports built into the system, so when you're running these exercises you can immediately get reporting back out to help you take it to the security teams and help prioritize your risk and remediation efforts. And we can do this all in a single tool, a single console. What we really like is that all of the exploits that are built into the system and there are thousands of them, everything from operating systems to SCADA and IoT devices are built and tested. So we know exactly what's going to happen when you try and safely run an exploit. If it is something that could be system effecting like possibility of doing a DLS or knocking down a service, our end users are modified, and it has automation and manual modes built in. So if you are just getting started, we have rapid pen test automation that allows you to quickly be effective with just a few clicks going out, scanning your environment, harvesting data and start to pivot into your organization to prove where these risky assets lie. And if you are a more experienced professional, advanced manual mode lets you do a wealth of things on any system out there. We have thousands of modules built into the system that you can use to exercise everything from loading remote shells on systems to attacking a database and gathering database information to doing remote code execution with your own shell code and being able to adjust the exploit source to work the way that you want it to work. So we have a great demo that you can see. We can get you set up with a proof of concept environments where you can test this out on your own, but we think Core Impact is a fabulous tool and we hope that you will take a look at it, as you think about exercising some of these different pen tests that we talked about.

Q & A

1. Which Pen Tests Are Most Successful? 

I would like to open it up for questions now, if you have questions, you can put them into the questions panel and we will cover them for you here. Somebody did have a question on which pen tests do people see the most success with? That's pretty open-ended but you know, I think it really depends upon what their goal is in their exercises. You know, so we talked about three different ones that we might have here. You know, like out of those three, the ones that I see being used the most is probably the vuln scanning validation. There's so many vuln scanners out there. You know, everybody's got one, maybe three that they're using and being able to utilize that to help determine the riskiness of identified potential vulnerabilities in their system. For example, one common thing that we'll see happen as a workflow type thing. A scanner identifies a vulnerability. Somebody goes out and dumps the patch on the system and they hit Rescan, and now the scanner says patches, they're great. And it's looking to see that a certain file or a certain DLL exists, and if it exists, close it out.

What gets missed many times is that that thing is not actually enforced on the system until somebody bounces the system or bounces the service. So if you came back around and attempted to exploit that vulnerability, you would actually succeed, you succeed very easily because just because the file is on the server does not mean that the file is being used, and you're able to see that remediation efforts. So what we'll see then is people will run their vuln scan, validate what's open, go through their remediation efforts, and then a Core Impact actually has a replay button, and with a single click, you can replay that whole test, which will go back out and retest all of those vulnerabilities to see if the remediation efforts were actually successful in blocking the exploits that were being utilized to access the system. That's a great one that we see being used as a workflow all of the time.

Another thing that we'll see quite often these days, there's just a lot of M&A going on. People are acquiring competitors, they're acquiring competition, they're adding other companies to their portfolios. What do you do when you wanna bring on that other network into your environment? How do you know what they have is safe before you interconnect yourself? And many times we'll see people go out, you can send a jump box out with Core Impact on it, so you can afford to play that jump box into this new environment, access it through a web security interface, and do a network pen tested investigation on that remote network, and be able to tell if there's any critical things that need to be patched and remediated before you let them interconnect with your systems. So we see that being used quite often again as another way, especially in today's world where we're less likely to be face-to-face or locally in an environment. I'm seeing this product being used and utilized a lot is to send those forward deployment boxes out either sending a VM and having put it in their environment, sending something like an Intel NUC or a laptop out where people can spin that up. And then, you know, as a tester can remotely access that environment and run your tests.

The other place I see it being used quite frequently is for compliance efforts. People that are worried about GDPR or CMMC or PCI being able to run a test on a regular basis and prove to the auditors that you are compliant with security controls. So being able to start out in the non PCI environment enclave and see if you can compromise, escalate, play passwords back into the other environment, for an example and have now reached the PCI enclave and get access to those systems. Among many other hundreds of ways that you might try to access them, that's a very simple one. It's the one that we see actually being very effective. People use passwords over again a lot. We see people reuse passwords over again a lot between enclaves also, which is very bad security practice. If I can harvest credentials in the non PCI environment and then replay them into the PCI environment, many times I can get into the PCI environment and now I can take that over. And that's the same kind of thing that you're going to see an attacker do. You know, it lets us take those examples of how we might see an attacker coming after our enterprise, run that exercise ourselves to see if that attacker might be successful, close those gaps, close those holes, move on to the next one and see what the next way that somebody might be able to get in would look like. Any other questions?

2. How Can One Validate False Positives?

Let's see, we have another one here. All of it, how to validate false positive with Core Impact. I think that's very much what I was talking about with the first one. We want to attempt to exploit the identified vulnerabilities that come up from a vulnerability scanner. So utilize the Core Impact which was part of the question we have, I think there's 15 different scanners, Nexpose, OpenVAS, Qualys, Nessus Tenable, SAINT, down the list. So you can take that report. What comes out of that scanner imported either from the report or via API into Core Impact, and then click a Vuln Scanner Validation Wizard, and we will go out and attempt to exploit all of those identified vulnerabilities, show you which ones we're really able to be exploited and which ones aren't and give you that information. If you saw an open vulnerability come up in the scanner and we were not actually able to exploit that vulnerability because it's not actually an existence out there. And I've seen that a lot when I've used them a common one, I see a lot. I run a lot of these on Linux and I'll see, I get tagged for open SSL vulnerabilities, all the time. 'Cause you're not on the latest one because the vendor has backed parted the fixes into a different version of the binary, the binary is patched, it just doesn't say latest .X on the version number. And we can prove those things.

3. What's the Purpose of Netsparker Integration? 

We had a question come up about when integration with Netsparker is coming in. So we do work with Acunetix and we have also been talking with Netsparker. We are planning to integrate that here in early 2021. We do like to keep adding these on, especially, with input from end users such as this looks like to be. So we will be bringing Netsparker in as one of our web application style, vulnerability scanners alongside AppScan, and Acunetix, and Burp Suite and a few others. So we are continually adding integrations. So we recently added PlexTrac as a reporting solution integration, very here in the near future, honestly, in the next couple of weeks, you'll start to see an announcement come out. We are doing interoperability integrations with Cobalt Strike tool for people that are using that tool in their environments to be able to deploy Cobalt Strike beacons from Core Impact agents directly, and on the other side Cobalt Strike being able to tunnel exploits from Core Impact through the Cobalt Strike beacon interfaces to pop out at the end of being able to use exploits.

4. What's the Benefit of Scheduling Tests?

So there was a question that came in about a scheduled tasks. So we do have the option to set things up on a schedule inside of Impact. So if you are planning on doing something on a more continual basis or maybe an off hours kind of basis where you might not wanna be there, we can actually build out a testing plan and put it on a schedule. And the Core Impact actually exercise that testing plan over that schedule to be able to run your environment and run your results and give them back to you. Somewhat related to that, we have the ability to also create macros with the things that you would like to test essentially, step-by-step the different things that you would like to run. We have our wizards, rapid penetration testing, RPT wizards that we have included in the system that give you one step capabilities out of the box and just let you fill in a couple of blanks, like how big of a test I wanna run, how noisy do I want it to be, how detailed you want me to exercise some of these different things, et cetera.

You can basically build your own rapid penetration test macros by just grabbing the modules that you wanna use. So I might wanna fingerprint this with a certain end map configuration, and then I want to attempt to exercise a certain set of exploits but only if they are certain safety. So I don't wanna exercise anything that might knock down a service or do a DLS, I just wanna use the safer ones and then I wanna have the reports generated out for me or maybe I just wanna target a specific exploit. I wanna go and test my DNS servers against SIGRed and see which one of thems are able to be compromised and filter that down to a very tiny set of things that I wanna look at. So it gives you a lot of flexibility in there and how you want to configure and use the product as an example.

Contact Us

If you do think of anything else after the fact here, we are always open and you can simply email, [email protected] and we will be able to get back to you and answer those questions. There is also a lot of videos on how to use Core Impact in different situations out there and available for you to see in the demo list as well. And I'm happy hunting, and we'll talk to you all again soon. Thank you very much.