Security · Topic 24 of 23 · Part V — Specialized assessment targets

Network infrastructure testing

A dedicated network-infrastructure assessment answers what an attacker can reach, from where, with what privilege, and how they would move — contrasting the real network against the architecture diagram.

Syllabus: § Assessment of Infrastructure → Network and infrastructure assessment
Topic 24 · Network assessment

The diagram is never right

By the end of this topic you can:
  • Scope and plan a network-infrastructure assessment, distinguishing it from application or identity testing
  • Test network segmentation, firewall rules, and routing policy systematically
  • Identify and abuse common Layer 2 and Layer 3 weaknesses
  • Assess perimeter and remote-access controls (VPN, ZTNA, exposed management interfaces)
  • Recognize IPv6-specific exposure and dual-stack pitfalls
  • Produce findings with concrete remediation paths that the network team can act on

What a network assessment actually assesses

The assessment answers six fundamental questions about the network as it actually is:

  • Exposure. What is reachable and to whom — external, partner, internal, management plane?
  • Segmentation. Does the boundary between zones hold where the architecture claims it does?
  • Policy. What does the firewall rule set actually allow vs. what is intended?
  • Protocol hardening. Are STP, HSRP/VRRP, OSPF, BGP, DHCP, DNS, NTP hardened against abuse?
  • Remote access. Are VPN, ZTNA, jump hosts, and management gateways trustworthy?
  • Address plan. Is the full address space — including IPv6 — governed?
Output A description of the real network at the time of testing, contrasted with the intended network. Findings are zone- and control-oriented, not host-oriented.

External perimeter assessment

Treats the tester as an internet-attached attacker. Infrastructure-specific emphasis:

  • Inventory the surface. Cross-check client inventory against DNS, certificate transparency (crt.sh), ASN allocations (whois, BGP route servers), passive DNS.
  • Find exposure that should not exist. Old hosts, forgotten subdomains, dev/staging instances, RDP/SSH/SMB on the internet, vendor-management interfaces (iDRAC, iLO, IPMI), SIP/VoIP control planes.
  • Verify perimeter posture. TLS configuration (testssl.sh), patch status of edge devices, default credentials on appliances, anonymous file-share access.
Most common finding Management interfaces of edge appliances exposed to the internet — firewall admin pages, VPN appliance consoles, hypervisor management. These attract attacker attention disproportionately and are behind many real-world breaches.

Testers consistently find production-grade services exposed that the client believes are internal-only — the strongest "diagram is wrong" evidence.

Internal segmentation testing

The primary question once inside: what can actually be reached that should not be reachable?

1Identify zones
From docs, configs, IPAM, or empirical scanning
2Place tester in each origin zone
Wall port, VPN profile, or SSID
3Probe each destination zone
L3 reachability, L4 protocol reachability, high-value endpoints
4Compare empirical vs. intended
Every difference is a finding

Common discoveries:

  • Flat networks behind a strong perimeter
  • Management VLAN reachable from user VLAN
  • Backup and monitoring networks bridging separated zones
  • Inconsistent segmentation — some sites enforce, others do not
  • ICMP blocked, but TCP/445 allowed; or reachability via a proxy that bridges zones

Firewall and ACL review

Pairs empirical reachability with a documentary review when ruleset access is available.

Platforms covered: iptables/nftables, Cisco ASA, Palo Alto Panorama, Check Point, pf (BSDs), Azure NSGs, AWS security groups and NACLs, GCP VPC firewall rules.

Patterns to flag in the rule set:

  • any/any allow; rules with service any; rules without logging
  • RFC1918 ↔ public permission; long-disabled rules still loaded
  • Shadow rules — later rule overrides earlier intent
  • Rule rot — rules referencing decommissioned hosts; years-old "temporary" exemptions; automation-generated rules with no documented intent
  • Missing or empty IPv6 policy; inconsistencies between same-named zones on different firewalls
Tools Vendor config exports + Nipper, AlgoSec, Tufin (commercial), or custom scripts that normalize a config file into a reviewable rule table.

Layer 2 weaknesses

  • VLAN hopping. Switch spoofing (negotiate DTP trunk from access port) or double tagging (802.1Q frame where access VLAN matches native VLAN). Mitigated: disable DTP, set native VLAN to unused ID.
  • STP manipulation. Crafted BPDUs to become root bridge; redirects traffic. Mitigated: BPDU Guard, Root Guard, Loop Guard.
  • DHCP starvation + rogue DHCP. Exhaust pool; serve attacker as default gateway and DNS. Mitigated: DHCP snooping, trusted-port config.
  • ARP spoofing / MitM. Classic on-LAN interception. Mitigated: Dynamic ARP Inspection (DAI), 802.1X, segmentation.
  • HSRP / VRRP / GLBP attacks. Default-gateway protocols with weak or no authentication; attacker becomes active gateway.
  • CDP / LLDP leakage. OS version, port, capability information broadcast broadly. Useful for the tester; a finding for the client.
Tools Yersinia, Bettercap, Scapy, ettercap

VLAN hopping mitigations are well-known — but aged switches, contractor equipment, and unmaintained sites frequently lack them.

NAC and 802.1X assessment

NAC binds wall ports to authentication — and is frequently bypassable:

  • MAB (MAC Authentication Bypass). Clone a permitted MAC (printer, VoIP phone, badge reader) and join as an exempted device.
  • VoIP-port voice/data separation. Voice VLAN often granted unconditionally — reachable without authentication.
  • 802.1X hub bypass. Insert a hub between an authenticated device and the wall port; ride the authenticated session.
  • No post-connect health checks. NAC checks at connection; not continuously. Change posture after authentication.
  • Quarantine VLAN over-privilege. The "default for unknowns" network frequently has more reachability than intended.
