Qwen3-4B-Instruct-2507-AETHER

AETHER Qwen3-4B ATT&CK Mapper — GGUF

Map malware to MITRE ATT&CK from static features, fully offline, in strict JSON.

A QLoRA fine-tune of Qwen3-4B-Instruct-2507 that reads a static-analysis feature block for a Windows PE, Linux ELF, script, PDF, archive, image, or kernel-driver report and returns MITRE ATT&CK techniques with tactic, behaviour, cited evidence, and confidence — as a machine-parsable JSON array. Packaged as GGUF for llama.cpp, Ollama, and LM Studio: no Python, no CUDA, no API key, no network.

Built for malware analysts, SOC and DFIR teams, threat-intelligence engineers, and automated triage pipelines that must run in an air-gapped or evidence-controlled environment where sending samples to a cloud LLM is not an option.

---

Table of contents

• What it does
• Quick start
• Files and quantizations
• Prompt format — read this first
• Output schema
• Recommended inference settings
• Training
• Training data
• Evaluation
• Limitations and biases
• Intended use and out-of-scope use
• License
• Citation

---

What it does

Give it the static features of a sample — imported API functions, section entropy, packing state, embedded strings, ELF dynamic symbols, script host objects, PDF action dictionaries, archive entry inventories — and it returns the MITRE ATT&CK techniques those features indicate:

[
  {
    "tactic": "TA0005",
    "technique": "T1620",
    "name": "Reflective Code Loading",
    "behavior": "maps and runs code from memory without touching the loader on disk",
    "evidence": [
      "import pair LoadLibrary + GetProcAddress",
      "import KERNEL32.dll!VirtualAlloc"
    ],
    "confidence": "medium"
  }
]

Every element cites the exact function or structure that justifies it, so an analyst can audit the mapping instead of trusting it. The model is trained to return [] when nothing malicious is indicated.

It covers 62 ATT&CK technique IDs across 10 tactics — Defense Evasion, Command and Control, Discovery, Persistence, Execution, Collection, Privilege Escalation, Impact, Initial Access, and Credential Access.

---

Quick start

llama.cpp (server)

# 1. Download the recommended quant (4.0 GB)
hf download emulsazib/aether-qwen3-4b-attack-GGUF aether-qwen3-4b-attack-q8_0.gguf --local-dir .

# 2. Serve it with an OpenAI-compatible API
llama-server -m aether-qwen3-4b-attack-q8_0.gguf --alias aether-qwen3-4b-attack -c 4096 -n 1536 --temp 0 --port 8080

Then call it like any OpenAI chat endpoint:

curl http://localhost:8080/v1/chat/completions -H "Content-Type: application/json" -d @examples/request.json

llama.cpp (one-shot CLI)

llama-cli -m aether-qwen3-4b-attack-q8_0.gguf -c 4096 -n 1536 --temp 0 -no-cnv -f examples/pe-dll-prompt.txt

Ollama

ollama run hf.co/emulsazib/aether-qwen3-4b-attack-GGUF:Q8_0

Or build it locally with the tuned defaults in the bundled Modelfile:

ollama create aether-attack -f ./Modelfile
ollama run aether-attack

LM Studio

Search for aether-qwen3-4b-attack in the model browser, or load the .gguf file directly. Set temperature to 0 — this is an extraction task, not a creative one.

Python

A minimal, dependency-light client is included at scripts/predict.py:

pip install requests
python scripts/predict.py --features examples/pe-dll-features.txt --format pe

---

Files and quantizations

Both files are GGUF v3, 398 tensors, qwen3 architecture, with the ChatML chat template and EOS token (<|im_end|>, id 151645) embedded — any stock runtime applies the correct template automatically.

Integrity — verify before use:

sha256sum -c SHA256SUMS

a28932be199b9d5341401691963e656116482ddc4784889d144e71ea76fe0faf  aether-qwen3-4b-attack-q8_0.gguf
fcd54ffcfa2ed852d42fafe3b239445bf18f15f10db7b99b32d4e4a320bf8fe4  aether-qwen3-4b-attack-f16.gguf

Want a smaller quant?

Smaller tiers are not published yet. Build any of them from the F16 file with a stock llama.cpp:

llama-quantize aether-qwen3-4b-attack-f16.gguf aether-qwen3-4b-attack-Q4_K_M.gguf Q4_K_M

Q4_K_M (~2.5 GB) is the usual choice for 8 GB machines. Note that this model emits strict JSON, and aggressive quantization is measurably harder on exact-format generation than on prose — validate JSON parse rates on your own samples before deploying a 4-bit tier.

---

Prompt format — read this first

This is the single most important section. Feature parity is the whole game.

