<?xml version='1.0' encoding='utf-8' ?>
<!-- Made with love by pretalx v2025.2.2. -->
<schedule>
    <generator name="pretalx" version="2025.2.2" />
    <version>0.7</version>
    <conference>
        <title>Pass the SALT 2026</title>
        <acronym>pts2026</acronym>
        <start>2026-06-30</start>
        <end>2026-07-02</end>
        <days>3</days>
        <timeslot_duration>00:05</timeslot_duration>
        <base_url>https://cfp.pass-the-salt.org</base_url>
        
        <time_zone_name>Europe/Paris</time_zone_name>
        
        
        <track name="ThreatIntel" slug="57-threatintel"  color="#bb0a58" />
        
        <track name="Hardware &amp; IoT" slug="60-hardware-iot"  color="#fc00ff" />
        
        <track name="Vuln Research" slug="63-vuln-research"  color="#ff0016" />
        
        <track name="Exploitation" slug="59-exploitation"  color="#000000" />
        
        <track name="System &amp; Hardening" slug="61-system-hardening"  color="#ff7a00" />
        
        <track name="Lost in PQC Translation (or not)" slug="54-lost-in-pqc-translation-or-not"  color="#3b8937" />
        
        <track name="Security by Design" slug="62-security-by-design"  color="#2008b3" />
        
        <track name="Crypto for Users" slug="55-crypto-for-users"  color="#5709f6" />
        
    </conference>
    <day index='1' date='2026-06-30' start='2026-06-30T04:00:00+02:00' end='2026-07-01T03:59:00+02:00'>
        <room name='Amphitheater 122' guid='e10da599-2e58-5d62-8cbb-2e6ac653d45d'>
            <event guid='d0bd8658-5fde-594f-a210-0fd5563d86ef' id='308'>
                <room>Amphitheater 122</room>
                <title>Finding the Needle in the Haystack with Dicozorus - A New Companion for Advanced Web Fuzzing</title>
                <subtitle></subtitle>
                <type>Talk</type>
                <date>2026-06-30T14:10:00+02:00</date>
                <start>14:10</start>
                <duration>00:35</duration>
                <abstract>URL fuzzing is a critical step in penetration testing, yet its effectiveness often hinges on the quality of wordlists. Publicly available lists frequently suffer from missing critical entries, poor sorting, lack of modularity, and irrelevant content, leading to inefficient scans and missed vulnerabilities.

This talk introduces a methodology for building better wordlists, along with a tool, Dicozorus, designed to support this process by providing a robust system for generating, managing, and curating high-quality fuzzing wordlists.

Dicozorus relies on a database that stores entries with rich metadata (severity, type, category, tags, references), enabling the creation of tailored wordlists based on context such as scope, network performance, or stealth requirements. Used internally for over five years, it has significantly improved wordlist quality and revealed numerous critical vulnerabilities absent from popular lists.

Dicozorus provides both a curated compilation of entries for immediate use as well as the ability for professionals to maintain custom, effective datasets.

