What Can Go Wrong On An Internal Penetration Test?

The majority of the time, an internal penetration test is conducted without any issues arising. However, there are a few things that can go wrong on an internal penetration test that deserve some consideration. In this blog, we will explore what can go wrong on an internal penetration test and what steps you can take to help prevent these issues.

So… what can go wrong on an internal penetration test and what can I do?

Systems can go down

Old systems can cause things to go wrong on an internal penetration test
Legacy systems have been known to go down after even light scanning activity during an internal penetration test.

This could be caused by misconfigurations, an old server running an unsupported operating system, or a particularly bad vulnerability. While good penetration testers will tell you that we’ll do everything in our power to prevent taking something down, there is always some level of residual risk with taking a black box approach to testing and actively exploiting vulnerabilities. But you want us to do this, as we explain here! Whatever issue causes a particular system to crash is something that you want to know about, to prevent it crashing during an unmonitored period.

What you can do: If there are any old or particularly sensitive hosts in scope, let your penetration testing team know during the project initiation meeting when discussing the Rules of Engagement. If there are particularly critical systems that could cause significant harm to your business if they went down, consider having the testing on those performed after regular business hours or during maintenance windows.

Data Corruption

This issue can occur due to security control failures or certain kinds of vulnerabilities. If there is a SQL Injection issue, placing a single quote into a field could modify or drop data in your database. You’d definitely want to know about this issue, but only after your rage subsided from potentially having to restore portions of your production database. Again, in anything but extreme scenarios, experienced penetration testers can avoid database modifications but the potential does exist.

What you can do: Prior to testing beginning, it’s a great idea to double check your organizational back-ups and restoration procedures. I mean, I’m sure you’re doing that on a regular basis anyway, right?

We may find that you’ve already been compromised

There’s a great saying in the security community that there are two types of organizations out there, those that have been breached and those that don’t know they have been breached. While not every assessment, it has happened that we discover an organization has already been compromised during testing. I wouldn’t necessarily classify this as a potential problem, but it’s important to understand that it does happen. Should this be the case, we will immediately stop testing and notify our emergency point of contact about what we’ve found. We’ll help you in any way we can to resolve the issue, and once you’ve given us the OK, we’ll proceed with testing where we left off.

What you can do: It’s a great idea to have a continuous monitoring process that looks at systems, event logs, and alerts on a regular basis to identify potential breaches and security incidents. You can help prepare for issues that you’ve missed by reviewing your organizational Incident Response policy and making sure you’ve exercised it recently.

Now you’ve scared me, I’m not sure I want this internal penetration test.

It’s not as bad as it sounds. As mentioned above, these issues don’t happen often. But with some proper planning and good security hygiene, you can help make sure they don’t happen to you. As penetration testers, we want to do everything we can to set you up for a successful penetration test and prevent any potential disruptions. After all, one of the major benefits of a penetration test is to find and fix issues before they cause problems for the business.

For More Information on Internal Penetration Tests, Check out our Guide!