Making sense of all the penetration testing types

Do you need to find out which type of penetration testing your company needs? Do you even need a penetration test, and if so, which kind?

You’ve come to the right place. I have helped nuclear power plants defend themselves, banks, SaaS companies, fintechs, medtech companies, etc. So, I’ve got first-hand experience with most pent types listed here and will try to cover as much ground as possible to describe them well. 

Why would one need to perform a penetration test? 

People come to us most commonly because someone forces them to run a pentest. 

Are there laws and regulations forcing you to run a penetration test?

I believe you should only run a penetration test after thoroughly protecting your IT infrastructure. But regulatory requirements don’t care about that – you might be forced to perform at least one penetration test per year, depending on your business type and location. 

United States

1. PCI DSS (Payment Card Industry Data Security Standard)

It would apply to you, if you handle payment card data – such as accepting card payments on your website or within your app. 

The PCI-DSS requirement is to run annual penetration tests (internal and external) after significant changes to your infrastructure.

Reference: PCI DSS Requirement 11.3.

2. HIPAA (Health Insurance Portability and Accountability Act)

If you store and/or process patient data, you have to comply with HIPAA.

While not explicitly requiring penetration tests, HIPAA’s Security Rule mandates risk assessments, for which penetration tests are often used.

3. CMMC (Cybersecurity Maturity Model Certification)

This applies to Department of Defense (DoD) contractors, for which regular penetration testing is required at higher maturity levels (e.g., CMMC Level 3+).

4. GLBA (Gramm-Leach-Bliley Act)

If you are a financial institution, then penetration tests may be necessary as part of the Safeguards Rule to identify vulnerabilities.

5. FISMA (Federal Information Security Management Act)

Applies to Federal agencies and contractors.

Your continuous monitoring and risk management programs should include penetration testing.

United Kingdom

1. PCI DSS

• Same as in the US.

2. NIS Directive (Network and Information Systems)

• Who it applies to: Operators of essential services (e.g., energy, health, and transport) and digital service providers.
• Requirement: Regular penetration testing is part of the security requirements.

3. ISO/IEC 27001

• Who it applies to: Organizations seeking ISO certification.
• Requirement: Penetration testing is recommended as part of a risk assessment strategy for ISO compliance.

4. Cyber Essentials Plus

• Who it applies to: Organizations seeking Cyber Essentials certification.
• Requirement: Includes vulnerability assessments and penetration testing for higher assurance levels.

European Union

1. PCI DSS

• Same as in the US.

2. NIS2 Directive

• Who it applies to: Expands on the original NIS Directive to include additional sectors and impose stricter cybersecurity requirements.
• Requirement: Regular security assessments, including penetration tests, are expected.

3. ENISA Recommendations

• Who it applies to: EU member states and critical infrastructure operators.
• Requirement: Encourages penetration testing as part of cybersecurity best practices.

4. SWIFT CSP (Customer Security Programme)

• Who it applies to: Organizations in financial services.
• Requirement: Annual penetration testing and red team exercises.

Australia

1. ACSC Essential Eight (Australian Cyber Security Centre)

• Who it applies to: Government agencies and critical infrastructure.
• Requirement: Regular penetration tests are recommended as part of the “Test and Patch” maturity model.

2. PCI DSS

• Same as in the US.

3. APRA CPS 234 (Australian Prudential Regulation Authority)

• Who it applies to: Financial services and insurers.
• Requirement: Regular penetration testing to assess vulnerabilities and validate the effectiveness of security controls.

4. Privacy Act 1988

• Who it applies to: Organizations handling personal data.
• Requirement: While penetration testing isn’t explicitly required, the “reasonable steps” principle often includes testing as part of due diligence.

Now that we know that you pretty much have to run a penetration test if your company falls under any of the regulations above, let’s see which are the types of pentest you might need to perform.

I will categorize them based on target, methodology, or environment. 

1. Based on Target