The tool will be made publicly available on Synacktiv&#8217;s GitHub repository ahead of the conference.</abstract>
                <slug>pts2026-308-finding-the-needle-in-the-haystack-with-dicozorus-a-new-companion-for-advanced-web-fuzzing</slug>
                <track>Vuln Research</track>
                
                <persons>
                    <person id='266'>Vincent Herbulot (Security&#8239;Researcher, Synacktiv)</person>
                </persons>
                <language>en</language>
                <description>The presentation is structured in several parts:
- **Introduction / The fuzzing challenge** : Penetration testing relies heavily on URL fuzzing to find vulnerabilities. Common fuzzing tools and wordlists, pros and cons.
- **Motivations: Why Existing Wordlists Fall Short** : Lessons learned from many penetration tests and thousands of scans. Identified Issues: Missing Entries /Unsorted Wordlists / Lack of Modularity / Improper Sizing / Irrelevant Entries (Junk). Examples based on well known wordlists will be presented
- **Objectives: What Dicozorus Aims to Achieve** : The solution we provide: not just an enhanced wordlist but a tool to generate, merge, filter, sort, tag, categorize, and track entries.
- **Dicozorus in Action: How It Works**: Core architecture / Key commands overview
- **How the builtin database was created**: A Multi-Source Aggregation Strategy based on:
  - Existing public Wordlists
  - Public Bug Bounty Reports
  - Public vulnerability databases
  - Past Fuzzing Traces
  - External contributions from auditors
- **Manual Review &amp; Curation**: While automated parsing provides volume, manual review is critical for assigning accurate metadata (severity, category) and filtering out noise, ensuring high-quality data for the built-in wordlists
- **Tangible Results**: Proving dicozorus&apos;s value by presenting feedback from internal usages, statistics on the entries of the builtin wordlist and comparison with publicly known wordlists.</description>
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.pass-the-salt.org/pts2026/talk/XGWGAK/</url>
                <feedback_url>https://cfp.pass-the-salt.org/pts2026/talk/XGWGAK/feedback/</feedback_url>
            </event>
            <event guid='a054a621-97eb-5100-8cf8-6e484d0e0c68' id='318'>
                <room>Amphitheater 122</room>
                <title>Fuzzwizard</title>
                <subtitle></subtitle>
                <type>Short Talk</type>
                <date>2026-06-30T14:45:00+02:00</date>
                <start>14:45</start>
                <duration>00:20</duration>
                <abstract>Fuzzwizard is a self-hosted fuzzer orchestrator for continuous fuzzing. It was built to help teams run fuzzers 24/7, monitor their status, centralize crashes, receive notifications, and inspect coverage.

Developers now add fuzzers alongside their unit tests, running them manually and keeping track of their results becomes difficult. Fuzzwizard addresses that problem with a customisable platform that can run locally and scale to multiple projects. It can also be used to run fuzzing campaigns and collect crashes and related information.</abstract>
                <slug>pts2026-318-fuzzwizard</slug>
                <track>Vuln Research</track>
                
                <persons>
                    <person id='270'>Marion Lafon (Security Engineer, Ledger)</person>
                </persons>
                <language>en</language>
                <description>Fuzzwizard is an open-source tool to orchestrate fuzzing campaigns. It is composed of several elements:

- A TUI (Terminal User Interface) to monitor the platform, inspect running fuzzers, manage tasks, and review recent crashes and coverage information.
- A backend and database to store crashes, expose them through an API, and make the collected data available outside the TUI for other tools.
- A notification service that alerts users when a crash occurs or when an administrative event happens, for example if the backend fails. The notification layer is extensible. Today, we support both a file-based provider and a Slack provider.
- A scheduler that orchestrates fuzzers for a given project. Several schedulers can run at the same time. The scheduler detects targets, launches fuzzers, monitors them, collects crashes, and triggers coverage collection. Fuzzers can be run either natively or inside containers. It can also rebuild targets and restart campaigns when binaries change.

These components are mostly independent, except for the TUI, which acts as a main entry point. The scheduler itself is implemented as a Rust library, and most of the behaviour is driven by configuration files, which makes the whole setup easy to adapt to different projects.</description>
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.pass-the-salt.org/pts2026/talk/UA97SY/</url>
                <feedback_url>https://cfp.pass-the-salt.org/pts2026/talk/UA97SY/feedback/</feedback_url>
            </event>
            <event guid='db685638-bed6-5e67-bdc9-357bf82b1f39' id='330'>
                <room>Amphitheater 122</room>
                <title>Automated Vulnerability Detection in Go: Concolic Execution for Multi-Threaded Binaries</title>
                <subtitle></subtitle>
                <type>Talk</type>
                <date>2026-06-30T15:05:00+02:00</date>
                <start>15:05</start>
                <duration>00:35</duration>
                <abstract>Go powers critical infrastructure, but analyzing compiled Go binaries for security issues remains difficult in practice.

In this talk, we present Zorya, an open-source concolic analysis framework designed to detect vulnerabilities directly at the binary level, including bugs that do not immediately crash the program.

We will show how Zorya combines runtime state recovery, symbolic reasoning, and constraint solving with the Z3 SMT solver to analyze real-world Go targets. Attendees will learn where traditional approaches fall short, how Zorya helps uncover exploit-relevant paths, and how this can improve real security audit workflows.</abstract>
                <slug>pts2026-330-automated-vulnerability-detection-in-go-concolic-execution-for-multi-threaded-binaries</slug>
                <track>Vuln Research</track>
                
                <persons>
                    <person id='278'>Karolina GORNA (Security Researcher, Ledger)</person>
                </persons>
                <language>en</language>
                <description>This session presents Zorya end-to-end as a security analysis capability, with recent advances included as part of a broader system view.

What attendees will get:

- How Zorya works in practice: concrete+symbolic execution over binary code, via Ghidra P-Code and Z3.
- What makes it usable on real Go binaries: compiler/runtime-aware strategies for TinyGo and gc targets, including multi-threaded/runtime constraints.
- Coverage beyond obvious crashes: overlay path analysis to inspect untaken paths and detect silent bugs without custom oracles.
- Operational usage model: interactive mode, function-focused exploration, and campaign/fuzzer-driven workflows.
- Evidence on real cases: vulnerability findings across real-world Go projects, with reproducible artifacts and lessons learned.

The talk is intended for offensive security practitioners, reverse engineers, and defenders who need practical methods to audit compiled Go software when source-level tooling is insufficient.

Website: https://zorya.karolinagorna.net
Project: https://github.com/Ledger-Donjon/zorya
Evaluation: https://github.com/Ledger-Donjon/zorya-evaluation</description>
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.pass-the-salt.org/pts2026/talk/KM8MUR/</url>
                <feedback_url>https://cfp.pass-the-salt.org/pts2026/talk/KM8MUR/feedback/</feedback_url>
            </event>
            <event guid='885ec5b2-29d9-519a-9cbe-9f2aab65915d' id='273'>
                <room>Amphitheater 122</room>
                <title>__Salty Firmware - Adventures in Firmware Encryption Reversing</title>
                <subtitle></subtitle>
                <type>Talk</type>
                <date>2026-06-30T16:10:00+02:00</date>
                <start>16:10</start>
                <duration>00:35</duration>
                <abstract>With the increased scrutiny on embedded device security, firmware encryption is rapidly becoming a standard hurdle in the analysis pipeline. As vendors increasingly attempt to lock down their systems, we&apos;re encountering a growing variety of encryption schemes applied at different layers&#8212;ranging from full firmware blobs to kernel images and root file systems.

This talk dives deep into the landscape of firmware encryption as seen in the wild, drawing from real-world targets such as telco routers, firewalls, IP cameras, printers, and IP phones. We&apos;ll explore encryption schemes implemented across Linux and BSD derivatives, with decryption logic buried in bootloaders, kernel code, or even opaque self-update binaries.

Rather than just showcasing results, this session is built as a reversing adventure: starting with an opaque encrypted blob, we&#8217;ll trace a path through static and dynamic reverse engineering to uncover the decryption primitive and ultimately access the firmware&apos;s inner workings. We&apos;ll analyze the recurring patterns, common developer pitfalls, and the surprising creativity some vendors bring to the table.

Whether you&apos;re building firmware extraction pipelines or you&apos;re just in it for the puzzles, this talk will arm you with practical techniques and insights for taking back control of encrypted firmware.</abstract>
                <slug>pts2026-273-salty-firmware-adventures-in-firmware-encryption-reversing</slug>
                <track>Hardware &amp; IoT</track>
                
                <persons>
                    <person id='253'>Quentin Kaiser</person>
                </persons>
                <language>en</language>
                <description>We will demonstrate firmware decryption using [unblob](https://unblob.org), a firmware extraction tool we&apos;ve open sourced and have been maintaining since 2022.</description>
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.pass-the-salt.org/pts2026/talk/NRFUKL/</url>
                <feedback_url>https://cfp.pass-the-salt.org/pts2026/talk/NRFUKL/feedback/</feedback_url>
            </event>
            <event guid='52489f9c-5d62-5224-b533-e25832238c9b' id='334'>
                <room>Amphitheater 122</room>
                <title>Introducing Sighthouse for Seamless Function Detection</title>
                <subtitle></subtitle>
                <type>Short Talk</type>
                <date>2026-06-30T16:45:00+02:00</date>
                <start>16:45</start>
                <duration>00:20</duration>
                <abstract>The aim of this talk is to address a common challenge faced by reverse engineers: distinguishing relevant software from third-party libraries within firmware or programs. This task often wastes time as unnecessary code is reversed.
Our goal is to provide an automatic function detection mechanism that enables researchers to efficiently identify third-party code, allowing them to focus on analyzing the proprietary components.

To tackle this issue, we introduce SightHouse, a new open-source project designed to assist reverse engineers. SightHouse is built on top of existing effective software, such as Ghidra&apos;s BSIM Similarity engine. Unlike previous tools like FLIRT, which rely on the raw bytes of the function; BSIM leverages Ghidra&apos;s P-Code (IIR), enabling cross-architecture similarity detection.

The challenges in function detection primarily revolve around the creation and maintenance of signature databases, and BSIM is no exception. Researchers face the task of finding, compiling, and extracting signatures from programs with symbols 
to populate these databases, which can be a time-consuming process.

To address these challenges, we proposed an automated pipeline designed to maximize data collection for function extraction. This system works by automatically scraping open-source projects, compiling and analyzing them, thereby streamlining the process and reducing the manual effort required.

We will present our contributions, including the benchmarks and experiments conducted to evaluate and select between different similarity engines. Additionally, we will release SightHouse to share with the community and encourage further development and improvement.</abstract>
                <slug>pts2026-334-introducing-sighthouse-for-seamless-function-detection</slug>
                <track>Hardware &amp; IoT</track>
                
                <persons>
                    <person id='264'>Sami Babigeon (Quarkslab)</person><person id='15'>Benoit Forgette</person>
                </persons>
                <language>en</language>
                
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.pass-the-salt.org/pts2026/talk/KVCNWM/</url>
                <feedback_url>https://cfp.pass-the-salt.org/pts2026/talk/KVCNWM/feedback/</feedback_url>
            </event>
            
        </room>
        <room name='Room LW109' guid='08301808-3867-517b-b353-bfb7b64da431'>
            <event guid='cd4f7b74-9959-5624-aff8-4845a022fd84' id='332'>
                <room>Room LW109</room>
                <title>Design Your First PCB: From Concept to Board</title>
                <subtitle></subtitle>
                <type>Workshop</type>
                <date>2026-06-30T14:10:00+02:00</date>
                <start>14:10</start>
                <duration>03:00</duration>
                <abstract>This workshop introduces you to the entire printed circuit board (PCB) design process, from the initial idea to the creation of your own board. You&apos;ll discover why creating a custom PCB can be a high-performance alternative to using standard modules and review the essential electronic concepts for designing reliable circuits. Through hands-on exercises, you&apos;ll learn to read and interpret component datasheets, understand the practical differences between analog and digital electronics, and use open-source PCB design software to transform a schematic into a complete PCB. We&apos;ll cover the process of sending a PCB to manufacturing, component selection and purchasing, and explore open-source options. Whether you&apos;re a maker, a student, or a future engineer, whether you&apos;re a complete beginner or not, this workshop will give you the tools to design your own PCB.</abstract>
                <slug>pts2026-332-design-your-first-pcb-from-concept-to-board</slug>
                <track>Hardware &amp; IoT</track>
                
                <persons>
                    <person id='281'>tcccorp</person>
                </persons>
                <language>en</language>
                
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.pass-the-salt.org/pts2026/talk/AACNG9/</url>
                <feedback_url>https://cfp.pass-the-salt.org/pts2026/talk/AACNG9/feedback/</feedback_url>
            </event>
            
        </room>
        <room name='Room LW112' guid='4cac865f-6304-566c-a547-4203b8029da0'>
            <event guid='795ae6c4-8595-5f24-8acb-6077656f5ac2' id='328'>
                <room>Room LW112</room>
                <title>In bed with Qubes OS, hands-on workshop</title>
                <subtitle></subtitle>
                <type>Workshop</type>
                <date>2026-06-30T14:10:00+02:00</date>
                <start>14:10</start>
                <duration>03:00</duration>
                <abstract>This workshop begins by introducing the fundamental principles behind Qubes OS. We&#8217;ll cover the entire process, from installation and configuration to common challenges and practical solutions.

We&apos;ll then explore various aspects of Qubes OS through demonstrations, hands-on labs, and exercises using pre-installed virtualized instances available to attendees.

Participants will leave with practical and operational knowledge that will enable them, maybe, to switch to Qubes OS as their main operating system.

Experienced users are also welcome to join and share their perspectives, along with tips and tricks of their own.</abstract>
                <slug>pts2026-328-in-bed-with-qubes-os-hands-on-workshop</slug>
                <track>System &amp; Hardening</track>
                
                <persons>
                    <person id='203'>William Robinet (Conostix S.A.)</person>
                </persons>
                <language>en</language>
                
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.pass-the-salt.org/pts2026/talk/J7EGL7/</url>
                <feedback_url>https://cfp.pass-the-salt.org/pts2026/talk/J7EGL7/feedback/</feedback_url>
            </event>
            
        </room>
        
    </day>
    <day index='2' date='2026-07-01' start='2026-07-01T04:00:00+02:00' end='2026-07-02T03:59:00+02:00'>
        <room name='Amphitheater 122' guid='e10da599-2e58-5d62-8cbb-2e6ac653d45d'>
            <event guid='38d1877e-1936-58a6-8e92-9c68b618416a' id='288'>
                <room>Amphitheater 122</room>
                <title>Quantum Apocalypse Update.ical</title>
                <subtitle></subtitle>
                <type>Talk</type>
                <date>2026-07-01T09:30:00+02:00</date>
                <start>09:30</start>
                <duration>00:35</duration>
                <abstract>In the future, Quantum computers will be able to break today&apos;s asymmetric cryptography, especially RSA,  CC and DH variants. This would lead to a catastrophic situation sometimes called &quot;Quantum Apocalypse&quot;. To avoid such situation, the cryptographic community started, quite a long time ago, works on new replacement algorithms, based on other mathematical properties, and which are called &quot;post-quantum algorithms&quot; (or quantum-safe algorithms).

Those new algorithms, while providing a solution for the Quantum threat, also comes with new various challenges to address: different usage constraints, size of keys/data, how to implement them in a secure
way, ......

In this session, we&apos;ll have a quick reminder of the Quantum threat, the post-quantum algorithms, the challenges to address, then we&apos;ll see the updated state of the post-quantum transition, from strategy guidelines to latest algorithm and protocols updates and implementations.

Then, we&apos;ll see some examples of what steps of this post-quantum transition can already be done in 2026, especially with Open Source tools, and what are the potential caveats and risks.</abstract>
                <slug>pts2026-288-quantum-apocalypse-update-ical</slug>
                <track>Lost in PQC Translation (or not)</track>
                
                <persons>
                    <person id='257'>Yvan Vanhullebus</person>
                </persons>
                <language>en</language>
                
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.pass-the-salt.org/pts2026/talk/BLUZVX/</url>
                <feedback_url>https://cfp.pass-the-salt.org/pts2026/talk/BLUZVX/feedback/</feedback_url>
            </event>
            <event guid='a1efbcbc-1cd7-55b2-9fee-9ee90cc2b87c' id='310'>
                <room>Amphitheater 122</room>
                <title>CryptPad experimented on Post-Quantum Cryptography</title>
                <subtitle></subtitle>
                <type>Talk</type>
                <date>2026-07-01T10:05:00+02:00</date>
                <start>10:05</start>
                <duration>00:35</duration>
                <abstract>CryptPad is an open-source end-to-end encrypted collaborative office suite focusing on being easy to use and protecting the privacy of its user, including from the service provider itself.

While security against a quantum adversary becomes more and more relevant, we experimented on the realisability of Post-Quantum CryptPad. This talk will expose how cryptography is used inside CryptPad, our methodology and the results  of these experiments.</abstract>
                <slug>pts2026-310-cryptpad-experimented-on-post-quantum-cryptography</slug>
                <track>Lost in PQC Translation (or not)</track>
                
                <persons>
                    <person id='160'>Fabrice Mouhartem (Senior R&amp;D Engineer, XWiki SAS/CryptPad)</person>
                </persons>
                <language>en</language>
                <description>CryptPad is an open-source end-to-end encrypted (E2EE) collaborative office suite. It enables secure collaboration between users without the service owner knowledgable about the content of their documents. It has been designed to be secure from login to document sharing&#8230; with even the internal support system being E2EE.

This architecture is by design interlaced with cryptographic constructions. Meanwhile, the deployment of quantum resilient solutions are becoming more and more urgent, especially in the context of encryption (as they can be targeted by &#8220;harvest-now-decrypt-later&#8221; attacks, while authentication cannot be forged _a posteriori_). In this context, we explored the different implementations of post-quantum standards selected by the NIST post-quantum cryptography standardisation process.

After careful consideration of the different candidates for both encryption and signature, we integrated crypto-agility solutions in CryptPad. This was done both for the advantages from a security and software engineering standpoint, and to be able to easily switch between traditional and post-quantum solutions for testing.

In this talk, we will first present how CryptPad works, then expose the different challenges we faced during the experiments, and finally show the results of these aforementioned post-quantum experiments from a performance and usability point of view.</description>
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.pass-the-salt.org/pts2026/talk/MV83GM/</url>
                <feedback_url>https://cfp.pass-the-salt.org/pts2026/talk/MV83GM/feedback/</feedback_url>
            </event>
            <event guid='09785f2b-1e00-5721-b3b2-a52804660252' id='329'>
                <room>Amphitheater 122</room>
                <title>Let&apos;s stay encrypted&#8212;rethinking WebPKI for post-quantum age with Merkle Tree Certificates</title>
                <subtitle></subtitle>
                <type>Talk</type>
                <date>2026-07-01T11:10:00+02:00</date>
                <start>11:10</start>
                <duration>00:35</duration>
                <abstract>The Web PKI is the foundation on which many security systems depend, and for many the gold standard of how to do PKI. On closer inspection, the Web PKI is an old system evolved with patches added from one crisis to the next. In this talk, we discuss recent efforts to modernize the Web PKI to maintain reliability and security in the face of the imminent threat from quantum computers.

The transition to post-quantum cryptographic algorithms is hampered by the massive increase in size of PQC signatures relative to traditional cryptographic signatures. A straightforward &#8220;copy/paste&#8221; approach in which PQC algorithms were naively added into the existing WebPKI would add massive increases in the size of the TLS handshake, leading to a significant (around 50% P50) handshake latency to every HTTPS connection made.

The impact of PQC on the web PKI wouldn&#8217;t stop at handshake sizes. The public web PKI also relies on transparency into certificate issuance (&#8220;Certificate Transparency&#8221;, CT) to help detect and mitigate unauthorized certificate issuance.  For the past decade, CT has served its purpose of holding Certification Authorities (CAs) accountable, recently notably detecting Fina CA&#8217;s mis-issuance of certificates for 1.1.1.1, Cloudflare&#8217;s Encrypted DNS service late last year. Unfortunately, a naive adoption of the most mature PQC algorithms into the current public CT ecosystem would likely result in the ecosystem&#8217;s collapse due to the increased operational costs for logs, burdening an already-fragile group of volunteer log operators.

Cloudflare and Google Chrome have spearheaded an effort, Merkle Tree Certificates (MTCs), that offer a new approach to HTTPS certificates that combine issuance and transparency into a single cryptographic object. Under active development in the Internet Engineering Task Force (IETF)&#8217;s PKI, Logs, and Tree Signatures (PLANTS) working group, MTCs reduce the overhead of post-quantum TLS certificates by 4-22Kb, eliminating the impact on client latency. Simultaneously, the design mitigates the impact on the Certificate Transparency ecosystem, likely resulting in reduced costs compared to today&#8217;s status quo.

In this talk, we&#8217;ll walk through the MTC proposal, interesting open discussions happening in the working group and discuss the results of early experimentation between Chrome and Cloudflare.</abstract>
                <slug>pts2026-329-let-s-stay-encrypted-rethinking-webpki-for-post-quantum-age-with-merkle-tree-certificates</slug>
                <track>Lost in PQC Translation (or not)</track>
                
                <persons>
                    <person id='277'>Bas Westerbaan</person>
                </persons>
                <language>en</language>
                
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.pass-the-salt.org/pts2026/talk/DVVX3Z/</url>
                <feedback_url>https://cfp.pass-the-salt.org/pts2026/talk/DVVX3Z/feedback/</feedback_url>
            </event>
            <event guid='960cdbad-8653-56b5-a6a3-62800f0db5f0' id='324'>
                <room>Amphitheater 122</room>
                <title>Suricata and IOCs, latest news on a love story</title>
                <subtitle></subtitle>
                <type>Talk</type>
                <date>2026-07-01T11:45:00+02:00</date>
                <start>11:45</start>
                <duration>00:35</duration>
                <abstract>Suricata&#8217;s approach to handling Indicators of Compromise (IoCs) has fundamentally evolved from basic IP-only rules to the highly performant Dataset concept. The talk will outline the key advancements, particularly the evolution in Suricata 8.0 to support JSON-based context within Datasets. This upgrade is crucial as an IOC is nothing without context. With JSON datasets, alerts embed comprehensive threat context opening the way to performance improvement and integration ease.</abstract>
                <slug>pts2026-324-suricata-and-iocs-latest-news-on-a-love-story</slug>
                <track>ThreatIntel</track>
                
                <persons>
                    <person id='171'>Eric Leblond</person>
                </persons>
                <language>en</language>
                <description>The presentation will detail several capabilities for dynamic threat intelligence operations, including the use of a Unix socket to dynamically add and remove elements from the live dataset list, and ongoing integration efforts with platforms like OpenCTI and MISP for seamless threat intelligence exchange. Additionally, a new feature allowing the output of PCRE captured groups directly into the alert context will be examined. This talk will demonstrate how these features enhance Suricata&apos;s ability to process, manage, and contextualize threat data in real-time.</description>
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.pass-the-salt.org/pts2026/talk/8JJSMR/</url>
                <feedback_url>https://cfp.pass-the-salt.org/pts2026/talk/8JJSMR/feedback/</feedback_url>
            </event>
            <event guid='a30ac0d2-beb7-56cb-bea7-dd62e019721e' id='312'>
                <room>Amphitheater 122</room>
                <title>CVE-2025-54068 : Deep dive into Livewire, from weak typing to pre-authenticated remote command execution</title>
                <subtitle></subtitle>
                <type>Talk</type>
                <date>2026-07-01T14:15:00+02:00</date>
                <start>14:15</start>
                <duration>00:35</duration>
                <abstract>CVE-2025-54068 exposed a critical vulnerability in Livewire, a popular full-stack framework for Laravel, enabling pre-authenticated remote command execution (RCE) by exploiting PHP&#8217;s weak typing and Livewire&#8217;s hydration mechanism. According to GitHub, Livewire was downloaded more than 74 million times, making it one of the most used Laravel dependency ever.

Traditionally, Livewire protects its state with a checksum signed by the application&#8217;s APP_KEY. However, this vulnerability allowed attackers to bypass the APP_KEY requirement entirely by smuggling synthesizers through the updates mechanism, effectively breaking the state synchronization between server and browser.

The root cause lies in Livewire&#8217;s component property update hydration process, where recursive calls and improper context preservation enabled malicious payload injection. Exploitation required only the target application&#8217;s URL, making it accessible to unauthenticated attackers. The vulnerability affected Livewire versions from 3.0.0-beta.1 up to 3.6.3, and was patched in version 3.6.4.

This talk will detail the technical chain from weak typing to RCE, demonstrate the exploit process, discuss the hardening measures implemented by Livewire to prevent similar issues in the future and more especially, show the consequences being the publication of the associated proof of concept during the end of last year.</abstract>
                <slug>pts2026-312-cve-2025-54068-deep-dive-into-livewire-from-weak-typing-to-pre-authenticated-remote-command-execution</slug>
                <track>Exploitation</track>
                
                <persons>
                    <person id='117'>R&#233;mi Matasse (Security research, Synacktiv)</person><person id='283'>Pierre Martin (Security Researcher, Depi)</person>
                </persons>
                <language>en</language>
                <description>Livewire traditionally secures its state using a checksum signed by the application&#8217;s APP_KEY. However, CVE-2025-54068 allowed attackers to bypass this protection entirely by smuggling synthesizers through the updates mechanism, disrupting the synchronization between server and browser. The root cause has been found in Livewire&#8217;s component property update hydration process, where recursive calls and improper context preservation created an opening for malicious payload injection. Exploitation required only the target application&#8217;s URL, making it accessible to unauthenticated attackers and significantly lowering the barrier to attack.

To automate the exploitation of CVE-2025-54068, we released Livepyre last December, an open-source tool on our GitHub page. The tool simplifies the process by identifying vulnerable Livewire installations and attempting to achieve RCE either by leveraging object types in the application&#8217;s snapshot or through a targeted brute-force approach. Livepyre&#8217;s release not only demonstrated the practical risk of the vulnerability but also served as a proof-of-concept to raise awareness and encourage rapid patching within the Laravel and Livewire communities.

Even tho the vulnerability was patched during July 2025, many servers were not protected against it on the internet.  The vulnerability affected Livewire versions from 3.0.0-beta.1 up to 3.6.3, and was patched in version 3.6.4. Its severity was underscored by its inclusion in advisories from CISA (Cybersecurity and Infrastructure Security Agency) after a worldwide spread by threat actors during the start of 2026, highlighting the risk to a vast number of applications and the urgency for immediate patching.</description>
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.pass-the-salt.org/pts2026/talk/XKQRMJ/</url>
                <feedback_url>https://cfp.pass-the-salt.org/pts2026/talk/XKQRMJ/feedback/</feedback_url>
            </event>
            <event guid='7611cf15-2934-5945-97fc-72e4b0b608c4' id='327'>
                <room>Amphitheater 122</room>
                <title>ChainLeak: From AI Framework to Cloud Secrets</title>
                <subtitle></subtitle>
                <type>Talk</type>
                <date>2026-07-01T14:50:00+02:00</date>
                <start>14:50</start>
                <duration>00:35</duration>
                <abstract>As organizations rapidly adopt AI frameworks and third-party components, traditional software
vulnerabilities are increasingly being introduced into AI infrastructure. While AI security discussions often
focus on model level issues such as prompt injections, the most dangerous risks frequently arise from
traditional software vulnerabilities within the frameworks that power AI systems.

In this talk, we will present two vulnerabilities we discovered in Chainlit, a widely used open-source
framework that helps building conversational AI apps (CVE-2026-22218 and CVE-2026-22219). The issues
affect internet-facing AI systems and can be triggered remotely, enabling attackers to steal sensitive files,
leak cloud API keys and secrets, and perform server-side request forgery (SSRF) on the AI framework
server. We confirmed the vulnerabilities in real world, internet facing applications used by major
enterprises, demonstrating how a framework layer vulnerabilities can escalate to cloud level impact.

We will walk through the technical details of the vulnerabilities and the exploitation chain that leads to
server compromise and credential exposure. We&#8217;ll also show how leaking artifacts such as cached
conversation history, configuration files, or environment variables can reveal highly sensitive enterprise
data.</abstract>
                <slug>pts2026-327-chainleak-from-ai-framework-to-cloud-secrets</slug>
                <track>Exploitation</track>
                
                <persons>
                    <person id='274'>Gal Zaban</person><person id='276'>Ido Shani</person>
                </persons>
                <language>en</language>
                
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.pass-the-salt.org/pts2026/talk/MPAYUX/</url>
                <feedback_url>https://cfp.pass-the-salt.org/pts2026/talk/MPAYUX/feedback/</feedback_url>
            </event>
            <event guid='24d61e98-0acc-578a-ad46-82b5c593c02b' id='292'>
                <room>Amphitheater 122</room>
                <title>Bypassing BitLocker in under 5 min using boot manager downgrade attacks</title>
                <subtitle></subtitle>
                <type>Short Talk</type>
                <date>2026-07-01T15:55:00+02:00</date>
                <start>15:55</start>
                <duration>00:35</duration>
                <abstract>BitLocker without a pre-boot PIN is widely deployed across enterprise environments and often considered a sufficient protection against physical access attacks. In practice, several techniques can defeat it, including long known hardware attacks; the bitpixie PXE-based software attack published in early 2025; and a boot manager downgrade attack we developed that exploits the slow rollout of Microsoft&apos;s UEFI CA 2023 certificate transition to revive a patched vulnerability (CVE-2025-48804) on fully updated machines.

This talk is a practitioner&apos;s field report. Drawing from real penetration testing engagements, we compare hardware and software attacks across the dimensions that matter in the field &#8212; setup time, required hardware, risk to the target device, success rate, and post-exploitation impact. We walk through the open-source PoCs we developed to operationalize bitpixie and the BitUnlocker downgrade attack, and share honest observations on the effectiveness of recommended mitigations in real-world enterprise configurations.

See https://github.com/garatc/BitUnlocker</abstract>
                <slug>pts2026-292-bypassing-bitlocker-in-under-5-min-using-boot-manager-downgrade-attacks</slug>
                <track>Exploitation</track>
                
                <persons>
                    <person id='260'>Cassius Garat (Intrinsec)</person>
                </persons>
                <language>en</language>
                
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.pass-the-salt.org/pts2026/talk/RVFD8B/</url>
                <feedback_url>https://cfp.pass-the-salt.org/pts2026/talk/RVFD8B/feedback/</feedback_url>
            </event>
            <event guid='04e9e2f0-f710-5e4b-9ab4-81b437a485ed' id='313'>
                <room>Amphitheater 122</room>
                <title>Zero Dependencies sounds great... until you try to share your code for the security good.</title>
                <subtitle></subtitle>
                <type>Short Talk</type>
                <date>2026-07-01T16:30:00+02:00</date>
                <start>16:30</start>
                <duration>00:20</duration>
                <abstract>The Rust ecosystem is often praised for its &quot;harmonized chaos&quot; of crates, but a new trend is emerging in security-critical tools: the total avoidance of dependencies. While projects like sudo-rs aim to reduce the supply chain attack surface, this architectural choice comes with a cost. During my PhD work on RootAsRole, I discovered that dependencies minimisation leads to monolithic designs where security logic is tightly coupled to use-cases.

This talk explores the friction between security-hardened isolation and the community&#8217;s need for reusable, battle-tested components. When we refuse to depend on others, we stop contributing to shared building blocks. We end up reinventing the wheel, forking unmaintained libraries, and scattering security expertise across dozens of &quot;independent&quot; forks. I will share many insights about what is the Good, the Bad and the Ugly.</abstract>
                <slug>pts2026-313-zero-dependencies-sounds-great-until-you-try-to-share-your-code-for-the-security-good</slug>
                <track>Security by Design</track>
                
                <persons>
                    <person id='215'>Eddie Billoir (Airbus Protect)</person>
                </persons>
                <language>en</language>
                
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.pass-the-salt.org/pts2026/talk/J9JGWE/</url>
                <feedback_url>https://cfp.pass-the-salt.org/pts2026/talk/J9JGWE/feedback/</feedback_url>
            </event>
            
        </room>
        <room name='Room LW109' guid='08301808-3867-517b-b353-bfb7b64da431'>
            <event guid='b4337c06-1e63-58cc-8d1a-529d54cb449b' id='314'>
                <room>Room LW109</room>
                <title>Web forensics with Lookyloo and Lacus</title>
                <subtitle></subtitle>
                <type>Workshop</type>
                <date>2026-07-01T09:30:00+02:00</date>
                <start>09:30</start>
                <duration>03:00</duration>
                <abstract>Websites are complex, they change all the time, it is extremely tedious to reproduce the load of one URL, especially when the malicious actors don&apos;t want you to probe their infrastructure.

During this workshop, we will look at techniques used by malicious actors to trick unsuspecting users, find phishing campaigns, and see **a lot** of slop.</abstract>
                <slug>pts2026-314-web-forensics-with-lookyloo-and-lacus</slug>
                <track>ThreatIntel</track>
                
                <persons>
                    <person id='141'>Rapha&#235;l Vinot (Developer, Lookyloo)</person>
                </persons>
                <language>en</language>
                <description>This workshop will cover the basics of Lookyloo, and Lacus, the infrastructure and use-cases:

* Capturing a website or rendering an HTML document
* Detailing the capture settings, different browsers
* Browser instrumentation and / or headfull capture
* Socks5 Proxies
* Init scripts post rendering
* Monitoring
* Automatic reporting
* Why using Lacus
* Onion / I2P support

You may have attended talks or workshops about lookyloo in the last few years, but we implemented many new features int he last year.

* Indexing, pivot and search across the dataset
* Forensic acquisition with Trusted Timestamps (RFC3161) 
* Use of Iframes in the tree, export rendered iFrames contents
* Proton VPN support for proxies
* Automatic and manual categorization on submission</description>
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.pass-the-salt.org/pts2026/talk/3EQEU7/</url>
                <feedback_url>https://cfp.pass-the-salt.org/pts2026/talk/3EQEU7/feedback/</feedback_url>
            </event>
            <event guid='ad3831ec-711b-5b01-883f-053cefba8068' id='323'>
                <room>Room LW109</room>
                <title>Threat Detection Engineering with Suricata</title>
                <subtitle></subtitle>
                <type>Workshop</type>
                <date>2026-07-01T14:15:00+02:00</date>
                <start>14:15</start>
                <duration>02:45</duration>
                <abstract>This hands-on workshop provides an in-depth exploration of advanced techniques for maximizing network threat detection using Suricata. Building upon core Suricata capabilities, this session delves into critical areas such as effective utilization of metadata keywords, including MITRE and regular metadata, to enrich detection context. Participants will learn practical methods for achieving fast Indicator of Compromise (IOC) matching and strategies for managing multiple Suricata versions within diverse environments. The workshop will also cover leveraging the Suricata Language Server (SLS) for rule development and optimization, including interpreting performance hints and implementing Continuous Integration (CI) for rulesets using SLS in batch mode. This session is designed for cybersecurity professionals seeking to enhance their Suricata expertise and implement cutting-edge threat detection strategies. Attendees will leave equipped with actionable techniques and practical examples to improve their organization&apos;s security posture.</abstract>
                <slug>pts2026-323-threat-detection-engineering-with-suricata</slug>
                <track>ThreatIntel</track>
                
                <persons>
                    <person id='171'>Eric Leblond</person>
                </persons>
                <language>en</language>
                
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.pass-the-salt.org/pts2026/talk/THXBWZ/</url>
                <feedback_url>https://cfp.pass-the-salt.org/pts2026/talk/THXBWZ/feedback/</feedback_url>
            </event>
            
        </room>
        <room name='Room LW112' guid='4cac865f-6304-566c-a547-4203b8029da0'>
            <event guid='f8c30c29-8cfb-5eb5-84a9-ccbda7eb9fb6' id='296'>
                <room>Room LW112</room>
                <title>Workshop to explore SightHouse! Learn how to use it to accelerate your reverse engineering process using its function identification features.</title>
                <subtitle></subtitle>
                <type>Workshop</type>
                <date>2026-07-01T09:30:00+02:00</date>
                <start>09:30</start>
                <duration>03:00</duration>
                <abstract>Reverse engineers frequently encounter firmware or large binaries containing a mixture of proprietary code and numerous third-party libraries. Identifying which components belong to external libraries is a recurring and time-consuming challenge that can significantly slow down analysis.

This workshop introduces SightHouse, an open-source project designed to help reverse engineers automatically detect third-party functions within binaries. SightHouse leverages similarity detection techniques built on top of Ghidra&#8217;s BSIM engine, which uses Ghidra&#8217;s P-Code intermediate representation to enable cross-architecture function similarity analysis. By identifying reused code, researchers can quickly isolate proprietary logic and focus their efforts where it matters most.

The workshop will begin with a short introduction to the challenges of third-party code identification and the similarity detection techniques used in modern reverse engineering workflows. Participants will then be introduced to SightHouse, its architecture, and how it integrates with existing reverse engineering tools.

Following this introduction, participants will apply SightHouse on a real-world reverse engineering target, learning how to detect and filter third-party libraries in practice.

In the final part of the workshop, participants will explore how SightHouse can be extended. They will learn how to create their own workers, enabling them to add new data sources, automate signature extraction, and contribute to expanding the system&#8217;s capabilities.

By the end of the session, participants will understand how to integrate automated function identification into their reverse engineering workflows and how to customize SightHouse to fit their own research needs.</abstract>
                <slug>pts2026-296-workshop-to-explore-sighthouse-learn-how-to-use-it-to-accelerate-your-reverse-engineering-process-using-its-function-identification-features</slug>
                <track>Hardware &amp; IoT</track>
                
                <persons>
                    <person id='15'>Benoit Forgette</person><person id='264'>Sami Babigeon (Quarkslab)</person>
                </persons>
                <language>en</language>
                <description>Material Prerequisites:
- Participants should bring:
- A Linux laptop
- Docker installed and working
- A supported Software Reverse Engineering (SRE) tool, such as:
  - Ghidra
  - Binary Ninja
  - IDA
- A functioning brain

Technical Prerequisites:
- Participants are expected to have:
- Basic reverse engineering knowledge
- Basic Python development experience</description>
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.pass-the-salt.org/pts2026/talk/UUCD9C/</url>
                <feedback_url>https://cfp.pass-the-salt.org/pts2026/talk/UUCD9C/feedback/</feedback_url>
            </event>
            <event guid='1ae9a8be-2ac1-5be9-a3f0-30227c03fa4a' id='272'>
                <room>Room LW112</room>
                <title>Hands-on Firmware Extraction, Exploration, and Emulation</title>
                <subtitle></subtitle>
                <type>Workshop</type>
                <date>2026-07-01T14:15:00+02:00</date>
                <start>14:15</start>
                <duration>02:45</duration>
                <abstract>Join us for this hands-on demo of [Unblob](https://unblob.org/), the flexible firmware extractor. In this session, we will extract firmware from an EV charger, dig into the firmware, and eventually emulate it so we can interact with the services in real-time. Unblob works on both hardware and downloadable versions of firmware so we have a target rich environment.</abstract>
                <slug>pts2026-272-hands-on-firmware-extraction-exploration-and-emulation</slug>
                <track>Hardware &amp; IoT</track>
                
                <persons>
                    <person id='253'>Quentin Kaiser</person>
                </persons>
                <language>en</language>
                <description>Pre-requisites: 
- Familiarity with command-line tools.
- Laptop

No prior experience needed, this session is appropriate for all skillsets.

By the end of the workshop, participants will have gained practical experience in extraction, reverse engineering, and emulation of embedded firmware. They will be equipped with the skills to understand and analyze firmware structure, write custom unblob handlers and extractors, and use full-system emulation for security research.

Workshop Duration: 2 hours</description>
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.pass-the-salt.org/pts2026/talk/TZJESW/</url>
                <feedback_url>https://cfp.pass-the-salt.org/pts2026/talk/TZJESW/feedback/</feedback_url>
            </event>
            
        </room>
        
    </day>
    <day index='3' date='2026-07-02' start='2026-07-02T04:00:00+02:00' end='2026-07-03T03:59:00+02:00'>
        <room name='Amphitheater 122' guid='e10da599-2e58-5d62-8cbb-2e6ac653d45d'>
            <event guid='458ef4d6-f5d7-591c-be86-d85aa68930f7' id='320'>
                <room>Amphitheater 122</room>
                <title>Simplifying log management, not just for security logs</title>
                <subtitle></subtitle>
                <type>Talk</type>
                <date>2026-07-02T09:30:00+02:00</date>
                <start>09:30</start>
                <duration>00:35</duration>
                <abstract>We live in an age where all decisions are based on data, and in case of IT security, the most important data are log messages. Logs are collected centrally and analyzed by various applications, so there are several trends to simplify log message collection. In his talk, Peter introduces central log collection, how creating a dedicated log management layer can save you resources on all fronts, and new technologies to simplify your infrastructure. OpenTelemetry combines logs, traces and metrics into a single protocol, while Kafka can provide a single data pipeline for your organization. A simple and efficient central log management solution allows you not just to save resources, but also provides real-time insight into what is happening in your organization, improving security. While configuration examples come from syslog-ng, the concepts that Peter presents apply to most log management applications.</abstract>
                <slug>pts2026-320-simplifying-log-management-not-just-for-security-logs</slug>
                <track>System &amp; Hardening</track>
                
                <persons>
                    <person id='25'>Peter Czanik, syslog-ng PO at One Identity</person>
                </persons>
                <language>en</language>
                <description>Even at IT security conferences, people often tell me that they &#8220;do not have central log collection&#8221; or that they &#8220;only do it due to compliance requirements&#8221;. Central log collection, however, is a lot more than just mere compliance. Setting up such a framework is in your best interest, as it provides ease of use, availability and security for log messages. If your logs are collected centrally, you can correlate problems across your whole network.
However, central log collection can easily get out of hand once your organization starts growing, especially if multiple analytics tools and collectors get involved. This is where a dedicated log management layer can help. Half a decade ago, Peter showed you how to implement such a layer purely based on the syslog protocol.
Nowadays, there are lots of possibilities for log management. OpenTelemetry combines logs, traces and metrics into a single protocol, simplifying data collection at the protocol level. All important data about your applications, including security logs, are forwarded using a single protocol and application.
Another possibility is using Kafka as a data pipeline in your organization. In this case, all data that are needed to run an organization are pushed to various Kafka topics, including security logs.
While my configuration examples come from syslog-ng, the concepts I describe apply to most log management applications.</description>
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.pass-the-salt.org/pts2026/talk/PJHY3V/</url>
                <feedback_url>https://cfp.pass-the-salt.org/pts2026/talk/PJHY3V/feedback/</feedback_url>
            </event>
            <event guid='756b87e0-607b-5b5d-b042-196140963636' id='322'>
                <room>Amphitheater 122</room>
                <title>Private Key Leaks in the Wild: from PTS to RWC, and back to PTS</title>
                <subtitle></subtitle>
                <type>Talk</type>
                <date>2026-07-02T10:05:00+02:00</date>
                <start>10:05</start>
                <duration>00:35</duration>
                <abstract>Private key leaks represent a critical security vulnerability, with over 400,000 leaked keys on GitHub in 2025, yet their real-world impact remains largely unknown due to the challenge of linking these mathematical objects to their operational usage.

We present the first systematic analysis mapping leaked private keys to active certificates, combining GitGuardian&apos;s dataset of 945,560 unique leaked private keys with Google&apos;s historical Certificate Transparency databases. In September 2025, our methodology successfully mapped 42,690 private keys to 139,767 certificates, revealing the impact of private keys leaked on GitHub and DockerHub. Using custom online and offline validation, we identified 2,622 valid certificates, enabling website impersonation and MITM attacks.

Our analysis reveals systematic failures in certificate revocation practices, with only 80 certificates revoked via CRL/OCSP and just 3 properly marked as key-compromised. We attributed certificates to 600 organizations across critical industries, though many could not be mapped to identifiable owners. With 20% of valid certificates having been exposed for over two years, our large-scale responsible disclosure campaign sent thousands of emails and revealed significant challenges in reaching certificate owners. 

But this research didn&apos;t happen in a vacuum. A discussion at Pass the Salt in 2025 sparked a research collaboration between GitGuardian and Google that made it possible. This talk tells that story. We&apos;ll walk through the methodology: from what seemed impossible in 2025, to leveraging Google&apos;s CT data, to today&apos;s Static CT logs.

In one year, the TLS ecosystem evolved to make duplicating this research possible. Classic CT logs are being replaced by static CT, which simplifies both log operations and certificate retrieval. Moreover, Certificate Transparency Log Archive is now available on archive.org. Together, these changes let any researcher replicate our results in 2026.</abstract>
                <slug>pts2026-322-private-key-leaks-in-the-wild-from-pts-to-rwc-and-back-to-pts</slug>
                <track>ThreatIntel</track>
                
                <persons>
                    <person id='225'>Guillaume Valadon</person><person id='243'>Gaetan Ferry (Security research, GitGuardian)</person>
                </persons>
                <language>en</language>
                
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.pass-the-salt.org/pts2026/talk/MVPRCH/</url>
                <feedback_url>https://cfp.pass-the-salt.org/pts2026/talk/MVPRCH/feedback/</feedback_url>
            </event>
            <event guid='06d783e8-7603-5f1c-b10d-b930685e99ee' id='321'>
                <room>Amphitheater 122</room>
                <title>GCVE: Rebooting Vulnerability Tracking for an Open Security Ecosystem</title>
                <subtitle></subtitle>
                <type>Talk</type>
                <date>2026-07-02T11:10:00+02:00</date>
                <start>11:10</start>
                <duration>00:35</duration>
                <abstract>The vulnerability ecosystem has become critical infrastructure for defenders, vendors, researchers, and open source maintainers. Yet the way identifiers and vulnerability data are assigned, published, and distributed still reflects a centralized model that does not always match the speed, diversity, and realities of today&#8217;s security landscape.

This talk introduces GCVE, a new approach to vulnerability identification and tracking designed to support a more open, decentralized, and resilient ecosystem. GCVE rethinks how vulnerability numbers can be allocated, how trusted actors can publish advisories, and how vulnerability information can be synchronized without creating unnecessary bottlenecks or dependency on a single central authority.

Through the lens of open source security, the talk will explain why this matters: maintainers need lightweight processes, defenders need timely and structured data, and the community needs a model that encourages participation rather than gatekeeping. It will also show how GCVE and its associated tooling can help make vulnerability tracking more transparent, interoperable, and adaptable.

Rather than presenting only a new identifier format, this session will explore a broader idea: how we can build vulnerability tracking as shared public infrastructure for the security community.</abstract>
                <slug>pts2026-321-gcve-rebooting-vulnerability-tracking-for-an-open-security-ecosystem</slug>
                <track>ThreatIntel</track>
                
                <persons>
                    <person id='135'>Alexandre Dulaunoy</person>
                </persons>
                <language>en</language>
                <description>The vulnerability ecosystem has become critical infrastructure for defenders, vendors, researchers, and open source maintainers. Yet the way identifiers and vulnerability data are assigned, published, and distributed still reflects a centralized model that does not always match the speed, diversity, and realities of today&#8217;s security landscape.

This talk introduces GCVE, a new approach to vulnerability identification and tracking designed to support a more open, decentralized, and resilient ecosystem. GCVE rethinks how vulnerability numbers can be allocated, how trusted actors can publish advisories, and how vulnerability information can be synchronized without creating unnecessary bottlenecks or dependency on a single central authority.

Through the lens of open source security, the talk will explain why this matters: maintainers need lightweight processes, defenders need timely and structured data, and the community needs a model that encourages participation rather than gatekeeping. It will also show how GCVE and its associated tooling can help make vulnerability tracking more transparent, interoperable, and adaptable.

Rather than presenting only a new identifier format, this session will explore a broader idea: how we can build vulnerability tracking as shared public infrastructure for the security community.</description>
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.pass-the-salt.org/pts2026/talk/QNGYSR/</url>
                <feedback_url>https://cfp.pass-the-salt.org/pts2026/talk/QNGYSR/feedback/</feedback_url>
            </event>
            <event guid='ec27c7b5-8eff-528d-98f1-d64fe806447c' id='316'>
                <room>Amphitheater 122</room>
                <title>Your credentials were leaked, so what?</title>
                <subtitle></subtitle>
                <type>Talk</type>
                <date>2026-07-02T11:45:00+02:00</date>
                <start>11:45</start>
                <duration>00:35</duration>
                <abstract>Everyday, all of us are flooded with phishing emails trying to impersonate many well-known brands (Netflix, DHL, Microsoft, Google, Facebook &amp; co). Some phishing campaigns are poorly prepared and can be easily spotted. On the other side, some are really well crafted and, be honest, who never clicked on a malicious link? If the flood is constant, it means that it works! And thread actors expect to get our credentials. But, is it really the case? How fast do they react once we disclosed them? That&#8217;s the purpose of our research.

We developed a tool, called PhishTrack, that behaves as a honeypot but with more interaction with phishing kits. The tool is fed with phishing URLs. They are visited, categorized and, if possible, we provide unique credentials. Then, we monitor the honeypot and expect (crossing fingers) that our credentials will be re-used. We simulate classing landing pages and protocols: a web portal, MS account, VPN login, VNC, SSH, RDP (and maybe more soon). As an example, our current record is 3 mins between the phishing page visit and the attempt to (ab)use the credentials from Nigeria.

The talk will be split in two parts: We will introduce the tool, what are the core components, how it works, how we deployed it. The second part of the talk will be a review of our findings.</abstract>
                <slug>pts2026-316-your-credentials-were-leaked-so-what</slug>
                <track>ThreatIntel</track>
                
                <persons>
                    <person id='26'>Xavier Mertens</person><person id='268'>Teqagogo</person>
                </persons>
                <language>en</language>
                
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.pass-the-salt.org/pts2026/talk/8SANMK/</url>
                <feedback_url>https://cfp.pass-the-salt.org/pts2026/talk/8SANMK/feedback/</feedback_url>
            </event>
            <event guid='da0f7b88-d690-5c5a-86b3-e09340378594' id='333'>
                <room>Amphitheater 122</room>
                <title>Oblivious HTTP - when the server does not want to see your IP</title>
                <subtitle></subtitle>
                <type>Talk</type>
                <date>2026-07-02T14:00:00+02:00</date>
                <start>14:00</start>
                <duration>00:35</duration>
                <abstract>It&apos;s common for users to look to hide their IP addresses. With Oblivious HTTP, it&apos;s reversed: the service chooses to blind itself.
We&apos;ll go over how this IETF standard ended up in Apple, Google, Mozilla, and Meta products, and how it evolved.</abstract>
                <slug>pts2026-333-oblivious-http-when-the-server-does-not-want-to-see-your-ip</slug>
                <track>Crypto for Users</track>
                
                <persons>
                    <person id='213'>Thibault Meunier (Research, Cloudflare)</person>
                </persons>
                <language>en</language>
                <description>HTTPS encrypts your request, but the server still sees your IP. That metadata alone may be enough to identify you. Oblivious HTTP ([RFC 9458](https://www.rfc-editor.org/rfc/rfc9458.html)) splits the request across two non-colluding parties: a relay sees your IP address but not your request, a gateway sees your request but not your IP address. Assuming they don&apos;t collude, no single party sees both.

The interesting part: this is a privacy guarantee services opt into, not users. By contracting a neutral 3rd party, the service operator makes a commitment that they cannot link their own users&apos; identity to the request these users are making.

The protocol was standardised at the IETF, and has [open source implementations](https://ohttp.info/#resources) in Go, Rust, Kotlin, and TypeScript. I&apos;ll demo one of them - ohttp-ts - and walk through [ohttp.info](https://ohttp.info/), built to make the protocol approachable.

Finally, we&apos;ll cover [chunked OHTTP](https://datatracker.ietf.org/doc/html/draft-ietf-ohai-chunked-ohttp-08), an advanced proposal, which enables streaming encrypted payloads incrementally directly relevant for AI inference over private prompts and large transfers.</description>
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.pass-the-salt.org/pts2026/talk/B8AN9M/</url>
                <feedback_url>https://cfp.pass-the-salt.org/pts2026/talk/B8AN9M/feedback/</feedback_url>
            </event>
            <event guid='8ac70f8f-7c1f-520a-9d0b-1665676c809d' id='287'>
                <room>Amphitheater 122</room>
                <title>KeibiDrop: Post-Quantum Encrypted Peer-to-Peer File Transfer Without the Cloud</title>
                <subtitle></subtitle>
                <type>Talk</type>
                <date>2026-07-02T14:35:00+02:00</date>
                <start>14:35</start>
                <duration>00:35</duration>
                <abstract>We present KeibiDrop, an open-source (MPL 2.0) peer-to-peer file transfer tool that provides end-to-end encryption using a hybrid post-quantum key exchange (ML-KEM-1024 + X25519) with ChaCha20-Poly1305 at the transport layer. KeibiDrop operates over direct IPv6 connections with no cloud intermediary, no STUN/TURN servers, and no persistent metadata. The relay server is treated as an untrusted blind intermediary: it sees only opaque lookup keys and encrypted blobs, and cannot correlate users or decrypt content. We discuss the cryptographic design, the privacy model, the trade-offs of an IPv6-only architecture, and the practical challenges of mounting remote files as a local FUSE filesystem with forward secrecy via automatic re-keying. A live demonstration accompanies the talk.</abstract>
                <slug>pts2026-287-keibidrop-post-quantum-encrypted-peer-to-peer-file-transfer-without-the-cloud</slug>
                <track>Crypto for Users</track>
                
                <persons>
                    <person id='256'>Marius-Florin Cristian</person>
                </persons>
                <language>en</language>
                <description>**KeibiDrop** addresses a concrete problem: transferring files between two devices without trusting a third party. Existing solutions make trade-offs: cloud storage (Google Drive, Dropbox) requires trusting the provider; tools like croc and Magic Wormhole relay traffic through servers that see both peers&apos; IP addresses and lack post-quantum resistance; platform-native solutions (AirDrop, Nearby Share) are locked to specific ecosystems. KeibiDrop works across any combination of macOS, Linux, Windows, and mobile (iOS/Android via gomobile), with or without FUSE - the filesystem layer is optional, not required, but very fun to use. The desktop UI is built with Slint and bound in Rust; the total binary size is 20 MB.

**Cryptographic design.** KeibiDrop implements a hybrid key exchange combining ML-KEM-1024 (NIST FIPS 203, Security Category 5) with X25519, deriving session keys via HKDF-SHA512. Key pairs are ephemeral: generated fresh each session and never persisted to disk. Peer authenticity is established through out-of-band fingerprint exchange: each peer&apos;s fingerprint is a SHA-512 hash over its ephemeral public keys (X25519 || ML-KEM), shared via a trusted channel (e.g. Signal, in person, QR code). During the handshake, the received public keys are verified against the registered fingerprint using constant-time comparison before any session key is derived. No certificate authority, no long-lived keys &#8212; if the fingerprint does not match, the handshake is rejected. The transport layer uses ChaCha20-Poly1305 AEAD with counter-based nonces and direction-separated prefixes to prevent nonce reuse. Automatic session re-keying triggers every 1 GB or approximately one million messages, providing forward secrecy by discarding old key material.

**Relay privacy model.** The relay server facilitates peer discovery only. Registered keys are held in memory for 10 minutes and then discarded - nothing is persisted. Registration data (fingerprints, public keys, IP addresses) is encrypted client-side before upload. The relay stores only `lookup_key -&gt; encrypted_blob`, where the lookup key is derived via HKDF from a room password shared out-of-band. The relay cannot reverse-engineer fingerprints, decrypt registration blobs, or correlate sessions across rooms. The relay operator sees IPv4 source addresses in access logs, but has no access to the encrypted content or the identities behind it. We present the threat model and the test suite that validates these privacy guarantees.

**IPv6-only architecture.** KeibiDrop deliberately avoids STUN/TURN/UPnP to prevent IP metadata leakage to third-party NAT traversal infrastructure. This is a privacy-first design choice with real trade-offs: it requires globally routable IPv6 on both peers. We discuss why this trade-off is defensible for privacy-sensitive use cases and what it costs in practice, including the challenges we encountered deploying across consumer ISPs.

**FUSE filesystem integration.** Remote files appear as a mounted local filesystem with lazy loading, enabling real-time access without downloading entire files upfront. We cover the practical challenges of building a secure FUSE filesystem: macFUSE versus fuse3 versus WinFSP behavioral differences, direct_io for write operations, deadlock prevention in the VFS layer, and cross-platform support across macOS, Linux, and Windows.

**Live demonstration.** Two laptops, one room. Files transferred with post-quantum encryption.

The talk targets security practitioners, privacy engineers, and contributors to free software who want to understand practical post-quantum cryptography deployment, privacy-preserving protocol design, and the engineering reality of building encrypted file transfer tools.</description>
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.pass-the-salt.org/pts2026/talk/33DFWY/</url>
                <feedback_url>https://cfp.pass-the-salt.org/pts2026/talk/33DFWY/feedback/</feedback_url>
            </event>
            <event guid='6e5db19f-97d2-507a-8044-f0420cadd4d5' id='291'>
                <room>Amphitheater 122</room>
                <title>Fractum: an open-source CLI for Threshold-Based Cold Storage of Critical Secrets</title>
                <subtitle></subtitle>
                <type>Talk</type>
                <date>2026-07-02T15:10:00+02:00</date>
                <start>15:10</start>
                <duration>00:35</duration>
                <abstract>**Shamir&apos;s Secret Sharing (SSS)** has been trusted for decades by organizations like ICANN (DNSSEC root key ceremonies), Trezor (SLIP-39), and Coinbase ; yet it remains largely inaccessible to individual practitioners and small teams who need cold storage for cryptocurrency wallets, SSH keys, infra recovery keys, or root CA credentials.

This talk introduces **Fractum**, an open-source (MIT) CLI tool that combines AES-256-GCM authenticated encryption with Shamir&apos;s Secret Sharing over GF(2^8) to split sensitive files into K-of-N threshold shares. Designed as an air-gapped, portable &amp; offline-first tool with zero network dependencies, This tool brings information-theoretic security to anyone with a terminal.

I will walk through the cryptographic design decisions: why GCM over CBC, how polynomial interpolation in GF(256) actually works at the byte level, how we handle entropy collection from multiple sources, and the trade-offs of implementing memory protection (SecureString with mlock and multi-pass overwrite) in a garbage-collected language like Python. A pre-recorded demo will show a full encrypt-split-distribute-reconstruct cycle running inside a network-isolated Docker container.

**Attendees will take away**: a clear mental model of how threshold cryptography works in practice, an understanding of the security properties (and honest limitations) of implementing SSS in Python, and a free tool they can use immediately for their own cold storage needs.

GitHub: https://github.com/katvio/fractum</abstract>
                <slug>pts2026-291-fractum-an-open-source-cli-for-threshold-based-cold-storage-of-critical-secrets</slug>
                <track>Crypto for Users</track>
                
                <persons>
                    <person id='259'>C&#233;dric - Katvio.com</person>
                </persons>
                <language>en</language>
                <description>**The gap no one talks about (3 min):**
There is a missing category between &quot;encrypt it and hope you don&apos;t lose the key&quot; and &quot;$50K HSM setup.&quot; Most practitioners fall back on copying encrypted files to multiple locations, which means a single key compromise exposes everything. I will frame the cold storage problem: cryptocurrency wallets, root CA keys, disaster recovery credentials, digital inheritance ; all scenarios where you need security measured in years, not sessions. 

**How Shamir&apos;s Secret Sharing actually works (5 min):**
No hand-waving. I will walk through polynomial construction over GF(2^8), Lagrange interpolation for reconstruction, and why the information-theoretic security guarantee is fundamentally different from computational security. If you have K-1 shares, every possible secret is equally likely ; this is not a bruteforce problem, it is a mathematical impossibility. Real-world precedents: ICANN DNSSEC ceremonies, Trezor SLIP-39, Ledger Recover, military grade algos.

**Building it in Python: the honest version (4 min):**
- Memory protection with SecureString: ctypes.memset(), mlock(), multi-pass overwrite
- Honest limitations: Python string immutability, garbage collection timing, no side-channel resistance
- Air-gapped design: &apos;--network=none&apos; Docker guarantee, no telemetry, self-contained share archives
- Supply chain considerations: minimal dependencies, SHA-256 integrity checking

**Demo: encrypt, split, reconstruct (4 min):**
Pre-recorded terminal session inside a &apos;--network=none&apos; Docker container. Encrypt a file, split into 3-of-5 shares, attempt reconstruction with 2 shares (fails, by design), reconstruct with 3 shares (succeeds). Inspect the share metadata and integrity verification.

**What is missing and what comes next (4 min):**
Open discussion of limitations: no formal verification of the SSS implementation, no side-channel analysis, Python GC constraints. Roadmap items: DPSS (Dynamic-committee Proactive Secret Sharing), HSM integration. Open questions for the community: share verification without reconstruction, HSM integration, formal verification approaches for Python crypto.

### Resources:
- **GitHub**: https://github.com/katvio/fractum
- **Documentation**: https://fractum.katvio.com
- **Security Architecture**: https://fractum.katvio.com/security-architecture/</description>
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.pass-the-salt.org/pts2026/talk/9VXT39/</url>
                <feedback_url>https://cfp.pass-the-salt.org/pts2026/talk/9VXT39/feedback/</feedback_url>
            </event>
            <event guid='b27d7b85-15f8-5499-9b42-9e08ef59305f' id='319'>
                <room>Amphitheater 122</room>
                <title>DesktopRanger Blocks Keystroke Spying: Hardening Windows Desktop Isolation</title>
                <subtitle></subtitle>
                <type>Short Talk</type>
                <date>2026-07-02T15:45:00+02:00</date>
                <start>15:45</start>
                <duration>00:20</duration>
                <abstract>Modern businesses routinely handle sensitive data&#8212;entering passwords, managing internal documents and emails, or conducting confidential meetings in applications such as Zoom and Signal. **Windows desktop isolation** can block basic keyloggers from capturing keystrokes from applications running on newly created desktops. Several security tools rely on this mechanism by running sensitive applications or password-entry screens on isolated desktops, providing effective defense against unsophisticated keyloggers. In practice, however, this protection is often treated as &#8220;good enough&#8221; once a protected desktop has been created.

This talk shows why that assumption is wrong: **Windows Desktop Isolation is not a true isolation boundary**.

The focus of this research is not kernel-mode interception, but high-privilege user-mode keyloggers. In other words, the talk addresses attackers that remain in user space, yet possess enough privileges to actively interfere with desktop-based protections and attach spying logic to sensitive contexts. This makes the problem especially relevant in **Man-at-the-End (MATE)** scenarios common in business environments.

I will present a series of experiments covering the four most common Windows keystroke interception techniques&#8212;**SetWindowsHookEx**, **GetAsyncKeyState**, **Raw Input**, and **DirectInput**&#8212;as well as **ETW-based monitoring**. The results show that privileged attackers can still capture keystrokes from protected desktop contexts, including Secure Desktop environments such as Winlogon, for example by launching a high-privilege process via **PsExec/Sysinternals**.

To address this weakness, I will introduce **DesktopRanger**, an open-source defensive prototype for creating hardened Windows desktops for secret input. **DesktopRanger** creates a protected desktop with a restrictive security descriptor, expressed in SDDL as `D:P`, preventing unauthorized opening through the standard desktop access path and limiting the attacker&#8217;s ability to obtain even the desktop name. When a legitimate application must be launched, access is relaxed only for a very short period. At the same time, desktop enumeration is blocked at the **Window Station** level to prevent hostile processes from discovering or attaching to the target desktop. Once the application has been initialized, the original restrictive state is restored: the user can again enumerate active desktops, but the protected desktop does not appear in the returned list.

I will explain the **Windows Desktop** and **Window Station** internals behind this design. I will also discuss how this approach can be combined with the open-source **MemoryRanger** bare-metal hypervisor to protect relevant kernel-side security structures against tampering, including **BYOVD-style attacks**.

The experiments show a clear contrast: a high-privilege attacker can still spy on Secure Desktop-style protected contexts, including **Winlogon**, whereas the same attacker is unable to attach to and spy from a desktop created by **DesktopRanger**.</abstract>
                <slug>pts2026-319-desktopranger-blocks-keystroke-spying-hardening-windows-desktop-isolation</slug>
                <track>Security by Design</track>
                
                <persons>
                    <person id='271'>Igor Korkin (independent security researcher)</person>
                </persons>
                <language>en</language>
                <description>This talk examines a practical and widely misunderstood security question: can **Windows desktop isolation** really protect sensitive keyboard input against a privileged attacker?

The problem is highly relevant because keylogging is not a legacy threat: modern spyware, stealers, and surveillance-oriented malware continue to use keystroke interception in active campaigns. This makes secure input a live defensive problem for password managers, privacy tools, and other applications handling credentials or confidential text on Windows.

I will begin with a concise explanation of the Windows desktop model, including the relationship between **Window Sessions**, **Window Stations**, and **Windows Desktops**, and why many security tools rely on isolated desktops for password entry and other sensitive workflows. I will show that this mechanism is effective against basic user-mode keyloggers, which is why it is often treated as a sufficient defense in practice.

The talk then presents the experimental results. I will show tests covering the four major Windows keystroke interception techniques&#8212;**SetWindowsHookEx**, **GetAsyncKeyState**, **Raw Input**, and **DirectInput**&#8212;as well as **ETW-based monitoring**. These experiments demonstrate that a privileged attacker can still deploy spying logic against protected desktop contexts, including Secure Desktop-style environments such as Winlogon, for example by launching a high-privilege process via PsExec/Sysinternals.

The second half of the talk introduces **DesktopRanger**, an open-source defensive prototype designed to harden the existing Windows desktop model. Its core goal is to create a protected desktop that an attacker cannot easily discover, open, or attach to. **DesktopRanger** creates the target desktop with a restrictive `D:P` security descriptor and limits the attacker&#8217;s ability to obtain even the desktop name. When a legitimate application must be started, access is relaxed only briefly, while desktop enumeration is blocked at the **Window Station** level, and the original restrictive state is restored immediately after initialization. In addition, **DesktopRanger** can deploy multiple desktop honeypots to mislead hostile attachment attempts toward decoy desktops instead of the real protected one. I will explain the Windows internals behind this workflow and why it changes the attack surface compared to conventional isolated-desktop designs.

Finally, I will show the security contrast observed in the experiments: a high-privilege attacker can still spy on Secure Desktop-style protected contexts, while the same attacker is unable to attach to and spy from a desktop created by **DesktopRanger**. I will also discuss how this design can be strengthened with the open-source **MemoryRanger** bare-metal hypervisor to protect relevant kernel-side security structures against tampering and **BYOVD-style abuse**.

The talk is intended for developers of password managers, desktop security tools, and other Free Software projects that need reliable secure-input mechanisms on Windows.</description>
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.pass-the-salt.org/pts2026/talk/FJZPZL/</url>
                <feedback_url>https://cfp.pass-the-salt.org/pts2026/talk/FJZPZL/feedback/</feedback_url>
            </event>
            <event guid='f7aed09d-c4b4-5a03-ad82-fdb6d0d0c94d' id='315'>
                <room>Amphitheater 122</room>
                <title>Rust, PAM and Typestate: Cooking up spotless authentication with nonstick</title>
                <subtitle></subtitle>
                <type>Short Talk</type>
                <date>2026-07-02T16:05:00+02:00</date>
                <start>16:05</start>
                <duration>00:20</duration>
                <abstract>Bim bam PAM! In this talk, we&#8217;re diving into the kitchen of system security to look at the PAM (Pluggable Authentication Modules) architecture.

We&#8217;ll start by deconstructing the classic PAM lifecycle. But instead of just &quot;wrapping&quot; the C API in Rust and hoping for the best, we&#8217;ll introduce nonstick. The secret sauce? We will demonstrate how nonstick uses Rust&apos;s design to encode the PAM expected behavior directly into the compiler.</abstract>
                <slug>pts2026-315-rust-pam-and-typestate-cooking-up-spotless-authentication-with-nonstick</slug>
                <track>Security by Design</track>
                
                <persons>
                    <person id='215'>Eddie Billoir (Airbus Protect)</person>
                </persons>
                <language>en</language>
                
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.pass-the-salt.org/pts2026/talk/NHZTG7/</url>
                <feedback_url>https://cfp.pass-the-salt.org/pts2026/talk/NHZTG7/feedback/</feedback_url>
            </event>
            
        </room>
        <room name='Room LW112' guid='4cac865f-6304-566c-a547-4203b8029da0'>
            <event guid='e3ce3b4e-cb2f-5c76-ba4d-b24c55818f2e' id='317'>
                <room>Room LW112</room>
                <title>A phishing trip with Fancy Bear - Let&apos;s analyze APT malware together!</title>
                <subtitle></subtitle>
                <type>Workshop 2h30</type>
                <date>2026-07-02T09:30:00+02:00</date>
                <start>09:30</start>
                <duration>02:30</duration>
                <abstract>In this beginner-friendly, hands-on workshop, participants will walk through the full attack chain of a real-world Fancy Bear (APT28/GRU) intrusion - from the initial phishing email to command &amp; control - guided by a purpose-built interactive training platform.

What to expect:
The workshop is structured across five chapters, each building on the last: threat actor background, payload delivery, exploitation, persistence &amp; installation, and command &amp; control. Participants work hands-on with real artefacts (phishing email headers, a weaponised RTF document, malware samples, and a C2 implant) and answer quiz questions via an interactive platform to validate their findings along the way - making progress immediately visible and keeping the session engaging for all skill levels.

What you will learn:
- How to analyse phishing emails and extract indicators from mail headers
- How to identify and dissect malicious Office documents (including MIME type mismatches and OLE/COM object abuse triggering CVE-2026-21509)
- Persistence techniques: file staging, scheduled task abuse, and LSB steganography in PNG files
- How to reverse simple string obfuscation (XOR + Base64) using CyberChef
- How threat actors repurpose legitimate open-source tools (Covenant C2 framework) and abuse trusted cloud services to blend into normal traffic
- All tools demoed/used throughout the workshop (e.g. oletools, CyberChef, and Covenant) are free and open-source, making every technique immediately reproducible.

Who should attend:
No prior malware analysis experience is required. Basic familiarity with the command line and a curiosity for how attacks actually work is all you need. Security students, CTF players, sysadmins, and blue teamers looking to build intuition for real-world threat actor tradecraft will get the most out of this session.

What to bring:
A laptop with a browser and internet access. All you need is a web brower, a text editor and an archive tool to unpack ZIP (AES-256) archives - other than that, no prior setup is required.</abstract>
                <slug>pts2026-317-a-phishing-trip-with-fancy-bear-let-s-analyze-apt-malware-together</slug>
                <track>Exploitation</track>
                
                <persons>
                    <person id='269'>Marius Genheimer (DFIR/Research, SECUINFRA)</person>
                </persons>
                <language>en</language>
                <description>This workshop does not depend on domain-specific knowledge, we will try to break the steps down as far as possible. Attendees will follow along through small exercises, with the opportunity to compare their solution through a quiz/validation system. Questions will be answered by the instructor, collaboration between attendees is strongly encouraged!

Important for message for attendees: If you would like to follow along, please bring laptop with a charged battery. You will be handling real-world malware (you act at your own risk; No backup, no pity). I recommend to use a virtual machine (e.g. FLARE-VM, Remnux). No special tooling is required, make sure to have the basics (Text and Hex Editor, Browser, ZIP utility) installed. No photos during the workshop please, you will receive a copy of the slides.</description>
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.pass-the-salt.org/pts2026/talk/UJGHEX/</url>
                <feedback_url>https://cfp.pass-the-salt.org/pts2026/talk/UJGHEX/feedback/</feedback_url>
            </event>
            
        </room>
        
    </day>
    
</schedule>
