The Cobalt Pentester Spotlight highlights the fascinating journey of our Core members. Through an interview style, we share their experiences, background, and insights into the world of an accomplished pentester.
What's your handle? Do you use more than one? Where did it come from?
No clever alias here. My handle is simply my name, Prateek Thakare, and I use it everywhere. Using my real name was a deliberate choice for me. It keeps my identity consistent, and it means the work I do always carries my name.
What got you into cybersecurity? How did you get into pentesting specifically?
My interest in cybersecurity began in high school, sparked by hacker movies and TV series. The idea was exciting, but I had no clear way into the field back then.
That changed in my second year of engineering, when I discovered bug bounties. Bug bounty gave me a real, hands-on entry point, and it's what drew me into pentesting.
What keeps me hooked is that pentesting feels like an ongoing mystery. Every attack technique, every zero-day, and every new methodology shows me a different angle and changes how I think about the next problem.
What exploit or clever attack are you most proud of and why?
The work I'm proudest of is breaking business logic. Every application rests on assumptions about how users will behave, and each of those assumptions has a story behind it. I enjoy questioning them one at a time until I find where the logic falls apart. That focus has helped me uncover valid, high-impact issues on public bug bounty programs.
Broken access control is a close second. I go after access control flaws that carry real impact, where a single missed check can expose data or functionality that should be off-limits.
Even so, I stay open to new techniques and attack classes. There's always something new to learn.
What is your go-to brag when talking about your pentesting skills?
My background in code review. Years of reviewing code have given me an instinct for picturing the code and logic behind an application while I'm testing it. That lets me design test cases that cover every piece of logic around a feature, not only the obvious entry points.
I also spend time getting to know the application the way an end user would. Once I understand how a flow is supposed to work, it becomes much easier to find where it breaks, and that's usually where the high-impact issues are.
Share a time something went wrong in the course of a pentest? What happened and what did you do?
Fortunately, I haven't had a pentest go wrong. Like any tester, though, I've missed issues now and then. That's part of being human. Every miss reminds me how much the details matter, so I work through every part of an engagement carefully and give each one my full attention.
To keep from missing things, I maintain my own testing checklist, take thorough notes during every engagement, and keep my knowledge current with something new every day.
What are your favorite tools or TTPs when conducting pentests? Why do you find them effective?
Burp Suite is the core of my manual testing. I lean heavily on its extensions to streamline my workflow and handle repetitive work, which leaves me more time for the parts of testing that need human judgment.
I also use Waymore extensively to search web archives. Older endpoints, forgotten parameters, and archived files often turn up leads that don't show up in the live application.
More recently, I've been adding various MCP servers to my workflow. They help with many supporting tasks, so I can spend more of my attention on in-depth manual testing.
What are your favorite asset types (web applications, APIs, network, etc.) to pentest and why?
My favorites are web applications, APIs, and mobile, along with code reviews.
Web and APIs are where my pentesting journey started and where I've found most of my bugs, so they'll always be home ground for me. After a few years focused on web, I moved into mobile pentesting, and digging into it in depth gave me fresh energy and a new set of challenges.
Code review has been part of my work ever since I moved into the engineering side of cybersecurity. Reading through different architectures, business logic, and tech stacks has broadened my knowledge, and it shapes how I approach every other kind of assessment.
What certifications do you have? Why did you go for those ones specifically?
I don't hold any certifications yet. So far, my learning has come mainly from hands-on work in real-world testing, bug bounty, and code review. I do plan to pursue a few certifications soon to add structure to that experience and go deeper in specific areas.
What advice do you wish someone had given you when you first started pentesting?
Depth matters a lot.
I wish someone had pushed me early on to go deep on everything and understand how things work at their core, instead of stopping at the surface. I only came to understand that and put it into practice after I moved into the engineering side of security.
I also wish someone had shown me sooner how wide the field is. Security goes well beyond web, API, and mobile testing. Areas like reverse engineering open up entirely new ways of thinking, and I would have liked to explore them earlier. I'm making up for that now by starting to dig into reverse engineering myself.
How do you approach explaining findings to customers during a pentest? Is there a way you discuss your findings with customers? How do you ensure they have a quality experience?
I keep in mind that the people reading my reports can come from any background, from security engineers to product owners. So I write every finding as if I'm explaining it to someone new to security.
Each report includes detailed screenshots and clear, step-by-step reproduction instructions. In the description, I also explain what the affected feature does and exactly where in the flow the issue occurs. That context helps customers understand not only what is wrong, but why it matters, and makes it much easier for their teams to validate and fix it.
What is your favorite part of working with a pentesting team? What about working on your own?
Working with a team is valuable because it exposes me to other people's perspectives and ways of thinking. A teammate often looks at a feature from an angle I wouldn't have considered, and that makes the whole assessment stronger.
Working on my own has its own benefits. When I own the entire pentest, I feel fully responsible for it, and that pushes me to make sure every part of the application gets thorough coverage.
Why do you like pentesting with Cobalt?
Cobalt gives pentesters a platform where we can work at our own pace while still bringing our best and delivering our best work. That balance has helped me grow, especially in how I approach professional ethics and responsibility on every engagement.
I also value the support Cobalt provides and the way the platform makes communicating with customers smooth and efficient. Those things let me focus on what matters most: the testing itself.
Would you recommend Cobalt to someone looking for a pentest? Why or why not?
Absolutely.
Cobalt brings together a large community of experienced pentesters from a wide range of backgrounds and specialties. That diversity means customers get testers with the right skills for their environment, and it gives them access to high-quality pentests.
What do customers or the media often misunderstand about pentesters?
Pentesters are often seen as people who just break things. In reality, we carry the responsibility of disclosing vulnerabilities responsibly and helping customers fix them. Breaking something is only the first step. Helping make it secure is the real goal.
Another common misconception is that pentesting is just a checklist exercise. With software being built and shipped faster than ever, security can't be a box to tick at the end anymore. It needs to be part of a fast-moving SDLC from the start, so teams ship secure software by design instead of trying to add security afterward.
How do you see pentesting changing in 2027 and over the next few years?
AI has already changed how we pentest, and that shift will only speed up. But as the saying goes, it's not the plane, it's the pilot. Testers with real knowledge and experience have a major advantage, because they know how to direct LLMs, judge their output, and apply it where it counts.
The way we work will keep transforming, but the best results will come from pairing these tools with human intelligence and judgment, not from replacing it.
What’s one non-technical skill (e.g., writing, communication, project management) that you believe is becoming critically important for a successful pentester and how do you cultivate it?
Communication.
Talking with customers, understanding what they need, and learning how their software is meant to work all make a big difference to the quality of a pentest. I prefer asking questions about the application up front, because the more context I have, the better I can focus my testing on what actually matters to the customer.
I build this skill by writing detailed reports. Explaining each finding clearly and completely, so anyone on the customer's team can follow it, keeps sharpening how I communicate.
What's your p(Doom)?
Low, as long as defenders keep pace.
AI is clearly changing how we work, and like any coin, it has two sides. Attackers are using AI too, and they are becoming more capable than ever. That raises the stakes for defenders to build and ship secure software.
In this landscape, defense in depth is no longer optional. It should be a baseline requirement, because layered controls greatly reduce the blast radius when something does get through.