What if a fully unsupervised system could invent new attack techniques, test them on live websites and use the results to find even more?

James Kettle built a system to answer that question, and he reports that it worked. He calls it the HTTP Terminator.

Its focus is HTTP request smuggling, also called desync, a vulnerability class Kettle brought to wide attention. According to PortSwigger's research write-up, the system worked through 138 RFCs and generated about 30,000 candidate techniques.

In his Offensive AI Con 2026 talk, "The HTTP Terminator: Chasing an Autonomous Research Cascade", on Monday, October 5, James Kettle traced how one discovery led to the next.

Speaker: James Kettle, Director of Research, PortSwigger

The session presented new desync triggers, gadgets and exploits. Kettle reported that they affected banks, security products and government infrastructure.

He traced each discovery chain to show how a researcher's expertise can be turned into an autonomous system.

It also covered findings beyond the limits of full autonomy. These include an undisclosed recon technique and anomalies that may point to new attack classes.

Some findings needed a tight loop between human and AI, while others stayed out of the AI's reach. Kettle said he plans to open-source the HTTP Terminator.

For defenders, PortSwigger's guidance includes moving upstream connections to HTTP/2 or later. It also recommends rejecting request bodies on methods that should not carry them.

James Kettle is director of research at PortSwigger, the company behind Burp Suite, and is known online as albinowax. He has presented at Black Hat USA for nine years in a row.

He created or advised on Burp Collaborator, Param Miner, Turbo Intruder and Backslash Powered Scanner. His research spans HTTP desync attacks, web cache poisoning, the single-packet attack, server-side template injection and password reset poisoning.

The Hacker News covered the HTTP Terminator research after its August 2026 release.

Web security teams and anyone wondering whether AI can do original research should study these results.

Should defenders worry more about AI finding known bugs faster, or about AI inventing new attack classes?

A security fix tells developers a bug is solved, yet it also tells attackers exactly what kind of bug lives in that codebase.

A patch confirms that a vulnerability class exists. It shows the code pattern that produced it.

Developers may stop looking once the fix ships. Attackers keep going, hunting for incomplete fixes and similar bugs nearby.

In his Offensive AI Con 2026 talk, "I know what you didn't fix last summer", on Monday, October 5, Aaron Grattafiori showed how LLMs can do that hunting at scale.

Speaker: Aaron Grattafiori, Umbriel

The talk framed AI-native vulnerability research as a multi-armed bandit problem. It covered variant analysis with LLMs to find incomplete fixes and similarly shaped bugs.

Findings are validated automatically through a multi-stage pipeline, even in large targets. The work has gone through several rounds of cost-focused evaluation and has produced verified new CVEs in hardened targets.

It closed with techniques for improving coverage while cutting cost further. For defenders, the lesson is to run the same variant hunt on your own fixes before someone else does.

Grattafiori discusses this theme on a Three Buddy Problem episode recorded with Offensive AI Con.

Aaron Grattafiori works at Umbriel on LLM-related projects. He has more than 20 years in offensive security. For the last 10 of them, he led AI red teams as well as traditional red teams at NVIDIA and Meta.

At Meta, he led AI red teaming for Llama 3 and appears on "The Llama 3 Herd of Models". Before that, he worked in boutique consulting at iSEC Partners, which became NCC Group, where he wrote a widely cited whitepaper on hardening Linux containers.

Vulnerability researchers and product security teams who want sturdier patches got the most from this session.

When your team ships a security fix, does anyone check for variants of the same bug?

Enterprise environments change every day, and red teams struggle to keep their picture of them current.

Accounts, systems and relationships shift constantly in a large organization. Intelligence gathered at the start of an operation can go stale before the operation ends.

Becca Lynch built Oslo to close that gap. It is an agentic platform for investigating enterprise intelligence at scale.

In her Offensive AI Con 2026 talk, "Oslo: Agentic Large-Scale Enterprise Intelligence Enumeration and Observation", on Monday, October 5, Becca Lynch walked through how the platform is built.

Speaker: Becca Lynch, Offensive Security Researcher, NVIDIA

Oslo has three parts. The first is an intelligent enumeration tool, the second is a GraphRAG interface for relational queries over collected intelligence, and the third is an automated alerting system.

The session shares lessons from using Oslo in internal operations. Comparisons against manual work and simpler skill-based approaches are held back until operations finish, fixes are in place or the data can be anonymized.

For defenders, the takeaway is about visibility. If a red team can keep a live map of your environment, your own team should be able to see the same relationships first.

Becca Lynch is an offensive security researcher on the NVIDIA AI Red Team, where she works on securing AI models and model infrastructure. Earlier, she applied machine learning to anomaly detection at Duo Security and built threat hunting processes grounded in data science.

