The Four Three Rule of Team PenTesting

Two posts in one night, because I’m catching up on some backlog items.  I’ve been teaching/training a team on PenTesting lately, and it’s caused me to think through some personal truths and approaches that I’ve taken for several years.  While going through that process I came to realize that I’d never really formally codified them; this is my attempt to do just that.  It all comes down to what I’m now going to call the “Four Three Rule of Team PenTesting”.

The term “Four Three Rule” applies to the the four rules that if not followed will guarantee a failure in the test itself (note that following them doesn’t guarantee success, but not following them will guarantee failure), and the three roles I see as critical to a successful team-based penetration test.  I’ll caveat that nothing you’re going to read here is particularly novel, but rather is just the distillation of my figuring out what works and what doesn’t work.

The Four Rules

1. Over communicate: I can’t count the number of times that I’ve been working on a target trying to find a way in, when someone else on the team had a username/password I could have used, or information about a configuration, or just knowledge in general that would have greatly eased the effort required to achieve the objective (I also can’t count the number of times I’ve been the one inadvertently withholding such information).  It’s absolutely vital to constantly inform other team members of what you’ve learned, know, and suspect.  That being said, there is often more information than you can readily communicate, which brings me to the second rule…
2. Document everything: It’s a maxim in penetration testing that if you didn’t document it, it didn’t happen.  Whether it’s a screenshot of a database you finally accessed or an unusual path you found in an old configuration file, you should be documenting it.  You should also be storing that evidence and sharing it in a common repository that everyone can search, and which will survive the most common attacks of Murphy’s Law (e.g. redundant storage, battery backup, and encrypted).  I’ll take having to choose what to cut from a report any day over wishing I had captured something.
3. Keep a backlog: You’re going to come across a LOT of things that you COULD explore.  Through experience (and by extension, bias) we’re likely to chase after things we’ve seen before, and in so doing we may miss out on things that we SHOULD explore more fully, or skip over something that we just wish we had the time to learn more about, but can’t prioritize right now.  In a solid team each member’s skills and strengths cover weaknesses in others, so what may be a difficult task for you might be a simple exercise for someone else.  Moreover, when someone gets stuck on their current path they have a range of options to choose from, and can quickly pivot to a new attack or vector.  One of the best reasons for this, however, is the things you never get around to exploring.  Those can be great amplifying information for your final report, and a list of potential training opportunities for the team to improve upon before the next engagement, as well as a valuable source for discussions about what to prioritize.
4. List and challenge your assumptions: All of the things we think we know work against us in a penetration test.  Is that system really an English language installation of Windows Server (and thus are the directories named what  you expect)?  Is that web server really hosted out of /var/www/html?  Is the nmap classification of that port accurate?  Make a habit of recognizing and documenting in your working notes whenever you make an assumption, and you’ll be more likely to identify when one of them might be impacting what you’re trying to do (and why it’s not working).  Moreover, when you find yourself making the same assumption over and over again put it in a personal “blind spots” list that you revisit as a matter of habit.  It will both improve your success rate as well as your process.

The Three Critical Roles

Building upon the four rules, I came to realize that there are three absolutely essential roles which have to be covered in any team.  When we’re testing by ourselves we of course take on all three, but I’ve found that a team of three or more personnel makes the division of labor much easier.

1. Controller: The Controller role is that of the leader.  He or she is responsible for determining where efforts will be expended, how long to work on each task, what the boundaries are for the efforts (based upon the agreed scope, of course), and keeping an overall perspective of what the team is doing.  The Controller role is in many ways a project manager for the testing activity, and should always be on the lookout for information which should be shared/called out between Executor roles.  Nothing should take place without the Controller being aware of it.  Much like the Highlander, there can be only one Controller.
2. Backlogger: The Backlogger role is that of capturing items that should be explored, and doing so with enough granularity to allow quick revisiting of targets.  He or she is responsible for capturing all the information that is identified by any member of the team.  While someone in the Executor role can also take on the Backlogger role, in my experience it is far more successful to have this be a dedicated person, because doing so maintains the focus on capturing targets of opportunity without worrying about losing focus to other areas.  When more challenging tasks are at hand and the Executor(s) are not generating information or data, the Backlogger can also build the draft report from the information already captured.
3. Executor: The Executor role is that of actually running commands and performing testing activities.  There may be one or more Executors in the team makeup, and each one coordinates their activities with the Controller.  The Executor is responsible for the execution of testing activities within the agreed upon scope, and capturing all evidence and artifacts to support report creation.  This is the role most junior personnel most aspire to, which works well since it is also the one which requires the least operational awareness.

This is the framework I’ve developed internally to keep things regulated and efficient when performing testing, but I’m always open to and welcoming of new ideas.  If you have any feedback, please let me know on Twitter.  Good hunting!