Reading JavaScript written not to be read

Cisco Talos has published a practitioner's account of pulling apart obfuscated JavaScript — the kind that arrives in phishing kits, malware loaders and compromised sites, and occasionally in legitimate software protection that has wandered into looking identical to all three.

The framing is useful because it is not about a specific family. Obfuscated JavaScript is still code, but code with the context stripped out: names ruined, strings hidden, URLs encoded, and the real behaviour deferred to runtime through decoders and eval. Opening the file and reading it, the default first move, stops working at that point.

Before any of the technique, the post spends its first section on handling. Assume the sample is hostile. Work on a copy and preserve the original. Do not run unknown JavaScript on a normal machine, in a normal browser profile, or anywhere that credentials, clipboard contents, SSH agents, npm tokens or corporate proxy details are within reach.

That caution is extended explicitly to AI tooling, and this is the part worth quoting to a team. The workflow described leans on AI assistance throughout, but the author is direct that such tools are neither a sandbox nor an evidence source on their own. They are for isolated snippets, decoded artefacts and recovered payloads that you are comfortable handing to whoever operates the tool. The goal is not to avoid AI in analysis; it is to avoid feeding hostile or sensitive material into infrastructure you do not control.

The analytical questions the post recommends are deliberately unglamorous — what does the sample read, what does it write, where does it connect — and that is why they survive contact with obfuscation. A decoder can rename every function and encode every string, but it cannot hide the fact that something eventually has to open a socket.