Levi Schuck

Engineering Manager, Staff Engineer

Levi stepped up to own the security of an engineering org during the pressures of a data breach. He’s reduced security defects, improved platform performance, and kept the org PCI compliant under QSA scrutiny. 

In his own time, he implements OAuth and OIDC for fun and has accidentally become a high impact maintainer in the passkeys ecosystem.

A real-time battle with a card-testing adversary

At 50x more authorizations per minute than typical and all for the same amount, alarms go off at issuing banks for a good reason. I'll share the story of how a card-testing adversary abused a misfeature that checked if a card is valid before vaulting it and how their strategies and my defenses evolved over a week long battle. I will share the techniques I used that ultimately distinguished legitimate customer traffic from automated abuse through residential proxies and creative scripts.

Kevin Buck

PCI GRC Manager, NBCUniversal

Kevin has over 4 decades of technology experience including development on every platform from mainframes to embedded systems with roles from system programmer to CTO. His first Defcon was in 2000 (Yay Alexis Park!) and it opened up a new world for him. He has been involved with PCI since 2005 as a level 1 merchant and PCI Qualified Security Assessor (QSA). He has written books on Rock 'n' Roll as well as Gravehunting (really!).

How to Epically Fail Your PCI Assessment

If your company accepts, processes, stores, transmits, dreams about, or accidentally leaves cardholder data on a sticky note, congratulations - you get the privilege of dealing with PCI DSS. For organizations processing enough transactions, the reward for your success is an on-site assessment conducted by a Qualified Security Assessor (QSA). Think of it as inviting a well-dressed, highly trained auditor to examine every corner of your security program and ask uncomfortable questions about decisions made by people who left the company three years ago.

In an ideal world, your controls are well-documented, operating effectively and everyone knows exactly where the evidence is stored. In the real world, someone discovers during the assessment that the quarterly review hasn't happened since the last presidential administration, nobody can explain a firewall rule labeled "DO NOT TOUCH" and a frantic war room appears overnight.

This session explores the most common (and a few impressively creative) ways organizations derail their PCI assessments. We'll cover how to avoid discovering critical compliance gaps in front of your QSA, why "we thought someone else was doing that" is not a valid control and how to prevent your assessment from turning into a high-stakes race against the reporting deadline.

Come learn how not to fail your PCI assessment spectacularly... preferably before your next assessment cycle.

Arnold Jared Morales Yepez

Senior Team Lead, Grupo Salinas

Since the age of 12, I've dedicated myself to computer science with a special focus on security. Now, at 22, I continue to explore this world with the same passion, driven by the constant evolution of technology and its endless learning curve.

I have a degree in Computer Forensics and Cybersecurity, and I'm currently pursuing a Master's degree in Artificial Intelligence and Cybersecurity.

Breaking BIOS in ATMs

The analysis begins at Ring -3, advancing toward the positive rings. Starting from the on-screen user

perspective imposes too many limitations. The shift in approach was deliberate: rather than assuming a

conventional attack vector such as connecting an external device or performing a kiosk-level bypass the

decision was made to start from the deepest layers of the system. This compromise is detected for the

following reason:

- DMA protection exists at the BIOS level.

The goal of this compromise is to activate PCI/PCIe through BIOS in order to perform a DMA

This section will be referred to as "BIOS Unprotection."

How was this achieved?

Two methods were identified:

A bridge was found that triggers a BIOS configuration reset.

BIOS duplication with encryption validation bypass (enables both Downgrade and Upgrade).

DMA or complete chain will not be shown since it is a delicate topic but BIOS research will be deepened

since it does not only apply to ATMs.

Ken Pyle

Security Researcher, Bank of America

Ken Pyle is a cybersecurity researcher, exploit developer, professor, and conference speaker specializing in vulnerability discovery, reverse engineering, adversarial cryptanalysis, and advanced offensive security research. He has disclosed vulnerabilities affecting major technology vendors and has presented research at leading security conferences including DEF CON, ShmooCon, and RSA Conference. He also serves as a graduate cybersecurity instructor, mentoring the next generation of security professionals.

His research focuses on systemic and architectural weaknesses in complex systems, protocol-level attacks, polyglot and semantic attack techniques, exploit development, cryptography, critical infrastructure security, and the intersection of emerging technologies with offensive and defensive cybersecurity. His work emphasizes novel attack surfaces, unconventional exploitation methodologies, and the security implications of design decisions across hardware, software, and communication protocols.

Breaking encryption isn’t hard—it’s just taught poorly.

Using decades-old OpenJDK PBKDF flaws, forgotten RFCs, hash collisions, and a few semantic edge cases, we’ll compromise multiple cryptographic systems with little more than a handful of carefully chosen values and several “useless” tools.

This talk explores how implementation bugs, legacy compatibility, and architectural assumptions can undermine otherwise sound cryptography—and why the real attack surface is often everything around the algorithm.

Furkan Fatih Demir

Independent Security Researcher & Penetration Tester, Barikat Cybersecurity

Furkan Fatih Demir is an independent security researcher and penetration tester with experience conducting authorized security assessments across financial services, aviation, public sector, and education industries. Their work spans a broad range of offensive security disciplines, with a particular focus on uncovering business logic vulnerabilities and security gaps that evade conventional tooling. Over the course of their career, they have identified critical vulnerabilities in production systems across multiple regulated industries, including authenticated findings in financial institution environments.

BNPL's Blind Spot: Exploiting Business Logic Flaws in Buy Now Pay Later APIs

Buy Now Pay Later has grown from a niche convenience to a $560 billion global ecosystem used by approximately 380 million people. Klarna, Afterpay, Affirm, and PayPal Pay Later process billions in transactions annually — and every transaction flows through a series of REST API calls. Security research on BNPL has focused entirely on fraud: account takeover, synthetic identity, first-party fraud. No one has looked at the API layer. This talk does. 

We systematically test the BNPL payment flow — session creation, authorization, order management, and capture — using public sandbox environments. Our methodology focuses on business logic flaws: scenarios where the API functions exactly as designed but can be abused in ways developers never anticipated.

Confirmed finding: Klarna's capture endpoint accepts any captured_amount value down to 1 cent ($0.01) on a fully authorized order, with no minimum validation. A $100 authorized order can be captured for $0.01 — returning HTTP 201 Created with Klarna-Order-Validation: Valid. In vulnerable merchant implementations, customers receive goods while only $0.01 is collected — a $99.99 financial loss per transaction. 

Attendees will leave with a practical attack methodology for BNPL integrations, an open-source reference implementation (vulnerable + patched), and a merchant-side security checklist.