Pentest Technical Domains

---
name: pentest-technical-domains
description: "Use when scoping or reasoning about the technical testing surface of an authorized engagement, at the level of method and coverage rather than exploit recipes. Covers reconnaissance and attack-surface mapping (OSINT, external footprinting), web application testing (the OWASP categories that matter), network and infrastructure, Active Directory and identity (the AD attack-path model, BloodHound, Kerberoasting at a conceptual level), cloud, and the other domains — APIs, mobile, wireless, OT/ICS/SCADA, and hardware/embedded. Framing is what to assess and how to cover it thoroughly, for authorized, in-scope work only."
---

# Penetration Testing: Reconnaissance and Testing Across Web, Network, Active Directory, Cloud, and Other Domains

> **Part 2 of 4** of the *Penetration Testing and Offensive Security* reference (plugin `penetration-testing`), covering §4–§9. Sibling skills: `pentest-authorization-scoping-and-methodology` (§0–§3), `pentest-red-team-ai-and-reporting` (§10–§13), `pentest-disclosure-career-and-reference` (§14–§20). Section numbers are shared across the set; a reference written as §N → `skill` points into that sibling skill.
>
> **Currency:** Verified August 2026. See §17 → `pentest-disclosure-career-and-reference` for the currency snapshot and what goes stale first.

> **⚠️ THE PREREQUISITE FOR EVERYTHING BELOW.** The entire difference between this
> profession and a felony is **documented, informed authorization from someone with the
> authority to grant it, for a defined scope, in a defined window.** Not implied consent.
> Not a verbal go-ahead. Not "the client seemed fine with it." Not a bug bounty scope you
> read quickly. **§1 → `pentest-authorization-scoping-and-methodology` is the section that matters most, and it is first for that reason.**
>
> This document is written for people doing authorized work — in-house security teams,
> consultancies, bug bounty participants operating inside a published scope, and the
> people who hire and manage them. **It is a methodology, process, and professional
> practice reference.** It deliberately does not contain exploitation recipes, working
> exploit code, or techniques for evading specific defensive products; those live in
> engagement-specific research, and the value of a reference like this is in the parts
> practitioners actually get wrong — scoping, method, evidence, and communication.
>
> **This is not legal advice.** §1 → `pentest-authorization-scoping-and-methodology` tells you what to ask your counsel, not what your
> obligations are in your jurisdiction.

> **How to read this.** Three markers:
> - **[DURABLE]** — professional practice, methodology, or a lesson the field has settled.
> - **[VERSIONED]** — regulation, tooling, market state. Verify.
> - **[CONTESTED]** — practitioners genuinely disagree.
>
> **The three framings that organize everything below:**
> 1. **The report is the product.** The client is not buying access to their systems —
>    they already have that. **They are buying a prioritized, reproducible, actionable
>    understanding of their risk.** A brilliant compromise written up badly is a failed
>    engagement (§13 → `pentest-red-team-ai-and-reporting`).
> 2. **Your job is to model a threat, not to win.** "I got domain admin" is not the goal;
>    **"here is how an attacker with these capabilities would reach these assets, here is
>    what detected them and what didn't, and here is what to fix first"** is.
> 3. **You are operating in someone's production environment and you can break it.**
>    Professional restraint — knowing what *not* to run — is a larger part of competence
>    than the ability to run anything.

---

## §4. Reconnaissance and Attack Surface

**[DURABLE] Attack surface discovery is where engagements are won**, and the finding is
usually not a clever exploit — it's the forgotten host nobody knew was internet-facing.

**Passive** (no interaction with the target): public DNS records and historical data,
certificate transparency logs (**an excellent source of subdomains**, and a reason
wildcard certs matter), WHOIS, public code repositories and package registries, job
postings (which describe the internal tech stack in detail), corporate filings, social
media and staff enumeration for the human layer (§10 → `pentest-red-team-ai-and-reporting`), breach-data checks for credential
reuse, and search-engine and internet-scan-database results.

**Active** (touching the target — **now inside the RoE window and scope**): DNS
enumeration, service and port discovery, web content and technology fingerprinting, and
authenticated enumeration where credentials were provided.

