JavaScript obfuscation: From party trick to phishing kit

This article from Cisco Talos explores the techniques used to obfuscate JavaScript code, primarily for malicious purposes like phishing and malware delivery. The author details various methods of hiding code, including string manipulation, identifier renaming, runtime decoding, and control-flow flattening. The article emphasizes that obfuscation is not just about making code unreadable; it's a deliberate effort to mislead analysts and prevent reverse engineering.

Over the last few years, I’ve spent a fair amount of time pulling apart suspicious JavaScript from phishing kits, malware packages, compromised sites, and other places where the readable source has been deliberately buried. I might not be a world-class JavaScript reverser, but I’ve learned enough useful tricks to make the mess explain itself.

Before touching the weird code, assume it is hostile. Work on a copy, preserve the original, and do not run unknown JavaScript on your normal machine, in your normal browser profile, or anywhere useful credentials, clipboard contents, SSH agents, npm tokens, cloud credentials, or corporate proxy details are available. That includes AI-assisted analysis. AI tools are useful here, and this whole workflow leans on them, but they are not a sandbox and they are not an evidence source by themselves. Use them on isolated snippets, decoded artifacts, and recovered payloads you are comfortable sharing with the tool in front of you. The goal is not to avoid AI; it is to avoid feeding hostile or sensitive material into places you do not control.

The useful questions are boring, which is why they work: What does it read? What does it write? Where does it connect? What code does it generate? What conditions change its behavior? What happens to a real user, developer, or build runner?

What counts as obfuscation? Let’s make some important definitions: Minification reduces raw code size by shortening identifiers and removing whitespace. Packing compresses or encodes code and reconstructs it at runtime. Encoding hides strings or payloads until decoded; encryption does the same with a key involved. Anti-analysis tries to punish, detect, or mislead the analyst and their tools. Obfuscation is an overall term for when code is transformed to preserve execution while obscuring intent.

Not all obfuscation is malicious, but it can be a reason to look more closely. Examples of benign uses include performance bundling/minification, IP protection and anti-tamper controls. Examples of suspicious uses are: hiding phishing credential exfiltration, malware loaders, browser extension abuse, npm package install scripts, compromised website injections, fake CAPTCHA and update flows.

Beautifying code is useful, but it is not deobfuscation. Tools like Biome or Prettier can restore indentation line breaks and basic readability, so they are usually a sensible first step. What they cannot do is restore original variable names, recover intent, rebuild removed structure, decode runtime strings, or turn a dispatcher loop back into normal logic. Beautifying makes the code easier to look at. It does not necessarily make it easier to understand.

Minification and packing take identifiers like myVeryImportantBusinessFunction and renames them to m. Packing goes further: Compress or encode the real code, then reconstruct and execute it at runtime. eval() does not care whether the input started life as readable JavaScript, Base64, gzip output, or a custom string table.

The usual move is to find the unpacking step and capture what comes out. Do not spend too long admiring the wrapper. Replace the execution sink, log the payload, decode the next layer, and keep going. Most obfuscated JavaScript is not one grand technique. It is a collection of smaller tricks stacked together until the useful behavior disappears under ceremony.

I normally group the tricks into a few buckets: hiding strings and identifiers, hiding which APIs are being called, generating code at runtime, making the control flow hostile, detecting or punishing analysis, adding noise without changing behavior. Static hiding makes the code harder to understand before it runs, usually by disguising strings, identifiers, API names, or structure so simple reading and searching become less useful. String hiding and encoding: If strings are hidden, the author probably cares about what simple scanning would find. This is especially useful when they need to include things like URLs, authentication tokens, common functions, or other interesting indicators. All these lines evaluate into the string