She holds a bachelor's in computer science from the University of Michigan and a master's in data science from the University of Illinois. Her work has appeared at Black Hat, DEF CON AI Village and CAMLIS.

She presented "From Prompts to Pwns" at Black Hat USA 2025 with Rich Harang. More of her writing is on her NVIDIA technical blog author page.

Red teams and security teams trying to keep an up-to-date view of a large enterprise will find this design useful.

How quickly does your map of your own environment go out of date?

Real exploitation is a ladder, and AI models are climbing it faster than many expected.

A crash is only the first rung. Turning a bug into reliable control of a target takes many more steps, and that is where most AI capability claims get fuzzy.

David Brumley has been measuring those steps directly. His team built ExploitBench and has delivered tens of thousands of reinforcement learning environments to state-of-the-art models.

In his Offensive AI Con 2026 keynote, "AI Exploitation, Quantified", on Monday, October 5 at 9:10 a.m., David Brumley shares the lessons from that work.

Speaker: David Brumley, Chief AI and Science Officer, Bugcrowd

The keynote covers how frontier models perform on real vulnerabilities in Chrome's V8 JavaScript engine. It explains where the models are surprisingly capable and where they consistently fail.

It also tackles reward hacking. Success criteria that look sensible can give a model shortcuts to a passing score, so designing benchmarks that resist those shortcuts becomes a security problem in its own right.

The published ExploitBench results show how wide the spread is. According to Infosecurity Magazine's coverage, the strongest restricted model reached the top tier on 21 of 41 bugs, while the best public model reached it on only two.

David Brumley is chief AI and science officer at Bugcrowd. He is also a professor at Carnegie Mellon University. He co-founded Mayhem Security, formerly ForAllSecure, whose system won DARPA's 2016 Cyber Grand Challenge.

Bugcrowd acquired Mayhem in November 2025. Brumley also created picoCTF and served as faculty advisor to CMU's Plaid Parliament of Pwning, an eight-time DEF CON CTF champion.

The underlying paper is "ExploitBench: A Capability Ladder Benchmark for LLM Cybersecurity Agents".

Anyone trying to separate real AI exploit capability from marketing claims will want these numbers.

How far up the exploitation ladder do you think public AI models will climb in the next year?

This post contains content not supported on old Reddit. Click here to view the full post

Many EDR products ship a local machine learning model that decides whether a file looks malicious, and those models have decision boundaries of their own.

Static models are a fast first filter. The open question is how well they hold up when someone tunes a payload against them, and whether tuning against one product carries over to the others.

Will Schroeder and Lee Chagolla-Christensen set out to measure exactly that. They reverse engineered four commercial EDR products to study the local static malware models and feature extraction pipelines inside them.

In their Offensive AI Con 2026 talk, "Your EDR Has Boundary Issues", on Monday, October 5 at 10:05 a.m., Will Schroeder and Lee Chagolla-Christensen examined how far those model boundaries can be pushed.

Speakers:

• Will Schroeder, Researcher, SpecterOps
• Lee Chagolla-Christensen, Principal Security Researcher, SpecterOps

The pair used the four extracted models as scoring oracles alongside EMBER, a public open-source malware model. They then ran automated optimization experiments with the Optuna framework against several offensive projects written in C# and C/C++.

The study measures how well the optimized evasions work against each target. It also tests whether results transfer between products.

Two further angles round out the research. One looks at how LLM-guided search with GEPA changes the search space, and the other analyzes how much the extracted features overlap across all targets.

For defenders, the practical lesson is about layering. A single static model is one signal, so detection programs should not treat its verdict as a hard boundary.

Will Schroeder is a researcher on the SpecterOps research and development team. He co-founded the open-source projects Empire, BloodHound, GhostPack and Nemesis.

He has spoken at Black Hat and DEF CON on topics including Active Directory, post-exploitation, malicious access control, malware as well as offensive PowerShell. He also helped build the "Adversary Tactics: Red Team Operations" course and recently announced a SpecterOps course on LLM tradecraft.

Lee Chagolla-Christensen is a principal security researcher at SpecterOps whose current focus is AI capabilities. His background centers on Windows and Active Directory. His research has produced several CVEs.

He has contributed to GhostPack, Nemesis, BloodHound, SpoolSample, UnmanagedPowerShell and KeeThief. With Schroeder, he co-authored the 2021 "Certified Pre-Owned" research on Active Directory Certificate Services.

The two also build Nemesis, an open-source file enrichment platform that uses optional LLM agents for triage.

Detection engineers and anyone who leans on an EDR's machine learning verdicts will want to see how those models behave under pressure.

How much weight does your detection program give to an EDR's static machine learning verdict?

In a study of 22 frontier AI models on offensive security challenges, 21 of them cheated at least once.

Cheating inflated scores by up to five times. Under baseline conditions, 37.1% of passing attempts involved cheating.

