Pentest: what it is and how a penetration test works

What a pentest is and why it differs from a vulnerability scan

A pentest, or penetration test, is an authorized offensive exercise in which security professionals simulate the behavior of a real attacker to identify, exploit and demonstrate the impact of vulnerabilities in systems, networks, web applications, APIs, mobile apps and cloud environments. The goal is not merely to list flaws, but to prove they are exploitable and to measure the concrete damage they would cause: access to customer data, improper financial movement, privilege escalation or full compromise of the environment.

The essential difference from a vulnerability scan is the presence of human intelligence and active exploitation. A scanner (Nessus, Qualys, OpenVAS, Burp Scanner) compares known versions and signatures against a CVE database and returns a list of possible issues — fast, cheap and full of false positives, without confirming whether the flaw is actually exploitable in context. A pentest validates each finding manually, chains low-severity flaws into a high-impact attack (chaining) and uncovers business-logic vulnerabilities that no scanner detects, such as bypassing transfer limits, manipulating the checkout flow or abusing authorization rules.

In practice, scanning and pentesting are complementary: automated scanning provides continuous coverage and basic hygiene between tests; the pentest is the deep, manual, contextual assessment. For fintechs, crypto exchanges and e-commerces that process real transactions, what matters is the latter — because the attacker trying to drain a wallet or defraud a payment also uses human reasoning, not just automated tools.

Types of pentest: black, grey and white box, and the targets tested

Pentests are classified first by the level of information given to the tester. In a black box, the team receives only the target (a domain or an IP) and acts as an external attacker with no inside knowledge — realistic, but slower and with the risk of not covering deep areas within the contracted time. In a grey box, the tester receives ordinary user credentials and partial documentation, simulating a customer, partner or low-privilege insider; it offers the best value for applications, since it maximizes coverage per hour. In a white box (or crystal box), there is full access to source code, architecture and administrative credentials, enabling the most exhaustive analysis possible, recommended for critical systems and in-depth security reviews.

In parallel, a pentest is classified by the type of target. A web application pentest focuses on flaws such as injection, broken authentication, access control and business logic. An API pentest (REST, GraphQL, gRPC) tests object-level authorization (BOLA/IDOR), authentication, rate limiting and data exposure — a critical vector in fintechs and mobile apps. A mobile pentest (Android and iOS) analyzes the client app, local storage, communication, certificate pinning and the backend API. A cloud pentest evaluates AWS, Azure and GCP configurations: IAM, buckets, security groups, secrets and privilege escalation paths. An external network pentest simulates the attacker on the internet against the perimeter; the internal network pentest assumes the intruder is already inside (successful phishing, a compromised device) and tests lateral movement.

Red Team is a category of its own: instead of covering the maximum surface, it pursues a specific objective (for example, accessing the customer database or the custody wallet) by simulating an advanced, persistent adversary, with no prior warning to the defense team (Blue Team), combining technical exploitation, social engineering and, at times, physical intrusion. It measures not only the existence of flaws but the organization's real detection and response capability. Decripte runs both manual web, API, mobile and cloud pentests and Red Team exercises targeted at fintechs, crypto companies and apps.

Reference methodologies and frameworks

A professional pentest follows recognized methodologies, which ensures reproducibility, coverage and comparability across tests. For web applications, the reference is the OWASP Web Security Testing Guide (WSTG) — stable version 4.2, with 5.0 in development — which details hundreds of tests by category (authentication, authorization, session management, input validation, business logic, including GraphQL injection). For mobile, the OWASP MASTG (Mobile Application Security Testing Guide), aligned with the MASVS verification standard, covers technical tests for Android and iOS. The OWASP Top 10 taxonomy and the OWASP API Security Top 10 guide prioritization, but do not replace the WSTG/MASTG as an execution guide.

For the end-to-end engagement process, PTES (Penetration Testing Execution Standard) defines seven phases — pre-engagement, information gathering, threat modeling, vulnerability analysis, exploitation, post-exploitation and reporting. NIST SP 800-115 (Technical Guide to Information Security Testing and Assessment) is the formal, compliance-oriented standard, with planning, discovery, attack and reporting phases. The OSSTMM (Open Source Security Testing Methodology Manual) brings a broader operational view, including physical, human, wireless and telecommunications security.

To describe adversary tactics and techniques — especially in Red Team and post-exploitation — MITRE ATT&CK is used, a matrix that catalogs real attacker behavior (reconnaissance, initial access, execution, persistence, escalation, lateral movement, exfiltration). Mapping findings against ATT&CK lets the client connect each vulnerability to the techniques it enables and assess their detection defenses. A good provider combines these references: WSTG/MASTG for technical depth per target, PTES or NIST for engagement structure and ATT&CK to contextualize the adversary.

The phases of a penetration test

Reconnaissance (recon): gathering information about the target. It includes OSINT (subdomains, leaked emails, public repositories, metadata, exposed infrastructure), DNS footprinting and discovery of the attack surface. In a black box, this phase maps everything an attacker would see from the internet without credentials.

Enumeration: from the identified surface, services, ports, technologies, versions, API endpoints, parameters, user roles and application flows are mapped. This is where the tester understands the business logic and forms attack hypotheses — the step that separates a manual pentest from a scan, which builds no such mental model.

