How to using magic byte validation in a security operations workflow
- Step 1Acquire the file without detonating it — Pull the attachment from the quarantine, the email gateway, or the alert and save it to a staging folder. Do not double-click — your OS would still execute a disguised
.exe. The validator inspects bytes; it does not protect you from launching the file yourself. - Step 2Open the validator on your triage host — On the Free tier everything runs client-side, so this is safe on an air-gapped or BYOD machine with no tooling. Confirm in DevTools → Network that no request fires during processing if your policy requires proof of no-exfil.
- Step 3Drop the single file in — One file per run (
acceptsMultiple: false). The bytes are read into browser memory and passed to file-type'sfileTypeFromBuffer— header signature only, no full parse, no execution. - Step 4Read the verdict —
detectedExt/detectedMimeis what the bytes actually are;claimedExtis what the name claims.threatDetected: truemeans they disagree and a type was detected. 'unknown' (detected null) means no signature matched — not auto-flagged. - Step 5Triage by result — Document extension hiding
exe/elf→ high priority, sandbox.zipunder an Office extension → benign by design, verify inner archive. 'unknown' on a text file → expected. Match → consistent type, no further type concern. - Step 6Document and escalate — Copy the JSON into the incident ticket as the file-type-triage line. Capture hashes with multi-hash-fingerprinter for IOC lists, then send genuine mismatches to the sandbox for behavioural analysis.
SOC triage decision table
Map each validator result to a triage priority and next action. 'Document-ext' means an extension like docx/pdf/xlsx that should never be an executable.
| Result | Signal | Priority | Next action |
|---|---|---|---|
Document-ext detects as exe/elf | threatDetected:true | High | Sandbox detonate; capture hashes as IOCs |
Image/audio detects as exe | threatDetected:true | High | Sandbox; likely staged dropper |
.docx/.xlsx/.pptx detects as zip | threatDetected:true | Low | Expected (OOXML is ZIP); verify inner archive |
| Extension and bytes agree | matches:true | Routine | Type consistent; continue normal workflow |
| Text/CSV/JSON returns 'unknown' | threatDetected:false | Low | Expected for signature-less formats |
| High entropy + unknown type | see entropy-analyzer | Medium | Possible packed/encrypted payload; sandbox |
Triage tool chain for a suspicious file
Where magic-byte validation fits in the broader browser-side IR toolkit. All run client-side; none execute the file.
| Step | Tool | Answers |
|---|---|---|
| 1. Type triage | magic-byte-validator | Is the file the type it claims? |
| 2. Byte inspection | hex-header-inspector | What do the first 256B–8KB look like? |
| 3. Entropy check | entropy-analyzer | Is it packed/encrypted (high entropy)? |
| 4. IOC capture | multi-hash-fingerprinter | MD5/SHA-1/SHA-256/SHA-512 for IOC lists |
| 5. Change watch | file-integrity-monitor | Did a known-good file change? |
Cookbook
Triage scenarios analysts hit on a real shift, with the validator output and the ticket line it produces.
Phishing attachment: invoice.pdf is a PE
A finance user reports a slow 'invoice'. The attachment is INV-4471.pdf. The validator reads MZ — it's a Windows executable wearing a PDF name. High-priority escalation.
File: INV-4471.pdf
Header: 4D 5A 90 00 ...
Validator:
{ "detectedExt":"exe", "detectedMime":"application/x-msdownload",
"claimedExt":"pdf", "matches":false, "threatDetected":true }
Ticket line:
Magic-byte triage: claimed .pdf, detected exe (PE/MZ).
Content/extension MISMATCH. Escalated to sandbox.Double-extension lure from a mail thread
A reply-chain attachment named scan_001.jpg.exe. Windows hides the trailing .exe. The validator confirms exe and the double-extension pattern is the obvious lure.
File: scan_001.jpg.exe
Header: 4D 5A ...
Validator:
{ "detectedExt":"exe", "claimedExt":"exe",
"matches":true, "threatDetected":false }
Ticket line:
Double-extension (jpg.exe) + PE header. Lure confirmed.
Note: matches=true because claimedExt is the last segment
(exe); the disguise is the .jpg decoration + executable.Benign Office doc — don't over-escalate
A .docx flags as zip. A junior analyst could mis-escalate; the table tells them it's expected. Verify the inner archive and close as benign.
File: meeting_notes.docx
Header: 50 4B 03 04 ...
Validator:
{ "detectedExt":"zip", "claimedExt":"docx",
"matches":false, "threatDetected":true }
Ticket line:
zip/docx mismatch is EXPECTED (OOXML = ZIP container).
Verified inner [Content_Types].xml present. Benign.Air-gapped triage with no tooling
An analyst on an isolated forensic host with no internet and no software-install rights needs a quick type check on a USB-recovered file. The browser tool works fully offline (Free tier, client-side).
Environment: air-gapped forensic VM, no installs allowed
File: recovered_blob (no extension)
Header: 7F 45 4C 46 ...
Validator:
{ "detectedExt":"elf", "detectedMime":"application/x-elf",
"claimedExt":"recovered_blob", "matches":false,
"threatDetected":true }
Ticket line: ELF binary recovered from USB. Sandbox queued.Unknown blob — entropy hand-off
A quarantined file detects as 'unknown'. Not auto-flagged, but the analyst chains to entropy-analyzer; high entropy across the file suggests a packed/encrypted payload worth detonating.
File: update.bin
Header: 1F 8B 08 ... then random-looking
Validator: { "detectedExt":"gz", "claimedExt":"bin",
matches:false, threatDetected:true }
→ gz container. Decompress in sandbox, re-validate inner file.
If validator returned unknown instead, run entropy-analyzer
to decide whether it's packed/encrypted.Edge cases and what actually happens
Analyst double-clicks the staged file
Operator riskThe validator never executes the file, but your OS will if you launch it. The most common IR mistake is opening the attachment to 'check' it. Always inspect by dropping into the tool, never by opening.
Forged header passes as benign
LimitationA skilled actor can prepend a valid %PDF/PK header so the validator reports a clean match. Magic-byte triage defeats lazy renaming, not deliberate forgery — never close a case on a clean type check alone; sandbox anything with other suspicious indicators.
OOXML / archive false positive
By design.docx/.xlsx/.pptx always detect as zip (threatDetected:true). Don't over-escalate; this is expected. Verify the inner archive structure to distinguish a real Office file from a ZIP renamed to a document extension.
Unknown is not 'safe'
LimitationText, custom, or encrypted formats return 'unknown' with threatDetected:false. That means no signature matched, NOT that the file is harmless. For unknown blobs from a suspect source, chain to entropy-analyzer and sandbox.
Polyglot / appended payload
PartialDetection reads offset-0 only, so a polyglot reports its first format and a payload appended after a valid header is invisible to type detection. Flag any size/structure anomaly for full sandbox triage.
No behavioural analysis
LimitationThis is a type-triage tool, not a sandbox. It tells you what a file IS, not what it DOES. A correctly-typed file (e.g. a real macro-laden .docm) can still be malicious. Use it to prioritise, then detonate.
File over tier size limit
413 over limitFree triage caps at 10 MB; larger samples need Pro (100 MB) or above, else fileToBuffer throws an over-limit error. For oversized disk images or containers, carve out a header sample first.
File with no extension
ExpectedRecovered/forensic files often have no extension. claimedExt becomes the whole name and any detected type reads as a mismatch — but detectedExt is still accurate, which is exactly what you want for nameless artifacts. Judge by detectedExt.
Multiple attachments at once
Single-fileThe validator is single-file. For a batch of quarantined attachments, run them one at a time or script the server-safe API path. Record each verdict separately in the ticket.
Frequently asked questions
Is it safe to put a suspected-malware file into this tool?
Yes, with the standard caveat. On the Free tier the file's bytes are read in browser memory and inspected by file-type — never executed, never uploaded. The danger in IR is launching the file with your OS, which this tool never does. Save it without opening, then drop it in.
Does it work on an air-gapped or offline host?
Yes. On the Free tier everything runs client-side with no server round-trip, so once the page is loaded it works offline. That makes it usable on quarantine networks, air-gapped forensic VMs, and locked-down BYOD laptops where you can't install agents.
How do I prove to my team that nothing was uploaded?
Open Chrome DevTools → Network before processing. On the Free tier no request fires while the validator reads the file. The bytes stay in browser memory. (Paid tiers can opt into the local @jadapps/runner, which also keeps processing on your machine.)
What's the highest-value mismatch to escalate?
A document or media extension (.pdf, .docx, .xlsx, .jpg) that detects as exe or elf. That's an executable wearing a benign mask — the classic dropper pattern. Sandbox it and capture hashes. The benign exception is OOXML detecting as zip.
Does it detect every PE/ELF malware sample?
It reliably identifies the file TYPE (PE via MZ, ELF via 7F ELF) with high accuracy. It does not assess behaviour — a correctly-identified executable could be benign and a clean type check doesn't clear a file. Confirm intent in a sandbox after type triage.
Can it catch polyglot files?
Only partially. It detects by the offset-0 signature, so a polyglot or a file with a payload appended after a valid header reports the first format. Treat structural anomalies as sandbox candidates rather than relying on the type verdict alone.
What does 'unknown' mean during triage?
No signature matched — the file is text-like (CSV/TXT/JSON), encrypted/packed (random bytes), or outside the 155-format set. It is NOT auto-flagged as a threat, but for a suspect source 'unknown' is not 'safe' — chain to entropy-analyzer and consider sandboxing.
How does this fit a full incident-response workflow?
Use it as step one: confirm type cheaply before spending a sandbox slot. Then hash with multi-hash-fingerprinter for IOCs, inspect bytes with hex-header-inspector, check packing with entropy-analyzer, and detonate genuine mismatches.
Can I batch-triage many attachments?
The UI is single-file. For a queue of quarantined files, run them individually or automate the server-safe API path (Developer tier) and record each detectedExt/threatDetected in the ticket. The server build needs the filename passed via the filename option to compute the claimed extension.
Will it tell me whether a macro-enabled doc is malicious?
No. It identifies the container type (a .docm still detects as zip, since OOXML is a ZIP). It can't see VBA macros or behaviour. For document threats, confirm the container is real OOXML, then send to a sandbox or document-analysis tooling.
What size of file can I triage on the free tier?
Up to 10 MB on Free — ample for nearly all attachment triage. Pro raises it to 100 MB, Pro-media 500 MB, Developer 2 GB. Only the header is needed, but the buffer is read subject to your tier cap, so carve a sample from oversized images.
Is the result suitable to paste into a ticket?
Yes — the output is compact JSON (detectedExt, detectedMime, claimedExt, matches, threatDetected). Copy it as the file-type-triage line of your incident record, alongside the hashes from multi-hash-fingerprinter, before escalating.
Privacy first
Every JAD Security operation runs entirely in your browser. Files, passwords, and PGP private keys never leave your device — verified by zero outbound network requests during processing.