Buckets:
| 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. | |
Xet Storage Details
- Size:
- 9.41 kB
- Xet hash:
- 9b1b24c21de1ff505f97726ae21437183908a667e7745dae022494b39addbb76
·
Xet efficiently stores files, intelligently splitting them into unique chunks and accelerating uploads and downloads. More info.