Exploitation: active, controlled attempts to exploit the identified vulnerabilities — injection, authorization flaws (IDOR/BOLA), authentication bypass, SSRF, deserialization, business-logic flaws. The goal is to confirm the flaw with concrete proof, not merely suspect it, always within the agreed scope and rules of engagement so as not to cause damage or downtime.

Post-exploitation: with an initial foothold, the tester measures the real impact — privilege escalation, access to sensitive data, lateral movement, persistence and reach to critical assets (customer database, payments environment, custody wallet). This phase answers the question that matters most to the business: how far an attacker would get.

Reporting: documentation of each vulnerability with evidence, risk classification (CVSS v4.0), a reproducible proof of concept (PoC) and prioritized remediation recommendations. It includes an executive summary for leadership and a technical breakdown for engineering teams.

Retest: after the client remediates, it is validated that each fix is effective and introduced no regressions or new flaws. The retest closes the loop and is often required by auditors and regulators as evidence of remediation. Decripte maintains an SLA to contain a critical incident within 1 hour should the test reveal an exposure already under active exploitation.

The deliverable: what to expect from the report and how to evaluate a provider

The final product of a pentest is the report, and its quality defines the value of the service. A good report has two layers. The executive report, aimed at leadership and auditors, summarizes the security posture, the business risk, the main findings and the overall recommendation in accessible language, without jargon. The technical report, for engineering teams, describes each vulnerability individually: description, exact location (endpoint, parameter, request), severity calculated by CVSS v4.0 (with the vector made explicit, not just the score), a step-by-step reproducible proof of concept, evidence (requests, responses, captures) and a specific, actionable remediation recommendation — not generic advice.

To evaluate a provider, look for concrete signals. Predominance of manual testing over scanner output: ask for a sample report and check whether it contains business-logic findings, flaw chaining and real PoCs, or only items any scanner would generate. Adherence to methodologies (WSTG, MASTG, PTES, NIST) that is stated and demonstrable. Mapping against MITRE ATT&CK in Red Team engagements. Team certifications (OSCP, OSWE, OSEP, CRTO, GPEN, GXPN) as evidence of real offensive competence. Clear rules of engagement, NDA and insurance. An included retest offering. Immediate communication of critical flaws during the test, rather than only at the end.

Be wary of providers who deliver just a scanner export relabeled as a pentest, who cannot show an anonymized sample report, who do not distinguish technical severity from business risk, or who do not offer a retest. The lowest price almost always corresponds to an automated test with a pentest veneer — which does not protect against a motivated human attacker.

When and how often to run a pentest

The consolidated rule of thumb is: at least once a year and always after significant changes — a new application, a relevant architecture refactor, an infrastructure migration, a new critical integration or a new payment flow. Significant change, not the calendar, is the most important trigger, because that is exactly when new flaws are introduced.

Regulatory and contractual drivers raise this frequency. In PCI-DSS 4.0, requirement 11.4 mandates internal and external pentests of the cardholder data environment (CDE) at least annually and after significant changes; segmentation controls must be tested annually — and every six months for service providers. In Brazil, the Central Bank's cybersecurity policy, updated by Resolution BCB 538/2025 and Resolution CMN 5.274/2025 (with a compliance deadline of March 1, 2026 for institutions already in operation), reinforces the requirement for periodic penetration tests, conducted independently by a specialized team, with documentation of findings and the action plan kept available to the regulator. The LGPD, although it does not name pentest explicitly, requires adequate technical security measures (art. 46), and the pentest is the objective evidence that those measures have been verified.

There is also the due diligence trigger: investment rounds, M&A and the onboarding of large corporate clients frequently require a recent pentest as a condition. For products that change continuously, the sensible approach is a recurring cycle — a comprehensive annual or semiannual pentest, complemented by targeted tests at each critical release and by continuous scanning in between. Decripte structures this program for fintechs, crypto companies and apps, aligning the cadence with the requirements of BACEN, PCI-DSS, LGPD and investor demands.

Passo a passo

1. Define the scope and objectives: list the targets (applications, APIs, apps, cloud accounts, networks), the type of test (black, grey or white box) and what you want to uncover, considering the requirements of BACEN, PCI-DSS, LGPD or due diligence.
2. Select the provider carefully: ask for an anonymized sample report, check the predominance of manual testing, adherence to WSTG/MASTG/PTES/NIST, team certifications (OSCP, OSWE, OSEP, CRTO) and whether a retest is included.
3. Formalize the engagement: sign an NDA, formal authorization and rules of engagement (test windows, permitted environments, prohibited actions, emergency contacts and an immediate communication channel for critical findings).
4. Conduct the test following the phases: reconnaissance, enumeration, exploitation, post-exploitation — always within scope and without causing unauthorized downtime.
5. Receive and analyze the report: review the executive summary, the technical breakdown with CVSS v4.0, the reproducible PoC and the recommendations; prioritize remediation by business risk, not just by technical score.
6. Remediate the vulnerabilities and document the action plan, keeping the evidence available to auditors and the regulator where applicable.
7. Request the retest to validate that each fix was effective and introduced no regressions, closing the loop, and schedule the next round according to the defined cadence.

Perguntas frequentes