Net Pentest

---
name: net-pentest
description: >-
  Guides authorized network and infrastructure penetration testing — external
  perimeter and internal/Active Directory — from scoping through reporting. Use
  this skill whenever the user is testing a network, hosts, or infrastructure
  they're authorized to assess: their own network, a client engagement with a
  signed scope, or a lab (HackTheBox, TryHackMe, GOAD, a local range). Trigger it
  for requests like "pentest my network", "scan this subnet", "enumerate these
  hosts", "what's exposed on our perimeter", "help with Active Directory / AD
  attacks", "Kerberoasting / BloodHound / password spray", "privilege escalation
  on this box", "which nmap/netexec/impacket command do I run", or "map lateral
  movement" — even when the user doesn't say "pentest". Follows the PTES / NIST
  SP 800-115 flow, organizes tooling into a repeatable workflow, and produces
  clean technical + stakeholder reports (PDF). Sibling to the web-pentest skill;
  use that one for a single web application. Authorized testing only — third-party
  and cloud-provider infrastructure is out of scope by default.
---

# Network & Infrastructure Penetration Testing

This skill helps you run a disciplined network penetration test — external or
internal, including Active Directory — and turn what you find into a clear
report. It follows the Penetration Testing Execution Standard (PTES) and
NIST SP 800-115 so coverage stays systematic.

For testing a **single web application**, use the sibling **web-pentest** skill
instead. Use this one for networks, hosts, services, and AD.

## Authorization comes first — every time

Network testing is only legal and ethical against infrastructure you're allowed
to test. Before any **active** work (scanning, enumeration, exploitation),
confirm the engagement is one of:

- The user's **own** network / infrastructure.
- A **client engagement** with a signed scope / rules of engagement (RoE).
- A **lab** the user controls or is licensed to use (HackTheBox, TryHackMe,
  GOAD, Vulnhub, a local range).

If authorization or scope is unclear, ask once before proceeding:
*"Is this a network you're authorized to test, and what's the exact scope?"*
Scanning or attacking infrastructure you don't own, without authorization, is a
crime — don't help with it, and say why.

Network engagements need a **tighter RoE than web**, because scans and exploits
can disrupt live services. Record before starting:

- **In-scope IP ranges / CIDRs and hostnames**, and every host explicitly **out**
  of scope (domain controllers, SCADA/OT, medical or safety systems, shared
  infrastructure).
- **Test windows** and rate/intensity limits — fragile services can crash under
  aggressive scans or exploits.
- Whether **exploitation**, **password attacks**, **DoS-prone checks**, and
  **AD changes** are permitted, or detection/enumeration only.
- A **point of contact** for "stop" and emergencies, and a rollback plan.
- **Third-party / cloud-provider infrastructure is out of scope by default** —
  test your own hosts and config, not the cloud platform, ISP, or hosting
  provider underneath (and note each provider's own testing policy; many require
  prior notice).

## Engagement types

- **External** — testing from the internet against the perimeter: what's exposed,
  what's exploitable from outside.
- **Internal** — testing from inside the network (assumed-breach or on-site):
  lateral movement, privilege escalation, and **Active Directory**, where most
  real-world compromise happens.

Say which you're doing; it changes the emphasis (perimeter hardening vs. AD and
lateral movement).

## The workflow

1. **Scope & RoE** — confirm authorization, record scope (above).
2. **Host discovery** — find live hosts in the in-scope ranges.
3. **Port & service scanning** — open ports, service/version detection.
4. **Enumeration** — dig into each service (SMB, LDAP, SNMP, SSH, web, DB, mail…)
   and, internally, enumerate Active Directory.
5. **Vulnerability identification** — map versions/configs to known issues;
   confirm, don't just trust a scanner.
6. **Exploitation & privilege escalation** — gain and elevate access, safely and
   in scope.
7. **Post-exploitation, lateral movement & pivoting** — demonstrate real impact
   (and, in AD, the path to Domain Admin).
8. **Reporting** — write each finding up with evidence, severity, and a fix.

Keep running notes of every host, port, service, credential, and foothold — the
report and the attack path depend on them.

## Where to go next

Read the reference for the phase you're in:

- **`references/methodology.md`** — the phase-by-phase network testing checklist
  (discovery, scanning, per-service enumeration, vuln ID, exploitation, privesc,
  pivoting). The core of the skill.
- **`references/active-directory.md`** — internal AD attacks: enumeration,
  Kerberoasting / AS-REP roasting, password spraying, SMB/NTLM relay, BloodHound
  attack paths, credential abuse (pass-the-hash, DCSync), and the path to Domain
  Admin. Open it on internal engagements.
- **`references/privesc.md`** — privilege escalation after a foothold, Linux and
  Windows (sudo/SUID/cron/caps; token privileges, service misconfig, stored creds).
- **`references/pivoting.md`** — tunneling and pivoting into deeper in-scope
  segments (SSH, chisel, ligolo-ng, proxychains, SOCKS/port-forwards).
- **`references/password-attacks.md`** — safe credential testing: spraying vs
  brute force, lockout policy, offline hash cracking, default/reused creds.
- **`references/cloud-identity.md`** — hybrid/cloud identity: Entra ID (Azure AD)
  and AWS — what's in scope (the client's tenant/config) vs the provider's
  platform (out of scope). Open it on hybrid/cloud engagements.
- **`references/wireless.md`** — Wi-Fi testing (WPA2/3-PSK handshake/PMKID,
  Enterprise/802.1X evil-twin, WPS, guest segmentation). Needs a monitor-mode
  adapter.
- **`references/containers.md`** — Docker & Kubernetes: exposed APIs (Docker
  socket, kube API/kubelet/etcd) and container escapes.
- **`references/tooling.md`** — how to run nmap, masscan, netexec (CrackMapExec),
  impacket, enum4linux-ng, responder, BloodHound, Metasploit, etc., with
  safe-usage notes.
- **`references/reporting.md`** — severity (CVSS), evidence, the attack-path
  narrative, and the **three deliverables (technical report, stakeholder summary,
  how-to-recreate), all as PDF** via `scripts/render-report.sh`.
- **`references/lab-targets.md`** — legal practice ranges and a learning path.
- **`assets/report-template.md`** — fill-in network pentest report.

## Working principles

- **Don't break production.** Scans and exploits can crash services — start
  low-intensity, respect the RoE, and never run a DoS-prone or known-unstable
  exploit on a live target without explicit sign-off.
- **Confirm before you exploit.** Prove a vulnerability with the lightest safe
  proof; a reliable, in-scope demonstration beats a risky one-shot exploit.
- **Handle credentials carefully.** Treat any credential or hash you recover as
  sensitive; record where it came from and what it unlocked, and don't reuse it
  outside scope.
- **Map the path, not just the bugs.** The valuable output of an internal test is
  the *attack path* (foothold → escalation → Domain Admin), not a pile of
  isolated findings.
- **Stay in scope, always.** An interesting host outside the agreed ranges is
  still out of scope — note it, don't touch it.
- **Log everything** with timestamps for the report and to prove scope discipline.