Find what an attacker would find — before they do.

A vulnerability scanner finds known CVEs. A penetration tester chains a medium-severity XSS with a misconfigured CORS policy and a predictable session token into a full account takeover.

The distinction between a vulnerability assessment and a penetration test is the distinction between a list of potential problems and a demonstration of actual exploitability. Automated scanners are excellent at finding outdated dependencies, missing security headers and known CVE patterns. They cannot find: an IDOR that lets you access another user's data by incrementing an ID parameter, a business logic flaw that lets you apply a discount code unlimited times, or the chain of three medium-severity issues that combine into a critical account takeover. Penetration testing requires a human who reads your application like an attacker — understanding what it is trying to protect, where the value is, and what the path of least resistance to that value looks like.

What a PROPELOO penetration test covers.

Different attack surfaces require different methodologies. Each engagement is scoped to the specific system and threat model.

System Layers

• Reconnaissance: Attack surface enumeration, technology fingerprinting, credential exposure scanning, third-party exposure
• Vulnerability Identification: Automated scanning + manual verification, false positive triage, novel vulnerability discovery
• Exploitation: Actual exploitation of verified vulnerabilities to demonstrate real impact
• Post-exploitation: Privilege escalation, lateral movement, data exfiltration simulation, persistence
• Reporting: Executive summary, technical findings with PoC, CVSS scoring, remediation guidance

Core Technical Capabilities

• Web Application Testing

  OWASP Top 10 coverage, business logic testing, authentication bypass, authorisation flaws (IDOR, privilege escalation), injection attacks, XSS/CSRF, session management and API security. Authenticated and unauthenticated assessment.

• API Security Testing

  REST and GraphQL API testing — BOLA/IDOR, broken authentication, mass assignment, rate limiting bypass, GraphQL introspection abuse, injection via API parameters, JWT vulnerabilities and API versioning issues.

• Mobile Application Testing

  iOS and Android testing — insecure data storage, certificate validation bypass (SSL pinning), client-side injection, improper authentication, binary analysis for hardcoded credentials, API traffic interception and runtime manipulation with Frida.

• Cloud Infrastructure Testing

  AWS/GCP/Azure misconfiguration — IAM privilege escalation, publicly accessible S3 buckets, metadata service exploitation (SSRF → IMDS), exposed management interfaces, secrets in environment variables and container escape.

• Network & Infrastructure Testing

  Internal network segmentation testing, exposed services on non-standard ports, SSL/TLS configuration review, default credential testing on network devices and VPN configuration assessment.

• Social Engineering Assessment

  Phishing simulation, pretexting scenarios, physical security assessment and security awareness baseline measurement — with metrics on click rate, credential submission and reporting rate.

How we think about penetration testing.

The best penetration testers think like developers who went wrong. They understand how the application was built and use that understanding to find the gaps between intended behaviour and actual behaviour.

• Context changes everything

  A generic OWASP Top 10 checklist applied without context finds generic vulnerabilities. A tester who has read the application architecture, understands what data is most sensitive and knows what the application's business logic is designed to prevent — that tester finds the vulnerabilities that matter. We spend time understanding the application before writing a single test payload.

  Axiom:

• Business logic bugs are the prize

  SQL injection and XSS are documented, well-understood and often caught by automated tools. The bugs that cause real data breaches are business logic flaws: the API endpoint that requires authentication in the UI but not the backend, the rate limit that applies per IP but not per account, the export function that does not check whether the requesting user owns the exported data. These require a human who is actively trying to misuse the application.

  Axiom:

• Chaining is where critical findings come from

  Many penetration test findings are labeled medium or low severity in isolation. The critical findings come from chaining: an information disclosure that reveals a username format, combined with a lack of account lockout, combined with a predictable session token, combined with a CORS misconfiguration — individually medium, combined critical. We do not stop at the first finding.

  Axiom:

• A finding without a reproduction path is not a finding

  Every finding in a PROPELOO report includes exact reproduction steps, HTTP request/response captures or screenshots demonstrating successful exploitation, and clear explanation of the business impact. A report that says "SQL injection detected in /api/login" without a working PoC is not useful to a developer trying to understand and fix the issue.

  Axiom:

The pentest decisions that determine coverage depth.

Scope, methodology and timing define what the test finds.

• Black box vs grey box vs white box?

  Impact: White box for finding the most issues. Grey box for the most realistic simulation of an attacker with some prior knowledge (e.g. a disgruntled employee). Black box for executive-level confidence that external attackers cannot easily compromise the perimeter.

  • Black box — no prior knowledge, simulates external attacker, lower coverage
  • Grey box — credentials + basic documentation, most realistic, recommended for most assessments
  • White box — full source code and architecture access, highest coverage, most vulnerabilities found
  • Purple team — attacker and defender work together, detects both vulnerabilities and detection gaps

• Full pentest vs vulnerability assessment?

  Impact: Penetration test for genuine security improvement. Vulnerability assessment for compliance where demonstration of exploitation is not required. Red team for mature security programmes that want to test detection and response, not just prevention.

  • Vulnerability assessment — automated + manual verification, no exploitation, compliance focus
  • Penetration test — full exploitation, chaining, demonstrates real impact
  • Red team — full adversarial simulation including detection evasion, tests response capability
  • Bug bounty — continuous community-driven coverage, variable depth

