I recently managed to recreate the Backdoor.Turn TTP with the help of LLMs. I’ll explore the technique in this post, and the reflections of using local LLMs for offensive security.
LLMs in Offensive Security
Cybersecurity is famously a sensitive topic with AI for good reasons. But like every other pentester out there, when someone tells me I cannot do something, my fingers start to tingle.
After a few months of working with various models & harnesses for cybersecurity, I have settled on a modality of working that takes advantage of the various means and models that are available to me.
There are benchmarks out there that put a model through its paces and comes out with a nice number that tells you which one is better: 82.7%! But what does that mean when it comes to working with these models and accomplishing a task? Does it mean it can only complete 82.7% of every task you throw at it? Or only tasks that have a ranked difficulty of 82.7%?
I wanted to give a rough sense of what these LLM capabilities mean when it comes to cybersecurity.
I’ve tested N-day development, weaponising exploits, agentic operators, and TTP development with varying degrees of success. I’m not an expert maldev, vulnerability researcher, red teamer, but I do dabble in these areas, so my experience may vary from those who have deep domain knowledge.
Backdoor.Turn TTP
My current project is to recreate the Backdoor.Turn TTP, which abuses anonymous guest users to obtain Microsoft TURN relay credentials to create an encrypted C2 UDP channel to an attacker controlled infrastructure using the QUIC protocol. It is hard to detect and block because it uses legitimate signaling, protocols, and infrastructure that is whitelisted through corporate NAT gateways.
Before starting this project, I knew nothing about these protocols or how Teams worked.
The below two screenshots demonstrate that I was able to get a QUIC connection from Microsoft TURN relay and send messages back and forth between the ‘malicious’ server and client.
This was reported on 16 June 2026 by Symantec, and I was able to get a POC working a few days later. I spent an hour of research on what this technique was about and the details of the TURN and QUIC protocol. Once I had enough information, I hand-authored a build guide (most frontier models will decline anything malicious or malicious-adjacent) and guided a local LLM (Deepseek-V4-Flash, Q2 running on a Framework Desktop 128GB) to finish the exploit. I ballpark the total time of development to be somewhere about 3 hours of focused work.
So now with some context of what I’m working on, I want to share some of my thoughts on how different models fit into the overall picture.
Fable, Opus, GPT 5.5 - Frontier models available through APIs (aka closed models) are incredibly capable, frequently being able to one-shot challenging prompts or solve problems that previous iterations were not able to. They fall short when it comes to cybersecurity not because they can’t solve the problem, but because they refuse to. The guardrails are in place and constantly updating, and I don’t want to be constantly looking for jailbreaks that are patched the next month, nor do I want to be at the mercy of another organisation’s favor to accomplish my work, especially if this favor can change on a whim.
What I found frontier models to be good for is deep research into a cybersecurity and illuminating the technical aspects of an exploit or technique. While they might decline to go into specifics, especially for explicitly malicious stuff, it is possible to isolate non-malicious, technical elements to create the structure for handing off the work work to my local model.
Deepseek, Minimax, GLM 5.2 - With the recent release of GLM 5.2, self-hosted frontier models are here. Sure, they may be beyond anything a typical person be able to host, but they provide a means to ensure that any achieved capability can be maintained independently, whether through on-prem hardware or rented hardware in the cloud. For most tasks, I find these set of models to be comparable to frontier models that are only available through APIs, although they can be significantly cheaper which is the main reason they are the main models driving my non-critical flows.
Crucially, these models also appear to have more permissive guardrails than closed models, which allows them to be deployed in somewhat ‘gray’ agentic areas.
Gemma 4, Qwen 3.6, and Deepseek v4 Flash (Q2 with ds4) - And then, we finally come to local models, something you can run in your bedroom or desk (provided you have the GPUs). There is a significant gap in capability between local and frontier models. Despite many claims that these models are good enough for some cancel their subscriptions and ’local is finally good enough’, I think there are some important caveats:
- Agentic autonomous research is challenging. I would only use local models for very targeted research. I don’t believe frontier models are capable of novel work today without expert guidance (i.e. I will be able to develop a new math theory with Mythos), let alone local models.
- Agentic coding requires close supervision. The models tend to tunnel-vision into a certain part of the code and get stuck, often a simple prompt or direct intervention is required:
- Agent complains about getting access denied errors when adding a peer during testing. Speculates that implementation of the protocol used by the Microsoft relay is different, examines spec multiple times. Problem? It was trying to route with a private IP instead of a public IP.
- Client is not able to read a value back from the server. EOF errors, agent speculates that the transport is incorrect, writes a UDP bridge. Problem? Server was terminating the connection immediately after sending the message. Allowing the client to terminate instead of the server solved the problem immediately. Bridge was not necessary.
- Unsuitable for any work that requires precision (e.g. byte level exploitation) or creativity though combining bits of specific knowledge together (e.g. malware development) without significant guidance. The LLM can write the boilerplate, but you need to write the important parts yourself. I think this is because cybersecurity, especially offensive security, thrives on the extremes, pushing the envelope of what is possible, whereas LLMs are a learned median. They are good for middle of the road development work, which is great if you are a developer, and gets you caught immediately if you are a special class of developer.
- Good harnesses extend what is possible with a given model and give your more mileage. Think of an LLM as the engine, and the harness as the frame around it. A good frame is aerodynamic & well-oiled. Selecting a harness that works for the task is just as important as using the right model.
- Of all the offsec stuff that I tasked the local LLM with, recreating the Backdoor.Turn TTP would be considered very easy. I think this is where the current local capabilities are for autonomous activity. A local model works best when paired as a junior developer that can help write the boilerplate or fix bugs, but as the difficulty increases, the main direction and specific code still needs to be written by a professional or expert.
Given the three archetypes, I see three main features of cost, capability and resiliency
If resiliency is not a consideration, then closed models are the way to go. However, if you have buckets of money to spend, an open weight frontier like GLM 5.2 may be better because you are buying resiliency while keeping frontier-level capability. The only reason resiliency is less of a local model because obtaining the equipment to run these models either are hard to obtain especially with a supply crunch, or capacity at that level is hard to rent consistently. Open weights use commodity hardware, so you’ll definitely be able to get your hands on something that can run a model, just don’t expect too much out of it.
Does that mean I would write off local LLMs?
No. As flawed as they are today, my own capability is still raised by leveraging them in a very select manner. Instead of having to work through the error messages, read esoteric library documentation, and examine snippets of example code, the local model can do that for me. What would have taken probably a week of focused evening work was condensed into a day of passive observation and about thirty minutes of active intervention.
I would even go further and say that because of the limitations of the model, I was forced to understand the technologies and implementation, and this is a positive thing to me.
People often ask me why I would spend real money on hardware that will never pay itself back when comparing against subscriptions. Closed models through APIs are smarter, faster, and cheaper, the trifecta of key considerations, but I personally feel this increase in capacity to be important enough to me secure it permanently, which is something I can’t guarantee otherwise.