Interview

First Steps in Bug Hunting

I first heard about bug hunting through friends in the local CTF scene, but what pushed me into it was my professional work. I had spent years evaluating security products, building detection scenarios, testing EDR telemetry and performing proof-of-concept work. Those tests often ended with me finding something that was not supposed to happen and reporting it to the vendor. I realized the same mindset could be applied much more broadly, so I started doing security research outside my day job and eventually moved into bug bounty hunting.

My advice to younger researchers is to stop collecting payloads and start reading code and documentation. The interesting bug is usually in the gap between what the vendor says the product does and what it actually does.

When I approach a new target, I do not scan first. I install it, use it the way a real customer would, learn its roles and data model, understand how the different components interact and only then start asking which boundaries are not actually being enforced.

About the Testing Methodology

I keep a fixed skeleton: mapping the application's routes, roles, privileges and major data flows before I touch anything. Then I let the target decide the rest.

I apply the same verification discipline to research and retesting. When I re-measure a finding, I use the report's original payload, test every route named in the report and include a control case where the behavior should be different. On a mature product, the generic checklist is usually already covered. The interesting bugs tend to live in code paths that the vendor's normal tests do not reach, especially where different components make different assumptions about identity, ownership or authorization.

My main tools are Burp Suite and a code editor, combined with small scripts and scanner passes written for a specific target. I prefer small tools that answer one question rather than maintaining a large generic scanner. For wordlists, I usually build them from the application itself: its routes, parameters, error messages and object names are often more useful than any public wordlist.

When a vendor fixes a finding, I preserve the old behavior from a frozen version as a known baseline and turn the fixed point into a regression test, so the finding does not simply disappear from the scanner's view.

Favorite Bug Classes

Multi-tenant authorization. Cross-tenant IDOR, broken object-level authorization and privilege escalation between roles are probably my favorite classes.

I like these bugs because they often survive ordinary code review. The code can look perfectly reasonable and the query can be well written, but the application still resolves a resource using the wrong ownership context or identifier. I particularly enjoy cross-tenant chains where several authorization decisions interact and the application eventually crosses an organizational boundary.

I also like SQL injection in places where people normally do not look for it, such as identifiers rather than values, or inside files and artifacts that the application parses on behalf of the user.

Certifications and Achievements

I hold Splunk Enterprise Certified Admin and Splunk Core Certified Power User, both from my defensive years. I have no offensive certification and I am open about that. Certifications can open HR doors, while a reproducible Critical opens engineering doors. They are a good structured way to learn when you are starting out and become much less important once you can demonstrate what you can actually do.

My team won Turkey's national Siber Beyin competition in 2017, organized through the Ministry of Youth and Sports, with around thirteen thousand applicants. In 2023, I placed second with my bank's team in the Finance Sector Focused Cyber Exercise, organized by the Ministry of Treasury and Finance, where we competed against forty-three teams. I have also participated in NATO Locked Shields on the Forensics track.

In bug bounty, the finding I am most proud of is a license verification bypass in an enterprise DFIR platform. By analyzing the application's license validation flow and trust model, I identified a way to bypass the intended verification and operate the application with Enterprise-level functionality. It required reverse engineering parts of the validation logic and understanding where the trust boundary could be broken.

The Future of Bug Bounty

Can bug bounty hunting be a full-time job?

It can be, and for some people it clearly is. I have chosen not to make it my full-time profession because I believe my day job is one of the things that makes me good at bug hunting. I see how security products are designed, tested, deployed and operated in real environments. I also see the problems defenders actually face. That perspective tells me where products are likely to break.

What is the role of automation in security testing?

Automation belongs at the beginning and at the end of the process, not in the middle. It is very good at telling me what changed between releases, which routes exist, whether old findings are still reachable and whether a known behavior has changed. It is much worse at deciding whether something is actually a vulnerability.

Every scanner I write has to prove itself against both a known bad case and a known good case before I trust it. Otherwise, a silent zero result can look exactly like a clean product. Automation should remove repetitive work so the researcher can spend more time understanding the application.

What are your expectations of bug bounty platforms?

Three things come first: triagers who actually read the evidence, decisions I can argue with on technical grounds and speed. Platforms should also keep improving the researcher experience through better automation around submissions, notifications and other repetitive parts of the workflow.

What is your impression of Hackrate?

I like Hackrate because it still feels relatively close to researchers. The triage I have received has generally been technical and specific, and when my severity was reduced, I could understand the reasoning behind the decision. I respect that more than simply receiving a generous severity rating. A technically justified decision tells me someone actually opened the report, understood the issue and made a decision based on the evidence.

Hackrate still has room to grow, especially on the platform and researcher-experience side. If it can keep the technical quality of its triage while improving the infrastructure and overall researcher experience, I think it can become a much stronger platform for security researchers.