The only reliable way to know whether a defence holds is to attack it. Offensive security testing — pentesting and red teaming — does exactly that: it hires professionals to breach an organisation's systems with its consent, before a real adversary does so without it. Although the two terms are often used interchangeably, they are distinct disciplines with different objectives, scope and depth. This article clarifies that difference, walks through the phases of a penetration test, reviews the standard methodologies and addresses the legal framework that separates an authorised assessment from a criminal offence.
Pentesting versus Red Teaming: two different objectives
A penetration test (pentest) aims to find and demonstrate as many vulnerabilities as possible within a defined scope — a web application, a network range, an API — during a fixed time window. Its success metric is coverage: the more valid, well-documented findings, the better. The defending team (blue team) typically knows the test is taking place.
A red team exercise, by contrast, is not about coverage but about realism. It simulates a specific adversary with a specific objective — for example, exfiltrating the customer database or compromising the Active Directory domain — and measures the organisation's real detection and response capability. Stealth is essential: the blue team is usually unaware of the exercise, which allows a genuine assessment of its controls. The difference can be summed up as follows: the pentest asks "what flaws do I have?"; the red team asks "would I notice if I were being attacked?".
| Criterion | Pentest | Red Team |
|---|---|---|
| Objective | Maximum vulnerability coverage | Achieve a specific goal as an adversary would |
| Scope | Defined and known | Broad, often the entire organisation |
| Blue team awareness | Usually informed | Not informed (stealth) |
| Duration | Days to weeks | Weeks to months |
| Measures | Vulnerability surface | Detection and response capability |
There is also purple teaming, where the red and blue teams collaborate in real time so that each offensive technique immediately improves a defensive capability.
The phases of a penetration test
Recognised methodologies — the OWASP Web Security Testing Guide, the PTES (Penetration Testing Execution Standard) and the NIST SP 800-115 technical testing framework — all converge on an essential sequence:
- Reconnaissance: gathering information about the target, both passively (OSINT, public records, DNS) and actively (port scanning with Nmap, service fingerprinting).
- Vulnerability analysis: identifying weaknesses using automated scanners and manual verification. The scanner generates hypotheses; the analyst confirms which ones are real.
- Exploitation: leveraging a vulnerability to gain access. This is where real impact is demonstrated, not just potential.
- Post-exploitation: privilege escalation, lateral movement and persistence. It answers the question "once inside, how far can I go?".
- Reporting: the most important phase and the most neglected. Without an actionable report, everything else counts for nothing.
Risk classification and tools
Every finding must be scored using an objective criterion. The de facto standard is CVSS (Common Vulnerability Scoring System), which assigns a score from 0 to 10 based on exploitability and impact vectors, translatable into severity categories ranging from critical to low. Known vulnerabilities are identified by their CVE (Common Vulnerabilities and Exposures) identifier, and weakness classes by their CWE (Common Weakness Enumeration). To prioritise what to fix first, the Known Exploited Vulnerabilities (KEV) catalogue maintained by the US agency CISA indicates which vulnerabilities are being actively used in real attacks — a factor that carries more weight than the theoretical score alone.
The standard toolkit includes Nmap for network discovery, Burp Suite for web application testing, Metasploit as an exploitation framework, and Cobalt Strike or Sliver for adversary simulation in red team exercises. Observed tactics are mapped against MITRE ATT&CK, the catalogue of attacker behaviours that serves as a common language between offence and defence.
The vulnerabilities that appear most often
Although every environment is different, certain weakness classes recur across most web application assessments. The OWASP Top Ten ranks them by prevalence and impact, and it is worth knowing them because they are the first place that both an assessor and a real attacker will look:
- Broken access control: users accessing resources or functions they are not entitled to — for example, changing an identifier in the URL to view another customer's data (insecure direct object reference). This is the most widespread category.
- Cryptographic failures: sensitive data transmitted or stored without adequate encryption, or using obsolete algorithms.
- Injection: SQL, operating system commands or LDAP, where unvalidated input is executed as code. This class has persisted for decades since its discovery.
- Insecure design: flaws that arise from architectural decisions, not implementation errors, and that no targeted patch can resolve.
- Security misconfiguration: services running with default credentials, excessive permissions or error messages that reveal internal information.
A recurring observation in serious reports is that business logic vulnerabilities — flows that allow, for example, applying a discount twice or bypassing a payment validation step — are the most valuable findings and the ones no automated tool detects, because they require understanding what the application should do, not just what it does. That is the difference between a scan and a real penetration test carried out by a skilled professional.
The report: where the value lies
A good report is structured on two levels. The executive summary, free of jargon, communicates the business risk to senior management: what the organisation could lose and how likely that is. The technical detail documents each finding with its description, reproducible evidence (screenshots, requests, exact steps), CVSS score, impact and, above all, a concrete remediation recommendation. A finding with no reproduction steps and no remediation guidance is noise. The quality of a pentest is judged by the usefulness of its report, not by the number of vulnerabilities listed.
Common mistakes
The first is relying solely on automated scanners: tools generate abundant false positives and, worse still, false negatives on business logic that no machine can detect. The second is not defining scope in writing, which leads to testing on unauthorised assets — a serious legal problem. The third is delivering a scanner dump as a report, without prioritisation or business context. The fourth is treating the pentest as an annual compliance formality rather than integrating it into the development cycle; a one-off test captures a moment in time, while threats are continuous. The fifth, in red team exercises, is accidentally breaking stealth and contaminating the detection assessment.
Legal framework: authorisation is everything
The boundary between a legitimate security assessment and a criminal offence is a single document: written authorisation. Unauthorised access to computer systems is a criminal offence in most jurisdictions — in Spain it is covered by Articles 197 bis and related provisions of the Penal Code — which means that without a contract defining scope, time window, included and excluded assets and a "get out of jail" clause protecting the assessor, any offensive test is illegal. The Rules of Engagement must specify which techniques are prohibited — typically denial of service and aggressive social engineering unless explicitly agreed — and who to notify if a pre-existing compromise is discovered. When tests touch personal data, the GDPR applies in addition, and it is advisable to align the process with security management standards such as ISO/IEC 27001, which treats technical tests as a verification control.
Frequently asked questions
How often should I run a pentest?
At a minimum, annually and after any significant change to the architecture or a critical application. Many compliance frameworks require it, but sound security logic calls for integrating it continuously, not just once a year.
Does a pentest guarantee that my system is secure?
No. It demonstrates that certain vulnerabilities exist, not that others do not. The absence of findings within a defined scope is not equivalent to absolute security.
Black box, grey box or white box?
In a black-box test the assessor receives no prior information (simulating an external attacker); in a white-box test they have full access to the code and architecture (maximising coverage); grey box is a middle ground. For most applications, grey box offers the best balance between realism and efficiency.
Can I run pentests against cloud services?
Yes, but major providers have specific policies on what can be tested and what requires prior notification. Reviewing those rules before starting is mandatory.
Conclusion
Pentesting and red teaming are not the same tool with two names: the former inventories your weaknesses, the latter tests whether you would notice a real attack. Choosing incorrectly between the two wastes budget — a red team exercise for a recently launched application is overkill, and a scoped pentest does not reveal whether your SOC can detect a stealthy intrusion. The value of either approach lies not in the spectacular exploitation phase, but in a report that management understands and the technical team can act on, and in written authorisation that keeps the entire exercise within the law. At Summum Sistemas we approach offensive testing as part of a continuous improvement cycle, with clear Rules of Engagement and actionable deliverables, because a vulnerability we find is a crisis your organisation will never have to live through.