Analysts lose time and make mistakes when they decode Base64, convert timestamps or pull indicators out of a blob of text with ad hoc scripts and random websites. CyberChef, an open source web application from GCHQ, chains hundreds of small data operations into repeatable recipes that run in the browser. This guide covers how CyberChef works, the recipes that matter for triage and investigation, how to run it offline so sensitive data stays on your own systems, how to share recipes safely, and when another tool is the better choice. It is written for SOC analysts, incident responders and threat intelligence analysts, and describes defensive use only, based on the project's own documentation and source.
Key takeaways
- Recipes, not scripts. CyberChef chains operations such as From Base64, Gunzip and Extract URLs into a recipe you can save, share and rerun on the next sample.
- Processing is local to the browser. The project states that recipe configuration and input are never sent to the CyberChef web server, but the browser, the hosting page and the URL still matter.
- Run your own copy for sensitive work. Use the offline download, the Docker image or a build on your network rather than a hosted instance you do not control.
- Magic is a lead, not a verdict. The Magic operation scores likely decodings with heuristics such as entropy and character frequency; confirm every result.
- Decoding is not verifying. JWT Decode reads a token without checking its signature; use JWT Verify with the right key before trusting any claim.
What the tool does
CyberChef describes itself as "The Cyber Swiss Army Knife", a web app for encryption, encoding, compression and data analysis. It is maintained by GCHQ, released under the Apache 2.0 licence (Crown Copyright), and developed on GitHub; the repository's package file lists version 11.5.0 at the time of writing. The operation catalogue in the source holds about 500 operations across categories including Data format, Encryption / Encoding, Public Key, Networking, Date / Time, Extractors, Compression, Hashing, Forensics and Flow control.
| Interface area | Purpose | Analyst tip |
|---|---|---|
| Operations (left) | Searchable, categorised list of operations | Add frequently used ones to Favourites |
| Recipe (middle) | Ordered chain of operations and their arguments | Disable a step instead of deleting it while testing; set a breakpoint to inspect intermediate output |
| Input (top right) | Text, pasted data or dropped files (up to about 2GB, browser dependent) | Use multiple input tabs to run one recipe across several samples |
| Output (bottom right) | Result, with Magic suggestions shown as an icon | Save output to file rather than copying binary data through the clipboard |
- Auto Bake: recalculates the output whenever input or recipe changes; turn it off for large inputs.
- Breakpoints and step: pause before an operation or step through one operation at a time.
- Flow control: Fork and Merge run operations on each line or delimited chunk; Subsection applies operations to regex matches only; Register stores capture groups as
$R0,$R1for later arguments; Label, Jump, Conditional Jump and Return build loops; Comment documents a recipe. - Node API:
npm install cyberchefexposes operations to scripts, andchef.bakeaccepts recipe JSON exported from the web app. Flow control operations are excluded in Node and throw anExcludedOperationError.
Defender use cases
| Task | Operations (exact names) | Notes |
|---|---|---|
| Decode Base64 or hex | From Base64, From Hex, From Base32, From Base85, From Charcode, URL Decode | PowerShell encoded commands are UTF-16LE: follow From Base64 with Decode text (UTF-16LE) or Remove null bytes |
| Unpack layered encoding | Magic, Gunzip, Raw Inflate, Unescape string, From HTML Entity, Microsoft Script Decoder | Common in obfuscated scripts (T1027) that decode themselves at run time (T1140) |
| Extract indicators | Extract URLs, Extract IP addresses, Extract domains, Extract email addresses, Extract hashes | Use Regular expression for formats the extractors do not cover |
| Defang for reports and tickets | Defang URL, Defang IP Addresses (reverse with Fang URL) | Defang URL options escape dots, http and ://; combine with Extract URLs |
| Inspect tokens | JWT Decode, JWT Verify, From Base64 (URL safe alphabet) | Decode shows header and claims only; see below |
| Normalise time | From UNIX Timestamp, Windows Filetime to UNIX Timestamp, Translate DateTime Format, Parse DateTime | Windows Filetime counts 100 nanosecond intervals since 1 January 1601 UTC; UNIX time counts seconds since 1 January 1970 UTC |
| Simple XOR | XOR, XOR Brute Force | Brute force supports keys up to 2 bytes and a crib (known plaintext) to filter results |
| File triage | Detect File Type, Extract Files, Strings, Entropy, Generate all hashes, Analyse hash | High entropy suggests compression or encryption; hash before and after for evidence notes |
| Certificates and keys | Parse X.509 certificate, Parse SSH Host Key, Parse ASN.1 hex string | Check validity dates and subject alternative names during phishing and TLS investigations |
| Quick content match | YARA Rules | Test a rule against one sample; see the YARA Rules Guide |
Parsing JWTs safely
The JWT Decode operation's own description says it decodes a token "without" checking whether the secret or key is valid, and points to JWT Verify for signature checks. JWT Verify takes the HMAC secret or a PEM encoded RSA or ECDSA public key. In practice: decode to read iss, aud, exp and alg during triage, verify only in an offline copy, and never paste a live bearer token or signing secret into a hosted instance. A captured, unexpired token is a working credential for whatever it grants. See the JWT Security Guide.
XOR in general terms
Single byte and short key XOR is a frequent light obfuscation layer in malware configuration and staged payloads. Magic's intensive mode tries all 255 single byte XOR keys and 7 bit rotations; XOR Brute Force lets you supply a crib such as http or MZ. Longer or rolling keys need a disassembler or script. See the Ghidra for Malware Analysis Guide.
How Magic decides
According to the project wiki, Magic runs regular expression signatures for operations with predictable output (Base64, hex, Gzip), executes matching operations speculatively up to the Depth argument, and scores branches by magic bytes, valid UTF-8, entropy and a chi squared comparison of byte frequency against 38 languages (245 with Extensive language support). Intensive mode adds brute forcing of more than 40 character encodings plus XOR and bit rotation. Results are likelihoods: random looking data can score well and a correct decode of binary content can score poorly.
Deployment and safe use
Hosting options
| Option | Data exposure | Best for |
|---|---|---|
| Public GCHQ instance (gchq.github.io/CyberChef) | Processing in browser per the project, but page code is served from the internet on each load and the URL can carry input | Training and non sensitive samples |
| Third party hosted copies | Unknown: the host controls the code served to you | Avoid for any work data |
| Offline download (link in the app's top left) | Runs from local files; can be hosted on a closed network | Analyst workstations, air gapped labs |
Docker image (ghcr.io) on localhost:8080 | Served from your own host | Shared internal instance for a SOC |
Build from source (Node.js v24, npm install, npm start) | Full control, can be code reviewed | Teams that patch or add operations |
| Node API | Runs inside your scripts or pipeline | Automating a proven recipe at scale |
Rollout steps for a SOC
- Pick a pinned release. Download a specific release or image tag and record its version and hash, so every analyst runs the same code.
- Host internally. Serve it from an internal web server or container behind your single sign-on, or distribute the offline copy to analyst hosts.
- Block or warn on public instances for work devices through the web proxy, with a note pointing to the internal copy.
- Build a recipe library. Save tested recipes as JSON in a version controlled repository with a description, sample input and expected output for each.
- Test upgrades. Before moving to a new release, run the library's sample inputs and compare outputs; keep the previous version available to roll back.
Data handling and sharing recipes
- URL sharing carries input: the documented deep link puts the recipe and the Base64 encoded input in the URL. A shared link to a ticket or chat channel therefore shares the sample too, and the link may persist in browser history. Share the recipe without input, or export recipe JSON.
- Local storage: saved recipes live in the browser's local storage, which is per browser and not backed up; keep the authoritative copy in the repository.
- Secrets: never paste API keys, passwords, session cookies or tokens into an instance you do not control. Where a decode reveals a credential, follow your secrets exposure process and rotate it. See the Secrets Management Guide.
- Malicious content: CyberChef transforms data but does not sandbox it. Save decoded payloads with a safe extension, keep them defanged in notes, and analyse execution in a sandbox.
- Evidence: record the recipe JSON and input hash in case notes so another analyst can reproduce the result. See the Digital Forensics (DFIR) Guide.
Detection and hardening value
CyberChef does not detect anything itself. Its value is speed and consistency in turning obfuscated data into something a detection or a decision can use.
- Feeding detections: once a recipe reveals a decoded command line or URL, write the behaviour as a Sigma rule rather than an indicator list. Sigma's
base64offsetmodifier can match encoded strings in logs directly. See the Sigma Rules Guide. - Feeding intelligence: extracted and defanged indicators go to the threat intelligence platform with context. See the Threat Intelligence Guide.
- Hardening signals: decoded PowerShell (T1059.001) or encoded command and control traffic (T1132) points to controls worth checking, such as script block logging and egress filtering.
Metrics
- Share of triage tickets with a reproducible recipe attached.
- Number of tested recipes in the library, and age since last test.
- Median time from alert to decoded payload for script based alerts.
- Number of proxy hits from work devices to public or third party CyberChef hosts (target zero for sensitive teams).
- Detections or intelligence records created from decoded content per month.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1027 Obfuscated Files or Information; T1140 Deobfuscate/Decode Files or Information | Recipes reverse the encoding layers these techniques describe |
| MITRE ATT&CK | T1132 Data Encoding; T1059.001 PowerShell | Decoding encoded C2 data and encoded PowerShell commands |
| NIST CSF 2.0 | DE.AE-02 | Analysing potentially adverse events to understand associated activity |
| NIST SP 800-53 Rev. 5 | AU-6, SI-4 | Audit record review and analysis of monitoring output |
Common failure patterns
- Pasting live secrets into a public or unknown instance because it was the first search result.
- Sharing a deep link in a chat channel and exposing the sample, including any personal data it holds.
- Trusting decoded JWT claims without verifying the signature and checking
alg. - Accepting the first Magic suggestion without checking the output makes sense.
- Wrong time base: treating milliseconds as seconds, or local time as UTC, and building a wrong incident timeline.
- Recipes living only in one analyst's browser, lost when the profile is cleared.
Alternatives
| Option | Strength | Trade-off | Choose when |
|---|---|---|---|
| CyberChef (self hosted) | Visual, fast, hundreds of operations, shareable recipes | Manual; browser memory limits on large data | Interactive triage of individual samples |
| CyberChef Node API | Same operations, scriptable | No flow control operations | Repeating a proven recipe over many items |
| Command line tools (base64, xxd, jq, Python) | Scales, auditable, scriptable | Slower to explore, more room for one off errors | Bulk processing and pipelines |
| Disassemblers and sandboxes | Handle complex or custom encryption and execution | Specialist skill and time | Custom crypto, long or rolling keys, behavioural analysis |
Small teams can run the offline copy on analyst workstations and keep a shared recipe folder. Larger SOCs should host one pinned internal instance, block public ones, and move high volume recipes into the Node API or their automation platform.
Practitioner checklist
- Host a pinned CyberChef release internally or distribute the offline copy.
- Block or warn on public and third party hosted instances for work devices.
- Ban pasting live tokens, keys and passwords into any instance you do not control.
- Keep a version controlled recipe library with sample input and expected output.
- Share recipes as JSON or links without input.
- Verify JWT signatures with JWT Verify before trusting claims.
- Normalise all timestamps to UTC and record the unit used.
- Defang indicators before they go into tickets, chat or reports.
- Attach recipe and input hash to case notes for reproducibility.
- Turn decoded behaviour into detections, not only indicator lists.
Standards and references
- GCHQ: CyberChef repository and README
- GCHQ: CyberChef web application
- GCHQ: CyberChef wiki, Magic
- GCHQ: CyberChef wiki, Flow Control
- GCHQ: CyberChef wiki, Node API
- MITRE ATT&CK: Deobfuscate/Decode Files or Information
- MITRE ATT&CK: Obfuscated Files or Information
Related NHI Mgmt Group resources: Sigma Rules Guide · YARA Rules Guide · JWT Security Guide · Incident Response Guide · SOC Guide