**⚠️ Recon is where scope violations happen**, because acquisitions, cloud tenants, and
partner infrastructure blur the boundary. **When discovery finds an asset you can't
confirm is in scope, ask before you touch it** — and note that the client frequently
doesn't know either, which is itself a finding.

**[DURABLE] "Shadow IT and asset inventory gaps" is one of the most consistently valuable
findings you can deliver**, and it costs the client nothing to fix conceptually and a great
deal to fix in practice.

---

## §5. Web Application Testing

**[DURABLE] The OWASP Top 10 is an awareness document; the WSTG is the testing
methodology.** Use the latter to work, the former to communicate.

### 5.1 The categories that matter

| Class | What you're checking |
|---|---|
| **Broken access control** | **Consistently the highest-impact category.** Can user A reach user B's object (IDOR)? Can a normal user reach admin function? Is authorization enforced server-side on every path, or only in the UI? |
| **Authentication** | Credential policy, brute-force and rate limiting, MFA implementation and bypass paths, session fixation, password reset flows (**a perennially weak spot**), account enumeration |
| **Session management** | Token generation, cookie flags, expiry, invalidation on logout and password change, concurrent sessions |
| **Injection** | SQL, command, LDAP, XPath, template, deserialization — the question is always *does untrusted input reach an interpreter* |
| **XSS and client-side** | Reflected, stored, DOM-based; CSP quality; and the actual impact given the app's session model |
| **CSRF** | Present on state-changing operations without token or SameSite protection |
| **SSRF** | Can the server be made to make requests you choose — **especially at cloud metadata endpoints** (§8) |
| **Business logic** | ⚠️ **What scanners cannot find and where the interesting findings live.** Negative quantities, race conditions on balance operations, workflow steps skipped, price manipulation, coupon stacking |
| **Cryptography** | Weak or misused primitives, key handling, tokens that aren't what they claim |
| **File upload and path handling** | Type validation, storage location, traversal |
| **Configuration and exposure** | Debug endpoints, verbose errors, default credentials, exposed admin, backup files, source maps |
| **Dependencies** | Known-vulnerable components and their real reachability |

**[DURABLE] The two things that distinguish a good web tester:**
1. **Understanding the application's own logic** well enough to know what "abuse" means in
   its terms. That requires reading documentation and using the app as a user first.
2. **Reasoning about real impact.** A reflected XSS on an unauthenticated marketing page
   is not the same finding as one in the authenticated account area, and reporting them at
   the same severity destroys your credibility (§13.2 → `pentest-red-team-ai-and-reporting`).

**Tooling orientation**: an intercepting proxy (**Burp Suite** is the professional
standard; **OWASP ZAP** is the capable free alternative) is the core of the workflow;
scanners find the known classes; **the manual work finds the logic flaws**.

---

## §6. Network and Infrastructure

**The workflow**: host discovery → service enumeration and version identification →
vulnerability identification → verification → controlled exploitation → post-exploitation
(§11 → `pentest-red-team-ai-and-reporting`).

**What actually turns up in real engagements**, in rough order of frequency:
**default and reused credentials**, **missing patches on internet-facing services**,
**exposed management interfaces** (databases, admin panels, remote access, printers,
hypervisors, IPMI/BMC), **weak or absent network segmentation** (the flat network is still
extremely common and is the single largest amplifier of any initial foothold), **legacy
protocols and unauthenticated services**, **weak TLS configuration**, and **credentials in
network shares, scripts, and config files**.

**[DURABLE] Segmentation testing deserves specific mention**: PCI requires it, and more
generally, *"can the compromised workstation VLAN reach the database VLAN?"* is often the
most decision-relevant question you can answer. It's also cheap to test and cheap to report.

**⚠️ Restraint in this domain specifically**: never run denial-of-service or resource
exhaustion without explicit written permission; be extremely careful with anything touching
**OT/ICS** (§9.4); avoid aggressive scanning of fragile embedded devices, medical devices,
and legacy systems, which genuinely fall over; and coordinate timing on anything that could
disrupt business operations.

---

## §7. Active Directory and Identity

**[DURABLE] AD is where most enterprise internal tests are decided**, because it is the
control plane for identity, and its default configuration accumulates weakness over
decades of organic growth.

