Growing up in the Netherlands, Pepijn van der Stap started hacking when he was 11. At 15 he realised it didn't just have to be a hobby. With a background in software engineering, Pepijn was always pulled between two things: building software, and breaking it in ways the developers did not expect.
His journey hasn't been a straight line. Pepijn has seen security from both sides of the terminal, an experience that taught him hard lessons but ultimately gave him clarity: knowledge is for building and protecting, not breaking. That past shaped his conviction that to build the strongest defence, you have to understand the offence just as deeply.
Today at Neo Security, Pepijn works on offensive security, red teaming, adversary simulation and the kind of testing where a scanner is not going to save you. In this interview, Pepijn talks about business logic vulnerabilities, why they keep showing up, and why real security work still comes down to understanding how a company actually works.
From hobby to profession
Q: The first question is a bit straightforward, but also something I always want to know when I meet hackers: How did you first become interested in hacking?
Pepijn: "From a young age I was really interested in IT. However, I didn't want to use things the way they were intended to be used. I wanted to use technology the way I wanted to use it. It was the desire to make technology work in the way I pictured it that led to me becoming interested in hacking.
At 12 or so, I discovered how easy it was to access websites, and how absurdly simple I could gain access to restricted data. I would try changing numbers in the requests, and I would apply common methodologies to test the limits of what I could do. I was constantly trying new strategies and learning.
When I was 15 I discovered a website with a responsible disclosure policy, and that was my first inkling that hacking could be more than a hobby. I was studying software engineering at the time, and when I finished my internship in programming I began to focus on the security sector. Getting involved in the security sector was when it really clicked for me that I could turn hacking into a profession."
Q: Having a background in software engineering must have given you an edge when it came to approaching exploits. How do you feel that studying software engineering has impacted your approach to hacking?
Pepijn: "My background in software engineering has given me a better sense of the business logic of a company: what's a real risk, how a specific application works, and where developers normally take shortcuts because something 'should never happen'.
Because of my background, when I conduct pentests or red team work I really understand what's going on behind the scenes. Not only the endpoint, not only the request, but the reason why that function exists in the first place. That matters.
A lot of serious vulnerabilities are not beautiful technical tricks. They are boring mistakes in a workflow. A user can upload something they should not upload. A role can approve something it should not approve. A system trusts a value because another system probably checked it before. That is where the real impact often sits."
This is the recurring theme in Pepijn's work: the highest-impact findings are rarely exotic exploits. They are workflow assumptions that nobody ever attacked before, in applications that were built to be used, not abused.
Business logic vulnerabilities in the wild
Q: Are business logic vulnerabilities still common in the work that you're doing?
Pepijn: "I think business logic vulnerabilities are one of the most impactful vulnerabilities I'm seeing right now. Even on web applications that put a lot of effort into secure development, business logic vulnerabilities are everywhere.
The problem is that they are hard to scan for. A scanner does not know what your business does. It does not know that a supplier should never see another supplier's invoices. It does not know that a low privilege user should not be able to trigger an admin workflow by changing one identifier. It does not know what 'normal' means inside your company.
I'll give you a concrete one. Hospital context. I'd spent about four hours going in circles on one application, and then it hit me: upload-file.ashx. I fired it off, and it errored. So I sat back, annoyed. Then I looked again: manage-files.ashx. That path was only visible once you were logged in as that specific user, very deeply nested, not something you would ever stumble across from the outside. It had a nice GUI around it, and it exposed all the parameters I needed. I fed those back into file-upload.ashx and got a shell. And it was not running as some limited web-service account, it was running as the most powerful account on a Windows machine, the one Windows itself uses. Full control of that box, in a hospital environment.
No scanner finds that for you. A scanner sees two handlers that return 200 and moves on. It does not know that the second endpoint hands you the exact parameters the first one refuses to accept. That is the whole point: scanners don't know context. You do, after four hours of being annoyed at one that wouldn't work.
And that finding didn't just give access to the site I was testing, it reached the IT company behind the application. The application only allowed certain users to upload, but it never checked whether the username belonged to the current session. Not only their customers were at risk, the managed service provider exposed all their other clients too. That is the kind of bug that looks small when you write out the request. In the real world it is the whole chain."
Four hours of nothing, then upload-file.ashx errored, manage-files.ashx handed me the parameters, and file-upload.ashx returned a shell with full control of the box. A scanner sees two handlers returning 200. It does not know the second one hands you the keys to the first.
Q: Why do you think business logic vulnerabilities are becoming increasingly common?
Pepijn: "Companies are developing a lot of applications these days. Some companies create a new application for every little event they do. A campaign, a giveaway, a customer portal, an internal dashboard, a partner login. Then the website is forgotten. When you're launching that many applications so quickly it makes it hard to monitor them all and to make sure that they're developed in a secure way. From a hacker's perspective, you look at all those applications and it's easy to find one that gets you right to the core of the business.
The other part is speed. Development teams move fast. They reuse components. They connect SaaS tools. They build APIs for internal usage and then later those APIs become exposed in some way. Nobody is doing that with bad intentions, but the result is a lot of logic that nobody has really attacked before. And attackers do not care which system you consider important. They care which system gets them further."
How Neo Security approaches it
Q: How does Neo Security approach these kinds of vulnerabilities?
Pepijn: "The only way to find these issues properly is to think like an attacker and an engineer at the same time. At Neo Security we do not only look for the standard findings. Of course you need to test for the basics. But the real value is in understanding what the application is supposed to do, what the company cares about, and how that can be abused.
For a normal pentest this means we do not just run tools and write a report. We look at the logic. We ask what the crown jewels are. We look at which users exist, which roles exist, which flows have money or data or access behind them.
For red team operations it goes further. Then the question is not 'can we find a vulnerability?' The question is 'can we achieve an objective in a realistic way, and can the organisation detect and respond to it?' That is a very different mindset. It is not about making noise. It is about realism."
Q: It seems that Neo Security compliments the work that hackers are already doing then in a nice way. Has working at Neo required a different approach than you're used to?
Pepijn: "Yes. The work is broader. In some security work you test one application. You go deep into that application, find the vulnerabilities, report them, and move on. That is still valuable. But at Neo Security we also look at the bigger picture: attack surface, identity, cloud, internal systems, suppliers, response, detection.
Because in a real attack, the attacker does not stop at the first finding. They chain things together. A small exposed service can become credentials. Credentials can become VPN access. VPN access can become internal enumeration. Internal enumeration can become domain access.
Somewhere in that chain there is usually one boring thing that was not supposed to be internet-facing, or one account that had too much access, or one workflow that trusted the wrong thing. That is the work I like. Not just finding a bug, but understanding what it means."
Exposed service, credentials, VPN access, internal enumeration, domain access: real attacks are chains, and the weakest link is usually a boring one. That is why Neo Security tests the chain, not just the individual application.
Research, tooling and what excites him
Q: You've done a lot of work researching vulnerabilities. How does that research background help in client work?
Pepijn: "Research teaches you patience. It also teaches you that systems are usually weird. When you are researching a vulnerability, you cannot just follow a checklist. You need to understand why the system behaves the way it behaves. You test assumptions. You break things apart. You try something that should not work, and sometimes that is exactly what works.
That mindset helps a lot in pentesting and red teaming. Especially with business logic vulnerabilities, because there is no one payload that finds them all. You need to read the application. You need to understand the developers a bit. You need to understand the business a bit. Then you push where the logic becomes thin."
Q: What kind of work are you most excited about right now?
Pepijn: "The most exciting work for me is where offensive research, tooling and real client impact come together. I like writing my own tools. I like automating the boring parts, but not pretending that automation replaces thinking. Good tooling gives you more time to do the interesting part: understanding the target, finding the weird edge cases, and proving real impact.
At Neo Security that can be a red team operation, a web application pentest, an attack surface review, or digging into something very specific that a client is worried about. The nice part is that the work is practical. We are not doing security theatre. The question is always: what can an attacker do with this, and how do we stop it?"
Wrapping up
Q: Finally, I have to ask, what's been one of the best parts about the work-style of Neo Security?
Pepijn: "Freedom and trust. The best security work happens when engineers have the space to go deep. Sometimes that means writing code. Sometimes that means spending hours on one strange endpoint because something feels wrong. Sometimes it means telling a client that the scary vulnerability is not their biggest problem, and the boring misconfiguration is. I like that.
At Neo Security there is room to be direct. No unnecessary layers, no pretending, no report full of filler. Just engineers doing the work, explaining what matters, and helping organisations become harder to attack. That is the kind of security I want to work on."
Pepijn's takeaway is simple: scanners find the known, but business logic vulnerabilities live in what makes your company unique. Finding them takes engineers who understand both the attacker and the business.
Curious what an attacker sees in your business logic?
At Neo Security, engineers like Pepijn test the workflows a scanner cannot understand: the roles, the flows with money or data behind them, and the assumptions that were never supposed to be attacked.
Whether you need a penetration test that goes beyond the checklist or a full red team operation, we can show you what a realistic attacker can do, and how to stop them.