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? What's the origin story?
I usually go by @dogukan, which comes directly from my first name. I’ve always preferred using my real name because it feels more honest and authentic to me, especially in a field where trust matters a lot.
What got you into cybersecurity? How did you get into pentesting specifically?
Cybersecurity started with pure curiosity for me. I was always interested in understanding how things worked behind the scenes. As a kid, that showed up in small ways, from taking apart toys to cracking open game files.
Over time, that curiosity moved into cheat codes and glitches. I was not just interested in using them; I wanted to understand what was happening beneath the surface. That same curiosity eventually pushed me toward creating things myself, starting with my own web projects. From there, the next natural question for me became: “How could this break?” I eventually found myself in pentesting, where curiosity, problem-solving, creativity, and a different way of looking at systems became useful.
What exploit or clever attack are you most proud of and why?
One that stands out happened while I was still at university and applying for a part-time role. As part of the process, their security team asked me to perform a black-box test.
During testing, I found a critical unauthenticated Insecure Direct Object Reference (IDOR) vulnerability that allowed access to applicants’ sensitive data by manipulating a parameter. It was not a complex bug technically, but the impact was serious because it exposed sensitive user data. That experience taught me early on that even simple vulnerabilities can create major business impact. In the end, my report also opened the door to a job offer, so it became an important moment in my career.
What is your go-to brag when talking about your pentesting skills?
My go-to brag is that I don’t just test features at a surface level. I spend real time understanding how an application works: the user flows, business logic, permissions, assumptions, and what can go wrong when those pieces do not behave as expected.
That depth of understanding is often what leads to the most impactful findings. Some of the best bugs I’ve found came from asking the right questions about how the application is supposed to behave, not just how it behaves technically.
Share a time when something went wrong during a pentest? What happened and what did you do?
A common issue I have seen during pentests is that test accounts do not always have the right permissions, or the test environment does not always have enough data to properly exercise certain workflows. This can limit parts of the testing and delay the engagement if it is not handled properly.
In those situations, I document the blockers clearly, share examples with the client, and explain which parts of the scope are affected. For me, the key is to keep the assessment moving while making sure any limitations are clearly communicated.
What are your favorite tools or TTPs when conducting pentests? Why do you find them effective?
For web and API testing, Burp Suite is my main tool. I use it to understand traffic, modify requests, test authorization, and dig into business logic issues. For content discovery, I like ffuf because it is fast, simple, and effective when you have a clear target scope and a good wordlist. For mobile testing, I usually combine JADX and Frida. JADX helps me understand the application statically, while Frida helps me see what is actually happening at runtime.
Overall, tools help me move faster, but the most interesting findings usually come from manual analysis and a deep understanding of the application.
What are your favorite asset types (web applications, APIs, network, etc.) to pentest and why?
I enjoy testing web applications, APIs, mobile apps, thick clients, and network and cloud environments, but I find it most interesting when these components are connected rather than tested in isolation.
Some of my most impactful findings have come from understanding how different layers interact with each other. A small weakness in one layer can sometimes create a much larger risk when combined with another issue elsewhere in the system. That system-level thinking is one of the things I enjoy most about pentesting.
What certifications do you have? Why did you go for those ones specifically?
Early in my career, I focused on practical Offensive Security certifications because I wanted hands-on experience, not just theory. I liked certifications focused on real-world problem solving because that is much closer to how pentesting actually works.
I also pursued SANS/GIAC training and certifications because they provide a structured and deep approach to specific areas like cloud security, DevSecOps, and modern security practices. For me, certifications are useful when they sharpen the way I think and expose me to scenarios I may not see every day.
What advice do you wish someone had given you when you first started pentesting?
Build strong fundamentals first. Understand how TCP/IP works, how browsers behave, how authentication and sessions work, and how requests move between the client and server.
Tools and techniques are important, but fundamentals are what help you understand why something works or breaks. Without that foundation, you are mostly guessing. I wish I had spent even more time on the basics before jumping into the more exciting parts of pentesting.
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 focus on business impact, not just technical details. I want the customer to understand what the issue means, how realistic the risk is, and what they should do to fix it.
Report quality matters a lot to me. I try to make every finding clear, reproducible, and actionable. A good finding should explain the issue, show reliable evidence, describe the impact, and provide practical remediation guidance. I prefer direct explanations over long narratives so the customer can quickly understand the risk and take action with confidence.
What is your favorite part of working with a pentesting team? What about working on your own?
Both have their place. With a team, I really value the different perspectives. Another tester may notice a blind spot I would have missed, or approach the same application in a completely different way.
Working solo gives me the freedom to go deep, follow my own methodology, and move at my own pace. I enjoy both, but for different reasons. Team testing is great for coverage and learning, while solo testing gives me space to focus deeply.
Why do you like pentesting with Cobalt?
What I appreciate most about Cobalt is how organized the process is. The platform, communication, scope, findings, and reporting flow are structured in a way that allows me to focus on testing instead of logistics.
Another thing I really value is the variety of experience Cobalt provides. I have had the chance to work on different types of pentests across different industries, technologies, and client sizes. That exposure helped me grow technically, but it also helped me understand how security expectations can change depending on the business, product, and environment.
The community is also a strong part of it. Being surrounded by skilled pentesters with different backgrounds and approaches makes a real difference. You can learn a lot just by seeing how other testers think and approach similar problems.
Would you recommend Cobalt to someone looking for a pentest? Why or why not?
Absolutely. Cobalt has a strong pool of skilled pentesters across different types of assessments, including web, API, mobile, network, and cloud.
The process is smooth from kickoff to final report delivery, and real-time communication throughout the engagement is a major strength. For customers, that means they get not only technical testing, but also clear reporting, collaboration, and practical guidance.
What do customers or the media often misunderstand about pentesters?
The biggest misconception is that pentesting is just running automated tools. In reality, tools are only one part of the process. Good pentesting requires thinking like an attacker, understanding the application’s logic, and exploring areas where automation usually cannot reach.
Another misconception is expecting a critical vulnerability in every engagement. Not finding severe issues does not mean the pentest failed. Sometimes it means the engineering and security teams have done a good job building and protecting the product.
How do you see pentesting changing in 2026 and over the next few years?
AI will definitely change how pentesters work. It will reduce repetitive manual effort, speed up parts of the process, and help testers analyze larger amounts of information more efficiently.
However, I don’t think AI will replace human judgment in pentesting. Every engagement has its own context, business logic, assumptions, and risk appetite. Understanding those details and turning them into meaningful security findings still requires human experience and critical thinking.
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. Being able to explain what you found, why it matters, and what to do about it is just as important as finding the vulnerability itself.
A strong pentester should be able to communicate with both technical and non-technical audiences. I try to build that skill by focusing on clarity in every report I write and every conversation I have with clients. The goal is not just to prove that a vulnerability exists, but to help the customer understand and fix it.
What's your p(Doom)?
Higher than I would like. AI is evolving faster than regulation and security practices can fully keep up with, and the human factor makes that risk even harder to control.
My concern is not only AI itself, but the combination of rapid advancement, regulatory gaps, and potential misuse by bad actors. I’m optimistic about the benefits of AI, but I think we need to be realistic about the risks and build stronger guardrails as adoption grows.
