This chapter covers the three primary penetration testing types defined by the level of knowledge given to the tester: white-box, black-box, and grey-box testing. Understanding these approaches is critical for the SY0-701 exam, as they directly map to Objective 2.1 (Explain the importance of security concepts in an enterprise environment) under the Threats, Vulnerabilities, and Mitigations domain. You must be able to distinguish between them, know when each is used, and identify the appropriate type for a given scenario. This chapter provides the technical depth and exam-focused guidance to master this topic.
Jump to a section
Imagine hiring a home inspector to evaluate a house you're considering buying. In a white-box inspection, you hand the inspector the original architectural blueprints, electrical schematics, and plumbing diagrams. The inspector knows every stud, wire, and pipe location before stepping inside. This allows a thorough check of every system against the plans, but it may miss issues that arise from unapproved modifications. In a black-box inspection, you give the inspector nothing—no plans, no history. They must probe the house from the outside, test outlets, open cabinets, and measure rooms to infer the layout. They might discover a hidden leak or a structural flaw, but they could overlook a subtle wiring issue that needs the blueprint to spot. In a grey-box inspection, the inspector gets partial information—say, the floor plan but not the electrical diagrams. They have some context to guide their search but still must discover many details themselves. Mechanistically, this mirrors penetration testing: white-box testing provides full knowledge (source code, network diagrams, credentials) to maximize coverage; black-box testing simulates an external attacker with no prior knowledge, forcing the tester to perform reconnaissance and enumeration; grey-box testing offers limited access (e.g., a low-privileged user account) to mimic an insider threat. Each approach yields different findings and risk perspectives.
What Are Penetration Testing Types?
Penetration testing (pentesting) is a simulated cyberattack against a system, network, or application to identify vulnerabilities that an attacker could exploit. The three main types—white-box, black-box, and grey-box—differ based on the amount of information provided to the tester before the test begins. This classification affects the scope, depth, realism, and cost of the test. The SY0-701 exam expects you to understand these differences and apply them to scenario-based questions.
White-Box Testing (Full Knowledge)
White-box testing, also known as open-box or crystal-box testing, gives the tester complete knowledge of the target environment. This includes:
Source code
Network diagrams
Architectural documentation
Credentials (e.g., admin accounts)
Configuration files
List of assets and IP addresses
How it works mechanically: The tester starts with all internal information and can focus on deep analysis. For example, with source code access, the tester can perform static analysis to find SQL injection flaws, hardcoded credentials, or insecure cryptographic implementations. With network diagrams, they can identify trust relationships and pivot points. The tester may also execute dynamic analysis with full debug symbols.
The advantage is maximum coverage—every line of code, every configuration, every network path can be examined. White-box testing is often more efficient because the tester doesn't waste time on reconnaissance. However, it does not simulate a real-world attack scenario where the attacker starts with zero knowledge. It is typically used for compliance requirements (e.g., PCI DSS) or when the goal is to find as many vulnerabilities as possible.
Tools and commands:
- Static analysis: bandit (Python), SonarQube, Checkmarx
- Dynamic analysis: Burp Suite with source code mapping
- Network scanning: nmap -A -T4 <target> with full subnet knowledge
Black-Box Testing (No Knowledge)
Black-box testing, also called closed-box or external testing, provides the tester with no prior information about the target. The tester must start from scratch, just like a real attacker. The only thing given is the target's public-facing domain or IP address (and sometimes a scope of acceptable targets).
How it works mechanically: The tester follows a standard penetration testing methodology:
1. Reconnaissance: Gather information from public sources (OSINT)—whois, DNS records, social media, job postings, Shodan, Google dorking.
2. Scanning: Use tools like nmap, masscan, and Nessus to discover live hosts, open ports, and running services.
3. Enumeration: Identify versions, users, shares, and potential vulnerabilities (e.g., SMB null sessions, anonymous FTP).
4. Exploitation: Attempt to exploit discovered vulnerabilities (e.g., EternalBlue MS17-010, SQL injection).
5. Post-exploitation: Maintain access, pivot, and exfiltrate data.
The key is that the tester has no shortcuts—they must discover everything themselves. This makes black-box testing more realistic but also time-consuming and potentially less thorough (the tester might miss a vulnerability hidden behind multiple layers). It is best for simulating external attackers (e.g., from the internet) or for red team exercises.
Tools and commands:
- Recon: theHarvester -d example.com -b google, dnsrecon -d example.com
- Scanning: nmap -sV -p- <target>
- Exploitation: Metasploit modules, custom scripts
Grey-Box Testing (Partial Knowledge)
Grey-box testing is a hybrid approach where the tester is given limited information, such as:
A low-privileged user account
Network access to a specific subnet
API documentation without credentials
Partial source code (e.g., only the frontend)
How it works mechanically: The tester has a head start—they can bypass the initial reconnaissance phase for certain aspects. For example, if given a standard user account, they can immediately focus on privilege escalation techniques. They still need to discover other vulnerabilities (e.g., from inside the network). Grey-box testing is often used to simulate an insider threat (e.g., a disgruntled employee) or a attacker who has already breached the perimeter.
The partial knowledge allows a balance between realism and depth. It is more efficient than black-box but more realistic than white-box. Grey-box testing is common in web application testing where the tester gets login credentials but no source code.
Tools and commands:
- Privilege escalation: LinPEAS (Linux), WinPEAS (Windows)
- Web testing: Burp Suite with authenticated session
- Lateral movement: PsExec, WMI commands
Key Components and Variants
Other related testing types that may appear on the exam: - Double-blind testing: The target's security team is not informed of the test (like a surprise audit). - Red team vs. blue team exercises: Red team acts as attackers (often using black-box), blue team defends. - Internal vs. external testing: Internal testing assumes the tester is inside the network; external testing starts from outside.
How Attackers Exploit vs. Defenders Deploy
Attackers typically use black-box methods for initial intrusion, then switch to grey-box once they gain a foothold (e.g., with stolen credentials).
Defenders deploy penetration tests to validate security controls. They choose the type based on the threat model: white-box for compliance, black-box for external risk, grey-box for insider threats.
Real Command/Tool Examples
White-box example (source code audit):
# Using bandit to find security issues in Python code
bandit -r /path/to/project -f json -o report.jsonBlack-box example (reconnaissance):
# DNS enumeration
nslookup -type=any example.com
# Subdomain discovery
sublist3r -d example.comGrey-box example (privilege escalation):
# On a Linux target with a low-privilege shell
./linpeas.sh | tee linpeas_output.txt
# Check for sudo privileges
sudo -lExam Relevance
SY0-701 tests your ability to differentiate these types in scenario questions. You must know:
Which type provides the most realistic simulation of an external attacker? (Black-box)
Which type gives the most comprehensive coverage? (White-box)
Which type is best for testing insider threats? (Grey-box)
Which type is most time-consuming? (Black-box)
Which type is most expensive? (White-box, due to deeper analysis)
Memorize these keywords: "full knowledge" = white-box, "no knowledge" = black-box, "partial knowledge" = grey-box.
Define Scope and Objectives
Before any penetration test, the organization and tester agree on the scope: which systems, networks, or applications are in scope, what type of test (white/black/grey-box), and the rules of engagement (e.g., no denial-of-service attacks). The objectives are defined, such as finding SQL injection vulnerabilities or testing incident response. For white-box, the tester requests all documentation. For black-box, only a target domain is provided. For grey-box, limited credentials or access are given. This step ensures legal authorization and clear boundaries.
Reconnaissance (Black-Box Only)
In black-box testing, the tester begins with open-source intelligence (OSINT). They gather information from public sources: DNS records, whois data, social media, job postings (may reveal tech stack), Shodan for exposed services, and Google dorking for sensitive files. Tools like theHarvester, Maltego, and Recon-ng automate this. The goal is to build a profile of the target without touching its systems. In white-box testing, this step is skipped because all information is provided. Grey-box testing may skip initial OSINT but still perform network enumeration from the given access point.
Scanning and Enumeration
The tester performs active reconnaissance: scanning for live hosts, open ports, and running services. Nmap is the primary tool. For example, `nmap -sV -p- 192.168.1.0/24` scans all ports with version detection. Enumeration goes deeper: extracting user lists via SMB null sessions, enumerating SNMP community strings, or discovering web directories with DirBuster. In white-box testing, the tester already knows the network layout and can focus on specific services. In black-box testing, this is a discovery phase. Grey-box testing may have a subnet but still needs to enumerate hosts.
Vulnerability Analysis
The tester identifies vulnerabilities in discovered services. They use vulnerability scanners like Nessus or OpenVAS, but also manual techniques. For example, they might test for SQL injection by sending `' OR 1=1 --` in input fields, or check for default credentials. In white-box testing, the tester can perform source code analysis to find flaws. In black-box testing, they rely on banner grabbing and known CVEs (e.g., CVE-2017-0144 for EternalBlue). Grey-box testers may have access to logs or configuration files that hint at weaknesses.
Exploitation and Post-Exploitation
The tester attempts to exploit identified vulnerabilities. For example, using Metasploit: `use exploit/windows/smb/ms17_010_eternalblue`. Successful exploitation gives initial access. Post-exploitation includes privilege escalation (e.g., exploiting a kernel vulnerability), lateral movement (e.g., using PsExec), and data exfiltration. In white-box testing, the tester may have admin credentials already and skip privilege escalation. In black-box testing, each step must be discovered. Grey-box testers may use the provided low-privilege account to pivot. The tester documents findings with screenshots and logs.
Scenario 1: Compliance Audit for a Financial Institution
A bank must comply with PCI DSS, which requires annual penetration testing. The compliance team chooses white-box testing to ensure maximum coverage. The tester receives full network diagrams, source code of the online banking application, and admin credentials. Using static analysis tools like SonarQube, the tester finds a hardcoded API key in the source code (CWE-798). This vulnerability would have been missed in a black-box test because the API key was not exposed externally. The tester also reviews firewall rules and finds an overly permissive ACL allowing SSH from the internet to a database server. The corrected action is to remove the hardcoded key and tighten the ACL.
Common mistake: The security team assumes black-box testing is sufficient for compliance. However, PCI DSS requires testing that identifies all vulnerabilities, which white-box testing achieves. A black-box test might miss internal misconfigurations.
Scenario 2: Red Team Exercise for a Tech Company
A software company hires a red team for a black-box exercise to simulate a real-world attacker. The red team is only given the company's public domain. They start with OSINT, discovering a forgotten subdomain (dev.example.com) that hosts a development version of the product with default credentials. They exploit it to gain access. Using nmap, they find an exposed RDP port on a jump server. They brute-force the password (using Hydra) and move laterally to the internal network. The blue team detects the intrusion via an IDS alert on the brute-force attempt but fails to contain it quickly. The correct response is to patch the dev server, disable default credentials, and improve IDS rules.
Common mistake: The blue team ignores the initial OSINT warning signs (e.g., exposed subdomain) because they assume attackers only target main domains.
Scenario 3: Insider Threat Simulation for a Hospital
A hospital wants to test the risk of a disgruntled employee with network access but no admin rights. They conduct a grey-box test, providing a standard nurse's workstation credentials. The tester uses tools like WinPEAS to enumerate the system, finding a scheduled task that runs with SYSTEM privileges and is writable by the user (CVE-2019-1215). They replace the task's binary with a reverse shell, gaining admin access. They then access patient records (PHI) to demonstrate data exfiltration. The mitigation is to review scheduled task permissions and apply least privilege.
Common mistake: The hospital focuses on external threats and neglects internal access controls. They assume that a standard user cannot escalate privileges, but misconfigurations like writable scheduled tasks are common.
Exactly What SY0-701 Tests:
Objective 2.1 requires you to "Explain the importance of security concepts in an enterprise environment." Penetration testing types fall under the security assessment and testing concept. The exam will test your ability to:
Differentiate between white-box, black-box, and grey-box testing based on the level of knowledge.
Identify appropriate testing type for a given scenario (e.g., compliance vs. realism).
Recognize related terms like "double-blind" or "red team."
Common Wrong Answers and Why Candidates Choose Them:
Choosing black-box for compliance: Many candidates think black-box is the "standard" test. But compliance (e.g., PCI DSS) often requires white-box for thoroughness. Wrong because they confuse realism with coverage.
Confusing grey-box with internal testing: Grey-box is about knowledge level, not location. Internal testing can be any type. Wrong because they think "internal" means partial knowledge.
Selecting white-box for simulating an external attacker: White-box is unrealistic for external attackers. Wrong because they focus on the "full access" aspect but forget the attacker's perspective.
Specific Terms and Values That Appear Verbatim: - "Black-box" = no knowledge - "White-box" = full knowledge - "Grey-box" = partial knowledge - "Double-blind" = tester and target team both unaware - "Red team" = offensive; "blue team" = defensive; "purple team" = collaborative
Common Trick Questions: - A question might describe a test where the tester is given network diagrams but no credentials. This is grey-box, not white-box, because credentials are missing. Candidates may incorrectly choose white-box because diagrams are provided. - Another trick: "Which test type is most realistic?" The answer is black-box, but candidates may choose grey-box because it's a "realistic insider threat." However, the question often implies an external attacker.
Decision Rule for Eliminating Wrong Answers: 1. Identify the level of knowledge given: none = black-box, some = grey-box, full = white-box. 2. Determine the goal: maximum coverage = white-box, realism = black-box, insider threat = grey-box. 3. If the question mentions compliance requirements, lean toward white-box. 4. If the question mentions a red team exercise, lean toward black-box. 5. If the question mentions a disgruntled employee or low-privilege user, lean toward grey-box.
White-box testing: full knowledge provided to tester.
Black-box testing: no knowledge provided; simulates external attacker.
Grey-box testing: partial knowledge (e.g., low-privilege account).
Double-blind test: neither tester nor target team knows about the test.
Red team uses black-box; blue team defends; purple team collaborates.
Compliance (e.g., PCI DSS) often requires white-box testing.
Black-box testing is most realistic for external attack simulation.
Grey-box testing is best for insider threat scenarios.
These come up on the exam all the time. Here's how to tell them apart.
White-Box Testing
Full knowledge of the target (source code, diagrams, credentials)
Maximum coverage and depth
More efficient (less time on reconnaissance)
Less realistic for external attackers
Higher cost due to deep analysis
Black-Box Testing
No prior knowledge of the target
Simulates real-world external attackers
Time-consuming (must perform reconnaissance)
May miss vulnerabilities requiring internal knowledge
Lower cost but less comprehensive
Mistake
Black-box testing is always better because it's more realistic.
Correct
Realism depends on the threat model. Black-box is realistic for external attackers, but white-box provides deeper coverage for compliance and internal threats. Each type has its purpose.
Mistake
White-box testing requires source code access.
Correct
White-box testing can include full documentation, network diagrams, and credentials—not just source code. Source code is one component, but the key is full knowledge of the environment.
Mistake
Grey-box testing is the same as internal testing.
Correct
Internal testing refers to the location (inside the network), while grey-box refers to the knowledge level (partial). An internal test can be black-box (no knowledge) if the tester starts without any info.
Mistake
Black-box testing finds all vulnerabilities because it simulates real attackers.
Correct
Black-box testing may miss vulnerabilities that require internal knowledge, such as hardcoded credentials in source code or misconfigurations in internal systems. White-box testing finds more vulnerabilities overall.
Mistake
Penetration testing types are mutually exclusive and cannot be combined.
Correct
Organizations often combine types: e.g., a black-box external test followed by a white-box internal audit. Red team exercises may use black-box for initial access and grey-box for lateral movement.
White-box testing provides the tester with full knowledge of the target, including source code, network diagrams, and credentials, allowing comprehensive analysis. Black-box testing gives no prior knowledge, forcing the tester to start from scratch like a real attacker. The exam tests your ability to choose based on scenario: white-box for compliance, black-box for realism.
Grey-box testing is ideal for simulating an insider threat or an attacker who has already gained limited access. It provides partial knowledge, such as a low-privileged user account, allowing the tester to focus on privilege escalation and lateral movement. Use it when the threat model includes internal actors.
PCI DSS requires both external and internal penetration testing, and it recommends a methodology that includes both black-box and white-box elements. However, the standard emphasizes thoroughness, so white-box testing is often used to ensure all vulnerabilities are identified. The SY0-701 exam may link compliance with white-box testing.
Yes, a single engagement can combine types. For example, the initial external assessment might be black-box, but once the tester gains a foothold, they switch to grey-box with the knowledge obtained. However, the exam typically presents them as distinct types for scenario questions.
Double-blind testing means that both the penetration testers and the target's security team are unaware of the test timing. It is a variant of black-box testing where even the blue team does not know an attack is coming, testing their detection and response capabilities. This is more stressful but provides a realistic assessment of incident response.
White-box testing is generally more expensive because it requires more skilled testers and deeper analysis (e.g., source code review). Black-box testing is cheaper but may require more time for reconnaissance. Grey-box testing falls in between. The exam may ask you to consider cost in scenario questions.
A red team conducts offensive security operations, often using black-box methods to simulate real adversaries. They focus on achieving specific objectives (e.g., accessing sensitive data) rather than finding all vulnerabilities. Red team exercises test the organization's detection and response capabilities, not just technical controls.
You've just covered Penetration Testing Types (Black/White/Grey Box) — now see how well it sticks with free SY0-701 practice questions. Full explanations included, no account needed.
Done with this chapter?