AFTER ROOT // DISPATCH 001

Welcome to After Root. I write about building a career without giving up what makes you a hacker.

Let’s start with something I learned in penetration testing.

Early in my career, I cared a lot about how cool the exploit was. What could I break? How did it work? How far could I take it?

Finding the vulnerability and showing how to reproduce it felt like the important part.

Later, I decided the report was the important part. You could have incredible technical skills, but if the report was poor, the end result was still a poor test. I put more weight on documenting the work and let the report speak for itself.

Experience changed that again. I found the most valuable part was the thirty-minute call to go over it.

That was where we could talk about the team’s goals, their timelines, and what they could realistically fix first. Sometimes those conversations surfaced other projects or problems where they needed help.

We could help them think through a strategy, including which risks they might choose to accept. The report held the evidence. The conversation helped the team decide what to do with it.

I gradually started understanding the why behind the work. My curiosity had mostly stopped at how the exploit worked. I needed to get just as interested in what that meant for the people depending on the system.

The vulnerability's name doesn't answer that question.

An internal application for sharing takeout menus and a critical payroll system give you different things to worry about. I need to know who depends on the application, what it touches, and what happens if something goes wrong. I can't get all of that from the severity rating.

Scoping meetings and report-outs reveal a lot if you listen. Maybe the application was rushed. Maybe it's an executive's pet project. Maybe it's already being rewritten.

Take the rewrite. Now I have more questions: when will it replace the current application? What depends on that application until then? Is the same problem being carried into the new version?

Those answers help us decide what needs fixing now, what belongs in the replacement, and what risk the business would be accepting by waiting. Learning the context changes the advice I give.

It can also change how far I take an exploit. Sometimes further exploitation is necessary to establish impact. Sometimes I already have enough evidence to explain the risk. Going further because it's technically interesting doesn't automatically make the test more useful.

There's a weird tension in penetration testing. The more vulnerabilities you find, the better you can feel about your work, and the worse the team across the table can feel about theirs.

I try to make it clear that we're part of the process of making the application more secure. They had something to get working and deadlines to hit. Bringing us in is already a step toward improving it.

Plenty of vulnerabilities also come from time passing. Frameworks age out of support. New attacks and bypasses are discovered. Good practices change. Finding something today doesn't automatically mean someone did a bad job yesterday.

If I treat the conversation like I'm grading their competence, I make it harder for them to tell me what they're actually worried about. I want us working through the problem together.

On your next scoping call or report-out, ask: “What are you most worried about with this system?”

Follow the answer. If they're worried about an outage, ask what stops when the system goes down. If they mention a rewrite, ask what depends on the current application until the replacement is ready.

Listen for what's missing, too. If you don't understand who uses the application or what they depend on it for, ask. Don't fill in the blanks yourself.

Good questions lead to better questions. Use what you learn to explain one finding in terms of what it means for that team and what they need to decide next.

Getting better at consulting has meant bringing more of my curiosity into the conversation. The people and their problems deserve the same interest I bring to figuring out how a system works.

What's a question that changed how you understood a technical problem? Hit reply and tell me. I'd like to hear it.

Stay curious,
Alex