What makes a vulnerability truly shocking is simplicity, once you notice the assumption everyone else missed. In this episode, Daniel shares a memorable SAML/SSO privilege escalation from a real engagement, then zooms out into what it takes to grow as a penetration tester: handling uncertainty, collaborating through roadblocks, and building the fundamentals that make creative problem-solving possible.
The conversation blends war stories with practical guidance for both aspiring testers and security leaders. We cover everything from dependency risk and real-world scoping realities to why thinking like an attacker belongs early in the SDLC, not at the end.
When Self-Signed SAML Assertions Work
Daniel opens with a pen test story focused on a large organization’s SSO implementation using SAML. The issue: the target service failed to properly reject self-signed, re-encoded SAML responses. That meant Daniel could swap his email for an administrator’s email inside the assertion, re-sign it, and effectively authenticate as an admin, turning a normal login flow into privilege escalation.
The developers initially didn’t believe it until Daniel reproduced the behavior live, at which point the room shifted from skepticism to panic when they realized the test was hitting production. It’s a sharp reminder that authentication and trust boundaries fail in quiet ways.
Pentesting is Collaborative
From there, the discussion moves into the day-to-day reality of consulting. Daniel explains that every team has a different baseline: some have security fluency, others barely know what a penetration test entails. He emphasizes that many engagements are gray-box and require real coordination. In practice, the work looks less like a solo operator and more like a constant dance to get everyone on the same page.
The Real OSCP Test is Resilience
Daniel recounts his OSCP path as both intense and unexpectedly chaotic. After months of preparation, he scheduled an early-morning exam start and immediately hit friction. Webcam issues, then later a power outage that wiped hours of momentum and threatened his ability to capture required documentation.
The story escalates: with the clock running and power still out, he packed his entire setup and relocated to a hotel in the middle of the night. There, after repeatedly revisiting the same ideas and links, a final attempt delivered the points needed to pass. The takeaway isn’t grind harder, but that persistence, restarts, and adapting under pressure are often the difference between failing and finishing.
Dependencies and Configurations are Hard
When asked what shows up most often in internal network tests, Daniel points to configuration-driven issues and dependency risk. Teams may implement their own code securely but unknowingly rely on deprecated libraries or components with long-standing CVEs. That supply-chain reality can undermine otherwise solid engineering.
His broader point: "my feature works" is not the same as "my system is safe." Security posture depends on what your software inherits, not just what you wrote.
Lab vs. Reality: Unknown Unknowns
In a lab environment, you know a vulnerability exists, you’re solving a puzzle. In the real world, there may be nothing exploitable in scope, or nothing you can find in time. Daniel describes this as a fractal level of ignorance: not only are there things you don’t know, there are things you don’t know you don’t know.
That mindset shapes how experienced testers operate: staying cautious, using lifelines (peers and communities) for sanity checks, and accepting that clean reports can be valid outcomes.
What to do When You Hit a Wall
Daniel’s playbook for getting unstuck is simple and battle-tested:
- Reach out for a sanity check: another set of eyes can confirm you’re not missing something obvious (or validate that the scope is simply hardened).
- Restart from first principles: go back to step one and re-walk the basics, because small oversights and tiny typos can invalidate an entire attack path.
- Document your work clearly: when findings are minimal, the value often lives in the rigor of the test plan and the evidence of diligence.
The thread running through all of it: computers do exactly what you tell them, not what you meant. Precision and process matter.
Crucial Skills for New Penetration Tests
Asked what newcomers should master first, Daniel highlights two fundamentals:
- Reading code: you don’t need to be an expert in every language, but being able to interpret logic and intent unlocks deeper testing and helps you reason about how systems can be made to behave unexpectedly.
- Terminal comfort (especially Linux): much of the tooling and workflow lives in a Linux ecosystem, and fluency gives testers flexibility and speed, especially when constraints show up in Windows-heavy environments.
Think Like an Attacker and Shift Left
Daniel offers guidance for security leadership: practice attacker thinking by looking for where users have freedom: input fields, API parameters, and especially anything sensitive exposed in places like URL strings or client-visible data flows. The goal is to intentionally inspect misuse cases, not just intended design.
Strategically, he reinforces shift left: bake security into the SDLC early. The earlier security decisions are made, the less painful (and less incomplete) it is than trying to retrofit secure architecture onto something already built.
