Skip to main content

Penetration Testing

Penetration testing is an authorized security assessment that simulates attacker behavior to find and help fix weaknesses before real attackers exploit them. It is legal only when scoped, approved, and documented. Modern pentesting goes beyond scanning servers. Realistic assessments may include web apps, APIs, cloud accounts, SaaS integrations, developer workflows, CI/CD pipelines, identity systems, and supply chain exposure.

Types of Penetration Tests

TypeScopeWhat it simulates
Black boxTester has little or no internal knowledgeExternal attacker
White boxTester has source code, architecture, and credentialsDeep review with maximum context
Gray boxTester has partial knowledge or user credentialsRealistic attacker with some foothold
ExternalInternet-facing systemsRemote attacks
InternalInside network accessCompromised employee or device
Web/APIWeb apps and APIsApplication abuse and data access flaws
CloudCloud accounts and workloadsIAM abuse, exposed storage, misconfiguration
Supply chain / CI/CDRepositories, pipelines, packages, build systemsDeveloper and release path compromise
Red teamMulti-stage adversary simulationFull security program effectiveness

Scoping and Rules of Engagement

Before testing begins, define:
  • In-scope systems, domains, APIs, cloud accounts, and repositories
  • Out-of-scope systems and prohibited actions
  • Testing window
  • Allowed methods, including whether social engineering is permitted
  • Rate limits and denial-of-service boundaries
  • Data handling rules
  • Emergency contacts
  • Reporting expectations
  • Written authorization
Testing without explicit written permission is illegal in most jurisdictions. “I was only testing” is not a defense.

The Pentesting Methodology

1

1. Planning

Confirm authorization, scope, objectives, contacts, and constraints.
2

2. Reconnaissance

Collect public and provided information about the target.
3

3. Scanning and Enumeration

Identify services, technologies, exposed endpoints, permissions, and attack paths.
4

4. Vulnerability Analysis

Map findings to weaknesses, CVEs, misconfigurations, and abuse cases.
5

5. Exploitation

Safely prove impact within scope.
6

6. Post-Exploitation

Determine blast radius without causing unnecessary harm.
7

7. Reporting

Communicate risk, evidence, impact, and remediation clearly.

Reconnaissance

OSINT is intelligence gathered from public sources. It often reveals exposed services, old documents, leaked credentials, staff names, technologies, and vendor relationships.

Passive Reconnaissance

SourceWhat you learn
DNS recordsSubdomains, mail servers, IP ranges
WHOIS and registrar dataOwnership and registration details
Certificate TransparencySubdomains and certificate history
Search enginesExposed documents, login pages, cached content
LinkedIn and job postsPeople, roles, technologies, vendors
GitHub and GitLabSource code, secrets, package names, internal docs
Shodan and CensysExposed services and banners
Wayback MachineHistorical pages and removed endpoints

Active Reconnaissance

Active recon interacts with the target and may be detected. Examples include port scanning, directory enumeration, API probing, and authenticated role exploration.

Scanning and Enumeration

Network Scanning with Nmap

# Basic TCP scan
nmap -sT target.com

# Full port scan with service detection
nmap -p- -sV -sC target.com

# UDP scan of common ports
nmap -sU --top-ports 100 target.com

Web and API Tools

ToolPurpose
Burp SuiteIntercept, inspect, and modify HTTP traffic
OWASP ZAPOpen-source web scanning and proxying
ffuf / GobusterDiscover hidden paths and files
NiktoFind web server misconfigurations
SQLMapDetect and exploit SQL injection in authorized labs
Postman / InsomniaExplore APIs and authorization behavior

Web and API Testing Focus

Prioritize vulnerabilities with real impact:
  • Broken access control and IDOR
  • Authentication bypass
  • OAuth misconfiguration
  • SQL injection and other injection types
  • XSS
  • SSRF
  • File upload abuse
  • Insecure deserialization
  • Missing rate limits
  • Sensitive data exposure
  • Business logic flaws
For APIs, test both route-level authorization and object-level authorization. A token that can call an endpoint should not automatically access every object behind it.

Cloud and SaaS Testing

Cloud and SaaS assessments require careful scoping because mistakes can affect production services.

Common Findings

  • Public storage buckets
  • Over-permissive IAM roles
  • Long-lived access keys
  • Unused admin accounts
  • Missing MFA for privileged users
  • Publicly exposed databases
  • Weak logging and retention
  • Unrestricted data export features
  • Risky OAuth applications

