Senior in 18 months, and a red team built from nothing
TLDR. Tell the people hiring you exactly where you want to end up, then do work strong enough that they have a reason to take you there. That is how I got onto a red team in 18 months, and it is most of what red teaming actually rewards.
The single smartest thing I did was on my first day. I met the partners of my team and told them plainly what I wanted: to be on a red team. I said it to the people who were going to be deciding my path, before I had done anything to earn it. From then on they were actively helping me get there.
A year later a red team position opened up, driven by a new government regulation. I was the first pick.
Getting to senior fast
The usual path from associate to senior is two to three years. I did it in about eighteen months, and I will be honest that it caused some friction. There were seniors who felt the red team seat should have been theirs, that they had more experience than me. They were not wrong about the experience.
What I had was consistency. On every project I was finding high or critical vulnerabilities. I followed the checklist so that the engagement met its requirements, but I did not stop there. The attacks I tried were more creative, and I was more thorough than the checklist asked me to be. That is the part that compounds: one strong finding is luck, strong findings on every project is a pattern someone notices.
The other half was certifications, and I went after them actively. After OSCP I took CRTP, and a CREST certification.
The certs that matter for red teaming
The CREST certification was easy. It was multiple choice, and the honest framing is that it certifies you rather than stretches you.
CRTP was the fun one. It focuses entirely on Active Directory attacks, and it is where the real applied work lives: Kerberoasting, silver tickets, genuine privilege escalation and lateral movement rather than the theory of them. It was more intense than OSCP in its subject, but very doable, and I would say more fun, because everything you learn is something you will actually do on an engagement.
Building a team that did not exist yet
When I joined the red team, almost nothing was there. Infrastructure, tooling, methodology, rules of engagement. I was part of building all of it from the ground up, and that was the best part.
I built sandboxes and virtual machines that imitated our clients' systems, so we could develop and test attacks against something realistic before going anywhere near production. I built our command and control lab on Azure, provisioned automatically with Terraform, so the whole environment could stand itself up rather than being hand assembled every time. That was for internal testing. It is worth saying clearly that it was not turned on our clients.
I will not go into the payloads in detail, but the work was specific to antivirus evasion, and it drew directly on the evasion material I was studying at the time.
The printer that let us in
On one engagement we were given a very wide attack surface. That sounds generous, and it is, until you find that the network is mature. The obvious routes were all well defended. Strong firewalls, ports locked down. Everything you would reach for first was exactly what they had prepared for.
The way in was a printer.
On a network with proper access control, every switch port asks a device to authenticate before it is allowed on. But a printer usually cannot authenticate, so it gets an exemption: the switch recognises it by its MAC address and lets it on anyway. That exemption is the hole.
Using Kali, I changed my laptop's MAC address to the printer's. When I plugged in, the switch saw a MAC it already trusted and put me on the network as if I were the printer. My ordinary laptop was now a machine on the client's internal network.
From there I enumerated. What I found were shared documents, notepad files and sticky notes, holding the cleartext credentials of several different accounts. That is a very high finding, and it is the oldest lesson in security wearing new clothes: the network was hardened, and someone had written the passwords down in a file anyway.
Red versus purple
The difference is simple and it changes everything about how the day feels.
On a red engagement, the defenders do not know we are attacking. The test is partly whether they notice at all. On a purple engagement, we plan the attacks together and out in the open. We tell them we are going to run a particular attack at a particular time, and the blue team watches their side and works on responding to it properly.
What surprised me most about my first red engagement was how open ended it was. On a pentest you work through a scope. On a red team you are handed a goal and left to be creative, and alongside that creativity, staying quiet matters enormously.
My first mistake, which was loud
On my very first red engagement I fired off an nmap scan without covering my tracks. No thought to the flags that keep it slow and quiet, just run. It threw off too much traffic at once, the blue team saw it immediately and reacted, and that flipped the engagement from red to purple, because the whole point of red is that they do not know you are there.
It was fine in the end, and it is funny to me now. But it is a clean lesson: on a red team, the scan that gets you caught is worse than the scan you never ran.
The dynamic with the defenders
We did not talk to the blue team directly. There was a middleman, and we only really engaged with them during purple work, where they would sometimes ask us to run an attack again so they could study it from their side. It was not the strange, adversarial thing you might imagine. It felt experimental, and genuinely useful for both teams.
The hardest part
Building evasion payloads from scratch. I would take every technique I could find, from the internet and from the evasion material I was studying, and most of them simply did not work, because they were already outdated. So I went to research papers and built from those, and even those got caught, because our client was running top of the line endpoint detection and response. When you are up against something like CrowdStrike, you are up against a product that has already seen and prepared for the known payloads. Making something it had not seen was genuinely hard, and it took a lot of testing.
That is the honest thing about red teaming: you go well past the hours anyone promises you. I would be up until three or four in the morning building a payload, because the next day I wanted to walk back into the client's office with something ready to test.
Takeaways
If you are doing web app pentests today and want to be on a red team in two years, the ground is shifting under this. Agentic AI red teaming is catching on. It is noisy right now, but within two years I expect it to be far more mature, and the cat and mouse game between offence and defence to get faster on both sides. How fast progress comes will depend heavily on the models each team is using.
Two things hold regardless of that:
Say where you want to go, to the people who can take you there, early. It worked for me on day one and it is still the highest-leverage thing I have done in my career.
And do more than the checklist. The checklist gets the engagement signed off. Everything past it is where you actually get good, and it is what people notice when a seat opens up.
Filed under security, red team, career. If any of this is wrong, or you have hit the same thing, tell me.
Published 11 September 2026.
