Internal Network Penetration Testing Guide

Here is the part that makes CISOs uncomfortable. On a recent assessment of a mid-size manufacturer, we plugged into a conference-room network jack, started Responder, and three hours later held the krbtgt hash, complete control of the domain, without firing a single exploit. Every link in that chain was a default someone forgot to change. That is what an internal network penetration test measures: not whether someone can get in, but how bad it gets once they do.

This guide walks the methodology a tester actually runs, with the real tool output at each step so you can reproduce the work or read a report and understand exactly what happened. We name the commands, point to the telltale line in each output, then close with a findings table and the GPO-level fixes that collapse the whole attack path. For wider context, start with our network penetration testing overview.

What is internal network penetration testing?

Internal network penetration testing is an authorized attack launched from inside your network, modeling a malicious insider or an attacker who already breached the perimeter. The external test answers "can someone get in?" The internal test answers the scarier question: once they are in, how far does it go?

The two are complementary. An external network penetration test probes your internet-facing edge; the internal test assumes that edge is bypassed and measures blast radius across Active Directory, file shares, internal apps, and the segmentation (or lack of it) between user, server, and management VLANs.

Most internal tests run in an assumed-breach posture: the client hands over a standard domain user account so budget goes toward finding real escalation paths instead of re-running a phishing campaign everyone already knows works. That single account is usually all an attacker needs.

How do you discover and enumerate internal hosts?

Start with host discovery and service enumeration, because you cannot attack what you cannot see. masscan sweeps a /16 for live hosts in seconds, then nmap fingerprints what answers. For Active Directory, port 88 (Kerberos), 389/636 (LDAP), and 445 (SMB) are your map.

Sweep SMB with NetExec (the maintained successor to CrackMapExec). The single most valuable column is signing status, because every host without signing required is a relay target later.

$ nxc smb 10.0.5.0/24 --gen-relay-list targets.txt
SMB  10.0.5.21  445  FILE01  [*] Windows Server 2019  signing:False  <- relay target
SMB  10.0.5.10  445  DC01    [*] Windows Server 2022  signing:True   (DC, signed)
SMB  10.0.5.34  445  APP02   [*] Windows Server 2019  signing:False  <- relay target
[*] wrote 2 hosts to targets.txt

That signing:False line is the whole ballgame; those two hosts go in your relay list. While scans run, harvest cheap context: null sessions for the password policy (enum4linux-ng -A, so you know the lockout threshold before you spray), default SNMP communities (snmpwalk -v2c -c public), and IPv6, which most networks ignore, where mitm6 abuses Windows preferring IPv6 DNS to prime a relay.

What attacks give you that first set of credentials?

The fastest path to your first credentials is name-resolution poisoning. When a host asks for a name DNS cannot resolve, Windows falls back to LLMNR and NBT-NS broadcasts, and Responder answers "that is me," capturing the NetNTLMv2 hash the victim sends.

$ responder -I eth0 -wd
[*] Listening for events...
[SMB] NTLMv2-SSP Client   : 10.0.5.61
[SMB] NTLMv2-SSP Username : CORP\j.reyes
[SMB] NTLMv2-SSP Hash     : j.reyes::CORP:1122334455667788:A1B2...:0101000000000000  <- crackable hash captured

That hash cracks offline with hashcat (-m 5600), but relaying is better because it skips cracking entirely. Turn off Responder's SMB and HTTP servers, then relay the live authentication to your unsigned-host list. The --dump flag pulls the SAM straight off the relayed target.

$ ntlmrelayx.py -tf targets.txt -smb2support --dump
[*] Authenticating against smb://10.0.5.21 as CORP/J.REYES SUCCEED
[*] Target system bootKey: 0x9a1f...
[*] Dumping local SAM hashes (uid:rid:lmhash:nthash)
Administrator:500:aad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::  <- local admin NT hash, no cracking needed

Swap --dump for -i to get an interactive SMB client or -c to run a command. Pair Responder with mitm6 to widen the victim pool. Also check AS-REP roasting (GetNPUsers.py ... -no-pass), which needs no credentials at all, and Group Policy Preferences cpassword in SYSVOL (gpp-decrypt).

BloodHound turns a permissions maze into a straight line

Lateral movement is about turning one credential into many, and the planning starts with BloodHound. Run the collector to snapshot every user, group, session, and ACL, then ask for the shortest path from your owned account to Domain Admins. The output is not a vibe, it is a literal edge list.

