Thousands of commits hit public GitHub repositories every minute, and a meaningful slice of them are hostile: credential stealers, reverse shells, crypto drainers, and nation-state lures wearing the costume of a coding challenge. The same things that make GitHub great for developers (openness, trust, free hosting, a domain nobody blocks) make it excellent disposable infrastructure for attackers.
This talk is about what happens when you try to watch all of it. I'll walk through a pipeline that scans the public event stream in near real time, the deobfuscation engine that turns walls of XOR'd, packed, and base64'd gibberish back into something a detection rule can match, and the messy reality of keeping false positives low enough that a human analyst still trusts the queue. Then the fun part: who's actually out there, including DPRK-aligned crews running fake job interviews to backdoor developers at crypto firms. Much of the data is first triaged by an autonomous AI analyst turned loose on live adversary infrastructure from a throwaway VM.
You'll leave knowing how to build this visibility yourself, and why GitHub belongs in your threat model next to email and the browser.
GraphQL's flexibility creates an attack surface traditional scanners weren't built for. GrapeQL is a modular GraphQL security platform that covers the full kill chain: fingerprinting the engine, probing for injection, auth bypass, IDOR, and DoS, then handing confirmed findings to an AI agent that produces a vulnerability report along with working exploit scripta.
The platform ships as a browser-based tool. Upload or edit YAML test cases directly in the UI, point it at an endpoint, and let it run. When a finding lands, click Exploit — the agent probes the vulnerable query or mutation with tailored payloads and emits a self-contained Python script you can download and run. It will be demo this live against a deliberately vulnerable GraphQL API, covering SQLi, command injection, and DOS attacks.
The talk is honest about where agentic generation earns its keep (injection chains, auth bypass) and where it doesn't (blind OOB, complex fragment bombs). If you're securing GraphQL APIs — or building tools for people who do — this is the architecture walkthrough you want.
Cybersecurity is always and everywhere a risk management function.
NIST CSF, ISO 27001, PCI DSS, C2M2, ATT&CK; the frameworks and methodologies are many. Professional associations publish competing Bodies of Knowledge. Colleges and universities offer an expanding array of diplomas and degrees. Everyone has an answer to how we should do cybersecurity.
But step back and ask a simpler question: what are we actually trying to accomplish?
It's easy to lose sight of this. We get absorbed in achieving compliance, implementing the architecture du jour, or chasing the latest threat intelligence. We optimize for framework alignment rather than outcomes. We confuse the map for the territory.
Author and practitioner Rick Howard offers a clarifying formulation: the purpose of cybersecurity is to reduce the probability of a material cyber event in the next business cycle.
This talk traces that thread across the profession. We start with risk itself, not as an abstract concept but as the fundamental tradeoff that underpins every security decision. We examine what higher education is teaching the next generation of practitioners and what the major Bodies of Knowledge say we should master. We dissect several popular frameworks, many of which explicitly call for a risk-based approach yet are routinely implemented as compliance checklists. We close by reconceptualizing the multifaceted practice that is cybersecurity through the focusing lens of risk.
Electron has evolved significantly over the years, adopting safer defaults and introducing security mechanisms aimed at reducing the risk of application compromise. While many of the well-known "secure by default" issues have been addressed, modern Electron applications remain vulnerable due to insecure implementation patterns, unsafe IPC designs, dangerous preload exposure, protocol handler abuse, and misplaced trust assumptions between renderer and main processes.
This talk explores how contemporary Electron applications can still be exploited even with recommended security configurations enabled. Through hands-on demonstrations using DVEA — a purpose-built vulnerable Electron application designed for security training and research — attendees will learn how common development mistakes can transform seemingly hardened applications into viable attack surfaces.
In this talk we expose how modern, browser-based IDEs (like VS Code and Cursor) have become the software supply chain's weakest link. The talk demonstrates how threat actors weaponize malicious extensions, 0-day vulnerabilities, and Chromium exploits to turn a developer's workspace into an enterprise backdoor - and delivers actionable insights for scaling IDE security.
The toll that stress can take on the body and mind is real. For cybersecurity professionals in particular, due various factors, stress can be a significant problem. In this presentation, we will look at the causes of stress and burnout in the field, discuss its impacts on individuals and on organizational security, and consider factors and actions that can reduce the risk.
Command-line activity is one of the clearest places where attacker behavior shows up, but interpreting it correctly is not always simple. A single command can be obviously malicious, completely benign, or only suspicious depending on context.
This talk goes over the design and development of Genos, an open-source command intelligence engine that classifies shell commands as benign, malicious, or context-dependent, while also mapping malicious behavior to MITRE ATT&CK techniques.
We will look at why command-line detection is difficult, how attackers use obfuscation and living-off-the-land binaries, and how Genos combines de-obfuscation, machine learning, and rule-based security logic to make real-time decisions. The talk will also cover lessons learned from building the system, including dataset problems, false positives, technique-mapping challenges, and the gap between a research prototype and something defenders can actually use.
While everyone is discussing jailbreaks and quick injection, most people are ignoring a very serious issue. Long before they respond to their first query, large language models are degraded during training, fine-tuning, and dataset preparation. And after the damage has been done, it is almost impossible to identify. I'll demonstrate how the LLM supply chain is being targeted by attackers in this session. We're talking about poisoned datasets that bypass validation checks, backdoored models that appear entirely normal until activated, and hacked training pipelines that inject vulnerabilities at scale. These attacks are not hypothetical they are already occurring, and the majority of enterprises are unaware of their vulnerability.
I'll go into real world attack scenarios including split view data poisoning (where your model learns different things than you believe it does), front running attacks that corrupt datasets before they're published, and RAG poisoning tactics that affect retrieval systems. You'll witness firsthand explanations of how these assaults operate and why conventional security measures fail to detect them.
It's not all gloom and doom, though. Additionally, I'll discuss doable tactics for safeguarding your AI development lifecycle, such as evaluating model behaviour, screening datasets, and putting in place appropriate supply chain controls. Whether you're creating models internally or using third-party solutions, you must understand where the vulnerabilities are and how to guard against them.
Anti-money laundering AI agents are being deployed at scale across North American financial institutions. They read documents, assess risk, and generate suspicious activity reports — autonomously, at high speed, and with minimal human oversight.
In this talk I will demonstrate a new class of adversarial attack I formalised and published: the Compliance Memory Poisoning Problem. By injecting just 50 adversarially crafted documents into a RAG-based AI compliance agent's retrieval corpus through entirely legitimate data ingestion pathways, an attacker can collapse the agent's detection accuracy from 91.9% to 1.4% — a 98.4% degradation — with no anomalous signature in any operational log. The agent continues operating normally. Compliance reports keep generating. Nothing looks wrong. Everything is wrong.
I will show exactly how this attack works, why standard cybersecurity monitoring cannot detect it, and present the Memory Hygiene Layer — a defense framework achieving 100% adversarial detection at 22.6ms response time without model retraining.
If your organisation deploys AI in compliance, fraud detection, or risk management — this talk is directly relevant to your attack surface.
Linux powers much of today's infrastructure, from cloud platforms and Kubernetes clusters to enterprise servers and home labs. While countless hardening guides and benchmark checklists exist, they often explain what to configure rather than why it matters.
This session takes a practical look at Linux security through the eyes of an attacker. We'll explore common attack paths, the defensive controls that disrupt them, and how to build multiple layers of protection using built-in Linux features and open source tools. Whether you're securing a single server or an entire fleet, you'll leave with practical techniques you can immediately apply.
Robot vacuum. Linux on wheels. Camera, mic, floor plan of your home, all riding around on WiFi. I opened one up, tapped the UART, dumped the firmware, and followed it to the cloud. Came out with root on any of these things in the fleet from any account. Vendor knows. This is the hack.
Most of us measure success one host at a time: find a malicious domain, file an abuse report, and wait days to weeks (or months) for a single domain to come down. That is a takedown. It is an essential part of mitigation, but it is slow, buying the attacker time to re-host the moment it works. Underneath it runs a faster layer most defenders never learn exists: an ecosystem of collective defense made of the internet's core infrastructure operators, such as browser and OS blocklists, public resolvers, mail reputation, and verdict aggregators, that can revoke an attacker's reach in minutes, sometimes faster than DNS propagation. I did not appreciate how much reach this layer has until I pulled the operators' own numbers. In this session I show how disruption and takedown work as two complementary layers, trace how one reported verdict propagates across the fabric of the internet, ground it in public documented cases, and show you how to tap in: point your resolvers at a public option, ingest open feeds, and report your own indicators to the community platforms built for it.
Penetration tests often fail before testing begins: unclear scope, missing access, vague expectations, and teams that are not ready to act on the findings. This talk covers the real-world parts of pentesting that do not show up in CTFs or exploit write-ups: scoping calls, messy asset lists, delayed credentials, defensive reactions, and reports that never become remediation work. Using anonymized consulting examples, we will look at how to prepare for a pentest, stay engaged during testing, and turn findings into actual security improvement.
CVE descriptions are notoriously vague. A few lines of text, a CVSS score, and you're left asking: what does this actually mean, and how does it work? Translating that into a working understanding of the underlying flaw requires a structured methodology and a willingness to dig into the internals of the target system.
This talk walks through the full research lifecycle of CVE-2026-21236 - a heap-based buffer overflow in the Windows Ancillary Function Driver for WinSock (AFD.sys) - from a blank slate to the first publicly available analysis report.
We’ll cover each phase of the process, including lessons that are learned along the way.
Attendees will come away with a workflow and practical tips for turning a Windows CVE into real understanding.
"Agentic SOC" is the security buzzword of the moment, and most of what you've
heard about it is vendor marketing. This talk strips away the hype and shows you
what an AI agent actually is :a brain (an LLM that reasons), tools (the actions
it's allowed to take), and memory (the context it can retrieve) then maps those
three pieces directly onto components you already run. Using Splunk and a small
live demo, you'll watch a trigger wake an agent, design and run its own queries,
and return a triaged result. You'll leave knowing how to build a basic agentic
detection-and-triage pipeline yourself, and just as importantly where it
breaks and why it isn't the turnkey magic you've been sold.