Infrastructure Penetration Testing: What It Covers and How It Is Scoped

Infrastructure penetration testing is a manual, authorized attack on the layer your applications run on. That layer is the network, the hosts, the services, and the identity systems that tie them together. An application test asks whether one product can be broken. An infrastructure test asks whether the environment around every product holds up when a skilled attacker pushes on it.

The scope questions arrive as soon as a compliance requirement or a customer questionnaire puts the term on your desk. Which hosts are in? Does Active Directory count? Is it one test or two? This guide answers them.

What infrastructure penetration testing covers

An infrastructure test works through four layers beneath your applications.

• The network. The internet-facing perimeter, firewall rules, VPN and remote-access gateways, and the segmentation between internal zones.
• The hosts. Servers, workstations, appliances, domain controllers, and the machines nobody patches because nobody remembers they exist.
• The services. Mail, remote-access portals, management interfaces, file shares, internal applications, and the older protocols still answering on the wire.
• Identity and access. Active Directory, the credentials that flow through it, the group policies and trusts behind it, and the hybrid link to cloud identity.

What it does not cover is the logic inside a specific application, which belongs to application testing.

Two tests, two starting points

Infrastructure testing splits into two engagements, and the difference is where the tester starts. Our guide to external vs internal penetration testing goes deeper on choosing between them.

External testing: from the internet, with nothing

An external network penetration test models an attacker with no access and no credentials. It opens with discovery of the footprint an attacker can actually see, which is usually larger than the address list in your inventory. Forgotten subdomains, staging systems left public, cloud accounts opened by a single team, and passwords circulating in breach data all belong to that footprint.

The tester then probes exposed services and misconfigurations for a first foothold, assesses perimeter firewalls and VPN gateways, and attempts exploitation of public-facing systems. With your approval, VPN, mail, and single sign-on portals are password sprayed at a rate that stays below lockout. The cloud and SaaS edge counts too: open storage buckets, internet-reachable consoles, dangling DNS records, and keys committed to public code.

What it typically finds:

• Services and management interfaces that should never have faced the internet
• Perimeter systems missing patches for exploits that are already public
• Weak authentication on VPNs and portals, including MFA gaps and reused passwords
• TLS, DNS, and cloud misconfigurations that leak information or hand over access

Internal testing: from a foothold, toward Domain Admin

An internal network penetration test assumes the perimeter has already failed. It begins from a foothold inside the network, usually a small appliance or virtual machine, plus an ordinary domain user account. That is where a real intruder stands after one successful phish.

From there the tester maps the domain, collects and relays credentials, climbs the privilege ladder, and moves host to host toward the agreed objectives. By default the objective is Domain Admin, along with whichever systems you name as the ones that would hurt most. Each step is mapped to MITRE ATT&CK, which shows your defenders where detection should have fired.

What it typically finds:

• Escalation from an ordinary user to Domain Admin via Kerberoasting, AS-REP roasting, delegation abuse, and weak ACLs
• Lateral movement through harvested credentials, pass-the-hash, pass-the-ticket, and SMB
• Segmentation that exists on the diagram but not on the wire
• Cleartext protocols, LLMNR and NBT-NS poisoning, and NTLM and LDAP relay
• Newer routes through Active Directory Certificate Services and the link between on-premises AD and Entra ID

How scope is counted

Scope decides price and duration, and the two tests count it differently.

External scope is counted in live hosts and ranges. Small means a handful of live hosts, typically a public website, a VPN gateway, a mail server, and a few other services. Medium means several dozen hosts over more than one range. Large means a broad estate over several ranges and cloud regions, with a long tail of forgotten assets to discover. The ranges you provide are the starting point rather than the limit, because discovery usually finds more.

Internal scope is counted in hosts, subnets, domains, and zones. One location, one domain, and no more than a few hundred hosts is the small tier. Adding sites, VLANs, and services moves the engagement up. The large tier is several domains or forests, thousands of hosts, and an on-premises directory synced to a cloud identity provider.

Active Directory is counted by complexity, not just size. Each extra domain, trust relationship, group policy object, and privileged group multiplies the escalation paths that must be checked.

Segmentation is counted by the zones that must be tested. Real segmentation has to be proven zone by zone, so every VLAN and access rule adds a reachability check. PCI DSS, for example, wants proof that each segment outside the cardholder data environment cannot reach into it.

Two habits keep the number down. If several sites or domains share a template, test one thoroughly and treat the results as representative. And retire the abandoned hosts you already know about before the test starts. The full size bands are on our pricing pages for external network testing and internal network testing.

