Types of penetration testing, and which ones you need

Penetration tests are named after what they attack. NIST SP 800-115 describes penetration testing as security testing that mimics real-world attacks to find ways around the security features of an application, system or network, and that list of targets is roughly how the work divides. The type decides where the tester starts, what access they need and which skills the work calls for.

The five core types, by target:

• External network penetration testing: internet-facing hosts and services, attacked from the internet with no prior access.
• Internal network penetration testing: the network behind the perimeter, usually including Active Directory, attacked from a compromised laptop or account.
• Web application penetration testing: one application, its roles and its workflows, tested for what a user can do that they should not.
• API penetration testing: the endpoints behind your applications and integrations, tested object by object and role by role.
• Mobile application penetration testing: an iOS or Android app, what it leaves on the device and the API it depends on.

Desktop applications and wireless networks are tested on the same principle. Three neighbouring services are easily mistaken for penetration tests: a cloud configuration review, a phishing simulation and a red team exercise.

Network penetration testing examines infrastructure rather than applications: hosts, the services they expose and the identity systems that tie them together. It is done from two positions with different results, so in practice it is two tests: external testing shows how somebody gets in, and internal testing shows how far they get. Segmentation testing, which checks that isolated zones really are isolated, and wireless testing are narrower variants of the same work.

Both positions are usually needed for a complete picture. Network penetration testing can be scoped as external, internal or both, with Active Directory attack paths part of the internal work.

An external penetration test examines everything you expose to the internet: public address ranges and the services on them, VPN gateways and remote access portals, mail and file transfer services, and anything in a cloud account with a public address. The tester starts with no credentials, like any outsider. A scan produces the inventory; the test is what a person does with it.

What it usually finds:

• Services nobody meant to expose, such as a forgotten development server, a database port or remote desktop.
• Edge devices, VPN appliances and firewalls among them, running versions with published exploits.
• Login portals and administrative consoles that accept default credentials or unlimited password guessing.
• Weak TLS, expired certificates and verbose banners, worth fixing and rarely the serious part.

Any organisation with internet-facing infrastructure needs one, especially after a change to the perimeter such as a new remote access product, a hosting move or an acquisition. PCI DSS makes external testing a requirement of its own, 11.4.3, due at least once every twelve months and after any significant change.

An internal test starts inside the network, through a device plugged into it or a remote connection, usually with an ordinary user account: the position of an attacker who has phished an employee or compromised a laptop, or of a malicious insider. The question is how far that foothold goes. Where Active Directory is in use, much of the work concentrates there, because it decides who can log in where.

What it usually finds:

• Name resolution poisoning that collects password hashes, and relaying that reuses an authentication without cracking anything.
• Weak service account passwords, cracked offline from a Kerberos ticket any domain user can request, the technique known as Kerberoasting.
• Certificate services, delegation settings and group memberships that give an ordinary account a path to domain administrator.
• Credentials left in file shares, scripts and group policy.
• A flat network, where any desk can reach the database servers.

Anyone with an internal network worth reaching needs one: offices, a data centre or a Windows estate run through Active Directory. Without Active Directory the test still runs, focused on segmentation, internal services and default credentials. PCI DSS requires it separately, under 11.4.2. An incident, a merger or a network reorganisation is also a good trigger, because that is when the layout stops matching what anybody believes it to be.

A web application test examines one application in depth: sign-in and account recovery, sessions, what each role can see and do, input handling, and whether the workflows that move money or data can be bent. OWASP publishes a methodology for it, the Web Security Testing Guide. Its current stable release, version 4.2, groups the tests into categories that include authentication, authorisation, session management, input validation, business logic and client-side testing.

Modern frameworks have made classic injection rarer, so the serious findings are usually broken access control and business logic:

• An identifier in a request that returns a record belonging to another customer.
• A checkout that trusts a price sent by the browser.
• A password reset link that keeps working long after it should have expired.
• An admin page that hides its link but not its function.
• Two low-severity findings that chain into account takeover.

For a software company this is usually the first test to buy, because the application is what customers and auditors ask about. Run one before a major release, after any change to authentication or permissions, and at least annually. The effort in web application penetration testing follows the number of user roles and tenants far more than the number of pages.

An API test examines the endpoints rather than the screens in front of them, whether REST, GraphQL or gRPC, documented or not. Every endpoint is tried with every role, and every object identifier with a second account, because the defining API flaw is an endpoint that checks who you are but not whether the object you asked for is yours. OWASP maintains a dedicated list, the API Security Top 10, last revised in 2023, which ranks broken object level authorisation first and broken function level authorisation fifth.

What it usually finds:

• An object identifier that returns a record from another tenant.
• A field added to a request, such as a role or a price, that the server accepts and stores.
• A free-tier token accepted on a paid route.
• Responses carrying fields the interface never displays.
• Login, one-time code and password reset endpoints with no limit on attempts.