• Testing against production vs staging?

  Impact: Staging with production-identical configuration for most testing. Production for passive reconnaissance and targeted testing of specific endpoints that cannot be replicated in staging. Always have a documented stop condition and emergency contact during production testing.

  • Production — real data, real configuration, highest risk of disruption
  • Staging with production-identical config — safer, may miss production-specific issues
  • Staging for active testing, production for passive recon — balanced approach
  • Development environment — lowest risk, least realistic

• How often to test?

  Impact: Quarterly manual testing for actively developed products, combined with SAST in CI for continuous coverage of new code. Annual minimum for stable products. Always test before a major release that adds authentication, payment or data access functionality.

  • Once before launch — minimum viable, catches pre-launch issues only
  • Annually — common, misses issues introduced by 12 months of development
  • Before major releases — tests changes, misses baseline drift
  • Quarterly + SAST in CI — best practice for actively developed products

• Internal team vs external firm?

  Impact: External firm for the primary annual penetration test — familiarity with the codebase creates blind spots that an external tester does not have. Internal team for ongoing security testing between external engagements.

  • External firm — fresh perspective, no familiarity bias, credible for compliance
  • Internal security team — deep context, continuous availability
  • Hybrid (internal + external) — external for annual assessment, internal for continuous testing
  • Bug bounty programme — supplement to internal/external, not replacement

• What to test first?

  Impact: Authentication flows and data access controls first — these are the highest-impact vulnerability classes and the most likely to have critical findings. Business logic testing requires the most time but finds vulnerabilities that no other methodology covers.

  • Authentication and session management — highest impact if broken
  • Data access controls (IDOR/BOLA) — most common critical finding class
  • Third-party integrations — often less tested, high impact
  • Business logic — highest ROI, not covered by automated tools

What PROPELOO tests.

• Web Application Pentest

  Full OWASP Top 10 + business logic testing with authenticated and unauthenticated assessment. PoC for every finding. Remediation guidance and re-test.

• API Security Assessment

  REST and GraphQL API testing — BOLA, broken auth, rate limiting, mass assignment, JWT vulnerabilities and injection via API parameters.

• Mobile App Pentest

  iOS and Android assessment — data storage, certificate pinning bypass, binary analysis, runtime manipulation with Frida and API traffic testing.

• Cloud Security Assessment

  AWS/GCP/Azure configuration testing — IAM privilege escalation, exposed resources, SSRF to metadata service and secrets exposure.

• Pre-launch Security Review

  Comprehensive assessment before production launch — web app, API, cloud infrastructure and third-party integrations. Go/no-go recommendation.

• Smart Contract Audit

  Solidity and Rust smart contract security review combined with economic attack modelling. Required before mainnet deployment for any protocol handling real value.

The penetration testing toolchain.

Different attack surfaces require different tools. No single tool finds everything.

• Web & API

  Stack: Burp Suite Pro, OWASP ZAP, Postman, ffuf (fuzzing), nuclei, sqlmap

• Mobile

  Stack: Frida, Objection, MobSF, apktool, jadx, iProxy

• Cloud

  Stack: Prowler, ScoutSuite, Pacu (AWS), CloudMapper, Checkov, TruffleHog

• Network

  Stack: Nmap, Nessus, Metasploit, Nikto, Wireshark, Responder

• OSINT & Recon

  Stack: Shodan, Censys, theHarvester, Amass, GitLeaks (secret scanning)

• Reporting

  Stack: Dradis, PlexTrac, Custom CVSS scoring templates, PoC documentation

Penetration testing methodology follows industry standards.

OWASP, PTES and OSSTMM provide the framework. Adversarial creativity fills the gaps.

• Injection Attacks

  SQL injection (error-based, blind, time-based), NoSQL injection, LDAP injection, OS command injection, SSTI and XML injection — tested with both automated payloads and manual context-aware variants that scanners miss.

• Broken Access Control

  IDOR (horizontal privilege escalation), missing function-level access control (vertical privilege escalation), path traversal, JWT manipulation and forced browsing to restricted resources.

• Authentication Weaknesses

  Brute force without lockout, credential stuffing, weak password policy, insecure password reset flows, session fixation and OAuth misconfiguration.

• Security Misconfiguration

  Default credentials on admin interfaces, verbose error messages, debug mode in production, CORS misconfiguration, missing security headers and directory listing.

• Cryptographic Failures

  Sensitive data in HTTP, weak encryption algorithms, hardcoded keys in source code, predictable token generation and improper certificate validation.

• Supply Chain & Third-party

  Outdated dependencies with known CVEs, third-party integrations with excessive permissions, webhook endpoints without signature validation and exposed API keys in client-side code.

The PROPELOO penetration test process.

1. 01. Scoping & Rules of Engagement

   Define scope, testing methodology, timing, communication protocol and escalation path for critical findings.

2. 02. Reconnaissance

   Passive and active recon — technology fingerprinting, endpoint enumeration, exposed credential scanning, third-party exposure.

3. 03. Automated Scanning

   Authenticated and unauthenticated automated scanning. False positive triage before manual testing.

4. 04. Manual Exploitation

   Manual exploitation of findings. Business logic testing. Authentication bypass. Privilege escalation. Lateral movement simulation.

5. 05. PoC Development

   For critical and high findings: proof-of-concept demonstrating real impact — data accessed, accounts compromised, systems breached.

6. 06. Report Delivery

   Executive summary + technical report with every finding: description, evidence, CVSS, business impact, remediation steps.

7. 07. Remediation Support & Re-test

   Developer Q&A, fix guidance and re-test of all critical/high findings after remediation. Final attestation.

Frequently Asked Questions