1.1. Network Penetration Testing

Its focus is to identify vulnerabilities in internal and external networks. It often includes: Firewalls, routers, switches, wireless networks and their configuration. It is worth conducting such a pentest, because hackers can easily take advantage of a weak point in your network. 

Network penetration testing could target MPLS networks, virtual private networks, remote access in a “work from home” scenario, etc. 

Why would you need to run a network penetration test? 

1. Identify Security Vulnerabilities
   1. Detect misconfigurations, unpatched software, or design flaws in the network infrastructure.
   2. Expose potential entry points for attackers, such as open ports or weak protocols.
2. Test the Effectiveness of Security Measures
   1. Evaluate the functionality of firewalls, intrusion detection/prevention systems (IDS/IPS), and other defenses.
   2. Confirm that network segmentation and access controls are properly configured.
3. Simulate Real-World Attacks
   1. Assess the network’s resilience against common attack vectors like:
   2. Denial-of-Service (DoS) attacks.
   3. Man-in-the-Middle (MITM) attacks.
   4. Exploitation of vulnerabilities in network services.
   5. Understand how an attacker might exploit the network.
4. Protect Sensitive Data
   1. Ensure the security of sensitive information in transit, such as personal data, financial transactions, or intellectual property.
   2. Validate encryption protocols like SSL/TLS.

1.2. Web Application Penetration Testing

Its focus is to evaluate the security of web apps and APIs. You might be surprised at the amount of tools available for free on Github and as paid software and services to enable penetration testers and hackers to conduct tests against your web applications and APIs. 

Many of them are automated, but most require some level of deep understanding of how web apps work and how to operate the tools to achieve the desired result. 

Type of Web App Pentesting	Definition	Focus Areas	Methods Used	Best For
Black Box Testing	Testing without prior knowledge of the application.	External attack vectors, unauthenticated access.	Reconnaissance, fuzzing, brute-forcing.	Simulating attacks from external threat actors.
White Box Testing	Testing with full access to source code and architecture.	Code logic, authentication, session handling.	Code reviews, static and dynamic analysis.	Internal testing for comprehensive analysis.
Gray Box Testing	Testing with partial knowledge of the application.	Privileged access misuse, logic flaws.	User simulations, API testing.	Mimicking insider threats or semi-privileged users.
API Penetration Testing	Testing the security of API endpoints.	Authentication, data exposure, rate limiting.	API fuzzing, parameter tampering.	Applications heavily reliant on APIs.
Dynamic Application Security Testing (DAST)	Automated testing focused on runtime behavior.	Input validation, response anomalies.	Automated scanning tools (e.g., Burp Suite).	Quick scans of live applications.
Static Application Security Testing (SAST)	Testing application code without execution.	Code structure, known vulnerabilities.	Code analyzers, static scanners.	Pre-deployment testing during development.
Mobile Application Testing	Testing mobile web apps or hybrid applications.	Secure API calls, local storage vulnerabilities.	Emulator testing, reverse engineering.	Mobile-specific web interfaces and apps.
Client-Side Testing	Evaluating vulnerabilities in client-side scripts.	Cross-site scripting (XSS), DOM manipulation.	Manual testing, browser debugging tools.	Frontend-heavy web apps.
Server-Side Testing	Analyzing vulnerabilities in backend operations.	Injection flaws, authentication bypass.	Manual SQL injection, command execution.	Backend-heavy or database-driven apps.
Business Logic Testing	Testing for flaws in workflows and application logic.	Logic flaws, privilege escalation.	Manual workflows analysis, user simulation.	Financial or complex process-based systems.

 

Web app pentests are looking for vulnerabilities such as: SQL injection, XSS, CSRF, session management flaws, but also misplaced backups (which might just as well include the plaintext passwords to the database), renamed system files, credentials stuffed in config files, among many other flaws. 

1.3. Mobile Application Penetration Testing

