Based in the Netherlands, Stefan Goossens, otherwise known as G0053, is both an independent security researcher and a partner for a marketing and web development company.
As someone who loves nothing more than building and breaking web applications, Stefan is perfectly placed at the intersection of these two careers.
While his day job is spent focusing on devising, guiding, and realizing user-friendly websites, his free time is spent testing those very applications to see what creaks, leaks, or collapses.
He is an Intigriti Hacker Ambassador and co-founder of HackerHideout, an exclusive community for bug bounty hunters, pen testers, and ethical hackers.
In today’s ‘Hacker Spotlight’, we talk with Stefan about his journey, the challenges he has faced, and shared insights for those wanting to start a bug bounty program.
I was online one day, doomscrolling through YouTube, and I came across a video of STÖK, a Swedish hacker who creates educational cybersecurity-related video content for the bug bounty community. What he was doing was really cool. In fact, I still remember his bright purple neon setup. But while I was intrigued, I was equally unsure. At this point, I did not know what was legal or not. So, I started researching. For peace of mind, I chose to start with Intigriti because it’s a European company who provide lots of information on what is and is not allowed.
My first bug was on a Red Bull program approximately 5 years ago. But my early success was with a private program, which accounts for one-third of my 3000 reputation points.
I was lucky. This private program had a very big scope, and I still didn’t have the hacking skills in place. I think the first bug was cross-site scripting. A very basic one. Just pasting 123 in every field and seeing if something came up. I started with SQL injections, cross-site scripting, and checking PortSwigger Academy and watching YouTube, and then gradually found more complicated bugs.
As a teenager, I liked to build websites, and I still do so with my company, next to online marketing, so I know a bit of HTML and how websites should behave. But I did not have the hacking experience. I’m just not super technical, so I prefer focusing on business logic vulnerabilities and application behaviour. I still can’t do the really complicated stuff, but I often find bugs by looking for error messages and testing unexpected inputs.
I like the challenge of a puzzle. I look at something, try to reverse it, and see if the business logic makes sense. I check in like a normal user and follow the process of ‘well, they want me to do this. But what happens if I do the opposite?’ Can I do something else? Can I get past this process to order things with a negative value? I like the process of seeing what else can be done.
It depends. Sometimes I find a program that I really like, and I spend two hours every night on it. But there are also weeks when I only spend two hours in the whole week. But when I find something I like, I try to be consistent with it.
And then once I do actually find something I like, I will think about it during the day and try things out later. For this, I have Caido hosted on Virtual Private Servers (VPS), and a self-hosted note-taking tool accessible from work to home. This means that if I’m at work, I use the same workspace. I even have a shortcut on my Apple Watch that transcribes what I say, and it sends my voice note to my note-taking application. I might be out doing groceries, and I’m like, ‘wait, I can do xyz?’ and then I feel like Inspector Gadget talking into my watch with my ideas to try later.
This is the same when I write code, sometimes I’m brushing my teeth, and I realize I’ve made a mistake, and I have to come back down, turn my computer on, and fix the code. My brain is still processing.
I don’t think I would ever be a full-time bug hunter. First, I’m not skilled enough. Second, I like having the mix of this with my day job. It means that if I just want to zone in, then I can, and if I have a slow day at work, I also hunt at my office, which is exciting. I can just click around for one hour and enjoy the process without the pressure.
Start earlier. I should have started 10 years ago or maybe even sooner. I am comfortable knowing around 50 to 60% of bug types, but I would like to be better at more. For instance, I don’t know a lot about Server-side Request Forgery (SSRF), but when I spot one that I think there might be something here, I just open Discord and talk with those who know more on the topic. Although I really like to collaborate, it would be nice to have some more knowledge about now unfamiliar vulnerabilities. I also experience this when I want to do a hacking night. I want to be able to learn more and join in more.
Starting now, it’s also hard because of AI. I feel like everything has changed, so I wouldn’t even know how to start now. I do experience FOMO from social media posts claiming AI finds bugs automatically, but I am equally sceptical of AI hype and concerned about misinformation. I value the puzzle-solving aspect of hunting, and I don’t want AI to take the fun out of it. I do use AI tools like Codex to enhance manual hunting workflow, but not to fully automate bug finding. AI can make manual hunting easier, but I’m also just a bit lost when there is so much misinformation going around.
Responsiveness, timing-wise, helps a lot because usually, when I find one bug, I submit it, and I don’t hunt until I see how the reply is on that one bug.
Four years ago, I would just open a program and hack, hack, hack. And then in a few weeks, they were all pending. And then two weeks later, you got your answer. But now, because the timeline is so long, you don’t get a sense of how the program works. If you get your answer three months after you submitted it, it kind of takes the thrill out of it.
It’s hard to find programs where you know your work is being appreciated. I now vet programs before investing significant time to understand if it’s a good program and if I’m going to do more on it. I submit one bug first to assess responsiveness and assessment quality.
Slow response times kill momentum and make it hard to gauge program quality, and friction from excessive requirements, such as headers, lengthy out-of-scope lists, and extensive known issues. I also wish that program pages were kept updated with a known issue list and what is being fixed. That would reduce some friction.
Thank you, Stefan, for sharing your journey and invaluable insights with our community. For anyone interested in hacking, your story shows that it’s possible to do it all: build a full-time career you love while hacking for the thrill of solving puzzles, learning, and growth, while simultaneously making the world a safer place.
At Intigriti, along with our mission to keep companies safe, we have a mission to create a community where hackers can thrive, grow their skills, and achieve great things.
Contact the team today to learn more.