Infrastructure testing vs a vulnerability scan

A vulnerability scanner matches what it sees on your hosts against a database of known weaknesses. Our validated scan adds an analyst who removes the false positives and ranks what remains by risk, at $1,500 flat per scan.

A penetration test is human-led. A tester decides which weaknesses can really be exploited, links them into an attack path, and demonstrates the outcome with evidence. Most of what an internal test finds, from Active Directory escalation to segmentation gaps, never appears in a scanner report at all. Run scans between annual tests to catch new exposures early, and rely on the test for what a scanner cannot do.

Infrastructure testing vs a web application test

A web application penetration test goes after a single application: its authentication, session handling, input validation, authorization, and business logic. An infrastructure test attacks the environment the application lives in: the host beneath it, the services beside it, and the network and identity around it.

The two meet at the web server. The application test cares about the code it serves. The infrastructure test cares about the operating system, the management interfaces, and what a compromised server can reach next. A serious program needs both.

How infrastructure testing maps to compliance

Most infrastructure tests are bought to satisfy a framework. Here is what each one expects, with the requirement numbers your auditor will cite.

• PCI DSS Requirement 11.4. Internal testing every 12 months at minimum and after significant change (11.4.2), and external testing on the same cadence (11.4.3). Exploitable findings must be corrected and retested (11.4.4). Segmentation testing is due at least annually for merchants (11.4.5) and every six months for service providers (11.4.6).
• SOC 2. Auditors rarely mandate a test outright but nearly always expect one for the Security criteria. An external test evidences CC6.6, the criterion covering threats from outside the system boundary. An internal test evidences CC6.1 (logical access) and CC7.1 (identifying vulnerabilities) for the systems inside it.
• NYDFS 23 NYCRR 500. Section 500.5(a)(1) requires annual penetration testing of information systems from inside the boundary and from outside it, scoped to systems handling nonpublic information. Section 500.5(a)(2) adds vulnerability scanning and manual review at a risk-based frequency.
• CMMC Level 2. No practice names penetration testing, but CA.L2-3.12.1 requires periodic assessment of controls, and a test is the strongest objective evidence. External testing supports boundary protection under SC.L1-3.13.1, and internal testing from inside the corporate network proves whether the CUI enclave boundary actually holds.

How to prepare

Preparation is mostly about removing the delays that stall a test after it has been booked.

For an external test:

1. Hand over an accurate list of live ranges and hosts, so discovery spends its time on the assets missing from the list.
2. Retire the abandoned hosts and staging sites you already know about.
3. Approve the rules of engagement in writing: our fixed source addresses, testing windows, and lockout-safe limits for password spraying.
4. Name a contact for same-day escalation of anything critical.

For an internal test:

1. Run the appliance or virtual machine we send you on your own network. It avoids the cost of a tester on site without narrowing the test.
2. Create an ordinary domain user account for the tester to start from, since that is what a real intruder usually holds first.
3. Flag anything fragile or out of bounds, from plant equipment to an aging server nobody dares reboot.
4. Agree the objectives: Domain Admin by default, plus the systems whose compromise would matter most.

Testing follows a documented methodology built on PTES, OWASP, and MITRE ATT&CK, with communication checkpoints agreed from scoping through the retest.

What the engagement includes

The price is fixed and agreed in writing before any testing starts. You receive an executive summary, a full technical report with reproduction steps, an attestation letter, and access to our findings platform. Remediated findings are retested free of charge. Testing is done by senior in-house testers holding OSCP and OSCE3 certifications. Testing typically begins within a week, and onboarding starts within 24 hours of the signed proposal.

External network testing starts at $4,200 and internal network testing at $6,000. Combined engagements are quoted as one number after scoping.

Frequently asked questions

Is infrastructure penetration testing the same as network penetration testing? In practice, yes. Both describe testing the network, hosts, services, and identity layer rather than a single application. The broader word reminds buyers that Active Directory and segmentation are part of the job.

Can a cloud-only company skip infrastructure testing? No. In the cloud the perimeter is made of security groups, public endpoints, and identity policies, all of which can be misconfigured like a firewall. The external test covers the cloud edge, and provider-specific layers are covered by cloud penetration testing.

The short version

Infrastructure penetration testing attacks the layer beneath your applications: network, hosts, services, and identity. An external test asks whether an outsider gets in, and an internal test asks how far one foothold spreads. Scope is counted in hosts and ranges outside, and in hosts, domains, and zones inside.

Ready to put a number on it? Tell us about your environment and you will get one fixed quote covering the external test, the internal test, or both.