The objective usually is to find vulnerabilities in iOS and Android applications. Often is a mix of examining the apps and web app penetration testing, as the mobile apps usually utilize the same or similar APIs or databases with the web versions of the same apps/business/SaaS. 

Mobile app penetration testers look for data leakage, insecure API calls, local storage issues, lack of code obfuscation, root detection, local configuration file credentials, etc. 

1.4. Wireless Penetration Testing

• Focus: Assesses wireless infrastructure.
• Includes: WPA/WPA2 cracking, rogue access points, WEP vulnerabilities.

Wireless security testing is critically important for organizations with physical locations, but is applicable even when they are fully remote.  Imagine your most critical data resides on a vulnerable device at someone’s home, and their WiFi network gets compromised by a targeted attack. Unfortunately, most WiFi networks at home are severely vulnerable to attack and breaking them takes less than 15 minutes even to unsophisticated teenage hackers.

Wireless penetration testing evaluates how susceptible your organization is to the most trivial of attacks. Ideally, even if a hacker is able to break into your WiFi network, they should be unable to see any clear-text traffic as all endpoints on your network should encrypt all data traveling wirelessly (such as, connecting to a VPN when on WiFi). 

Wireless penetration testing usually includes signal interception, device spoofing, and pairing flaws.

1.5. Cloud Penetration Testing

• Focus: Identifies risks in cloud-based services and architectures.
• Includes: Misconfigurations, insecure APIs, access control flaws.

Anything and everything can be in the Cloud nowadays. Whatever your business, you’re either using Microsoft, Azure, Google, Baidu or some other major cloud service provider. Some of these setups might include hybrid environments and contain incredibly complex architectures, just begging for human error and misconfiguration. 

Thus, cloud penetration testing is a must for most modern companies, at least once per year. 

1.6. Social Engineering Penetration Testing

Probably the most interesting type of penetration testing, for many reasons. Social engineering can’t easily be controlled with technical measures. You can’t just ‘buy another firewall’ and fix the social engineering problem. It has many angles: will the social engineer call your team? Text them? Send them emails? Will they just drop USB drives around the office? Will they simply listen in on conversations in the restaurant next to your office, and use that info to gain further ground?

Social engineering penetration testing tests human susceptibility to manipulation.

• Includes: Phishing attacks, baiting, impersonation.

1.7. Physical Penetration Testing

Physical penetration testing tests your physical security controls. It usually involves a significant portion of social engineering, but not necessarily. Physical security penetration testers own an impressive amount of physical security bypass devices and methods. 

When the rules of engagement allow it, they can even physically destroy your defenses, just as a criminal would. Your objective is to detect and stop them – and if you did not, then you have an opportunity to improve. Don’t get mad that they cut a cable here and there, get mad at your processes that did not detect them on time. 

This type of test usually evaluates your cameras, motion detectors, access control systems. The pentester will try to clone employee access cards, get in from unexpected locations and during the night or weekend, dress as a courier or repair man. They can try picking your locks and see how resistant they are to lockpicking. They might even try ‘dumpster diving’, looking through your trash for confidential information and client data. 

1.8. Database Penetration Testing

The most popular DBMS (database management systems) in the world have incredibly complex manuals on security. Not surprisingly, very few IT experts read the security section of these manuals. As a result, many databases are left misconfigured and insecure.

They need to be tested in a penetration test, considering the specifics of attacking a database. These are:

Authentication Mechanisms

• Weak or default credentials.
• Absence of multi-factor authentication (MFA).
• Poor password management policies.

Access Control and Privileges

• Excessive user privileges.
• Misconfigured roles and access controls.
• Absence of the principle of least privilege.

SQL Injection Vulnerabilities

• Unsanitized user inputs leading to SQL injection.
• Exploiting dynamic queries.

Database Configuration

• Weak database configurations.
• Unnecessary or misconfigured database features enabled.
• Insecure default settings.

Data Encryption