Any product with a public or partner API, or a single-page or mobile front end, needs its API tested, because that is where the authorisation decisions are made. An API serving one web front end is normally tested with that application. One that is a product in its own right, or serves several clients, deserves its own API penetration testing scope.

A mobile test covers the app binary, what the app leaves on the device and the API it talks to. The binary is decompiled and read for secrets and unsafe settings. The running app is instrumented, its storage inspected, and its certificate pinning and root and jailbreak detection bypassed so its traffic can be read and changed, which is expected work rather than a finding. Then the backend is sent requests the app never would. OWASP sets out the controls in the Mobile Application Security Verification Standard, from storage and cryptography to resilience and privacy, and how to test them in its companion guide, the MASTG.

What it usually finds:

• Session tokens and personal data left on the device after logout.
• Credentials in plain preference files rather than the keychain or keystore.
• Components and deep links exposed to other apps on the same device.
• A biometric prompt that unlocks nothing.
• A limit the app enforces and the backend does not.

Anyone shipping an app that handles accounts, payments or personal data needs one, before launch and after significant releases. If you ship on both platforms, test both, because the two codebases fail differently. Scope mobile application penetration testing with the API behind the app, not instead of it, because that is where the serious findings usually sit.

Much of a cloud estate is covered by the types above: its internet-facing addresses belong in an external test, and the applications in it are tested as applications. What is specific to cloud is the control plane, meaning identities and permissions, storage policies, network rules and logging. It can be examined in two ways that are not interchangeable.

A cloud penetration test attacks it, for example by turning an application flaw into the credentials of the server it runs on, or by escalating privileges through permissions nobody reviewed. The infrastructure of the provider itself is off limits, and each major provider publishes rules for customer testing; AWS, for example, permits testing listed services in your own account without prior approval and prohibits denial of service testing. A configuration review reads the control plane instead, with read-only access, a benchmark such as the CIS Benchmarks and a person triaging the results.

We offer the second kind: our cloud configuration review checks AWS, Azure or GCP accounts against the CIS Benchmarks, with read-only access. It is not a penetration test: nothing is exploited or changed, and its report should not be presented as one. What it reliably finds is misconfiguration, such as publicly reachable storage and databases, over-permissioned roles, identities without multi-factor authentication and logging switched off. A cloud penetration test answers the next question, which is what an attacker could actually do with what the review describes.

Social engineering testing asks whether people can be persuaded to give an attacker access. A phishing simulation is its controlled form: realistic lures by email, text message or phone call, recording who clicks, who enters credentials and who reports the attempt.

It is not a penetration test of your systems. It measures people and process, produces rates by team rather than a list of vulnerabilities, and needs its own consent and rules, which is why penetration test scopes leave it out unless it is bought on purpose. Our phishing simulation is scoped and reported separately for that reason. Its value is evidence of how staff actually respond, which is what an awareness programme should be built on.

A penetration test asks what is wrong with a defined set of systems and tries to find as much of it as time allows. A red team exercise asks whether your organisation would notice and stop a real attack. It is given an objective, such as reaching a particular system or dataset, and pursues it as an adversary would: quietly, by whatever route works, including people where agreed. The NIST glossary, citing CNSSI 4009, describes a red team as a group authorised to emulate a potential adversary against the security posture of an enterprise.

A penetration test is judged on coverage and findings, a red team exercise on what the defenders saw: which steps were detected and how quickly anyone responded. Mapping each step to MITRE ATT&CK, a knowledge base of adversary tactics and techniques, lets defenders trace each gap to a technique.

Red teaming is not an advanced penetration test and does not replace one. It earns its cost once regular testing is in place, findings are being fixed and there is a detection and response function to exercise; before that, it mostly rediscovers what a penetration test would find for less. Our red teaming is framed the same way, as adversary simulation against detection and response.

Black box, grey box and white box describe how much the tester is told before starting, not what is tested, and any type above can be run in any of them. Grey box, with an account for every role and an outline of the architecture, is the usual default for application testing because the days go on the authorisation model rather than on rediscovering what you already know. Internal tests often start from an assumed-breach position for the same reason. The trade-offs are set out in black box, white box and grey box penetration testing.

Work back from the question rather than forward from a list of services.

1. 1Start with who is asking and what they wrote. An auditor who needs internal and external testing and a board asking whether an attack would be noticed want different types, and the wording usually settles it. How to scope a penetration test covers the rest.
2. 2List what you run. A web product means web application and API testing. A mobile app adds mobile testing against the same API. An office network or a Windows domain means internal testing. Anything with a public address means external testing.
3. 3Follow the route to what matters most: where your most valuable data or function lives, and the path an attacker would take from first contact to it.
4. 4Leave the exercises that test people and detection until the systems have been tested, unless people or detection is what you were asked about.

Types combine naturally in one engagement, usually for less than buying them separately, because the reconnaissance is shared. The pairings follow the attacker: web application with its API, mobile with the API behind it, external with internal. Our VAPT engagements combine several types in one scope, and a secure code review can sit alongside a test where the risk is in logic rather than exposure.