What We Find on Internal Network Penetration Tests

An internal network penetration test starts where most serious attackers eventually arrive: inside your perimeter. Whether through a phishing email, an exploited internet-facing service, or a compromised third-party connection, attackers who reach an internal foothold will attempt to move laterally, escalate privileges, and reach the systems that matter most. An internal test simulates that progression — and the findings tell a different story from external testing. The perimeter may hold, but the interior of most networks allows an attacker to reach domain administrator within hours.

No meaningful network segmentation

The most consistent finding on internal tests is a flat or insufficiently segmented network. In a flat network, any system can communicate directly with any other — a compromised workstation can reach domain controllers, database servers, file servers, and backup infrastructure without encountering any internal boundary. There is no requirement to break through anything; lateral movement is simply navigation.

Segmentation is often discussed and occasionally documented but rarely implemented effectively. Finance systems that were supposed to be isolated are reachable from the developer network. Manufacturing and operational technology is bridged to the corporate domain. The practical consequence is that a low-privilege foothold anywhere on the network can become domain administrator access given enough time and the right sequence of steps.

Legacy name resolution protocols

Windows networks accumulated support for legacy protocols over decades. LLMNR (Link-Local Multicast Name Resolution) and NBT-NS (NetBIOS Name Service) are both enabled by default in Windows and were designed at a time when network security was not a primary consideration. When a Windows machine fails to resolve a hostname through DNS, it broadcasts a request on the local network segment asking if anyone knows the address.

Any machine on the same segment can respond to that broadcast — including a tester's laptop. When it does, the requesting machine often automatically authenticates against the responding machine, sending an NTLM credential hash that can be cracked offline or relayed directly to authenticate against other services on the network. This technique requires no interaction from any user and works in most Windows environments we test. It has been a known issue for over a decade. It can be disabled with a single Group Policy setting. Most environments have not made that change.

Active Directory attack paths

Active Directory misconfigurations that create privilege escalation paths are found in nearly every internal engagement. The specific configurations vary, but the pattern is consistent: combinations of settings that individually appear acceptable create routes from a standard user account to domain administrator that can be identified and exploited systematically.

Kerberoasting — extracting service tickets for accounts configured with Service Principal Names and cracking them offline — is viable in environments where service accounts are configured with weak or non-rotating passwords, which is most of them. Misconfigured Active Directory ACLs give accounts write permissions over other accounts or groups, creating escalation paths that are invisible in standard IT management tooling but straightforward to map with the right approach. Unconstrained delegation — a legacy Kerberos setting — allows certain machines to impersonate any user who authenticates to them, effectively providing a path to domain administrator if a domain controller connects to the machine.

Credentials found in the environment

Internal environments consistently contain credentials outside of identity management systems. Scripts that connect to databases or APIs with hardcoded passwords in plaintext. Configuration files on shared drives containing service account credentials. Group Policy Preferences — a legacy Windows feature used by many organisations to distribute local administrator credentials — stores passwords in an "encrypted" format using a key that Microsoft published publicly; any authenticated domain user can decrypt them. Documentation on accessible file shares that includes passwords copied in for convenience. These findings require no exploitation — they require reading files that the authenticated test account is permitted to access.

Excessive local administrator rights

In many organisations, domain users hold local administrator rights on workstations — configured this way either for convenience or as a legacy of IT support processes that were never revisited. The consequence for internal testing is direct: local administrator access on a workstation allows extraction of cached credentials from that machine's memory. Those credentials are then usable against other machines where the same accounts have been used. In environments where IT administrators log on to workstations to perform support tasks, the cached credentials on those workstations include highly privileged accounts.

Microsoft's Local Administrator Password Solution (LAPS) addresses this by generating unique, rotating local administrator passwords for each workstation. Environments that have deployed it fully are materially harder to move laterally through. Most environments we test have not deployed it, or have deployed it incompletely.