Infrastructure Pen Testing: What We Actually Test on Your Network

‍‌​‌‌​​​‌‌‌‌‌​‌​​​‌​‌​​‌‌​‌​‌‌​​‌‌​​​‌‌‌​​‌​‌‌‌​‌‌‌‌​‌‌‌​​‌​​​‌‌‌‍An infrastructure pen test checks whether your network, servers, and supporting systems would survive an attacker who's already inside. External scans check what's visible from the internet. An internal test checks everything behind the firewall that you're relying on to keep people out. Most organisations are surprised by what we find, because quarterly external scans and CE Plus assessments test different things.

Why does the internal network matter?

Most breaches don't start with someone hacking through the firewall. They start with a phishing email, a compromised credential, or a device that connects to a network it shouldn't. 85% of businesses identifying breaches in 2025 experienced phishing attacks (Cyber Security Breaches Survey). Once an attacker is past the perimeter, the question isn't whether your firewall held. The question is what they can reach from the inside.

Here's what an infrastructure pen test answers. Not "can someone break in?" but "what happens after they do?"

What does an infrastructure test actually cover?

An infrastructure engagement typically has two parts: external testing and internal testing. Some organisations only need one, but most need both.

External testing

This is the view from the internet. The tester scans your public IP ranges, identifies services that are exposed, and looks for weaknesses in how they're configured. Outdated software, exposed management interfaces, weak TLS configurations, and services that shouldn't be public-facing at all.

External testing also checks your DNS records, email security configuration (SPF, DKIM, and DMARC), and whether anything is leaking information that an attacker could use to plan a more targeted attack.

If you've ever wondered what your organisation looks like from outside, this is the test that tells you, and the results can be genuinely shocking.

Internal testing

This is where the interesting findings live. The tester connects to your internal network (physically, over VPN, or through a drop box shipped to your office) and works through what an attacker could do with a standard user's level of access.

What actually matters here is Active Directory, because it controls access to everything else. Who has admin rights, and are there service accounts with passwords that haven't changed in years? Can I extract credentials from memory on machines where admins have logged in? Is Kerberoasting possible because service accounts use weak passwords?

From there, the test branches out depending on what the network looks like: file shares with open permissions, database servers that trust the application server without authentication. Network segments that are supposed to be isolated but share a management VLAN. Printers and IoT devices running default credentials that give a foothold nobody expected.

Every network is different and the methodology is consistent, but the findings depend on how your systems were built, maintained, and connected over the years. Honestly, configuration drift creates most of the problems I find. Something that was properly locked down three years ago has accumulated exceptions, temporary rules, and forgotten service accounts that nobody went back to clean up.

The most common reaction I get from IT teams during internal testing is "we didn't know that was there." A service account created by a contractor in 2019 that nobody disabled. A test server that was supposed to be decommissioned but is still running on the network. A firewall rule labelled "temporary" that has been in place for four years. I regularly find networks with a dozen or more orphaned service accounts, every one of them a potential foothold. These things accumulate silently, and nobody notices them because they do not cause operational problems. They only become visible when someone looks for them with hostile intent.

What do we typically find?

I can't list specific client findings, but the patterns repeat across hundreds of engagements, and here's what comes up most often.

Active Directory weaknesses

Active Directory is the backbone of most Windows networks, and it's where the biggest risks tend to live. Excessive admin rights, Kerberoastable service accounts, and unpatched domain controllers are common across organisations of every size. Our Active Directory attacks guide covers the specific techniques in detail.

Credential issues

Passwords stored in Group Policy Preferences (an old vulnerability that still appears). Shared admin passwords that are reused across multiple servers. Service accounts with "Password1" that were set up as temporary and never changed. Local admin accounts with the same password on every workstation in the building. Look, if the same local admin password works on 50 machines, one compromised device gives an attacker the run of the building.

Network segmentation failures

The network diagram shows separate VLANs for production, corporate, and guest traffic. The reality is that a management network connects all three, or a misconfigured switch port allows traffic to cross boundaries that should be enforced. Segmentation that looks correct in documentation but fails in practice is one of the most common infrastructure findings.

Outdated and unpatched systems

Servers running operating systems that reached end of life years ago. Firmware on network devices that hasn't been updated since installation. Applications with known vulnerabilities that nobody patched because "it works and we don't want to break it." The 14-day patching requirement for Cyber Essentials catches some of this, but a pen test checks the devices that fell through the patching process entirely.

Legacy protocols and services

SMBv1 still enabled on file servers despite being deprecated for years. LLMNR and NetBIOS Name Service broadcasting credentials on the network for anyone to intercept. Telnet running on switches instead of SSH, and NTLMv1 authentication still accepted by domain controllers. These are easy wins for an attacker and straightforward to fix, but they persist because nobody checked. It's honestly frustrating how often I find protocols from the 1990s running on networks that handle sensitive data.

I run a tool called Responder during most internal assessments. It listens for LLMNR and NBT-NS broadcasts on the network, which are essentially devices shouting "does anyone know where this server is?" into the void. When I respond pretending to be the server they are looking for, the device sends me its credentials. On a network where LLMNR hasn't been disabled, I typically capture usable credentials within the first 30 minutes of the engagement. Sometimes they belong to admin accounts, which is worse. The fix is a single Group Policy setting, but I find LLMNR enabled on the majority of Windows networks I test. It's a worried look from the IT manager every time. (per the latest configuration compliance framework update).

