Types of Tests: Black, Grey and White Box

Not all penetration tests are the same. Two tests of the same company can produce very different results depending on how much the tester knows in advance. In this lesson you will learn the three classic approaches, black, grey and white box, and how to pick the right one for a given goal.

Now that the legal foundations are in place, the next question a client will ask you is: "What kind of test do you propose?" The answer depends on what the client wants to learn. Choosing badly wastes money and gives a false sense of security.

The idea: how much does the tester know?

The three names come from engineering. A black box is a device whose inside you cannot see. A white box is a device you can open and inspect. A grey box is somewhere in the middle. Applied to penetration testing, the "box" is the target system and what is hidden is its internal information.

Black box

The tester receives almost nothing, typically a company name or a list of public addresses. This simulates an external attacker with no inside knowledge. The tester must discover everything: which systems exist, which services run, where the weaknesses are.

• Advantages: realistic view of what an outsider can see and do; tests the visibility of the organisation from the internet.
• Drawbacks: a lot of time is spent on discovery, so less time is left for deep testing. Important internal weaknesses may remain unnoticed because the tester never got far enough.

White box

The tester receives full information: network diagrams, source code, configuration, accounts with various privilege levels, sometimes even access to the developers. This simulates a very well informed attacker (such as a malicious insider) or, more commonly, simply gives the most thorough review possible.

• Advantages: maximum coverage and efficiency; the tester can focus on subtle weaknesses that a black box approach would almost never find, such as logic flaws in code.
• Drawbacks: less realistic as an attack simulation, and it requires the client to prepare and share a lot of material.

Grey box

The tester receives partial information, usually a normal user account, a description of the application, and perhaps the network ranges. This simulates an attacker who already has a foothold: a customer with an account, an employee, or someone who has stolen a password.

• Advantages: a balance between realism and efficiency; many serious weaknesses, such as an ordinary user reading other users' data, only appear once you are logged in.
• Drawbacks: it does not tell you how an outsider could obtain that first foothold, unless you combine it with another approach.

Approach	Information given	Simulates	Typical use
Black box	Almost none	External attacker	Checking exposure from the internet
Grey box	Partial (user account, diagrams)	Customer, employee, stolen account	Applications with user areas
White box	Full (code, configuration, admin accounts)	Insider or in-depth review	Critical applications, pre-release audits

Other dimensions of a test

"Box colour" is only one axis. A real mission description also states:

• External vs internal: attacking from the internet, or from inside the company network (for example from a laptop plugged into the office network).
• Infrastructure vs web application vs wireless vs social engineering: the technical area under test. Social engineering, such as phishing simulations, requires its own explicit authorisation and strict rules about employees.
• Announced vs unannounced: whether the defenders (the "blue team") know about the test. Unannounced tests check detection and response, but they need a clear emergency contact so that nobody calls the police by mistake.

Penetration test, vulnerability assessment, red team: not the same thing

Clients often mix these terms. A good tester clarifies them at the start.

• Vulnerability assessment: a broad, mostly automated search for known weaknesses, with a list as the result. It does not usually try to exploit them.
• Penetration test: a human-driven attempt to exploit weaknesses in a defined scope and time, to show real impact.
• Red team exercise: a long, stealthy simulation of a realistic adversary with a specific objective (for example "reach the finance database"), often testing people and processes as much as technology. It is usually reserved for mature organisations.
• Bug bounty: an open programme where many independent researchers may report weaknesses within published rules, and are rewarded for valid findings.

The MITRE ATT&CK knowledge base describes the tactics and techniques of real adversaries and is frequently used to plan red team scenarios and to describe findings in a common language. We will use it again in later chapters.

Choosing the right test

To pick an approach, ask three questions.

1. What is the client afraid of? An external intrusion, a malicious customer, a rogue employee, a leak through a supplier?
2. What is the time and budget? A black box test consumes many days on discovery. If the budget is small, a grey box test often gives more findings per hour.
3. What is the maturity of the organisation? A company that has never been tested usually gains more from a thorough grey or white box review than from a stealthy simulation that would simply succeed.

The best programmes combine approaches over time: for example an annual external black box test plus a grey box test of every major release of the main application.

Your fil rouge: choosing the approach for Lighthouse Labs

For Project Lighthouse, you will use a grey box approach with a small twist. You will start like an outsider: the only information you hold is the fictional company name and the address range of your lab. Later, when the course reaches post-exploitation, you will be given a low-privilege account, as if you had obtained it through a phishing mail. That mix lets you practise both the discovery skills and the internal steps without spending hours waiting.

Your turn: pick the approach

For each case, choose black, grey or white box (or a combination) and justify your answer in one or two sentences.

1. A bank wants to check that its new online banking application cannot be abused by an ordinary customer, before it goes live next month.
2. A start-up wants to know what an attacker on the internet can find out about its public infrastructure.
3. A software editor wants the most thorough review of the code of its authentication module before a major release.

See a solution

1. Grey box. The main threat is a logged-in customer, so the tester should have one or two normal accounts. A white box review of the code could complement it.
2. Black box. The question is exactly what an outsider can see, so the tester receives only the company name or domain list in the scope.
3. White box. The tester needs the source code and design documents to find subtle logic and cryptographic mistakes that no external test would reveal.

Next, you will turn these decisions into the document that protects everyone: the authorisation and the scope.