Field test A 30-minute on-site visit with a Raspberry Pi at a wall port usually reveals what NAC actually enforces — faster than weeks of remote analysis.

Routing protocols and IPv6 exposure

Routing-protocol abuse

  • OSPF. Inject an LSA with attractive cost to redirect traffic. Mitigated: MD5/SHA-HMAC auth, passive-interface on user-facing links.
  • BGP (iBGP / eBGP). Rogue announcement attracts traffic. iBGP without auth is a finding; eBGP without route filtering is serious.
  • RIP. Largely legacy; frequently unauthenticated.
Tools FRR, Quagga, ExaBGP — run a router stack from a laptop and join the routing domain.

IPv6 dual-stack reality

  • Rogue RA. Clients accept attacker as default gateway and prefer it over IPv4. Mitigated: RA Guard at the switch.
  • mitm6. Rogue DHCPv6 combined with WPAD to capture NTLM authentication on Windows clients.
  • Firewall asymmetry. IPv4 policy mature; IPv6 policy on the same firewall is often empty. Reachability the operator blocked is open over IPv6.

Most networks are dual-stack whether the operator realizes it — Windows, macOS, Linux, and mobile all bring up IPv6 link-local by default.

Remote access and management-plane assessment

Remote access (VPN / ZTNA)

  • VPN policies frequently place VPN users into a "trusted" zone with broad reachability
  • ZTNA promises per-application access but is often misconfigured to grant flat-VPN equivalence
  • VPN appliances (Pulse Secure, Fortinet, Citrix, Cisco AnyConnect, OpenVPN) have a track record of pre-auth RCE — check version and patch level
  • Guest wireless reaching the corporate network is the canonical wireless finding

Management plane

  • Network management systems (SolarWinds, Cisco DNA Center, Aruba Central) — compromise of these is compromise of every device they manage
  • TACACS+ / RADIUS servers — centralized auth for network devices; frequently older, under-audited deployments
  • Network CI/CD (Ansible, NetBox, Nautobot, vendor controllers) — equivalent impact to NMS compromise
  • Out-of-band networks — best-practice isolation; often flat, poorly monitored, and the keys to the kingdom
Critical gap A network test that skips the management plane misses the highest-impact finding class.

OT / ICS adjacency

Many enterprise networks border industrial-control or building-automation systems (BMS, HVAC, badge access, video, manufacturing). These operate on fragile protocols — Modbus, BACnet, DNP3 — and cannot be aggressively scanned.

The scope must explicitly include or exclude OT zones. What should be tested is the boundary controls between IT and OT — not the OT systems themselves.

Safety-critical risk IT testers who reach into OT can cause equipment failures, production stoppages, or physical harm. Treat OT-adjacent ports as off-limits unless explicitly scoped with OT specialists.
Scope posture Agree in writing before the engagement starts: which OT zones are in scope, which are out, and what scanning intensity is permitted at the boundary.

Methodology: typical engagement sequence

1Scope & zoning model
Zones + intended traffic from architecture docs
2External perimeter
Surface inventory; exposure; appliance versions
3Internal reachability matrix
Empirically map zone-to-zone; compare to intent
4L2 / L3 posture
VLAN, STP, ARP, DHCP, RA, routing-protocol hardening
5NAC & 802.1X
Physical access from typical wall ports
6Firewall / ACL review
Documentary + empirical
7Management plane
NMS, controllers, OOB
8IPv6 audit
Dual-stack exposure
9Findings & remediation
Zone- / control-oriented; not host-oriented

Tooling reference

CategoryTools
Discovery & scanningnmap, masscan, zmap, rustscan; netexec (formerly CrackMapExec), enum4linux-ng
Layer 2Bettercap, Yersinia, Scapy, ettercap
IPv6mitm6, ndp-toolkit, THC IPv6 attack toolkit
Routing protocolsFRR / Quagga / ExaBGP
Firewall config reviewVendor exports + Nipper, AlgoSec, Tufin
Capture & analysisWireshark, tcpdump, Zeek (large captures)
VisualizationMaltego (surface), Graphviz / yEd (reconstructed network maps)

Tool choice follows the assessment phase — not the other way around. Scoping and zone modelling require no tooling at all.

Check — reading a firewall configuration

Reflection

You have read access to the firewall configuration. Beyond explicit any/any allow rules, what patterns are you looking for?

Reveal answer

Rule rot: rules referencing decommissioned hosts; years-old "temporary" exemptions. Shadow rules: later rule overrides earlier intent. Rules without logging; rules from automation with no documented intent. Missing IPv6 policy. Rules bridging management VLAN to user VLAN. Weak source constraints (any from a partner network). Inconsistencies between same-named zones on different firewalls. ICMP blocked but all other traffic allowed.

What you take home

  • A network assessment focuses on control efficacy — not just which services are running
  • The output is the gap between the real network and the architecture document; that gap is the finding
  • Internal segmentation is tested by empirically probing zone-to-zone reachability, not by reading configs
  • Management interfaces exposed to the internet are the single most common external finding
  • Layer 2 attacks (VLAN hopping, STP, DHCP, ARP) remain effective wherever hardening is absent
  • IPv6 is live on almost every enterprise network; its firewall policy is usually empty
  • The management plane (NMS, OOB, controllers) is often a higher-impact target than any individual host

Next: Topic 25 — Wireless security testing. Extending the infrastructure assessment to RF-layer controls and wireless-specific attack paths.

END · TOPIC 24

The diagram is wrong. Prove it.

Before the next session, sketch the zone model for a network you know — then list three tests that would verify whether segmentation actually holds.