CyberChef for Red and Blue Teams: Deterministic Data Transformation with an AI Recipe Planner

GCHQ's CyberChef, a deterministic data transformation workbench, is being paired with AI recipe planners to safely decode and transform data in security operations. The tool's deterministic engine ensures reproducible results, while LLMs propose recipes that CyberChef executes, reducing the risk of trusting AI-generated decodes. Developers are advised to pin reviewed releases and avoid executing decoded content.

This mandatory notice applies to every procedure and example in this article. GCHQ's CyberChef is a browser-based data transformation workbench — often described as a “Cyber Swiss Army Knife.” It chains operations into recipes for encoding/decoding, hashes/checksums, compression, binary/hexdumps, character encodings, certificate/data parsing and many other transformations. Its most important property for AI-assisted security work is that the transformation engine is deterministic code . The LLM can propose or interpret a recipe, while CyberChef performs the actual decode/transform. That is safer and more reproducible than asking an LLM to mentally decode a long blob and trusting the answer. CyberChef's own security policy cautions that cryptographic operations should not be relied on as a security guarantee. Use established cryptographic libraries/HSM/KMS implementations for production cryptography; use CyberChef for analysis and transformation. CyberChef is not a standard Kali package in the sources verified for this article, so use the upstream project. Current CyberChef getting-started documentation updated April 2026 requires Node.js 24 for the development build. A clean local source workflow is: sudo apt update sudo apt install -y git Install Node.js 24 through your approved Node version-management/package process, then: git clone https://github.com/gchq/CyberChef.git cd CyberChef npm install npm start Upstream documents the development server at: http://localhost:8080 For a production build: npm run build Upstream says the resulting production-ready files are written under build/prod/ . For security-sensitive environments, pin a reviewed CyberChef release rather than always building master , and monitor upstream security releases. The project published security fixes in 2026, which is a practical reason to keep the version current. CyberChef is not a full malware sandbox, packet analyzer or forensics suite. It is a transformation layer that works extremely well on data extracted from those tools. SOC data frequently contains nested transformations: URL encoding → Base64 → gzip → JSON, or hex → bytes → embedded strings. CyberChef lets an analyst construct a visible recipe and preserve it with the case. A useful rule: do not execute decoded content . Transform it as data. If the output becomes a script/binary, move to a malware-analysis workflow rather than running it from the analyst desktop. Common tasks include: Use CyberChef on an extracted artifact — a registry value, encoded PowerShell fragment, log field or carved blob — while preserving the original evidence and its hash. CyberChef should not replace evidence acquisition or chain-of-custody controls. In an authorized engagement CyberChef helps the tester reason about application encodings and data formats without writing disposable scripts. It can reproduce how an application encodes identifiers, headers or payload structures, and it can create deterministic test data for a staging endpoint. Do not use the recipe system as justification to generate malicious payloads for targets outside scope. The same scope/authorization rules apply as with any other tooling. Use it when the problem is fundamentally data representation or transformation . If the problem is network capture, use Wireshark/tshark; if it is memory forensics, use Volatility; if it is web request interception, use Caido; if it is cloud attack paths, use CloudFox. CyberChef and LLMs complement each other unusually well: Input: a suspicious text field from an alert. Model output schema: { "proposed recipe": {"operation": "From Base64", "arguments": }, {"operation": "Gunzip", "arguments": } , "reason": "The input shape is consistent with Base64 and the decoded header should be checked for gzip magic bytes.", "confidence": 0.71 } The harness does not trust the recipe because the model said so. It runs the first deterministic step, validates the output signature, and only then continues. If the operation name is not on an allowlist, the pipeline stops. CyberChef documents a Node API with a bake function for recipe chains. Current upstream build instructions use: npm run node That gives you a possible automation path without browser control. Pin the CyberChef version and test the exact operation names against that build; operations evolve over time. cyberchef: version policy: pinned reviewed release execution: local node api allowed operations: - From Base64 - From Hex - URL Decode - Gunzip max input bytes: 5242880 execute decoded content: false model: provider: local ollama name: "${OLLAMA MODEL}" purpose: recipe planning and interpretation validation: record input sha256: true record output sha256: true record recipe: true operation allowlist: true max recipe steps: 8 security: network egress: denied model can execute shell: false Set OLLAMA MODEL to a locally reviewed model whose capabilities you have tested for this harness. For highly sensitive incident data, keeping both CyberChef and the model local avoids sending raw payloads to a hosted provider. Do not bind the security workflow to one vendor. The tool adapter, authorization policy, evidence schema and audit log should remain stable while the model can be swapped. | Role | Practical model choice | Why | |---|---|---| | Deep correlation, long evidence sets, final security reasoning | gpt-5.6-sol or claude-sonnet-5 | Use the strongest generally available model when the task is ambiguous, cross-source or high-impact. | | Routine triage, classification, deduplication and report drafting | gpt-5.6-terra | Good fit when the workflow is already constrained by deterministic tooling and schemas. | | High-volume, low-complexity labeling or first-pass routing | gpt-5.6-luna | Keep expensive reasoning out of repetitive classification. | | Sensitive/offline evidence | A locally approved Ollama model that supports the capabilities your harness needs | Keep raw evidence on-premises. Verify the exact installed model with ollama list ; do not assume every local model supports tool calling or structured output. | Current OpenAI documentation describes Sol as the frontier GPT-5.6 model, Terra as the capability/cost balance, and Luna as the cost-sensitive high-volume tier. Anthropic currently documents claude-sonnet-5 as its Sonnet 5 model. Ollama documents tool calling and OpenAI-compatible APIs, but support is model-dependent. For security operations, the model is not the authorization system . Target scope, credentials, rate limits, network egress, mutating actions and approval gates belong in the harness or surrounding control plane. A production-grade AI security harness should enforce these controls outside the LLM: The control pattern matters more than whether the orchestration layer is a custom Python service, a Kubernetes workload, an MCP host, a CI job or an analyst workstation. master forever.