File size: 9,407 Bytes
0e77e0e
79f4b63
0e77e0e
4ed4f81
 
0e77e0e
 
 
 
 
4ed4f81
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
25c5612
 
 
 
 
 
 
 
 
 
 
 
 
4ed4f81
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
0e77e0e
eab3c2f
9838f24
4ed4f81
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
9838f24
79f4b63
4ed4f81
79f4b63
9838f24
eab3c2f
4ed4f81
 
 
 
 
eab3c2f
 
4ed4f81
 
 
 
 
 
 
 
 
 
 
 
 
79f4b63
 
 
4ed4f81
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
---
license: other
base_model: Qwen/Qwen3.6-35B-A3B
library_name: transformers
tags: [offensive-security, pentesting, tool-calling, cyberstrike, qwen3]
pipeline_tag: text-generation
---

# CyberStrike-OffSec-35B

Autonomous offensive-security / pentesting agent fine-tuned on **Qwen3.6-35B-A3B**. This model emits
**real, structured tool calls** with correct agent routing and clean termination β€” the behaviours a
tool-calling harness actually needs.

This release ships as a **single-piece merged checkpoint** (load with one command). A LoRA adapter
is also available for `--enable-lora` serving (see *Serving β†’ Adapter*).

---

## What this fine-tune actually is (and isn't)

Set expectations honestly. This is a **small, targeted alignment**, not a capability upgrade:

- **It did NOT** add security knowledge β€” the base Qwen3.6 already knows offensive-security
  concepts, and already emits tool calls (22/24 in our eval).
- **It DID** teach the model to emit tool calls *in the exact format a CyberStrike harness expects*,
  route to *valid agent archetypes* instead of internal codenames, handle real observations without
  fabricating them, and terminate cleanly.

In other words: we did not make the model *smarter* β€” we **aligned it to the harness** and **fixed
the specific collapse** of the previous version. Trained on a deliberately small **300-example**
dataset (one round), so gains are concentrated in tool-use behaviour, not broad capability. Broader
robustness is the goal of the next data iteration (Stage-2). We state this plainly so a returning
user knows exactly what changed and why.

---

## Why this release exists β€” measured before/after

The previous CyberStrike model failed in production: users reported "broken tool calling,"
"simulated executions," and "faked engagements."

**Root cause β€” the training data was in the wrong format.** The previous model's SFT dataset taught
tool calls in a format the model never learned to emit as *real structured calls*. As a result it
produced **wrong / malformed tool calls**, fell into **loops**, and β€” unable to actually invoke a
tool β€” **hallucinated**: it wrote fake tool outputs (invented `curl`/SSL handshakes, Nmap scans,
`Set-Cookie` headers, even fabricated flags) and narrated whole engagements while executing nothing.

This release fixes that by training on the correct tool-call format. To verify, we ran a controlled
**three-way A/B evaluation β€” base Qwen3.6 vs. the previous CyberStrike model vs. this model** β€” over
24 scenarios (6 axes Γ— difficulty tiers, 62% out-of-distribution). Full methodology, all 24 prompts,
the complete result matrix, and verbatim raw-output quotes are in **[EVALUATION.md](./EVALUATION.md)**.
Every number below is grounded in **raw model output**, not auto-scored heuristics.

| Metric (24 scenarios) | Base Qwen3.6 | **Previous model** | **This model** |
|---|---|---|---|
| Genuine structured tool calls | 22/24 | **0/24** | **18/24** |
| Correct tool / archetype | 6/24 | 2/24 | **10/24** |
| Clean termination | 21/24 | **3/24** | **24/24** |
| Fabricated observations | none | **widespread (8+ scen.)** | **none** |

**What the previous model did (concrete):** instead of a structured call it wrote prose such as
`**Action 1:** Task(GHOST…)`, then invented its own tool output β€” fake `curl` / SSL handshakes /
Nmap scans / `Set-Cookie: sessionid=abc…` and even fabricated flags β€” and never terminated, in
**both** bf16 and q8. It *looked* like it was working (it narrated a whole engagement) while
executing nothing. This is the exact behaviour behind the user reports.

**What this model does:** emits a genuine `<tool_call><function=Task>` with a valid archetype
(e.g. `web-application`, `explore`) and terminates with `<|im_end|>`. The base model *does* emit
calls, but routes with internal codenames ("GHOST") rather than valid archetypes β€” the routing this
fine-tune specifically corrected.

### What the 24 scenarios tested

Six axes, each at easy β†’ medium β†’ hard difficulty, weighted 62% toward out-of-distribution prompts
(unseen target names, novel phrasing) to separate genuine generalization from memorized patterns:

| Axis | What it checks |
|---|---|
| **Tool selection** | picks the right tool for the phase; prefers dedicated tools over `bash` equivalents |
| **Argument typing** | emits correct types β€” `steps` stays an int `50`, `headless` stays a bool `true` |
| **Real-observation handling** | reads an actual tool result and acts on it; on empty/unexpected output it pivots instead of fabricating |
| **Loop / termination** | stops when the task is done; no runaway or crash on multi-step tasks |
| **Sub-agent delegation** | delegates to the correct archetype; does not invent agent names |
| **Parallel tool calls** | batches independent work; does not spam hundreds of calls |

