Safely Deobfuscate and Explain a Suspicious Script

Tier: Core · Workflow area: Incident response, DFIR & CTI

This playbook does that safely: static analysis and explanation only, never execution, with every claimed behavior verified against the actual code.

When to reach for this

• •
  You have a captured suspicious script or command line (from an alert, email, or artifact) and need to know what it does.
• •
  The sample is obfuscated (encoding, concatenation, aliasing) and manual decoding is slow.
• •
  You need an explanation you can put in a case note and act on.

This is static analysis of a captured sample only. Never use AI (or anything else) to run the sample outside a proper isolated sandbox — and never point offensive tooling at systems you do not own.

The workflow

1. 1.

   Handle the sample as inert evidence. Keep the script in a text file inside your analysis environment. You are reading it, not executing it. Treat it like a hazardous artifact — no double-clicks, no "just to see."

2. 2.

   Ask for layer-by-layer deobfuscation with explanation.

   Copy

   This is a captured suspicious script (sample, for DEFENSIVE static analysis
   only — do not execute anything, do not help me run it). Deobfuscate it:
   - Decode each obfuscation layer (base64, concatenation, char codes) and show
     the deobfuscated result at each layer.
   - Explain what the final script does, line by line.
   - List every observable it would produce: network destinations, files
     written, registry keys, processes spawned, persistence.
   - Map the behaviors to MITRE ATT&CK techniques where clear.
   Quote the exact code line behind each claimed behavior. If a section is
   ambiguous, say so — do not guess at intent.
   
   <<<SCRIPT>>>
   

   Expected output: the decoded script at each layer, a line-by-line explanation, an observables list (IOCs/behaviors), and ATT&CK mappings — each behavior tied to the code line that produces it.

3. 3.

   Verify the decode independently. Decode at least the outer layer yourself (base64 -d, a CyberChef recipe) and confirm it matches the model's claimed layer-1 output. If the model's decode diverges from a deterministic tool, trust the tool.

4. 4.

   Confirm each claimed behavior against the code. For every "downloads from evil.example" or "writes to Startup," find the exact line that does it. A behavior with no corresponding line is the model inferring intent — flag it, do not report it as fact.

5. 5.

   Extract observables into your IOC workflow. The network destinations, file paths, and hashes become detection and blocking inputs — after you have confirmed each against the code (hand off to pb-12 for STIX).

Verify before you trust it

• Deterministic decode check: re-decode the outer obfuscation layer with a real tool (base64/CyberChef) and compare. Models occasionally "helpfully" clean up or paraphrase the decoded output — the tool's byte-exact result wins.
• Code-to-behavior check: every claimed behavior must map to a specific line. If the model says the script exfiltrates data but no line opens a network connection, the claim is invented intent — reject it.
• False-positive catch: watch for benign scripts flagged as malicious. Obfuscation is used by legitimate installers and packers too; confirm the behavior is actually hostile before you escalate, rather than trusting "looks obfuscated, must be malware."

Pitfalls

• Hallucinated behaviors. Models pattern-match to "typical malware" and report exfiltration or persistence that this specific sample does not do. The line-by-line grounding is the only defense.
• Paraphrased decodes. An LLM may "tidy" the deobfuscated code, subtly changing a URL or variable. Always cross-check the decode with a deterministic tool.
• Any temptation to execute. The fastest way to understand a script is not to run it. Static analysis stays static; dynamic analysis belongs in a purpose-built sandbox, never on your workstation.
• Over-trusting ATT&CK mappings. The model may map a benign operation to a scary technique. Verify the mapping against the actual code behavior.

Tools

• Isolated analysis environment + local LLM (Ollama): deobfuscate and explain the captured sample fully offline, with no risk of the sample or its indicators leaving the box.
• DFIR/decode toolkit (CyberChef, base64, PowerShell AMSI logs): the deterministic decoders you check the model's layer output against.
• MITRE ATT&CK Navigator: verify the technique mappings for the confirmed behaviors.

Client-safe variant

A captured malicious sample from a client's environment may embed client identifiers (internal URLs, usernames, paths) in the payload, so analyze it inside the client boundary. Use a local Ollama model in an isolated environment; do not paste the sample into a public AI tool, both for confidentiality and because the sample is hostile code. Where feasible, redact embedded client-specific strings before prompting, keeping the structural code intact so the deobfuscation logic still works. Confirmed observables and the behavior explanation go into the client's case system and IOC feeds; the sample itself stays contained, and any decision to detonate it dynamically happens only in the client's sanctioned malware sandbox.