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 →skillpoints into that sibling skill.Currency: Verified August 2026. See §17 →
pentest-disclosure-career-and-referencefor 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-methodologyis 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-methodologytells 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.
Plugin: penetration-testing · View SKILL.md on GitHub