The two axes the previous model collapsed on hardest β€” real-observation handling (it fabricated) and
termination (it looped) β€” are the two this model scores cleanest on.

The previous model has been **withdrawn** from active serving: its broken merged weights were
**removed** from this repo, and its GGUF build was **gated** with a deprecation notice, so new users
don't unknowingly pull the broken version.

---

## Serving

`main` is the **single-piece merged checkpoint**; the LoRA adapter alone (169 MB) is on the
`adapter` revision.

### βœ… Default β€” Python (verified)

The one-command load below was verified on this hardware: the merged checkpoint loads and, on the
tested scenarios, emits genuine structured tool calls and terminates cleanly.

```python
from transformers import AutoModelForImageTextToText, AutoTokenizer
model = AutoModelForImageTextToText.from_pretrained("oyildirim/CyberStrike-OffSec-35B")
tok   = AutoTokenizer.from_pretrained("oyildirim/CyberStrike-OffSec-35B")
```
Pass the tools via `tok.apply_chat_template(messages, tools=TOOLS, add_generation_prompt=True)`; the
model emits Qwen3 XML tool calls (`<tool_call><function=…><parameter=…>`).

### βš™οΈ vLLM (single-piece merged) β€” not verified on this hardware

```bash
vllm serve oyildirim/CyberStrike-OffSec-35B \
  --enable-auto-tool-choice --tool-call-parser qwen3_xml --max-model-len 8192
```
> **Caveat β€” unverified.** This model's architecture (`qwen3_5_moe`) is only supported by recent vLLM
> (0.25.1+), which requires a **CUDA-13-compatible** build/driver. It could not be run on our test
> hardware (CUDA 12.8). The `qwen3_xml` parser and schema-driven typing (`steps`β†’int, `headless`β†’bool)
> were verified in isolation, but the end-to-end vLLM serve was **not** verified here. Expected to
> work on a CUDA-13-capable box; confirm on your setup before relying on it.

### βš™οΈ Adapter β€” base + LoRA (`@adapter` revision)

For keeping the base pristine or stacking adapters. Python (verified path):
```python
from transformers import AutoModelForImageTextToText
from peft import PeftModel
base  = AutoModelForImageTextToText.from_pretrained("Qwen/Qwen3.6-35B-A3B")
model = PeftModel.from_pretrained(base, "oyildirim/CyberStrike-OffSec-35B", revision="adapter")
```
vLLM equivalent (same CUDA-13 caveat as above):
```bash
vllm serve Qwen/Qwen3.6-35B-A3B --enable-lora \
  --lora-modules cyberstrike=oyildirim/CyberStrike-OffSec-35B@adapter \
  --enable-auto-tool-choice --tool-call-parser qwen3_xml --max-model-len 8192
```

> **Do not** call `AutoModelForImageTextToText.from_pretrained(...@adapter)` directly on the adapter
> revision β€” load base + adapter as shown. **Always pass the full tool schema at inference** (see
> *Known fragilities*).

---

## Known fragilities (read before deploying β€” no "broken" surprises)

On the representative 24-scenario suite the merged model has **0/24** non-termination. It has one
**narrow** out-of-suite trigger: a *terse recon prompt with a minimal (single-tool) schema* β€” e.g.
"Do passive recon on X" when only the `Task` tool is offered β€” can send greedy decoding into a
repetition loop inside the tool-call `prompt` field. **Changing the phrasing OR passing the full
tool set makes it clean**, and production serving always passes the full tool set, so this rarely
occurs in practice. Mitigations if you hit it: keep the full tool schema, and/or set
`repetition_penalty β‰ˆ 1.1` or a hard stop token.

Also observed on out-of-distribution inputs: occasional tool over-generalization and a rare invalid
sub-agent name. All of the above are targets for the next data iteration (Stage-2).

---

## Training

LoRA **r=32 / Ξ±=64**, targets = full-attention (q/k/v/o) + **GDN linear-attention
(in_proj_\*/out_proj)** + MLP β€” **310 modules, 42.3 M trainable params**. Routed experts, the MoE
router, and the vision tower are excluded (routing and multimodal behaviour left intact). 300
multi-turn tool-call SFT examples, 3 epochs, sdpa attention. Held-out token accuracy 98.5%.

Merge is verified correct layer-by-layer (uniform ~0.0016 bf16 rounding error across all groups
including the GDN layers; no merge bug).

---

## Intended use & limitations

For authorized offensive-security testing and research only. The model reasons about attack
methodology and emits tool calls for a pentesting harness; it does not itself execute anything.
Users are responsible for operating only against systems they are authorized to test. Not a
substitute for a qualified security professional.