How to Pass a Red Team Interview
I get the question “What makes a good Red Teamer?” or “What do you look for in a Red Team candidate?” (which I read as “What do I need to pass a red team job interview?”) fairly regularly. Some people asking are seasoned professionals exploring next career options, others are brand new to the field and are trying to lock on to what they perceive is their career aspiration. Since I’m a fan of answering a question like this once (if you read that as a form of laziness, I probably would just smile and not deny it), I figured I’d just capture some thoughts here.
My disclaimer: While I’ve been around the Internet for two decades now, I’ve only spent my time red teaming for a very short period of time, so there are others (many of whom I consulted when I myself started recruiting) who may have more compelling answers and include details I miss. Also, what I think the relevant skills are today may change a year or two from now. But with that disclaimer out of the way, let’s dig in …
Trustworthiness.
Yes, this sounds all Boy Scouts, but it’s true. Your tenure will be a non-starter or short lived if your host organization perceives any form of untrustworthiness. You’re getting paid to break into companies, so your employer needs to know that you will behave responsibly. Even after the job interview, consider this characteristic to be under constant review. Notice this is the first quality in this list.
Know the role.
If you cannot articulate the difference between a penetration test and red team, go figure that out first. So many people think “red team” either is all inclusive of everything from vulnerability scans, to code reviews, to penetration tests, to full-on objective based adversary simulation. Others think “red team” is just the moniker for the top ninja hackers in the penetration test field. Massive hint: none of those are true.
Know yourself.
For many of the smartest penetration testers I have met, I honestly do not think most of them would be happy in red team roles compared to advanced penetration test and exploit development roles — even though our industry promotes “red team” as the top rung in the ladder. Believe it or not, some advanced penetration testing may be more technical, while red team is more operational and realistic. A good penetration tester can be noisy in a whitebox lab, but come out with a perfect set of exploits for a target. A good red teamer may only get one live shot at a target, so that chance may simply be to phish for creds and log in like an admin. If that’s less rewarding for you, recognize that pentesting may actually be a better fit — and that’s not derogatory in any way, it’s just a different kind of offensive security work. Also, if you think phishing is cheating, then that’s an indicator you should stick with penetration testing instead of red teaming.
Healthy Competition.
Some people understand that the red team role is about simulating adversaries, and can really articulate what that means, but they are too close to the adversary and forget that the primary purpose of a red team is to be the training partner for the blue team — not just to compete and win. Any organization can have an adversary win for free — they don’t need a red team, they just need to put an unpatched system with default creds directly on the internet and watch it happen. What they need from their red team is a genuine desire to improve security posture — not a desire to keep vulnerability information secret for a future competitive advantage.
Creativity.
A big portion of breaking into an organization’s IT systems involves challenging normal thoughts and processes. Above all else, coming up with unique solutions to problems — and being able to execute on them — really is important.
Operational IT experience.
To quote the Red Team Journal, a novice red teamer thinks like an attacker, but a journeyman thinks about the attacker and defender. Our defenders are the IT pros who deal with change controls, continuous integration, project management, budgets, 24x7 support, war rooms when stuff breaks. If you have that experience/knowledge, you’ll have a leg up.
Development Skills
We like to build our own tools and extend the functionality of existing tools. This is a moving target and static tools will result in failed objectives. Red Team candidates should at least script in python or powershell. Candidates who can build web apps, implants in C/C++, and manage infrastructure will have a huge leg up.
Unique Skills
On a large, well-equipped red team, each candidate should bring unique skills to the table. The team doesn’t need a dozen cookie cutter candidates with similar backgrounds and expertise. A team with less skill overlap is more capable working on a diverse set of objectives and campaigns. Find something a little different and make it your own. You may consider yourself to be very proficient at red teaming, but get passed up during interview selection, not because of your lack of proficiency, but because you have considerable overlap in the core of your skillset with other members of the team. Skill diversity is very important.
Now for all the other misconceptions…
It’s not necessary for a successful red team candidate to be an expert penetration tester. It absolutely helps and probably never hurts (except if it means you always look for RCE over phishing), but if you can phish and think like a covert systems administrator, then you can probably be successful on a red team. Some people think red teaming is all about locating remote code execution vulnerabilities and exploiting them — trust me, we usually wish it was that simple. The reality is RCE bugs are rare — we’ll pop them if we find them, but typically we have to social engineer and phish our way in, or abuse features rather than bugs. RCE bugs are more likely present on the internal network than Internet facing, but even still they are not as common as some may think. Just because Nessus says some service version is vulnerable, does not mean that it’s RCE exploitable, that exploit code is available, or that the red team can actually weaponize an exploit within the timeline of the adversary simulation campaign.
It’s also not necessary to have a decade of experience, but it absolutely helps. The longer you’ve spent in the IT industry, the more quickly you’ll recognize patterns and the mindset of defenders which can help you to exploit and persist. If you’re junior and you have an affinity for red teaming, you can probably do fine without it, but if you haven’t watched a few large enterprise projects roll out, you’ll be at a disadvantage — learn what you can from the people with a couple gray hairs on their head to make up for it. If you want to end up doing red team work, then do yourself a favor and get a variety of roles and exposure before moving into red team — it will still be there when you’re ready.
Hopefully this helps any aspiring red team candidates — and also streamlines my future interviews (if you didn’t read this prior to interviewing, you clearly didn’t do your OSINT homework!).