Finding Category	How Common	Typical Impact	Easy to Fix?
Excessive AD admin rights	Very common	Domain compromise	Yes, but politically difficult
Weak service account passwords	Very common	Privilege escalation	Yes
Network segmentation gaps	Common	Lateral movement	Depends on architecture
Missing patches on non-standard devices	Common	Known exploit paths	Yes, once identified
Legacy protocols (LLMNR, SMBv1, NTLMv1)	Common	Credential capture	Yes
Shared local admin passwords	Common	Lateral movement	Yes, with LAPS
Default credentials on network devices	Moderate	Network device control	Yes
Unencrypted internal traffic	Moderate	Data interception	Depends on applications

How does this relate to Cyber Essentials?

Cyber Essentials and CE Plus test whether you meet the five technical controls: firewalls, secure configuration, patch management, access control, and malware protection. What actually happens during an infrastructure pen test is different: it tests how those controls hold up when someone is actively trying to break them.

CE Plus confirms that your firewall is configured correctly. A pen test checks whether the network behind the firewall is designed so that a breach at one point can't escalate to a full compromise. CE Plus checks that your patches are within 14 days. A pen test checks the devices that your patching system doesn't know about. The CE assessment costs around £300 to £1,500 depending on the level. A pen test is a different investment entirely, but it answers a different question.

They're different tests answering fundamentally different questions. CE Plus asks "are your controls in place?" A pen test asks "would your controls actually stop an attacker?"

If you need CE Plus, Net Sec Group handles that assessment. If you need a pen test, that's a separate engagement scoped to your specific network. Organisations spending £5,000 or more on security assessments should make sure they're buying the right one.

How does the testing work in practice?

A typical infrastructure test runs three to ten days, depending on the size of the network and whether external and internal testing are both in scope.

Before testing starts, we agree on scope: which networks, which IP ranges, which sites, and what's excluded. We agree on rules of engagement, including what hours testing happens, who gets notified if we find something critical during the test, and whether social engineering is included.

During external testing, the tester works through your public-facing infrastructure methodically. Port scanning, service identification, vulnerability checking, and manual testing of anything that looks interesting. This usually takes one to two days.

During internal testing, the tester works from a position inside your network. The first priority is understanding the environment: what services are running, how Active Directory is structured, what network segments exist, and where the interesting data lives. From there, testing follows the path an attacker would take, escalating privileges, moving laterally, and seeing how far access can be pushed from a standard starting point.

After testing, every finding goes into a report with a description, evidence, severity rating, and specific remediation steps. The report is written for two audiences: the technical team who will fix the issues, and the board or management who need to understand the business risk. Blunt findings with clear evidence are what makes the report useful, not sanitised summaries.

The evidence section matters more than most people expect. For every finding, the report includes the specific steps I took to exploit it: screenshots, command outputs, and exact requests. This serves two distinct purposes that matter for remediation. First, it lets the technical team reproduce and verify the finding. Second, it lets them test their fix against the same technique. A finding without reproduction steps is an assertion. A finding with evidence is a demonstrated risk.

I include a 30-day retest window in every infrastructure engagement. Once the team has remediated the critical and high findings, I retest those specific items to confirm the fixes work. The report is then updated to reflect the current status. This matters for compliance and supply chain purposes, because clients and auditors want to see that findings were not just identified but resolved.

When do you need an infrastructure pen test?

You need one if:

• You haven't had your internal network tested by an external party before
• Your last pen test was more than 12 months ago and your network has changed since
• You're preparing for ISO 27001, PCI DSS, or another standard that requires it
• A contract or insurer specifically requires a CREST or CHECK pen test
• You've had a security incident and need to understand how it happened
• You've completed significant infrastructure changes (cloud migration, office move, network redesign)

If you're not sure whether you need a full infrastructure test or whether a vulnerability scan would cover your requirements, ask before buying. A scan and a test answer different questions at different price points, and buying the wrong one wastes money either way. A vulnerability scan for a small network might cost a few hundred pounds. A full internal pen test runs into thousands. The wrong choice is the one that doesn't answer your actual question.

What the remediation looks like

After the test, I walk through the findings with the technical team. Not just a handover of the report, but an actual conversation about each finding, how it was exploited, and what the fix looks like in their specific environment.

Some findings are quick wins that take minutes to resolve. Disabling LLMNR is a Group Policy change. Removing a forgotten service account takes five minutes. Changing a default password on a network switch takes less than that. I've had engagements where the entire critical findings list was resolved in a single afternoon.

Others are more involved and, bluntly, more stressful. Cleaning up Active Directory permissions requires mapping out who has admin rights, understanding why they have them, and negotiating with the people who will lose access they are used to having. Implementing network segmentation properly might require new hardware or significant reconfiguration. Replacing a legacy system that can't be patched might involve a capital expense of £10,000 or more and a migration project that takes months.

The report prioritises findings so the team knows what to fix first. Critical findings that provide immediate, exploitable access to sensitive systems get fixed before moderate findings that require specific conditions to exploit. Bottom line: the priority isn't just about the technical severity. It's about what an attacker would actually do with the finding in the context of your business.

I also flag findings that overlap with CE requirements. If I find unpatched devices during the pen test, that is both a pen test finding and a CE compliance issue. Addressing it resolves both requirements at once. This overlap is useful for organisations maintaining both CE certification and an annual pen test, because one piece of remediation work often satisfies both requirements.

---

---

Related articles

• Active Directory Attacks: What We Find on Internal Networks
• Can AI Actually Do a Pen Test?
• API Security Testing: What a Pen Tester Actually Checks
• The Five Cyber Essentials Controls: A Technical Guide

netsec-canary-2dabba2728d1.