**The conceptual model to hold**: AD is a graph. **Users, groups, computers, and
permissions are nodes and edges**, and an attack path is a route through that graph from
where you are to what you want. **BloodHound** made this the standard mental model, and
"reduce the number of paths to Tier 0" is now how mature organizations think about AD
hardening.

**The recurring weakness classes** (all well-documented publicly and all fixable):
**excessive privilege and unnecessary Domain Admin membership**, **Kerberos delegation
misconfiguration**, **service accounts with weak passwords and high privilege**,
**credential material left in memory on shared systems**, **legacy authentication
protocols still enabled**, **weak or absent tiering** (admins logging into workstations),
**Group Policy misconfiguration**, **certificate services misconfiguration** (a rich vein
since 2021), and **stale accounts and permissions nobody has reviewed**.

**[DURABLE] The remediation advice is more valuable than the compromise.** Tiered
administration, LAPS or equivalent for local admin passwords, protected users and
authentication policies, removing unnecessary privilege, and monitoring the specific paths
you demonstrated. **A report that says "we got DA" without the graph and the fix is worth
much less than one that says "these four edges enable it; break any of them."**

**Hybrid and cloud identity** (Entra ID and equivalents) has expanded this domain
substantially — **conditional access gaps, consent phishing, token theft, and
on-prem-to-cloud trust paths** are now core to internal testing.

---

## §8. Cloud

**[DURABLE] Cloud testing is mostly configuration review, and the shared responsibility
model determines what's even in scope.** You test *your client's configuration*, not the
provider's infrastructure (§1.3 → `pentest-authorization-scoping-and-methodology`).

**Where findings concentrate**: **IAM** (over-permissive roles, wildcard policies,
unused-but-live credentials, **privilege escalation paths through role assumption** — the
cloud equivalent of §7's graph problem), **exposed storage** (still, in 2026),
**metadata service access via SSRF** (§5.1 — a classic pivot from web to cloud),
**secrets in environment variables, images, and CI/CD**, **public snapshots and AMIs**,
**network exposure** (over-broad security groups, unintended public endpoints),
**logging gaps** (can they even see what you did?), and **CI/CD pipeline compromise paths**,
which are increasingly the highest-impact finding available because the pipeline can deploy
anything.

**Container and Kubernetes**: overprivileged pods, exposed API server or kubelet, weak RBAC,
secrets handling, and **escape paths from container to node to cluster**.

**⚠️ Read the provider's current penetration testing policy before you start.** Permitted
activity, prohibited services, and the requirement for separate approval on
stress/DoS-style testing all vary by provider and change over time.

---

## §9. Other Domains

### 9.1 APIs
**[DURABLE] APIs are where broken access control lives now.** The **OWASP API Security Top
10** exists because API testing has distinct failure modes: **BOLA/IDOR at scale**, broken
function-level authorization, **mass assignment**, excessive data exposure (the API returns
more than the UI displays — **read the raw responses**), missing rate limiting, and
**undocumented or deprecated endpoints still live**. Get the spec (OpenAPI/GraphQL
introspection) if you can; enumerate if you can't.

### 9.2 Mobile
Follow **OWASP MASTG/MASVS**. Static analysis of the package, dynamic analysis on device or
emulator, and — critically — **the backend API, which is usually where the real risk is**.
Common findings: secrets in the binary, insecure local storage, weak certificate
validation, and **client-side controls assumed to be enforcement**.

### 9.3 Wireless
Authentication configuration, guest/corporate separation, rogue AP and evil twin
susceptibility, and client behaviour. **⚠️ RF crosses property boundaries** — a specific
scoping and legal concern (§1.3 → `pentest-authorization-scoping-and-methodology`).

### 9.4 OT / ICS / SCADA
**[DURABLE] This is the domain where restraint is a safety issue, not a professionalism
issue.** Devices are fragile, protocols often lack authentication by design, and **a scan
that is routine on IT infrastructure can halt a physical process.** Passive techniques and
lab replicas are strongly preferred; **anything active requires explicit, informed,
engineering-level sign-off**, and the Purdue model is the standard framing for
segmentation. If you are not experienced here, **say so and decline** rather than learn on
someone's plant.

### 9.5 Hardware and embedded
Physical interfaces, firmware extraction and analysis, secure boot, and the debug ports
manufacturers forget to disable.