Finally, while testing people is of course not teaching them the attacker mindset, it is teaching them how an attack might rear its ugly head and that alone gives them defenses against it. So, as security professionals, it's also our duty to form attack methods that, once executed, have no long-lasting adverse effects on the population tested—a major contrast when compared to those breeched by a malicious attacker. After all, some of the most devastating attacks haven't been the most technical—they've simply been human versus human. The catch is that only one human knows about the attack as it unfolds. By offering insight into the principles of AMs, we should be able to move the needle on security in the right direction without adversely affecting the population.
A Quick Note on Scope
The word scope will be used frequently throughout this book and chapter. It refers to a document that is an agreement on the work you're going to perform for a client. It outlines what you can and cannot do. It is your get out-of-jail-free card if you are caught (if you stuck to the terms of it) and possibly your never-go-to-actual-jail card if you are caught (if you stuck to the terms of it).
The scope will permit you to do a whole host of things, like enter a building from any given area or use real employee names in a phish. It might let you break into a building during the day but not at night (within normal working hours), or it might allow you to impersonate employees, both in person and over the phone. It is decided by the client.
Here's the bottom line of scope: you don't have to do everything scope permits. You cannot do a single thing it prohibits. Ensure you understand scope before you embark on the work. Make sure it uses clear language, and make sure you clarify anything you are unsure of.
Collectively, as a team, we've broken into hundreds of servers and physically compromised many of the world's most tightly guarded corporate and government facilities, including banks, corporate headquarters, and defense sites. However, I am always struck by how James Bond–like people think the job is. Each job is a long process that looks at legalities, operational conflicts that have to be worked around, and deliverables.
The first phase of the process is aligning with the target, picking a period in which to attack and defining the scope. To discuss that in great detail is beyond the range of this book, although an important point about scope should be made: scope limits what you do, not how you think. Breaking that down a little further, the scope matters to you because it tells you what you are and are not allowed to do—if you are not allowed to impersonate an internal employee, then you might pivot to impersonating a contractor. You may not be allowed to spoof numbers or name drop, so your AMs will have to forge ahead, giving you deceptive and creative ideas to offset those limitations. For instance, if you can't spoof numbers, you might get a burner number that's a few digits off from the one the target will expect. If you can't name drop, you might use names that sound close to the one. If scope limits you from using tools, like card cloners, then you might have to use a look-alike card and feign a technical error when it won't permit you access. Basically, scope adds complexities to your job, but it doesn't limit the power of your AMs; it simply exercises it in different ways.
There are good and bad outcomes that arise from having a scope in place. Primarily it is a protection for you as an attacker, which is why stepping outside the lines of them can be so damaging and devastating, both to your company and to your career. They are protection for the target, too. Most often you will hear new people in the field saying a real attacker would never stick to scope, so why should they? This is more complex than you'd first think. The first part of the statement is true; an attacker does not have a scope to stick to. However, if the client is asking you to go after the same asset that a real and malicious attacker would, the outcome is the same. Your clients should train their staff on how to spot attacks even when they are using spoofed numbers and impersonation, but if you are able to successfully breach them with these limitations in place, you further hit home to them how vulnerable they are. Scope is an attacker's blessing in disguise.
There are, however, grounds to challenge scope. If the client is too extreme in either direction, without good cause, you should—professionally—be able to point out to them how it precludes valuable testing. For instance, if you are vishing a bank and the client doesn't want you to use any semblance of an existing department as your pretext, you might point out that such limitations are heavily skewed in a way that will impact the findings and go against their security posture and future mitigations. It's too far removed from a realistic attack scenario.
However, if you are breaking into a government facility and the client doesn't want you to take any device in that's able to film or photograph, that shouldn't be too much of a concern for you as long as a mechanism is in place for you to prove your successes (and failures). Some clients will want a representative to accompany you; others will want you to check in at different points throughout the building. In the case of most pen tests, you will usually screenshot your progress. However, some clients will prohibit this and use their own logs as an example.
We will not cover report writing, although it is a large part of a job for most clients. What I will say about reports is that they should not be approached with fear or loathing. Equally, they should not be treated as precious. They are a way for you to give a coherent and exhaustive rundown of what you did from start to end and to give recommendations based on all of that. Giving the client all the vulnerabilities you saw but didn't take is important, too. I care more for a simple and easy report to both write and to read. There's still an element of AMs law involved in writing them: you must know the objective of the report (to show them where they are vulnerable and how to close those vulnerabilities); you must be able to take the information you gathered and describe it effectively, leveraging it for the report; you will have to stay professional the entire report—it is not a document for you to write your moves out like a screenplay; and you must always keep the objective of the report in mind so that it doesn't drift in the direction of fiction or in the direction of data only, without fixes.
Summary
Attacker mindset can be used from your computer, but it really can't be taught there. It's a set of skills and laws working in combination.
AMs is a set of cognitive skills applied to four laws. Used together, they produce an advantage for the attacker and a disadvantage of the target.
Teaching the attacker mindset to those who don't seek to harm us, but to protect us, will greatly impact our successes in information security going forward.
The following chapters present a complete system for building this mentality and untangling the complex web of thinking and resulting actions that make an attacker mindset so formidable.
Reports are, for most people, the least fun part of the job but the most important part for the client.
Key Message
War is 90 percent information; the rest is how you apply it to the objective. An attacker takes in information to achieve an objective, but instead of profiting in the end, an ethical attacker seeks to strengthen defenses they circumvented or defeated. AMs’ largest commodity is information; it is the use of this information that defines the attacker and the attack.
To carry out the acts of an attacker requires curiosity and persistence, which are interdependent as one often drives the other. Information processing is another important skill. A subset of information processing