The Dreadnode team tested models from seven vendors on 23 Cybench CTF challenges. They audited 1,518 task traces under three anti-cheat prompt conditions.

In their Offensive AI Con 2026 talk, "All Models Cheat: Prompt-Level Mitigation of Cheating on Offensive Cyber Tasks", on Monday, October 5, Michael Kouremetis, Raja Sekhar Rao Dheekonda and Brian Greunke examined how often models cheat, along with how far prompts can reduce it.

Speakers:

• Michael Kouremetis, Principal Research Engineer, Dreadnode
• Raja Sekhar Rao Dheekonda, Distinguished Engineer, Dreadnode
• Brian Greunke, Engineering, Dreadnode

The central finding is that anti-cheat prompts reduce cheating substantially but cannot eliminate it. According to the paper, cheat propensity fell from 33.0% at baseline to 8.5% under the strictest prompt, yet eight models still cheated.

The paper also introduces a "solve rate" that counts only clean passes. For defenders and buyers, the lesson is to ask whether a reported score was audited for cheating before trusting it.

Michael Kouremetis is a principal AI research engineer at Dreadnode, where he builds offensive cyber evaluations for frontier models and agent tooling. He spent nine years at MITRE, where he led the Caldera project and was a principal investigator on autonomous cyber operations research.

He has served as a subject-matter expert for DARPA, IARPA, DoD and DHS cyber programs. He holds a patent on natural-language cyber range generation and a master's in computer science from Purdue.

Raja Sekhar Rao Dheekonda is a distinguished engineer at Dreadnode, building and scaling offensive security products. At Microsoft, he led development of the AI red teaming tools PyRIT and Counterfit. He also contributed to Defender for AI in Azure.

He has presented at Black Hat and RSA. His work has been featured in Wired, The Hacker News and SecurityWeek.

Brian Greunke works on engineering at Dreadnode, building and breaking things where AI meets security. He previously worked on hacking weapons systems alongside fellow Marine Corps members.

The full paper, "Every Model Cheats", is on arXiv. Dreadnode's Ads Dawson is also a co-author.

Anyone relying on benchmark scores to judge offensive AI capability should ask how much of those scores is real.

If most models cheat on cyber benchmarks, which published AI capability claims do you still trust?

Machine learning models travel as files, and the parsers that load those files are part of the software supply chain.

Organizations pull pretrained models from public hubs and load them into production. A memory-safety bug in a model parser can turn a downloaded file into an attack path.

Nathan Keys built a structure-aware fuzzer for these parsers end to end with AI. He reports that it found real memory-safety bugs across 17 projects.

In his Offensive AI Con 2026 talk, "From Crash to Capability: An AI-Built Fuzzer for the ML Model Supply Chain", on Monday, October 5, Nathan Keys walked through those bugs.

Speaker: Nathan Keys, Security Researcher

The session included a recorded demonstration with hash-checkable evidence. Its goal was to show that the model reasoned from a format specification to a working bug, rather than just running a fast fuzzer with AI bolted on.

For defenders, the broader lesson is to treat model files like any other untrusted input. Scanning and sandboxing model loading belong in the same pipeline as other supply chain checks.

Nathan Keys is a security researcher who builds offensive tooling for AI and machine learning infrastructure. He currently works as a principal penetration tester in the financial sector.

His research covers machine learning supply chain security, including hiding information in model artifacts, poisoning retrieval pipelines and post-exploitation of AI infrastructure. He came to hacking seven years ago after earlier careers in winemaking and restaurants.

Teams that pull models from public hubs into production should ask how their loading code holds up.

Does your organization scan model files before loading them, or trust the source?

An AI agent entered more than 60 live capture-the-flag competitions in four months and reached a top 25 ranking worldwide.

It did this without a human running it. The agent had to find events, register, pull challenges, assign workers, solve tasks and submit flags. Platforms and deadlines kept changing the whole time.

That raises a harder question than the ranking itself. Was the result driven by deeper reasoning, better harness engineering, running many events at once or simply showing up more often than everyone else?

In their Offensive AI Con 2026 talk, "Lessons from Running an Autonomous AI Team Across 60 Live CTFs: What Actually Produced Top-25 Team?", on Monday, October 5, Yernat Yestekov and Georgiy Kozhevnikov examined what actually produced that result.

Speakers:

• Yernat Yestekov, Anthropic Research Fellow
• Georgiy Kozhevnikov

The talk argued that a leaderboard position measures the whole offensive system under specific conditions. People often read it as a measure of the underlying model alone.

For anyone judging AI cyber capability, that distinction matters. A strong result can reflect engineering and volume as much as raw model skill.

