Do You Want to Play the Hacker Game?

The most common interpretation of penetration testing is something I like to refer to as The Hacker Game. In this game, pentesters are given the minimum information required to establish legal scope and the rules of engagement, but little-to-no additional knowledge about the target organization, tech, or applications. "Here is our public domain. Have at it, hAcKeR BOi!"

This is OK. We're used to this and have lots of ways to level the playing field; OSINT, public breach data, internet-facing login portals, phsihing, and password spraying are the (time-consuming) gifts that keep on giving.

But here's the thing: our job is not to win The Hacker Game. Our job is to leave the client more informed, skilled, and secure than we found them. If the engagement turns into a competition of our offensive skill versus the client's defensive controls for no reason beyond winning, I do like our chances, but we all lose.

This raises an important philosophical distinction at the heart of pentesting in general: penetration testers should bring an adversarial mindset and techniques, but the engagement itself does not have to be adversarial.

What Are You Trying to Test?

I know it might seem like I'm against playing The Hacker Game. I'm not. In fact, LARP-ing as a real attacker during a more competitive pentest can be a lot of fun. There are also many legitimate reasons to limit a tester’s knowledge or access, especially if you are narrowly interested in what an external attacker can independently discover from the outside.

What I am against is the all-too-common notion that The Hacker Game should be a default starting point for penetration testing in general. Clients opt for black-box engagements with limited information sharing because that is where they believe a real-world attacker would begin from. Pentesters accept the challenge because discovering everything independently feels more 1337 and impressive. Neither of these perspectives prioritizes what really matters: what are we actually trying to test and how do we deliver the most value to the client?

A great pentest should be customized to the needs, goals, and priorities of the target organization. Sometimes that means maximizing information sharing with a less sophisticated client who is trying to get a handle on the basics. Other times it means a red team engagement where you prioritize stealth over speed to gauge the effectiveness of the blue team's detection and response capabilities. And sometimes it means no information sharing at all because a key executive or stakeholder only believes findings are real if the tester "found them the real way".

Either way, the clock is ticking and the meter is running.

The Tradeoff Between Time, Knowledge, and Value

Scoping can be one of the most crucial and frustrating processes in preparing for a penetration test. Assets that are worth the attention of a pentester are not hard to come by, but deciding what to prioritize and how long to test for can be a tricky balance. Most penetration tests are time-boxed, often to just a few days to a week or two. A black-box approach to testing requires pentesters to spend more of that time learning about the environment. That includes identifying systems, understanding architecture, finding applications, mapping trust relationships, determining which data matters, figuring out how different components interact, learning which business processes depend on them, and whatever else might be relevant.

Again, I do not believe that a black-box approach is inherently better or worse than white box. It just prioritizes different things. And sometimes the client withholds knowledge intentionally as a construct of the engagement. Other times, the organization simply lacks visibility into its own environment. The difference matters, but the practical effect on the engagement is the same: the pentester must spend limited time reconstructing information before testing it.

That time has to come from somewhere. It may mean that fewer attack paths are explored. Potential vulnerabilities get less follow-up. Findings are tested individually instead of being chained together. An edge case that could have exposed a serious business logic flaw never gets the attention it deserves.

For example, identifying a potential SQL injection vulnerability in a web application can sometimes happen relatively quickly. But proving risk by weaponizing the vulnerability into a meaningful exploit can be extremely tedious and time consuming. Should a pentester spend hours blindly trying to weaponize it or should they collaborate with the dev team to tailor the attack with knowledge of how the actual query and source code handle the associated input? The latter might turn an inconclusive finding into a demonstrated business risk, while giving the developers a better understanding of how the vulnerability can actually be exploited.

Starting with more knowledge does not make the test less effective. It gives the pentester more possible starting points and more time to construct meaningful attack paths because time and money are realistic constraints.

Should You Play the Hacker Game?

Maybe. It depends. You have to start from a firm understanding of what you are actually trying to accomplish and structure the pentest to best suit your needs. “We want to see if you can hack us” is a starting point for that conversation, not a complete testing objective.

Do you want to know what an unauthenticated outsider can discover and exploit? A black-box approach may make sense. Do you want to understand whether someone with a compromised employee account can reach sensitive systems? Start the tester with an appropriate account. Do you want to find weaknesses in a business-critical application before attackers do? Providing documentation, access to different user roles, and time with the developers may be a better use of your budget than making the tester guess how everything works.

You also do not have to pick one approach and stick with it for the entire engagement. You can agree on an initial period of testing with limited information, then share context and access to explore what lies beyond the first obstacle. The important thing is to distinguish between a boundary you want to test and a roadblock that is simply consuming time. If discovering that information independently is part of the objective, great. Budget for it. If it is not, ask what you gain by withholding it.

The Hacker Game has its place. Just make sure you're playing the game for a reason.