In short. Most infrastructure penetration tests are decided by five ordinary weaknesses: unpatched or out-of-support systems, weak authentication on services that matter, exposed management interfaces, flat networks with no segmentation, and cleartext protocols. Close those five and you move out of the easy-target category.
Most infrastructure penetration tests are not won by clever exploits. They are won by the same five weaknesses, found in a different order each time: unpatched or out-of-support systems, weak authentication on services that matter, misconfigured network devices and exposed management interfaces, flat networks with no segmentation, and cleartext protocols that hand over credentials to anyone listening. This guide describes each one as we actually encounter it, what it lets an attacker do, and what fixes it.
The list is deliberately unglamorous. Attackers prefer the easy route, and unless you are being specifically targeted, closing these five moves you out of the easy category.
1. Unpatched and out-of-support systems
How it shows up. An internal scan lists a server whose operating system left support two years ago because the application on it will not run on anything newer. A firewall on firmware from the year it was installed. A file server missing a critical patch that has had public exploit code for months. Windows 10 machines still on the network a year after Microsoft ended support in October 2025.
What it lets an attacker do. Public exploits for known vulnerabilities are the fastest route from a foothold to a domain administrator. When a patch is released, the vulnerability it fixes is public knowledge; exploit code typically follows within days for anything serious. An unpatched system is a documented way in.
What fixes it. An asset inventory that is actually maintained, so that you know what is running and what is out of support. A patching cadence that gets critical and high-rated updates on within 14 days, which is also the Cyber Essentials requirement. For the legacy system that cannot be upgraded, isolation: put it on its own segment, restrict what can talk to it, and treat it as already compromised.
2. Weak authentication where it matters
How it shows up. A VPN or remote desktop gateway with no multi-factor authentication. Service accounts with passwords set in 2019 and never changed. Local administrator passwords that are the same on every workstation. Password policies that permit “Company2026!” and a user base that has independently converged on it. Default credentials on printers, cameras, out-of-band management cards and the occasional database.
What it lets an attacker do. Log in. Password spraying against an externally facing service with no MFA is the commonest way we get our first foothold on an external test; on internal tests a shared local administrator password lets us move to every machine that shares it. Credentials taken from one system become access to the next.
What fixes it. MFA on every remote access path and every cloud service, without exceptions for senior staff. Unique local administrator passwords managed by a tool such as LAPS. Service accounts with long random passwords, rotated, and with only the privileges they need. A password policy that blocks known-breached passwords and common patterns rather than insisting on a symbol.
3. Misconfigured network devices and exposed management interfaces
How it shows up. A switch management interface reachable from the user network. A firewall administration page reachable from the internet, sometimes with a certificate that gives away the vendor and version. SNMP with the community string “public”. A remote management protocol enabled on a device nobody has logged into for years. Access control lists that were opened for a project and never closed.
What it lets an attacker do. Control of a network device is control of the traffic that passes through it. An attacker on a switch or firewall can redirect, intercept or block traffic, open holes in the boundary, and often reach segments that were supposed to be isolated. Exposed management interfaces are also a favourite target of the automated exploitation that follows any vendor advisory.
What fixes it. Management interfaces on a dedicated management network, reachable only from administrative hosts. Remote administration from the internet off, or behind MFA and restricted to known addresses. Default credentials and community strings changed, unused protocols disabled, and firmware on a patching schedule alongside the servers.
4. No network segmentation
How it shows up. One flat network in which the reception desk PC, the finance server, the CCTV recorder, the building management system and the domain controllers can all reach each other. Guest Wi-Fi that lands on the corporate LAN. A cloud VPC with a single security group allowing everything inside it.
What it lets an attacker do. Go anywhere from anywhere. A phishing email that compromises one laptop becomes access to the whole estate, because nothing stands between that laptop and the systems that matter. Ransomware spreads across flat networks in hours; across segmented ones it is contained to the segment it landed in.
What fixes it. Segmenting by function and sensitivity: user devices, servers, management, operational technology, guests, each on its own network with firewall rules between them that permit only what is required. It does not have to be perfect to be valuable. Separating user devices from servers and putting anything legacy in its own segment removes most of the risk.
5. Cleartext protocols
How it shows up. Telnet and FTP still enabled on network devices and legacy servers. HTTP administration pages. LDAP without TLS. SMB signing not required, and LLMNR and NetBIOS name resolution left on, which together let an attacker on the network collect and relay credentials without anyone entering a password.
What it lets an attacker do. Read credentials off the wire, or relay them to authenticate as the user without knowing the password at all. On internal tests, credential relaying through legacy name resolution is one of the most reliable routes from a plain network connection to administrative access, and it depends on nothing more than defaults that were never changed.
What fixes it. Disable the cleartext versions and use the encrypted ones: SSH, SFTP, HTTPS, LDAPS. Require SMB signing. Turn off LLMNR and NetBIOS name resolution through group policy. Each of these has been possible for many years and each is still routinely absent.
How we find them
An internal infrastructure penetration test starts from the position of an attacker who has a network connection, whether through a compromised device, a rogue insider or a plugged-in laptop, and establishes what they can reach and how far they can get. An external infrastructure penetration test does the same from the internet. Both are scoped by an active tester, delivered by a named consultant, and reported within 5 working days with the findings rated by real impact rather than scanner score. The sample report shows how a finding like each of the above is written up.
A build and configuration review takes the complementary approach: rather than attacking from outside, we review a representative server, workstation or network device against a hardening standard such as the CIS benchmarks, which catches misconfiguration before it becomes exploitable.
Frequently asked questions
What is the most common infrastructure vulnerability?
Missing patches and out-of-support software, by a distance. It is the finding that appears in almost every internal test and the one most directly exploitable.
Is a vulnerability scan enough to find these?
A scan will find unpatched software and some cleartext services. It will not tell you that a shared local administrator password lets an attacker move between every workstation, or that the flat network makes a single compromise a total one. Those need a person.
How often should infrastructure be tested?
External infrastructure at least annually and after significant change. Internal infrastructure every one to two years, annually for organisations that handle sensitive or regulated data.
Do these apply to cloud environments?
Yes, in translated form. Segmentation becomes security groups and network policies; management interfaces become the cloud console and its identities; patching applies to the virtual machines and containers you run. Our cloud penetration testing covers configuration and identity in AWS, Azure and Google Cloud.