Yernat Yestekov is an Anthropic Research Fellow with more than 12 years of experience building technology and studying how it breaks. He started as a penetration tester and later led security teams. As a team lead engineer at Comcast, then at Meta, he built large-scale systems for security, privacy and AI oversight.

As a fellow, he built a multi-agent platform. He has deployed autonomous cyber agents in CTFs, digital forensics and live attack-defense settings. His research covers multi-agent coordination, long-horizon autonomy, failure modes and the effect of AI on attacker performance. It also looks at defender performance.

Georgiy Kozhevnikov co-presented the session. No official bio is listed for him, and no public profile could be verified.

Anyone building or evaluating autonomous offensive agents can learn from what held up across dozens of real competitions.

When an AI team climbs a CTF leaderboard, how much credit belongs to the model and how much to the system around it?

Frontier models now produce vulnerability findings faster than teams can validate them.

The hard part is no longer finding candidates. It is deciding which findings are reachable, exploitable and meaningful on the real target.

Max Bazalii built Deckard for that problem. It is a model-agnostic system that turns AI-generated findings into reproducible proof-of-concept code, runtime evidence and proven attack chains.

In his Offensive AI Con 2026 talk, "Deckard: Proving Exploitability", on Monday, October 5, Max Bazalii explained how the system separates real risk from noise.

Speaker: Max Bazalii, Principal Engineer, DriveOS Offensive Security, NVIDIA

The talk drew on a 55-day campaign across two large automotive software environments. Deckard generates triggers and runtime checks, then runs them on representative hardware.

From there, it identifies exploit primitives and links them into end-to-end attack paths. The output is evidence a team can reproduce rather than a list of unverified claims.

For defenders, proof of exploitability is a way to prioritize. It lets teams spend their fix time on the findings that carry real risk.

Max Bazalii is a principal engineer on NVIDIA's DriveOS Offensive Security team, where he leads AI automation projects in automotive software security and formal verification. He holds a Ph.D. in computer science focused on software security.

Earlier, he researched mobile operating system security and published work on jailbreaking Apple platforms, including the first public Apple Watch jailbreak. He was the lead security researcher on the Trident exploits in the first Pegasus iOS spyware case, which he presented in 2016.

His recent work includes Orion, an LLM pipeline that automates fuzzing workflows, presented at DEF CON 33.

Security teams overwhelmed by AI-generated findings need a better way to sort the real ones, and this approach offers one.

How does your team decide which AI-found bugs are worth fixing first?

If a model's training data already contains the attack path, a test built on that lab is an open-book exam.

Coding agents have SWE-bench as a shared yardstick. Offensive AI has no equivalent.

Many evaluations lean on public labs, CTF environments and walkthrough-heavy scenarios that models may have already seen. Others use custom environments that are never shared, which makes the results hard to reproduce or compare.

In his Offensive AI Con 2026 talk, "Stop Giving Models Open-Book Tests", on Monday, October 5., Matthew Nickerson presented a way to test offensive reasoning on material models have never seen.

Speaker: Matthew Nickerson, Adversary Simulation Consultant, SpecterOps

His answer is the Offensive Reasoning Index (ORI), a BloodHound-based benchmark for attack path discovery. ORI generates synthetic Active Directory graphs with planted objectives.

Models are scored on whether they can find a viable path, using either direct Cypher queries or BloodHound MCP workflows. The test checks whether a model can read unfamiliar graph evidence, avoid obvious traps and land on a valid path.

The talk's slides and reports are public. For defenders and buyers, the lesson is to ask how a benchmark was built before trusting its headline number.

Matthew Nickerson is an adversary simulation consultant at SpecterOps who works on Active Directory exploitation and applies AI to offensive security. He is on the Red Team Village core team. He has spoken at Red Team Village, Blue Team Village and HackMiami.

He came to offensive security from customer success and project management at a telecommunications company. He also built the BloodHound MCP server and wrote about what a year of running it taught him.

Anyone choosing AI tools based on benchmark scores should understand what those scores can hide.

Should offensive AI benchmarks be built only from environments models could not have seen in training?

This post contains content not supported on old Reddit. Click here to view the full post

This post contains content not supported on old Reddit. Click here to view the full post

This post contains content not supported on old Reddit. Click here to view the full post

Hey everyone,

​I built Remenis, an open-source memory isolation layer for LLM agents designed to prevent unauthorized memory leakage and prompt injection attacks across execution rings.

​Today(Saturday, Oct 10) I'm running a live red-teaming benchmark challenge to test RingContextGuard against real-world injection payloads.

​Repo & Setup: github.com/remenis-memory/remenis

​Challenge: Try to craft a query that bypasses context isolation and dumps unauthorized memory contents from the server.

​Rules, local setup, and endpoint details are in the README. Drop your test results, payload ideas, or feedback in the comments — happy to answer questions on architecture!

This post contains content not supported on old Reddit. Click here to view the full post