Sure Dave, I can to that! - LLM-Driven malware development

This presentation examines how modern LLM safeguards fail in practice during malware development. Direct requests for malware are often refused. The same objective can still succeed once it is broken into smaller, legitimate-looking tasks and spread across multiple models, sessions, and narratives.

The session centers on a stealer/worm-style sample developed through iterative multi-model workflows in OpenCode. Qwen 3.5 Plus and MiniMax 2.7 performed most of the build work. GPT-5.4 was used for troubleshooting and debug refinement. Claude Sonnet 4.5 was used for early pseudocode and design support. A build agent later recommended rewriting the sample in Rust to produce a more realistic, compiled simulation.

The focus is bypass methodology. The presentation examines how refusals were weakened or reversed through cover stories, "closed lab" framing, multi-turn escalation, code-to-code debugging requests, static-analysis laundering, persona injection, false safety assurances, session resets, reverse psychology ("which models should be avoided?"), and model shopping. Cleaned excerpts from actual interaction logs will show the progression from refusal, to reframing, to scoped assistance, to maintenance and bug-fixing support for the malware artifact.

The session also cover a short case study in the wider history of LLM abuse. It connects the findings to public reporting on threat actor use of AI from Google Threat Intelligence Group and OpenAI/Microsoft, and to the progression from earlier malicious AI branding such as WormGPT to more recent reporting such as VoidLink. The emphasis is on operational usefulness: faster iteration, easier debugging, lower skill barriers, and more efficient malware development workflows.

Current safety systems are strongest against explicit malicious intent and weakest against workflow abuse. A model does not need to produce a full malware build in one answer to be dangerous. It only needs to be helpful often enough.

The session shows where safeguards are breaking, what kinds of prompts and interaction patterns are succeeding, and what traces this activity still leaves behind in prompts, build workflows, and operator behavior. A controlled demo of the final sample will be included as evidence of outcome.

This presentation is aimed at red teamers, threat researchers, defenders, and anyone working on AI safety, detection engineering, or emerging attack surfaces.