Penetration Testing & Red Teaming

This is the falsification step. Every other pillar produces claims — this control is implemented, this code is safe, this identity boundary holds — and this one goes and checks. Its value is proportional to how uncomfortable the findings are.

Two disciplines live here, and conflating them is a common mistake. A penetration test is breadth-first against a defined scope: it measures how much is broken. A red team engagement is objective-based and stealth-constrained: it measures whether anyone notices. The first tests controls; the second tests the people and pipelines meant to catch someone bypassing them.

Everything here assumes authorized testing: defined scope, written rules of engagement, and provider policy compliance for cloud targets.

Why it matters

A control that has never been tested is a hypothesis. Organizations routinely discover during an incident that a control they’d been reporting as effective for three years was misconfigured from the start. Adversarial validation is the only thing that closes that gap before an attacker does.

Red teaming extends that from controls to response. Detection coverage on paper is another untested hypothesis, and the only honest way to check it is to run the technique and see whether anything fires — which is why the output of an engagement here is an input to Detection Engineering, not just a report.

The second-order value is the report. A finding that a developer can reproduce and fix is worth ten findings that get filed and forgotten — which makes writeup quality a technical skill, not a formality.

How this connects

• → Detection Engineering: the purple team loop, and the reason red teaming is scoped into this pillar. Emulate the technique, check whether the detection fires, fix whichever end was wrong.
• → IAM: cloud pentesting is largely identity pentesting. Privesc chains, trust policy abuse, and managed identity abuse are IAM misconfigs, exploited.
• → AppSec: the same flaw catalog from the offensive side. Every web finding maps to a secure coding control that was missing.
• → GRC: required outright by PCI DSS and FedRAMP; findings are control gaps expressed as exploits.
• → Threat Intel: ATT&CK mapping is the shared vocabulary. Prioritize testing by what adversaries actually do, and feed findings back as intel.
• → AI & Automation: LLM application testing is a fast-moving new target class, and agent-assisted reporting is the obvious tooling win.
• → Cloud & Infrastructure Security: segmentation, egress control and workload isolation decide how far a foothold travels. Most cloud pivots are architecture findings before they are exploits.
• → Incident Response & Digital Forensics: a red team engagement is a rehearsal for response, and the honest measure of both is what the responders actually caught.
• → Data Security & Privacy Engineering: exfiltration is usually the objective, so egress controls are precisely what the operator is testing.

What’s here

Subsection	Focus
Web Application Pentesting	OWASP WSTG and PTES methodology, recon and mapping, authn/session and authz testing, injection and business logic, client-side, upload/SSRF/XXE chains
Cloud Pentesting	AWS enumeration and IAM privesc, Azure/Entra and managed identity abuse, Kubernetes RBAC and pod escape, rules of engagement
Tools & Commands	nmap, amass, httpx, Burp, ffuf, sqlmap, Nuclei, Pacu, Prowler, ROADrecon, BloodHound, Impacket, NetExec, Sliver — in command → what it does → what the output means → what next format
MITRE ATT&CK	Matrix structure, cloud and container matrices, Navigator for coverage mapping, Atomic Red Team and Caldera, D3FEND mitigation mapping
Red Team Operations	Engagement design and objectives, threat-informed adversary emulation, C2 infrastructure (Sliver, Havoc, Mythic), operational security and evasion tradecraft, deconfliction and blue team handoff, measuring an engagement by what defenders caught
Report Writeups	Report anatomy, finding structure, justifying severity, evidence hygiene, retest and closure, writing for the developer who has to fix it
Specialized Testing	API and GraphQL, mobile, AI/LLM application testing

Scope

Content here is for authorized engagements, CTFs, and defensive research. Red team tradecraft — including evasion — is covered so defenders can build and validate detections against it, under written authorization and agreed rules of engagement. Not for use against systems you don’t have permission to test.