Network and infrastructure penetration testing. Use when the engagement covers hosts, network devices, or segmented internal networks rather than a web application. Covers segmentation analysis, protocol-level attacks, network device testing, and infrastructure pivot paths.
Installs into .claude/skills of the current project.
Sponsors
SSkills DirectorySkills Directory
Know which skills are safe — weekly.
SSkills DirectorySkills Directory
Is that skill safe to install?
Are you the author of Infrastructure Network Pentesting?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/harezadmm-infrastructure-network-pentesting)
---
name: infrastructure-network-pentesting
description: >-
Network and infrastructure penetration testing. Use when the engagement covers hosts, network
devices, or segmented internal networks rather than a web application. Covers segmentation
analysis, protocol-level attacks, network device testing, and infrastructure pivot paths.
---
# SKILL: Infrastructure & Network Pentesting
> **AI LOAD INSTRUCTION**: Infrastructure testing is not "web testing without HTTP". The target
> is the **network itself** — its segmentation, its trust boundaries, and its protocols. The
> central question is never "which host is unpatched" but "**what can reach what, and what
> trusts what**". This skill covers the segmentation-first approach, the protocol attack surface,
> and the pivot paths that a host-by-host scan misses.
## 0. RELATED ROUTING
- [recon-and-methodology](../recon-and-methodology/SKILL.md) — discovery phase
- [unauthorized-access-common-services](../unauthorized-access-common-services/SKILL.md) — default-credential services
- [active-directory-kerberos-attacks](../active-directory-kerberos-attacks/SKILL.md) — the identity layer
- [infrastructure-and-network](../../core-subjects/infrastructure-and-network.md) — doctrine
- [windows-lateral-movement](../windows-lateral-movement/SKILL.md) — post-pivot movement
---
## 1. SEGMENTATION FIRST — THE REAL QUESTION
A port scan produces a host list. That is not the assessment. The assessment is the
**reachability matrix**.
| Question | Method | Why it matters |
|---|---|---|
| What networks exist? | routing tables, ARP tables, CDP/LLDP, traceroute, DHCP scope | reveals segments you were not given |
| What can reach what? | scan from **each** segment, not one | the standard finding is a flat network |
| Where are the firewalls, really? | test from both sides | a rule is one-directional until proven otherwise |
| What is the management plane? | out-of-band networks, jump hosts, IPMI/iDRAC | usually less defended than the data plane |
| What is dual-homed? | hosts with interfaces in two segments | the pivot path |
| What is the trust model? | domain membership, NFS exports, SMB shares, database links | trust transcends segmentation |
**Scan from inside each segment.** The most common infrastructure finding is that a segmentation
policy exists on paper and a permitted rule (or a dual-homed host, or a switch misconfiguration)
bypasses it. You cannot find that from a single vantage point.
**Put the reachability matrix in the report.** It is the artefact clients can act on — more than
any individual vulnerability.
---
## 2. PROTOCOL ATTACK SURFACE
Many "network" attacks are really **authentication-protocol** attacks. These are the highest
value in a Windows environment and no amount of application patching addresses them.
| Protocol | Attack | Requirement |
|---|---|---|
| **LLMNR / NBT-NS / mDNS** | name-resolution poisoning to capture NetNTLM | any Windows network — **enabled by default** |
| **NTLM relay** | relay captured auth to a host that does not enforce signing | SMB signing off / LDAP signing off |
| **SMB** | null sessions, share enumeration, signing downgrade | legacy config |
| **Kerberos** | roasting, delegation abuse, unconstrained delegation | AD specifics |
| **LDAP** | anonymous bind, unsigned bind relay | default in many deployments |
| **DNS** | zone transfer, cache poisoning, dynamic-update abuse | misconfiguration |
| **DHCP** | rogue server, starvation | no DHCP snooping |
| **ARP / NDP** | spoofing for MITM | no dynamic ARP inspection |
| **Spanning tree** | root bridge takeover | no BPDU guard |
| **VLAN** | hopping via DTP, double tagging | trunk misconfiguration |
| **SNMP** | default community strings, write access | v1/v2c in use |
| **Routing** | OSPF/BGP injection | no authentication |
**LLMNR/NBT-NS poisoning is the single highest-yield network attack on a Windows estate,** and
it is on by default. It requires no vulnerability — only that a user mistypes a hostname.
If you test nothing else on the network layer, test this.
---
## 3. NETWORK DEVICE TESTING
Routers, switches, firewalls, load balancers and VPN concentrators are distinct targets with
distinct weaknesses.
| Device class | Focus |
|---|---|
| **VPN concentrator** | pre-auth vulnerabilities, credential policy, MFA enforcement — **the highest-value external target** |
| **Firewall** | rule audit, management interface exposure, rule-shadowing analysis |
| **Switch** | default credentials, unencrypted management, spanning-tree and VLAN weaknesses |
| **Router** | protocol authentication, ACL correctness, SNMP |
| **Load balancer** | request smuggling, header handling, host-header trust |
| **Out-of-band / BMC** | IPMI, iDRAC, iLO — **frequently default-credentialed and rarely patched** |
**The out-of-band network is the most commonly missed target.** BMCs give console access and
often share credentials across an entire fleet. They sit on a management network that is
assumed to be trusted, which is exactly why they are not hardened.
**The VPN concentrator is the highest-value external target** because it is intentionally
internet-facing and its compromise yields network access directly. Test credential policy and
MFA enforcement there before anything else.
---
## 4. PIVOT AND MOVEMENT PATHS
Infrastructure assessments are graded on **how far you got**, not on how many hosts you touched.
```
external → VPN / exposed service → internal segment
internal → dual-homed host → second segment
segment → management network → infrastructure devices
workstation → credential → server → domain controller
any host → logging/backup infrastructure → everywhere
```
| Pivot mechanism | Use |
|---|---|
| SSH port forwarding | simple, detectable, effective |
| SOCKS proxy through a foothold | general-purpose |
| RDP session hijacking | on a shared host |
| WinRM / PsExec / WMI | Windows lateral movement |
| Shared credentials | the most common and most damaging |
| Trust relationships (AD, NFS, DB links) | **bypasses segmentation entirely** |
**Trust relationships defeat segmentation.** An NFS export that trusts a hostname, a database
link between two networks, or a domain trust between forests each provide a path the firewall
does not govern. Look for trust before looking for a firewall gap.
---
## 5. CONFIRMING THE FINDING
Network testing's discipline: **the boundary's own configuration is the artefact**, and a service banner
is not a finding. This table is the gate.
| Step | Question | What it proves |
|---|---|---|
| 1 | Is the **segmentation model written down first**: what may reach what, and by which rule? | without the intended model, no crossing is a finding |
| 2 | Was the **direct path demonstrated BLOCKED** before the crossing was attempted? | the control, and the difference that makes it a finding |
| 3 | Is the crossing evidenced on **both sides**: your path and the far host's own reply? | one-sided evidence is a routing artefact |
| 4 | Is the **refusal shape recorded** (timeout, ICMP unreachable, TCP reset)? | the shape identifies the control that denied it |
| 5 | Is the **protocol's trust assumption** named, and the L2 prerequisites stated? | ARP and NDP attacks need adjacency, which is a precondition |
| 6 | Was the target's **authorisation and window** confirmed, and the third-party boundary respected? | infrastructure testing has the largest blast radius |
| 7 | Is the impact the **reachability achieved**, not the protocol's theoretical weakness? | "SMBv1 is present" without a crossing is an observation |
**A written segmentation model, a blocked direct path as the control, and two-sided evidence.** An open
port is an observation; a crossing the policy forbids is the finding.
---
---
## 6. EVIDENCE STANDARD
| Item | Why |
|---|---|
| the **reachability matrix** as built from each segment | the primary infrastructure deliverable |
| for each finding: network path, protocol, and the requirement it violated | reproducibility |
| which segmentation control failed, and where | the actionable root cause |
| credentials obtained, with privilege level (values redacted) | scope of impact |
| the full pivot chain with each hop | proves the depth of access, not just presence |
| device firmware/OS versions | patch status is part of the finding |
| the OOB/BMC state even if not exploited | it is a latent risk the client must know about |
---
## 7. REMEDIATION REFERENCE
1. **Disable LLMNR and NBT-NS** via GPO — removes the entire poisoning class with no operational cost.
2. **Enforce SMB and LDAP signing** — closes the NTLM relay path; requires an audit before rollout.
3. **Segment with enforcement, not intent** — verify rules from both directions; remove dual-homed hosts or firewall them.
4. **Hardened management plane** — OOB networks isolated, no default credentials, jump hosts required, MFA on VPN.
5. **Network device hygiene** — no default credentials, encrypted management (SSH/HTTPS only), SNMPv3, authenticated routing protocols, DHCP snooping, dynamic ARP inspection, BPDU guard.
6. **Patch OOB controllers** — they are the most neglected and highest-impact unpatched surface.
7. **Trust-path review** — audit domain trusts, NFS exports and database links as network paths, because that is what they are.
8. **Detection on the network layer** — ARP/DHCP anomalies, unsigned authentication attempts, and lateral-movement protocols; segmentation without monitoring only slows an attacker.
---
## 8. EXECUTION PRIMITIVES
Section 1 states that the real question is segmentation, not the device count. This section is **how to
prove a segment boundary is crossed**. The proof is the boundary's own configuration and the reading read
from the far side, with the boundary shown REFUSING before the crossing.
### 7.1 The boundary, measured before anything is touched
```bash
# THE BOUNDARY IS THE SUBJECT. Measure it from BOTH sides before attempting anything.
cat <<'BOUNDARY'
THE THREE THINGS THAT MUST BE ESTABLISHED, in this order:
1. WHERE the boundary is: the L3 hop that separates your position from the target segment.
It is a router, a firewall, or a switch with an ACL - and it is a DEVICE, so it is reachable
for administration (see section 3), or it is not.
2. WHAT the boundary permits TODAY: which ports, FROM WHICH source, to WHICH destination.
A rule that permits your source to reach the target is a FINDING. A rule that permits a
DIFFERENT source is not your finding, and claiming it is the family's commonest overreach.
3. WHETHER the boundary REFUSES the crossing you claim. THIS IS THE CONTROL: an attempted
crossing that the boundary FILTERS, with the refusal visible at the far side (a timeout, an
ICMP unreachable, or a TCP reset), before any permitted path is found.
BOUNDARY
echo
echo "=== THE MEASUREMENT, from YOUR side ==="
SEG="${TARGET_SEGMENT:?e.g. 10.20.30.0/24}"
GATEWAY="${GATEWAY:?the near-side address of the boundary}"
echo "--- the routing path to the segment, and the last hop before it ---"
traceroute -n -w 1 -q 1 "$GATEWAY" 2>/dev/null | tail -3
echo "--- the segment's own census, WITH the source recorded for each ---"
IFACE="$(ip route get "$GATEWAY" | awk '{for(i=1;i<=NF;i++)if($i=="dev")print $(i+1)}')"
nmap -sn "$SEG" -e "$IFACE" 2>&1 | tail -20
echo " EVERY reading above is FROM YOUR SOURCE. Record which interface and which address, because"
echo " a segment that is reachable from one interface and not another is TWO different findings."
echo
echo "=== THE CONTROL: the crossing that MUST be refused ==="
cat <<'CONTROL'
demonstrate a crossing the boundary REFUSES, e.g.:
- a port on a host in the segment that is filtered (no SYN/ACK, or a reset)
- a host that does not answer a ping while others do
- a protocol the boundary inspects and drops
RECORD the refusal's SHAPE: a timeout (silently dropped), an ICMP unreachable (rejected), or
a TCP reset (refused). Those three indicate THREE different controls and three different
interpretations: a timeout means no answer at all, which is NOT the same as a refusal.
CONTROL
```
**A rule that permits your source to reach the target is a finding; a rule that permits a different source
is not.** And the refusal's shape matters: a timeout is not the same as a refusal.
### 7.2 The protocol surface, before exploitation
```bash
echo "=== THE PROTOCOL SURFACE (section 2), returned to the boundary where relevant ==="
cat <<'PROTO'
THE PROTOCOLS THAT MATTER AT A SEGMENT BOUNDARY, and the specific thing to establish:
VLAN hopping / DTP -> whether the boundary's trunk is negotiable FROM YOUR POSITION
(this is a LAYER-2 finding, and it needs LAYER-2 access)
STP manipulation -> whether you can become the root bridge from your port
(also LAYER-2, and it needs a port in the same broadcast domain)
VRRP/HSRP -> whether the gateway's status is protected by authentication
LLDP/CDP -> what the boundary ADVERTISES about itself, which is your reconnaissance
Routing protocols -> whether OSPF/BGP/EIGRP is authenticated on the link
DNS / DHCP -> whether an internal client can be pointed elsewhere
THE PREREQUISITE FOR EACH IS DIFFERENT. L2 attacks need L2 adjacency. A routing-protocol attack
needs an adjacency on that protocol. STATE THE PREREQUISITE, and state whether you achieved it -
a technique whose prerequisite was never met is an UNVALIDATED technique, not a finding.
PROTO
echo
echo "=== THE RECONNAISSANCE THE BOUNDARY ITSELF GIVES YOU ==="
echo " LLDP/CDP advertisements (from a device ON the segment) name the boundary's model, its firmware,"
echo " its management VLAN, and its uplinks. THAT is the reconnaissance, and it is read from the"
echo " segment - not from a banner on a port you happened to open."
echo
echo " tcpdump -nn -v -i <iface> -c 20 -s 1500 'ether proto 0x88cc' # LLDP"
echo " tcpdump -nn -v -i <iface> -c 20 -s 1500 'ether[20:2] == 0x2000' # CDP"
```
**A technique whose prerequisite was never met is an unvalidated technique, not a finding.** Layer-2
attacks need layer-2 adjacency, and stating the prerequisite is part of the finding.
### 7.3 The device, and its configuration as the artefact
```bash
echo "=== SECTION 3's POINT: THE DEVICE'S CONFIGURATION IS THE FINDING ==="
cat <<'DEVICE'
A DEVICE'S BANNER PROVES NOTHING. What matters is one of:
- the ACL or rule SET, read from the device -> THAT is the boundary's actual policy, and it is
the artefact. A device that REFUSES to show it is itself a finding (no read-only account, ...)
- the running configuration, or its diff against the intended one
- the management ACL: WHO may administer it, from WHERE
- the authentication: local, TACACS+, RADIUS, and whether there is a fallback
THE STRONGEST PROOF IS THE DIFF: the intended policy (the documentation) versus the running
configuration (the device). The DIFFERENCE is the finding, and it is often a stale rule nobody
removed and cannot now be justified. THAT is what a network assessment is for.
AND THE MANAGEMENT-PLANE QUESTION, which is usually the largest finding here:
from WHICH source addresses is the device administrable? If the answer includes the segment you
are already on, the ASSESSMENT finds the boundary administrable from a position it should not be,
and THAT is a segmentation finding in its own right.
DEVICE
echo
echo "=== the read-only check, and the credential tier ==="
echo " record WHICH tier of access produced the configuration:"
echo " a read-only account (the least invasive, and preferred)"
echo " an enable/privileged account"
echo " a default or shared credential <- ITSELF a finding, and frequently the main one"
echo " the tier is part of the finding: 'we read the ACL with a default account' is TWO findings."
echo
echo "=== THE DEFAULT-CREDENTIAL CONTROL ==="
echo " a default credential that WORKS is a finding. The control is that a NON-default, correctly"
echo " ROTATED credential is what SHOULD work, and that the default should have been refused."
echo " record both: what the default reached, and what the device's own policy says should be permitted."
```
**The device's configuration, or its diff against the intended policy, is the finding — not its banner.**
The access tier that produced the configuration is part of the finding.
### 7.4 Movement, and the end-to-end harness
```bash
echo "=== SECTION 4's POINT: THE MOVEMENT PATH, PROVEN AGAINST THE BOUNDARY ==="
cat <<'MOVE'
THE MOVEMENT CLAIM MUST NAME THREE THINGS:
the SOURCE position (where you were)
the BOUNDARY (which device and which rule permitted it)
the DESTINATION (what you reached, and WHAT YOU READ THERE)
AND IT NEEDS THE PAIR:
the direct attempt WITHOUT the move -> REFUSED by the boundary
the same attempt VIA the move -> the destination's reply
THE FALSE POSITIVE TO AVOID: a path that was ALREADY PERMITTED and merely UNTESTED. If the
boundary allows your source to reach the destination directly, then no 'movement' occurred -
and the finding is the PERMITTED RULE, not the technique that used it. THOSE ARE DIFFERENT
FINDINGS AND THE SECOND IS NOT AN ACHIEVEMENT.
MOVE
echo
echo "=== the end-to-end harness ==="
python3 - <<'PY'
print("=== INFRASTRUCTURE / NETWORK ACCEPTANCE CHECKLIST ===")
CHECKS = [
("the BOUNDARY was identified as a device, with its address and, if possible, its identity",
"the boundary is the subject; the host count is not"),
("the boundary's ACTUAL policy was established: which source may reach which destination",
"a rule permitting YOUR source is the finding; a rule permitting another source is not"),
("a crossing the boundary REFUSES was demonstrated FIRST, with the refusal's SHAPE recorded",
"timeout vs ICMP unreachable vs reset are three different controls"),
("the SOURCE interface and address of every reading are recorded",
"reachable from one interface and not another is two different findings"),
("for every L2 or protocol technique, the PREREQUISITE is stated and whether it was achieved",
"an unmet prerequisite makes it an unvalidated technique, not a finding"),
("the DEVICE'S CONFIGURATION (or its diff against the intended policy) is the artefact",
"a banner proves nothing"),
("the ACCESS TIER that produced the configuration is recorded",
"a default credential is itself a finding"),
("the MANAGEMENT-PLANE reachability was assessed: from which sources is the device administrable",
"admin reachable from a segment that should not have it is a segmentation finding"),
("a movement claim names the source, the boundary, AND what was read at the destination",
"the destination's reply is the proof"),
("the movement pair was run: direct REFUSED, via-the-move SUCCEEDED",
"a path that was already permitted is a permitted-rule finding, not a movement achievement"),
("the finding is classed as a SEGMENTATION gap, a DEVICE misconfiguration, or a CREDENTIAL issue",
"three different remediations"),
]
for n, how in CHECKS: print(" [ ] %-72s -> %s" % (n, how))
print()
print("=== THE REPORT SHAPE ===")
print(" boundary : the device, the address, and its identity")
print(" policy : the rule set or its diff against the intended policy")
print(" control : the refused crossing, with the refusal's shape")
print(" prerequisite: for each technique, whether it was met")
print(" movement : source, boundary, destination, and the read-back")
print(" access : the tier that produced the configuration")
print(" class : segmentation / device configuration / credential")
PY
```
**The movement pair — direct refused, via-the-move succeeded — is the proof.** And a path that was already
permitted is a permitted-rule finding, not a movement achievement.
---
## 9. RELATED SIBLINGS - LOAD TOGETHER
- [tunneling-and-pivoting](../tunneling-and-pivoting/SKILL.md) - the transport a movement path uses
- [reverse-shell-techniques](../reverse-shell-techniques/SKILL.md) - the callback an infrastructure assessment depends on
- [cloudflare-waf-recon-survival](../cloudflare-waf-recon-survival/SKILL.md) - the same boundary logic at the internet edge
- [linux-security-bypass](../linux-security-bypass/SKILL.md) - the endpoint layer beyond the boundary
- [security-reporting-and-documentation](../security-reporting-and-documentation/SKILL.md) - how a config diff is reported