SaaS Questions

  • Who has admin access?
  • Which third-party apps have OAuth grants?
  • Can users bulk export data?
  • Are audit logs available and retained?
  • Are API keys scoped and rotated?
  • What alerts exist for unusual login and export behavior?

Supply Chain and CI/CD Testing

Recent attacks against developer tools and package ecosystems make supply chain testing increasingly important.

Areas to Review

  • Repository permissions and branch protection
  • Personal access token scope and lifetime
  • Secrets in source code and commit history
  • CI/CD workflow permissions
  • Self-hosted runner isolation
  • Package publishing permissions
  • Dependency confusion exposure
  • Unsigned releases
  • Build scripts that download and execute remote code
  • Extension and plugin allowlists

Safe Test Ideas

  • Create a harmless test secret and verify secret scanning catches it.
  • Attempt to push to protected branches with low-privilege accounts.
  • Review whether untrusted pull requests can access secrets.
  • Check whether package names can be confused with public registry packages.
  • Verify release artifacts are signed or traceable to a workflow.

Exploitation

Exploitation proves that a weakness has real impact. It must stay within scope and avoid unnecessary damage. Good exploitation:
  • Demonstrates access with minimal data exposure.
  • Uses test accounts or synthetic records when possible.
  • Captures evidence without disrupting users.
  • Stops before destructive actions.
Bad exploitation:
  • Exfiltrates more data than needed.
  • Causes downtime without approval.
  • Creates persistence without explicit authorization.
  • Tests out-of-scope systems.

Post-Exploitation

Post-exploitation answers: what could an attacker do after the first foothold? Activities may include:
  • Privilege escalation checks
  • Credential and token exposure review
  • Lateral movement path analysis
  • Data access validation
  • Cloud role assumption review
  • CI/CD abuse path analysis
  • Package publishing impact assessment
Persistence, data exfiltration, and lateral movement are high-risk activities. They must be explicitly authorized and carefully controlled.

Reporting

The report is the most important deliverable. A finding that is poorly explained may not get fixed.

Finding Structure

  1. Title: Clear and specific.
  2. Severity: Critical, High, Medium, Low, or Informational.
  3. Summary: One plain-language paragraph.
  4. Affected assets: Systems, endpoints, accounts, or workflows.
  5. Evidence: Screenshots, requests, logs, or command output.
  6. Impact: What an attacker could realistically do.
  7. Root cause: Why the issue exists.
  8. Remediation: Specific fix guidance.
  9. Retest steps: How to verify the fix.

Business Impact Examples

  • Account takeover
  • Data exposure
  • Cross-tenant data access
  • Repository cloning
  • Package publishing compromise
  • Cloud resource takeover
  • Service disruption
  • Regulatory or contractual exposure

Bug Bounty Programs

Bug bounty programs allow researchers to report vulnerabilities for rewards. They are not permission to test anything you want. Getting started:
  1. Read the policy and scope carefully.
  2. Practice on legal labs such as PortSwigger Web Security Academy, OWASP WebGoat, Hack The Box, and TryHackMe.
  3. Start with common bugs such as IDOR, XSS, access control, and information disclosure.
  4. Write concise reports with clear reproduction steps.
  5. Do not access, modify, or download unnecessary data.
  • Always get written authorization.
  • Stay within scope.
  • Minimize impact.
  • Protect sensitive data.
  • Report promptly.
  • Do not disclose publicly without permission.
  • Keep evidence secure.
JurisdictionExample law or concern
BrazilLei 12.737/2012, unauthorized access
USComputer Fraud and Abuse Act
EUDirective on attacks against information systems
UKComputer Misuse Act

Practical Lab Ideas

  1. Perform OSINT on a fictional company domain.
  2. Scan a local lab network and write a short asset inventory.
  3. Find and fix IDOR in a vulnerable web app.
  4. Review a CI workflow for secret exposure risk.
  5. Test a cloud IAM policy in a sandbox.
  6. Write a professional report for one finding.

Key Takeaways

  1. Authorization is mandatory.
  2. Scoping protects both tester and client.
  3. Modern pentests include cloud, SaaS, identity, and CI/CD.
  4. Supply chain paths are valid attack paths when in scope.
  5. Proof of impact should be controlled and minimal.
  6. The report is the product.