Verizon's Data Breach Investigations Report has, for years, tied a large and stubborn share of breaches to misconfiguration and stolen-or-default credentials rather than novel exploits. The pattern on internal engagements matches exactly: the domain falls because a switch still uses admin/admin, SNMP answers to the community string public, or a flat network lets one compromised laptop reach the domain controllers. There is rarely a zero-day in the story.
This post catalogs the network security misconfigurations testers find on nearly every internal engagement, shows the actual exploit output for the worst of them, and gives the config-level fix for each. Think of it as the defender's counterpart to our internal network penetration testing guide and external network penetration testing checklist.
Network security misconfigurations are settings, defaults, and architectural choices that weaken a network without being a software vulnerability. There is no CVE to patch; the device works exactly as configured, and that configuration is the problem, which is why a scanner that only reports missing patches walks right past them.
They span every layer: default or weak credentials, unencrypted or unsigned protocols, overly permissive firewall and ACL rules, missing segmentation, and exposed administrative interfaces. Because they require judgment to spot and context to prioritize, misconfigurations are where manual penetration testing earns its keep over scanning alone.
The NSA and CISA codified the pattern in their joint advisory on the top ten cybersecurity misconfigurations, and it reads like a pentest report: default configurations, poor credential hygiene, weak segmentation, insufficient access controls, and unrestricted code execution among them. The things government red teams find inside federal networks are the same things a commercial tester finds inside yours, because the root cause, compatibility-first defaults that never got hardened, is universal.
Default credentials remain the most common finding because devices ship with them and busy teams never change them. Switches, routers, printers, iLO/iDRAC/IPMI controllers, IP cameras, and PBXs all arrive with documented defaults, and lists like SecLists make checking trivial. A tester sprays known defaults with NetExec, and the hit rate is depressingly high.
SNMP is the close runner-up, and a single read-only community often hands over the whole network map. Watch what one snmpwalk against public returns.
$ snmpwalk -v2c -c public 10.0.0.1
SNMPv2-MIB::sysDescr.0 = Cisco IOS Software, C2960 ...
IP-FORWARD-MIB::ipCidrRouteDest = 10.20.0.0 <- full routing table, the VLAN map
IP-FORWARD-MIB::ipCidrRouteDest = 10.30.0.0 <- management subnet revealed
$ onesixtyone -c community.txt -i hosts.txt
10.0.0.1 [public] Cisco IOS ... <- community guessed, no auth at allOn one engagement, that single public community on a core switch handed over the entire VLAN map and the management subnet, all the routing context an attacker needs before touching anything noisier. The fix is procedural and config-level: a hardening baseline that mandates credential changes at provisioning, and SNMPv3 with auth/priv so read-only community strings stop existing.
Insecure protocol settings turn ordinary traffic into an attack vector. The headline example is SMB signing not being required, which lets an attacker relay captured NTLM authentication straight to another host. Combined with LLMNR and NBT-NS enabled (the Windows default), Responder poisons name resolution and feeds the relay. The whole chain is three commands and no exploit.
$ nxc smb 10.0.0.0/24 --gen-relay-list targets.txt
SMB 10.0.0.21 445 FILE01 signing:False <- relay target written to targets.txt
$ responder -I eth0 -wd
[SMB] NTLMv2 Hash : CORP\svc_scan::CORP:1122... <- victim auth captured
$ ntlmrelayx.py -tf targets.txt -smb2support --dump
[*] Authenticating against smb://10.0.0.21 SUCCEED
Administrator:500:aad3b4...:31d6cfe0...::: <- local SAM dumped, no password crackedThe same theme repeats across protocols: cleartext Telnet and FTP where SSH/SFTP belong, unencrypted LDAP instead of LDAPS, missing 802.1X so anyone with a jack gets a DHCP lease, and unencrypted SIP/RTP on the voice network. Each is a compatibility-first default. Disabling LLMNR/NBT-NS and enforcing SMB signing alone closes the most reliable internal credential-theft path, the same one detailed in our Active Directory penetration testing checklist.
A flat network turns a single compromised host into access to everything, which is why segmentation is the most effective architectural fix. When workstations, servers, management interfaces, and voice systems share one broadcast domain, a foothold anywhere reaches the crown jewels with no further effort.
Testers confirm the gap rather than assume it, sweeping across VLAN boundaries to see what actually answers. This exposes whether segmentation lives in a diagram or in the firewall.
$ nmap -sn 10.30.0.0/24 # from a user-VLAN host, can we even see the mgmt range?
Nmap scan report for idrac-esx01.corp (10.30.0.40) <- mgmt host answered = flat in practice
Nmap scan report for sw-core01.corp (10.30.0.1)
Host is up (0.0011s latency).If a user-VLAN host can reach the management range, the network is flat regardless of the VLAN tags, and a common tester mistake is trusting the labels instead of testing reachability end to end. Proper segmentation isolates user, server, and management VLANs, restricts traffic between them with ACLs, and puts a jump host in front of administrative planes, a core control in NIST and the CIS Controls that dramatically shrinks blast radius.
Exposed management and administrative interfaces are the first thing to hunt because they offer the most control for the least work. An nmap sweep for the usual suspects (nmap -p 22,23,80,443,623,2379,3389,5985,8006,8443,9443,10250 <range>) surfaces switch admin panels, IPMI/BMC interfaces on 623, Proxmox and ESXi consoles, etcd on 2379, the Kubernetes kubelet on 10250, and WinRM on 5985.
Each is a control plane. An unauthenticated kubelet on 10250 lets you exec into running pods, and an IPMI controller with default creds is game over for the host behind it, since the BMC can mount media, reset the OS password, or power-cycle the box independent of any OS-level control. The fix is to keep management interfaces off general-access networks entirely, require strong unique credentials and MFA, and restrict access to a bastion. Treat the BMC and hypervisor planes as Tier 0, on par with domain controllers, because whoever owns them owns every workload above them regardless of OS hardening. Pair that isolation with a recurring discovery scan, since the real failure mode is not one missed device but the steady stream of new ones nobody added to the management VLAN. Because new devices and services appear constantly, these exposures reappear between annual tests; agentic pentesting is the continuous way to catch a newly exposed interface within days instead of months.
Individually each misconfiguration looks minor; chained, they walk an attacker from a network jack to Domain Admin without a single exploit. This is the sequence on most internal engagements, and every link is a default someone forgot to change.
Not one step needed a CVE. That is the uncomfortable point of this topic and why the same chain shows up in our internal network penetration testing guide and the Active Directory penetration testing checklist. Fixing five defaults breaks every link.