My Journey: From Pentest to Red Team to Blue
I was a web application developer in 2010 when I learned about pentesting. I fell in love with the idea that I could get paid to break everyone else’s apps instead of making mine work. After three years of awesome training from the SANS Institute and a lot of CTFs, I landed my first pentest job with Black Hills Information Security (BHIS) in 2014. It was a dream come true, and I enjoyed it as much, or even more, than I thought I would. Occasionally, as a pentester at BHIS, I was able to perform red team engagements. I really had a blast with that and when I saw a full-time red teaming position open with Walmart Global Tech in 2017, I took the leap.
I know there are varied opinions on the differences between a pentest and a red team engagement. But allow me to give my opinion here, based on my experiences.
A pentest
- Limited scope: A specific application, network (e.g. internal, external, PCI), or tactic (e.g. phishing, assumed breach, physical)
- The “customer” is the application developer and/or systems administrators
- Not concerned with trying to go undetected or be stealthy
- Often tester system is added to an allow list and alerts are ignored
- Deliverable: Disclosure of all major vulnerabilities of the systems in scope
- Short: a few days to a week
Red Team Engagement:
- Broad scope, anything goes (almost) in order to reach the objective.
- The “customer” is the defensive team (blue team) to determine how well they detect and respond to intrusion.
- Keen interest in operating with stealth to go undetected. Tester systems never added to an allow list.
- Deliverable: Disclosure of the steps taken to achieve the objective (e.g. access to secret sauce recipe). Not a comprehensive list of vulnerabilities.
- Long: weeks to months.
As noted above, a pentest is technically deep. You are digging deep into the weeds to find any and every vulnerability possible. Whereas a red teamer is focused on reaching a specific goal, such as gaining access to a specific database, and is likely to take the easiest route to get there. Getting your phish through taking too long? Maybe just walk in the open back door and plug in a keyboard.
I loved the variety in red teaming (the breadth), but it came at the expense of losing some technical depth that I hadn’t anticipated. Also, due to the focus and structure of the red team during that time, I spent a lot of time buying, aging, and categorizing domains, creating phishing ruses, setting up servers, SSL certificates, and so on. Since none of our infrastructure was reusable from campaign to campaign, this had me doing this sys admin type work about 50% of the time. I enjoyed learning that part, but it didn’t take long before it became mostly “doing” and little “learning”. This is what first got me considering a change, but what would it be? Blue team was an option. I knew that there would be tons of learning for me to soak up there, but I was scared. I always wanted to be in offensive security, and now, I was considering giving it up voluntarily!
There are two things that helped make the decision to move to the blue team:
1) The fact that I would become a better red teamer by learning the blue team side.
2) The realization that this didn’t have to be a one-way road. I could still pursue a role in offensive security in the future if I chose to.
So, in 2019 I joined Walmart’s blue team as a “Dynamic Defense Engineer” which I would define as a role that adapts to the needs of the organization to improve defensive readiness. When I joined the team, I expected to be given a giant list of prioritized tasks and start working my way down the list like I did as a developer under the “Agile Development” methodology. Instead, I was challenged to propose solutions and improvements of my own, and then, make it happen. Because of this, I was able to work on things that have a big impact on the organization but also are in the areas I’m passionate about.
I proposed that the blue team start emulating attacker behaviors in a scripted, easily repeatable fashion to aid in detection development and validation. I recruited help from many of the SOC analysts and it became a full-fledged project involving the open source Atomic Red Team Project. The dev team also got involved and built automation around the whole process and built a detection catalog to show where our detection gaps are.
In my work with attack emulation on the blue team, I have been able to learn about and play with all attack techniques. Whereas, as a red teamer I focused on only the stealthiest techniques and only used them at the point in an engagement where a technique was fitting to use. I have enjoyed this blue team opportunity to learn about and test all attack techniques, where I can quickly measure detectability and most importantly, to add detections where they are found missing.
Do I miss being a red teamer? Yes, I miss those moments where my heart is pounding, and my hands are sweating when I see that something I tried worked. To me, that is the most exciting and fun thing but a close second to that level of excitement is seeing custom detections I’ve written catch the bad guy or the red team.
So what next? I love to learn, and based on my prior offensive work experience I feel like my learning continues to be more maximized on the blue team. I also love sharing the attacker mindset with my fellow blue teamers in a mentoring capacity.
The more you know about offense, the better defender you can become and vice-versa. So, my advice is to try both in order to maximize your learning and experience before you settle down into one or the other. For sure, I have learned more in my three years on the blue team than I would have learned in “another three years” on the red team. But at the same time, I recognize that the longer I am away from the red team side, the less that becomes true. The good news is that my options are open and if at some point I move back into offensive security, I will be better because of my experiences on the defensive side.
