Infrastructure Penetration Testing: A Guide for MSPs

Infrastructure penetration testing is a manual security test of the systems underneath your client's applications: the servers, firewalls, routers, switches, hypervisors, directory services and cloud plumbing that everything else runs on. Applications get tested constantly. The infrastructure holding them up usually does not, which is exactly why attackers go there. MSP Pentesting runs these engagements under your brand, channel-only, so you can sell the service without hiring an infrastructure security team.

Here is the part most MSPs miss. Your client probably has had a web app tested. Their SaaS vendor tested theirs. Nobody tested the domain controller, the hypervisor, the backup server, or the flat VLAN that connects them.

That gap is your opening.

What infrastructure penetration testing actually covers

The name gets used loosely, so let's be specific. An infrastructure test targets the layer below the application, and it usually spans four areas.

• Network devices. Firewalls, routers, switches, VPN concentrators. Default credentials, weak management interfaces, outdated firmware, and rule sets that quietly permit far more than anyone intended.
• Servers and hosts. Windows and Linux systems, their patch levels, exposed services, local privilege escalation paths, and the service accounts nobody has rotated since the original build.
• Directory and identity. Active Directory in most cases. Delegation problems, Kerberos weaknesses, over-privileged accounts, and the path from a standard user to Domain Admin.
• Virtualization and cloud fabric. Hypervisor management planes, storage networks, cloud IAM roles, and the management interfaces that were supposed to be internal only.

The point of testing them together is that real attacks cross those boundaries. A tester who only looks at one layer misses the chain.

Infrastructure testing vs a network pentest

These terms overlap and vendors use them interchangeably, which makes scoping conversations messy. The practical difference is depth and scope.

If your client asks for a network test and their real worry is "could someone take over our environment," they want infrastructure testing. Scope it that way and the report answers the question they actually asked.

What testers find, over and over

The findings repeat across almost every engagement. That consistency is useful, because it means you can predict what a client's environment likely looks like before anyone tests it.

• Flat internal networks. One compromised workstation reaches the file server, the backup appliance, and the domain controller. Segmentation exists on the diagram but not in the switch config.
• Management interfaces where they should not be. Hypervisor consoles, iDRAC and iLO, switch admin pages, and backup consoles reachable from the general user VLAN.
• Credential reuse across tiers. The same local administrator password on every server. One dump, and the tester owns the estate.
• Service accounts with far too much. Domain Admin rights granted years ago for a migration that finished, and a password that has not changed since.
• Backups as the soft target. Backup infrastructure reachable and weakly authenticated, which turns a contained incident into a ransomware event with no recovery path.

None of these are exotic. All of them are findable in a manual test and invisible to a scanner, because a scanner reports open ports rather than the chain those ports enable.

Why scanners do not cover this

A vulnerability scanner is genuinely useful for hygiene. It is not an infrastructure test, and the difference matters when your client is deciding what to buy.

A scanner tells you a host is missing a patch. A tester tells you that the missing patch on a print server yields local admin, that local admin gives up a cached service account, that the service account has delegation rights, and that the chain ends at the domain controller. Same environment. Completely different report.

The chain is the product. That is what a manual tester produces and a tool cannot.

How the engagement runs

A well-run infrastructure test follows a predictable arc, which makes it easy to explain to a client who has never bought one.

1. Scope and authorize. Agree the ranges, the systems, the testing window, and what is explicitly out of bounds. Get written authorization before anything starts.
2. Discover. Map what is actually there, which is regularly not what the documentation claims. Forgotten hosts are common and they matter.
3. Test and chain. Work the findings the way an attacker would, combining small issues into real paths rather than listing them separately.
4. Prove impact. Demonstrate what an attacker reaches, with evidence, and stop short of anything destructive.
5. Report and retest. Deliver findings ranked by real risk, with concrete remediation, then retest once the client has fixed them.

That last step carries more weight than people expect. A report saying "we found five issues and here is proof all five are now closed" is far stronger evidence than a list of problems. It also gives you a natural second engagement.

When your client needs one

Timing sells this service better than fear does. The moments that genuinely warrant an infrastructure test are easy to spot.

• Ahead of a SOC 2 or ISO 27001 audit, where an assessor wants evidence that controls were tested rather than documented
• After a migration, a data center move, or a cloud rollout, when the architecture changed faster than the documentation
• Following an acquisition, when two estates got connected and nobody has tested the join
• At cyber insurance renewal, where insurers increasingly ask for testing evidence rather than a signed questionnaire
• After an incident, to find out whether the original path is genuinely closed

How MSPs deliver it without hiring specialists

Infrastructure testing needs people who have broken this kind of environment before. Hiring them is expensive and keeping them busy is harder, which is why most MSPs never build the capability and quietly lose the work to a security firm that then owns the relationship.

The channel model solves that. You scope the engagement with your client, hand the testing to a partner who works only through the channel, and the report comes back under your brand. Your client sees your logo. You keep the account, the margin, and the trust, and you never staff a test team. That is what white-label pentesting exists to do, and it slots alongside the rest of your security stack rather than competing with it.

If you are already running assessments for clients, an infrastructure test is the natural technical layer under a risk assessment. The assessment says where the risk probably is. The test proves which parts are real.

What a good infrastructure report contains

The report is the deliverable your client remembers, and it is where a lot of testing firms quietly disappoint. If it arrives as raw scanner output with a logo on the cover, it damages your brand rather than building it.

Four things separate a report your client acts on from one that sits in a folder.

• Scope and method up front. What was tested, what was not, and how. An auditor needs this to judge whether the evidence covers the systems in their boundary.
• Attack paths, not just findings. Show the chain from initial access to impact. A list of twelve medium findings is far less useful than one narrative proving how three of them combine.
• Severity tied to this environment. A CVSS score is a starting point, not an answer. A medium on an isolated test box and a medium on the box holding backups are not the same risk.
• Remediation someone can execute. Specific, ordered, and written for the engineer who has to do the work on a Tuesday afternoon.

Add the retest evidence and the report does double duty. It fixes the client's security and it proves the fix held, which is exactly what an assessor or an insurer wants to see. For a sense of the structure, our pentest report template shows how we lay these out.

Frequently asked questions

What is infrastructure penetration testing?

It is a manual security test of the systems underneath the applications: servers, network devices, identity services, virtualization and cloud fabric. The goal is to find how far an attacker gets once they have a foothold, not just which ports are open.

How is it different from a vulnerability scan?

A scan lists known issues on individual hosts. An infrastructure test chains issues together to prove real attack paths, and validates which findings actually matter. Scanners support hygiene. Tests produce evidence.

Internal or external?

Both, and they answer different questions. External tests what an attacker reaches from the internet. Internal tests how far they get once inside, which is where most infrastructure findings live. If budget forces a choice, internal usually surfaces more.

How often should a client run one?

Annually for most, and again after any significant architecture change. Compliance frameworks generally expect at least yearly testing, and a major migration invalidates the previous result.

Can an MSP offer this without an in-house team?

Yes. Scope it with the client, deliver the testing through a channel-only partner, and hand over a report carrying your brand. You keep the relationship and the margin without carrying testing payroll.

The bottom line

Your clients' applications get tested. The infrastructure underneath them usually does not, and that is where the paths to a full compromise live. Infrastructure penetration testing finds those paths, proves them, and gives your client evidence they can hand to an auditor or an insurer.

You do not need to build a test team to sell it. Scope the engagement, deliver it under your own brand, and keep the client relationship where it belongs.