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

Educational purpose only for Red team and Blue team cyber operations. Do not use for any destructive purpose and this blog will neither be responsible nor supporting for any destructive activities.

This mandatory notice applies to every procedure and example in this article.

What CyberChef is

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.

Installing/running CyberChef locally on Kali Linux

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.

Capabilities that matter

• Base64/Base32/URL/hex and many other encoding transformations;
• hashing/checksum operations;
• compression/decompression;
• binary/hexdump conversion;
• parsing of selected structured/network/certificate formats;
• string/byte operations and character-set conversion;
• recipe chaining and reproducibility;
• local browser execution for sensitive evidence;
• Node API for programmatic recipes after building the Node package.

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.

Blue-team use

Decode suspicious payloads without custom one-off scripts

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.

Email/phishing and web incident analysis

Common tasks include:

• decode URL-encoded redirect parameters;
• inspect Base64 MIME or application fields;
• normalize obfuscated strings;
• calculate hashes for case correlation;
• inspect certificate text/encoded blobs;
• convert hexdumps into byte views for further analysis.

Forensics support

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.

Red-team use

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.

When to use CyberChef

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.

AI-assisted Red/Blue operations

CyberChef and LLMs complement each other unusually well:

• the LLM recognizes likely encodings/formats and proposes a sequence;
• CyberChef executes the sequence deterministically;
• the harness records the recipe and hashes the input/output;
• the LLM interprets the result in incident/engagement context.

Blue AI example

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.

Programmatic Node API

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.

Example harness configuration

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.

Model selection: keep the model interchangeable

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.

Minimum harness controls

A production-grade AI security harness should enforce these controls outside the LLM:

• explicit engagement or operational authorization reference;
• target allowlist and denylist evaluated before each tool invocation;
• least-privilege service identity and short-lived credentials;
• read-only/default-passive execution unless a human approves a stronger action;
• secret and PII minimization before model submission;
• structured model output validated against a JSON Schema/Pydantic model;
• evidence provenance: command, timestamp, tool version, source object and raw-result hash;
• immutable audit trail of prompts, tool calls, approvals and final actions;
• no shell access for the model when a narrow function wrapper can perform the same task;
• fail closed when scope, parser output or authorization is ambiguous.

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.

Common failure modes

• Trusting “Magic” or an AI guess as proof. Validate operation output and file/data signatures.
• Executing decoded content. Decoding is analysis; execution belongs in an isolated malware sandbox.
• Using CyberChef for production cryptography. The upstream security policy explicitly cautions against relying on its cryptographic operations for security guarantees.
• Building master forever. Pin/review releases and update for security fixes.
• Letting the model invent operation names. Validate against the installed CyberChef operation registry.