The model was fine-tuned on structured static-analysis feature blocks, not on raw file bytes. Feeding it a hexdump, a raw binary, a disassembly listing, or free-form prose gives it a representation it has never seen, and output degrades to noise.

A prompt has two parts.

1. The system prompt — one per file format

Use the exact system prompt for the sample's format. All seven are reproduced verbatim in examples/system-prompts.md. The PE one:

You are AETHER's threat intelligence extractor. Analyze the static features of this
Windows PE executable — its imported API functions, section entropy, packing state and
embedded strings — and map the malicious functionality to MITRE ATT&CK. Return ONLY a
JSON array. Each element must be {"tactic": "TAxxxx", "technique": "Txxxx[.xxx]",
"name": "<technique name>", "behavior": "<what the sample does>", "evidence": ["<exact
function/structure that proves it>", ...], "confidence": "low|medium|high"}. Cite only
evidence present in the features. Return [] if nothing malicious is indicated.

Supported formats: pe, elf, script, pdf, archive, image, driver_report.

2. The user message — a section-delimited feature block

Markdown ## sections in a fixed order, key=value lines inside. For PE:

## File Profile
format=PE/dll
machine=IMAGE_FILE_MACHINE_AMD64
subsystem=IMAGE_SUBSYSTEM_WINDOWS_CUI
size=717955 bytes
sections=10
imported_functions=55
exported_functions=79
tls_callbacks=yes
resources=no
authenticode=absent
overlay_bytes=2179
entropy_whole_file=6.21

## Section Table (name, sizes, entropy, permissions)
.text      vsize=534592    rawsize=535040    entropy=6.08 perms=X
.data      vsize=448       rawsize=512       entropy=1.78 perms=W
...

## API Imports (DLL!Function) — suspicious first
KERNEL32.dll!GetProcAddress
KERNEL32.dll!VirtualAlloc
KERNEL32.dll!VirtualProtect
...

## Exported Functions
...

## ASCII Strings (top 40 by signal, min length 10)
...

A complete, real example is at examples/pe-dll-features.txt, and the full ChatML-wrapped prompt at examples/pe-dll-prompt.txt.

Ordering matters. Suspicious imports are listed first so that truncation never drops evidence the model is expected to cite.

Generating feature blocks

The canonical extractor — the same code that built the training set, covering all seven formats — is app/models/aether_features.py in the AETHER project. Reusing it is strongly recommended over reimplementing: the training corpus and the inference prompt were produced by the same function, and that parity is what makes the model accurate.

---

Output schema

A JSON array. Each element:

Elements are severity-sorted, strongest first. An empty array [] means no malicious indicators.

The model returns TTPs only — never IoCs. The training targets carry no indicators, so URLs, IPs, hashes, and mutex names should be recovered with a deterministic extractor, not asked of this model.

---

Recommended inference settings

Truncation is a real failure mode. A sample with many techniques can produce a long array. In this release's own verification run, a 768-token generation cap cut the array off mid-element, so the output did not parse. Budget at least 1536 tokens and always validate the parse — treat a JSONDecodeError as "raise the cap and retry", not as "the model is broken".

Although the GGUF advertises the base model's 262,144-token context, the useful prompt window is 2,304 tokens — the sequence length the LoRA was trained at. Feature blocks are designed to fit inside it.

---

Training

QLoRA fine-tune, merged into the base weights and exported to GGUF.

Choosing the Instruct checkpoint was deliberate. An earlier AETHER adapter used a base Qwen2.5-Coder checkpoint whose ChatML tokens were untrained placeholders in the output head — <|im_end|> was bit-identical to <|im_start|>, so it could never fire, and generation ran to the token cap on every request. Qwen3-4B-Instruct-2507 has a genuinely trained <|im_end|>; this model stops on real EOS.

---

Training data

A corpus of 16,258 static-analysis records distilled from 19,161 files, built from live malware feeds.

Label distribution: 74,410 technique instances over 62 technique IDs and 10 tactics. The head is dominated by Defense Evasion (TA0005, 43,597) — T1027 Obfuscated Files or Information (10,242), T1071.001 Web Protocols (8,611), T1497 Virtualization/Sandbox Evasion (6,955), T1620 Reflective Code Loading (5,839).

Sample provenance: MalwareBazaar (abuse.ch) daily batches and family-aware recent queries, with family/type classification via the VirusTotal API v3.

After the 2,304-token cap and leak filtering, 9,347 train records and 512 eval records were actually used — 5,279 dropped as over-length, and 31 eval records dropped for overlapping the train split.

The dataset and the raw samples are not distributed with this model. Malware samples carry their own redistribution terms, and MalwareBazaar and VirusTotal each impose acceptable-use conditions on their feeds. The collection and labelling pipeline is open in the AETHER project; run it against your own credentials to reproduce the corpus.

How the labels were made — important

Targets were produced by a deterministic rule engine: a curated indicator table maps observed API imports, section characteristics, symbols, and string patterns to ATT&CK technique IDs with integer weights, then groups them by technique and derives confidence from the summed weight and the number of corroborating indicators.

The labels are not human analyst annotations and not ground truth. This model is best understood as a learned, generalizing distillation of a rule-based ATT&CK mapper — it extends to feature combinations the rule table does not enumerate, but its ontology, its blind spots, and its systematic errors are inherited from that table. Read the evaluation number below in that light.

---

Evaluation

Eval loss curve: 0.0485 → 0.0236 → 0.0225 → 0.0183 → 0.0111 → 0.0105 → 0.0084 → 0.0083.

Read this honestly. An eval loss of 0.0083 measures how faithfully the model reproduces the rule engine's labels on held-out samples. It is not precision and recall against analyst-verified ATT&CK mappings, and it should not be quoted as detection accuracy. No human-labelled benchmark exists for this task yet, and building one is the most valuable contribution this project could receive — see CONTRIBUTING.md.

---

Limitations and biases

Know these before you deploy it.

1. It is not a maliciousness classifier. It maps functionality to ATT&CK. Benign software legitimately calls VirtualAlloc, VirtualProtect, and LoadLibrary; packers and installers legitimately show high entropy. Expect non-empty output for benign binaries. Never treat a non-empty array as a verdict.
2. Static analysis only. No execution, no unpacking, no emulation, no network behaviour. A packed sample yields the packer's techniques, not the payload's. Anything that only manifests at runtime is invisible.
3. Labels inherit a rule engine's ontology. Techniques outside the indicator table cannot be produced, no matter how clearly the features imply them.
4. Severe class imbalance. Defense Evasion appears 43,597 times; Credential Access 202 times. Rare techniques (T1014 x1, T1036.008 x1, T1490 x2, T1562.001 x3) are effectively unlearned. Do not rely on the tail.
5. Format coverage is uneven. PE is well covered (9,201 records); images (83) and driver reports (52) are thin.
6. Prompt-format sensitivity. Off-format input silently degrades quality rather than erroring. This is the most common way to get bad results.
7. Long outputs truncate. Budget at least 1,536 generation tokens and validate the JSON parse.
8. It can hallucinate evidence. The system prompt demands only cited evidence, and training reinforces it, but a 4B model under distribution shift will occasionally cite a function that is not in the input. Verify cited evidence against the feature block — it is cheap, exact string matching, and it is the single highest-value guardrail you can add.
9. English only.
10. Corpus recency. The feeds were collected up to August 2026; techniques and tooling that emerged later are unrepresented.

---

Intended use and out-of-scope use

Intended: defensive malware triage and enrichment; ATT&CK-mapping automation in a SOC, DFIR, or CERT workflow; offline and air-gapped analysis where cloud LLM submission is prohibited; sandbox and pipeline enrichment; research and teaching on ATT&CK mapping; a baseline for further fine-tuning.

Out of scope: as a sole or authoritative verdict on whether a file is malicious; as a replacement for an analyst, a sandbox, or an AV/EDR engine; in any automated block, quarantine, or delete path without human review; for generating malware, evasion techniques, or offensive tooling; on inputs other than the feature blocks described above.

This model reads descriptions of already-collected artifacts and produces defensive classifications. It does not generate malicious code, and it is not fine-tuned to. Use is subject to USE_POLICY.md.

---

License

Apache License 2.0 — see LICENSE and NOTICE.

The base model, Qwen/Qwen3-4B-Instruct-2507, is Apache-2.0 licensed by Alibaba Cloud; these weights are a derivative work and carry the same license. Commercial use, modification, and redistribution are permitted under Apache-2.0 terms, including preserving the notices above.

MITRE ATT&CK® is a registered trademark of The MITRE Corporation. This project is not affiliated with or endorsed by MITRE. ATT&CK technique and tactic identifiers are used descriptively under MITRE's terms of use.

---

Citation

@software{aether_qwen3_4b_attack_2026,
  title  = {AETHER Qwen3-4B ATT&CK Mapper: static malware features to MITRE ATT&CK in structured JSON},
  author = {Sazib, Emul Ahamed},
  year   = {2026},
  url    = {https://huggingface.co/emulsazib/aether-qwen3-4b-attack-GGUF},
  note   = {QLoRA fine-tune of Qwen3-4B-Instruct-2507, GGUF release}
}

See CITATION.cff for the machine-readable form.

Acknowledgements

Qwen team, Alibaba Cloud for Qwen3-4B-Instruct-2507 · ggml-org/llama.cpp for GGUF and the runtime · abuse.ch for MalwareBazaar · VirusTotal for classification data · MITRE for the ATT&CK framework.