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, and what's the origin story?
Oyildirim on Cobalt, and orhnyldrm on other platforms. Just my name, Orhan Yildirim. I used whatever was available when I signed up, and I never really thought about it beyond that.
What got you into cybersecurity? How did you get into pentesting specifically?
Psychology degree, co-founded a business, then ran the family tea factory for a while. When economic conditions forced us to shut it down, I had a choice: either go back to my old career or take a risk on something I was actually passionate about - computers.
This was about 10 years ago. Cybersecurity was just starting to take off - defensive security barely existed, just constant news about breaches and hacks. I took some training courses and the difficulty hit me hard. Turns out I enjoy pushing myself through hard things.
What exploit or clever attack are you most proud of and why?
I'd say a US government agency VDP. I found an unauthenticated API endpoint exposing immigration application records. No auth, no access control, just increment the account ID, and you get someone else's sensitive data. Simple IDOR, but the impact was real: anyone on the internet could pull immigration records by guessing numbers.
Not technically complex, but that's what made it memorable. Sometimes the most critical findings are the ones hiding in plain sight. A single curl request, no tokens, no headers - just a raw GET and you're in.
Another one that stuck with me: a US state benefits portal. Started as a basic IDOR on a member endpoint, but the SSN field came back encrypted. Most people would stop there. I dug into the JavaScript files and found the encryption key hardcoded in the frontend. CyberChef, decrypt, full SSN exposed.
What made this one satisfying was the extra step. The encrypted response looked secure at first glance - probably passed a few reviews that way. But client-side encryption with a hardcoded key is no encryption at all.
What is your go-to brag when talking about your pentesting skills?
I don't specialize. Web, API, mobile, cloud, Active Directory, IoT - I've tested across all of them. That's my edge.
Something you learn in one domain always shows up somewhere else. A trick from API testing helps you spot a mobile app flaw. An Active Directory pattern appears in cloud misconfigurations. Experience isn't just years - it's connecting what you've learned across different areas.
There are people way more skilled than me in specific niches. But I'd rather be dangerous in multiple domains than expert in just one.
Share a time something went wrong in the course of a pentest? What happened and what did you do?
Early in my career, mostly doing Active Directory tests. I had a password pattern from the client and built a wordlist to spray across accounts.
Open office environment. About ten minutes in, people start standing up from their desks. "I can't log in." "What's happening?" I immediately knew what I'd done. Checked the password policy. Three attempts before lockout. I'd locked out a good chunk of the office.Found the IT admin, got accounts unlocked, everyone back to work. Now I check lockout thresholds before touching anything.
What are your favorite tools or TTPs when conducting pentests? Why do you find them effective?
Burp Suite with custom extensions I write myself - mostly focused on JavaScript analysis. Hardcoded secrets, dangerous sinks, DOM-based issues. If it's in the JavaScript files, I want to catch it.
For recon and automation, ProjectDiscovery tools: katana for crawling, httpx for probing, nuclei for scanning. I keep up with their repos - they ship fast and the templates are community-driven.
I don't trust a single tool to find everything. Scanner says clean, I go manual. The interesting bugs live where automation doesn't look.
What are your favorite asset types (web applications, APIs, network, etc.) to pentest and why?
Two years ago I would have said APIs and cloud environments. APIs because the logic flaws hide in the business layer, not behind a UI. Cloud because misconfigurations compound - one wrong IAM policy and you're somewhere you shouldn't be.
Now it's AI and LLM implementations. Everyone is rushing to ship AI features, security comes second. Prompt injection, training data leakage, model manipulation - the attack surface is new and most teams don't fully understand what they've exposed. I've been doing a lot of these assessments lately and the findings are interesting.
Ask me again in two years, it'll probably be something else. That's what I like about this field.
What certifications do you have? Why did you go for those ones specifically?
OSCP, OSCE, OSWP, CRTO, CRTP, and several HTB Pro Labs. I prefer Offensive Security certs and anything with hands-on labs. Multiple choice tests don't prove much.
In this field your experience is tied to the cases you've seen. Certs with real labs give you more cases, more edge scenarios, more failures to learn from. I try to stay active on HTB and do research when I can. What worked last year might not work today.
What advice do you wish someone had given you when you first started pentesting?
Find your domain early. Web, API, cloud, mobile - each one needs different skills and different thinking. Some people figure this out after years of jumping around. I would have saved time knowing this sooner.
Also, build something. A few projects on the side. When you've written code and dealt with architecture decisions yourself, you see applications differently. You spot what developers miss because you've been there.
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?
Report quality speaks for itself. High level description, affected resources, impact, steps to reproduce, remediation, references. If you fill these out with enough detail, the customer sees what you actually did. Steps to reproduce should be written so someone seeing the application for the first time can follow them - another tester will verify this during retest anyway.
Customers want to hear about their business logic, not generic findings. If you're testing a banking app, an XSS might be valid but it won't excite them. They want to know if you tested the actual banking operations - transfers, approvals, limits, whatever their core features are.
I spend the first few days understanding what the application does, who it's for, how it works. Once you understand their logic, you can talk in their language. That's when the conversation gets useful for both sides.
What is your favorite part of working with a pentesting team? What about working on your own?
Team testing has a rhythm. Someone finds something, someone else spots a related feature, suspicion builds around a specific area and everyone focuses there. You learn from how others think - that hacker mindset rubs off. I've picked up more from watching teammates approach a problem than from any course.
Solo is different. Bug bounty is mostly alone. I like the focus - no coordination, no waiting, just you and the target. You go deep at your own pace.
Both work. Depends on the engagement.
Why do you like pentesting with Cobalt?
Cobalt is a hive where no one steps on each other. Not just core members - every TMP, every CSM knows pentesting inside out. I've had engagements with long-time customers where I finish the test just by checking in on them. First-time customers get a different experience - for them, this place is a school.
In this industry, experience alone doesn't make you good. You have to keep up. Cloud security came in about 10 years ago, Web3 peaked 5 years ago, then API security, now AI/LLM. Mastering each domain completely is nearly impossible. Cobalt keeps you in that ecosystem.
You might be building expertise in one area, doing solid work, and then learn something new from a tester in their first year. Happened to me - spent years doing something, thought I had it figured out, then a junior tester casually mentions "oh that's called Crescendo Attack." Thanks for that.
There's a saying: "Karate ni sente nashi" - to defend yourself, you need to know how to attack. That's what we do here.
Would you recommend Cobalt to someone looking for a pentest? Why or why not?
If you're a startup, you probably first hear about pentesting when you need SOC2 or some other compliance. If you're enterprise, you either have hundreds of tests to schedule or you're stuck in corporate chaos trying to fit your annual pentest somewhere in the calendar.
Cobalt is ready for both. Always.
I worked at one of the best consulting firms in Turkey for years. We'd do hundreds of tests annually, but by month 7 or 8 we'd stop taking new clients - booked until Q1 next year. Now think about those customer profiles again. You'd be scrambling to find someone available. That's when Cobalt shows up.
Or say you did your first test somewhere else, it finished, and you still don't really understand what a pentest is. Next year you want actual value for your money. Cobalt shows up again.
If you're going to need a pentest someday, you'll run into Cobalt one way or another.
What do customers or the media often misunderstand about pentesters?
People think pentester means "white hat hacker" and move on. A pentester looks at your system the way a hacktivist would, the way a financially motivated attacker would, the way a state-sponsored operator would. We wear different hats depending on your threat model.
What customers misunderstand: they think automation does what we do. They spend hundreds of thousands on security products, then a single pentest finds what none of those tools caught. Many companies treat pentesting as a compliance checkbox. That changes after the first real engagement.
Media has its own narrative. Years ago they pushed automation as the replacement for manual testing. Still waiting. Now it's AI that will replace pentesters. AI can help, it makes certain tasks faster, but it doesn't have human creativity. It doesn't have persistence. It doesn't have the stubbornness to keep pushing when nothing is working.
Think about it this way: if I needed surgery and felt comfortable lying on that table letting a robot operate on me with zero human involvement, then I'd trust full automation for my security too. Not there yet. Maybe never.
Every new technology brings new attack vectors anyway. AI included.
How do you see pentesting changing in 2026 and over the next few years?
2026 and beyond, pentesting shifts gears again. AI products and their implementations will dominate the conversation. New tools, new data leaks, new attack vectors. No matter how securely you configure AI, it's still a fresh surface that needs to be tested.
We're seeing new startups in security tooling claiming scalable, capable automated testing. But a skilled pentester with time and some development knowledge can already do most of that with existing open source tools. The real problem has always been business logic. OWASP keeps logic flaws at the top for a reason - automation struggles there.
AI will bring improvements to pentesting workflow. But implementing it properly still takes effort. We now have AI agents that write their own code, grant their own permissions, run autonomously. A few weeks ago another one dropped - acts as a personal assistant, controls your entire machine, you can command it remotely.
Think about that. Last year we were talking about zero trust. Now people are handing their entire system - personal data, projects, everything - to an AI agent. I wouldn't let another person look at my screen for some of this stuff, but we're watching people give full access to an agent they barely understand.
That contradiction alone proves manual pentesting isn't going anywhere. If anything, regulations will expand scope requirements. The threat model AI created guarantees more work for pentesters, not less.
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?
Pentesters always prioritize technical skills first. But that's becoming something you can offload to AI now. Hands-on practice on a specific technology isn't my top priority anymore - AI can help you get there faster.
What matters more: chaining vulnerabilities together, developing hacker mindset, keeping up with new technologies. The thinking, not just the doing.
For client-facing work, communication has always been the most important skill. Understanding what the customer actually needs, what worries them, what their priorities are for this specific test. You can find a hundred vulnerabilities but if you can't translate that into something meaningful for them, it doesn't land.
I studied psychology before getting into security. That background helps more than any certification when I'm sitting across from a customer trying to understand what they're really asking for.
What's your p(Doom)?
People won't set their Instagram profile to public, but they're handing over their email, calendar, company data, personal photos, entire computer to AI agents. That contradiction is about to land somewhere bad.
A single company like JP Morgan spends 15 billion dollars a year on technology - more than many countries' budgets. And we still watched a patch error from one endpoint security vendor take down millions of devices worldwide. That was just a patch mistake.
Now imagine a vulnerability in AI infrastructure at that scale. I don't want to picture that scenario. That's my doom.
