Penetration Testing

The Low-Hanging Fruit That's Always There

Jun 2, 20265 min read

Every penetration tester has a personal list. The findings they have written up so many times that they could produce the report section from memory, in the dark, mildly concussed. The things that appear in environments ranging from 20-person startups to enterprises with dedicated security teams and seven-figure tool budgets.

The specifics vary. The categories do not. Here is the list, annotated.

Default Credentials on Something Important

Admin. Admin. Enter. In.

This should not work in 2026. It works constantly. Network devices, management interfaces, industrial control systems, VPN appliances, printers with web consoles that also happen to sit on the internal network. The default credentials are in the documentation. The documentation is on the vendor's public website. This is not a sophisticated attack vector. It is a Google search and a login attempt.

The reason it persists is tedious but real. Devices get deployed under deadline pressure. The person who deployed them has seventeen other things to do. Changing the default credentials is step 12 of a 40-step setup guide and step 12 feels optional when step 11 was changing the IP address and the thing is working. Months later, nobody remembers that step 12 never happened.

A configuration management process that verifies credential changes before a device is considered production-ready costs almost nothing and would eliminate this finding from the list. Most organizations do not have one.

Unpatched Externally-Facing Services

The Cybersecurity and Infrastructure Security Agency publishes a list of vulnerabilities that are being actively exploited in the wild. It is called the Known Exploited Vulnerabilities catalog. It is free. It is updated regularly. Some of the entries have been on the list for years.

On a meaningful percentage of external network penetration tests, we find internet-exposed services running software with KEV-listed vulnerabilities. Not theoretical vulnerabilities. Not proof-of-concept-only vulnerabilities. Vulnerabilities with confirmed active exploitation that someone thought were urgent enough to add to a federal government priority list.

The argument is usually that patching production systems requires maintenance windows, testing, change management, and coordination across multiple teams. This is true. It is also not a satisfying answer when the vulnerability has been on the KEV list for eight months.

SMB Signing Disabled Across the Internal Network

This one is for the internal assessments. SMB signing is a control that prevents relay attacks, where an attacker intercepts authentication traffic and relays it to authenticate somewhere else without ever cracking a password. When it is disabled, a technique called NTLM relay becomes straightforwardly exploitable in a way that can lead to domain compromise in environments that have done everything else reasonably well.

SMB signing has been available and configurable since Windows 2000. It is disabled by default on workstations because Microsoft made a performance tradeoff that made sense in the late nineties when signing added measurable overhead on the hardware of that era. Modern hardware makes that overhead negligible. The default never changed.

Enabling it requires a Group Policy change. It is one of the most consistently impactful fixes on an internal assessment relative to the effort required. It shows up on findings lists constantly because almost nobody thinks to enable it until a tester points it out.

Overly Permissive Internal Network Segmentation

The ideal: distinct network segments for servers, workstations, printers, IoT devices, guest networks, and any other category with meaningfully different trust levels. Strict controls between them. A compromised workstation cannot directly reach domain controllers or file servers because there is no route.

The reality: a flat network where everything can reach everything, sometimes decorated with a firewall at the internet edge that gives the impression of segmentation without providing any. A compromised endpoint can scan the entire internal network, authenticate to any accessible share, and move laterally toward whatever is most valuable because nothing is stopping it.

Network segmentation projects are large, disruptive, and require coordination with every team that relies on network connectivity, which is every team. They get planned, descoped, partially implemented, and then quietly deprioritized. The finding shows up on the next pentest.

Why These Keep Appearing

None of these are unknown problems. There is no organization that has never heard of default credentials or patch management. The persistence is operational, not informational.

Security work competes with product work, infrastructure work, and every other kind of work for the same finite pool of engineering time. Controls that require sustained operational discipline rather than a one-time deployment drift without active maintenance. And organizations tend to commission penetration tests at a frequency that lets findings age between assessments.

The useful response to seeing these findings is not embarrassment. It is to build the operational structures that catch them before the next tester does: configuration baselines, automated patch compliance checks, periodic internal network scans with actionable thresholds, and change management processes that treat security configuration as a first-class requirement.

The low-hanging fruit persists because nobody is assigned to pick it. Assign someone.