• Lack of encryption for data in transit and at rest.
• Weak or outdated encryption algorithms.

Backup and Recovery Mechanisms

• Insecure storage of backups.
• Lack of encryption for backup data.

Database Communication Protocols

• Use of outdated or insecure protocols.
• Vulnerabilities in database-specific communication.

Auditing and Logging

• Lack of proper logging mechanisms.
• Insecure storage of log files.
• Failure to monitor database activities.

Stored Procedures and Triggers

• Vulnerabilities in stored procedures.
• Exploitable triggers leading to privilege escalation.

Third-Party Integrations

• Insecure connections with external applications.
• Weak integration points between the database and third-party tools.

Data Exposure

• Overexposed sensitive data.
• Lack of masking or anonymization for production data.

Denial of Service (DoS)

• Lack of protections against resource exhaustion.
• Vulnerabilities that can cause database unavailability.

1.9. API Penetration Testing

API penetration testing evaluates API endpoints for vulnerabilities. Often developers leave publicly-available API endpoints unprotected, wrongly presuming that if it’s not linked from somewhere, the hackers would never find out about it. 

But if your application (on a mobile phone, or in a web app) calls this API endpoint, the hacker can just intercept the request and see where it’s going. Then it is simply about following attack playbooks. 

Most often tested are broken authentication, rate limiting issues, insecure object references, and input sanitization (not necessarily user input, but also service-to-service communication). 

Based on Methodology

Black Box Penetration Testing

• The tester has no knowledge of the target company’s network. They don’t know the operating systems to be tested, they don’t know the number of servers, nothing. Usually, they’re just given an IP address range and a couple of email addresses. Penetration testers love this kind of penetration testing most, because it gives them a wildcard on creativity in their approach. 
• This is the best way to simulate a real-life attack before one materializes. 

White Box Penetration Testing

• The tester has full access to system details like source code and architecture.
• Identifies vulnerabilities from an insider’s perspective.

Gray Box Penetration Testing

• The tester has limited knowledge, such as user credentials or network architecture.
• Simulates an insider attack with restricted privileges.

Based on Environment

External Penetration Testing

• Focus: Assesses vulnerabilities in publicly accessible assets.
• Includes: Websites, public-facing servers, DNS configurations.

Internal Penetration Testing

• Focus: Evaluates security from within the organization.
• Simulates an attack from a compromised device or insider threat.

3.5. Red Team Engagements

• Focus: Simulates sophisticated attacks mimicking real-world threat actors.
• Includes: A mix of physical, social, and technical penetration testing.

Specialized Types

DevSecOps Penetration Testing

A hacker or even a malicious insider could break your CI/CD process and compromise your DevSecOps practices. That is why it is important to launch DevSecOps penetration tests at least once a year.

The pentester will then evaluate the whole system for flaws – not just weaknesses and vulnerabilities, but missed steps or misconfiguration.

Integrates security testing into CI/CD pipelines. DevSecOps penetration testing includes code vulnerabilities and deployment misconfigurations.

Blockchain Penetration Testing

Blockchain projects were thought to be ‘secure by default’ due to the immutable nature of the blockchain. But it turned out they are quite vulnerable. Tests blockchain-based applications and smart contracts.

Smart contracts audit is a significant part of penetration testing a blockchain project, especially if it is built on the Ethereum or a similar network.

You should audit consensus vulnerabilities, cryptographic flaws, and wallet security.

Wireless and Bluetooth Penetration Testing

Physical devices need to be checked for firmware and hardware vulnerabilities. Firmware hacking requires advanced reverse engineering skills and as such, this is more of a reverse engineering job with a focus on security, than it is penetration testing. It includes chip-level testing, side-channel attacks and tampering risks.

Additionally, physical devices are checked for electromagnetic emanations, as sometimes even hardware security modules and processors can emit clear-text information in the form of electromagnetic waves before they encrypt the data. You can refer to this Tempest article on Wikipedia.