$ bloodhound-python -d corp.local -u j.reyes -p <cracked> -c All -ns 10.0.5.10
# Shortest path to DA, as the graph renders it:
J.REYES@CORP.LOCAL
  --MemberOf-->        HELPDESK@CORP.LOCAL
  --GenericWrite-->    SVC_BACKUP@CORP.LOCAL      <- you can set this account's SPN
  --MemberOf-->        BACKUP_ADMINS@CORP.LOCAL
  --GetChangesAll-->   CORP.LOCAL (domain)        <- DCSync rights = game over

That graph says the quiet part loudly: your help-desk user has GenericWrite over a service account that ultimately holds DCSync rights. With the path in hand, NetExec does the moving via pass-the-hash and impacket gives remote execution (wmiexec.py, psexec.py). Spraying a recovered local-admin hash across the subnet usually lights up the classic flat-fleet problem where one password was reused everywhere. On each new box, dump fresh credentials with secretsdump.py and repeat. The Active Directory specific abuse (Kerberoasting, delegation, ADCS) gets its own playbook in our Active Directory penetration testing checklist.

What does the full internal attack chain look like?

The pieces connect into one repeatable chain from network jack to Domain Admin, usually inside a day. The manufacturer engagement from the intro ran exactly this sequence in under three hours.

1. Poison: Responder answers an LLMNR broadcast and captures j.reyes' NetNTLMv2 hash from a help-desk workstation.
2. Relay: with Responder's SMB off, ntlmrelayx relays that auth to an unsigned file server and dumps the local SAM.
3. Reuse: the local admin hash is reused fleet-wide, so pass-the-hash opens dozens of hosts.
4. Map: BloodHound shows the cached help-desk user has GenericWrite over a service account with DCSync rights.
5. Dominate: abuse the ACL to gain replication rights, then secretsdump.py -just-dc-user krbtgt DCSyncs the domain.

Not one step used a CVE. Every link was a default or a reused password, which is what makes internal testing so productive and so uncomfortable to read in a report. The most common tester mistake here is spraying passwords before reading the lockout policy and freezing half the domain on day one, so always pull the policy first.

What do vulnerability scanners miss internally?

Scanners miss almost the entire identity attack surface, which is exactly where internal compromises live. A Nessus or Qualys scan flags missing patches and weak TLS, but it never walks the BloodHound graph, so it will not tell you a help-desk group has WriteDACL over a Tier 0 account or that an ESC1 certificate template lets any user mint a Domain Admin cert.

The mistakes that let attackers win are equally invisible to a scanner: local admin password reuse, service accounts running as Domain Admin with a 2014 password, kerberoastable SPNs on privileged accounts, and unconstrained delegation on a print server. These are configuration and relationship problems, not vulnerabilities with a CVSS score, so they need a human (or an attack-path engine) chaining behaviors rather than checking versions. This is the gap continuous attack-path testing covers, re-walking these chains as the directory drifts instead of once a year, the same logic in our enterprise network misconfigurations guide.

How do you fix what an internal pentest finds?

The findings cluster into a short, fixable list, and fixing the top four kills most attack paths. Disable LLMNR and NBT-NS by Group Policy so Responder has nothing to answer, and enforce SMB signing everywhere to break NTLM relay.

# GPO: Computer Config > Admin Templates > Network > DNS Client
Turn off multicast name resolution = Enabled    # kills LLMNR
# GPO: registry, kills NBT-NS
HKLM\...\NetBT\Parameters\NetbiosOptions = 2
# GPO: Microsoft network server: Digitally sign communications (always) = Enabled  # SMB signing

Then deploy LAPS so a single dumped local hash does not open the fleet, and move service accounts to group Managed Service Accounts (gMSA) so passwords rotate automatically and resist Kerberoasting. Prune the GenericWrite, DCSync, and unconstrained-delegation rights BloodHound flagged, adopt a tiering model that keeps Tier 0 credentials off workstations, harden ADCS templates that allow SAN supply, and rotate krbtgt twice. Defenders should read our guide on securing against Active Directory attacks. Because these misconfigurations creep back with every new GPO and group change, point-in-time testing leaves gaps; agentic pentesting is the continuous way to keep checking these paths as your environment drifts.

Frequently asked questions

Sources and references

• MITRE ATT&CK: Lateral Movement
• NIST SP 800-115 Technical Guide to Security Testing
• BloodHound Documentation