Analyzing a Multi-Stage JavaScript Dropper That Delivers a Crypto Clipper via PowerShell

What the chain actually does

What stands out in this campaign is not the clipper itself. It is the path it takes to get there.

The first stage is JavaScript. That script does not do the heavy lifting on its own. It stages the next step, then hands execution to PowerShell. PowerShell then pulls or builds shellcode, and that shellcode eventually leads to the crypto clipper payload.

That layering matters because each hop changes what defenders can see:

• JavaScript often looks like a small loader or droplet.
• PowerShell blends into admin activity unless you have good logging.
• Shellcode avoids a lot of file-based inspection because the malicious logic is no longer sitting in a neat PE on disk.

Impact: a chain like this can slip past tools that only look for suspicious executables or obvious malware hashes.

Why JavaScript was chosen for the first stage

JavaScript is a convenient first-stage loader because it is flexible, easy to obfuscate, and common in delivery paths such as archives, shortcut abuse, and social engineering. It also gives the attacker a clean bridge into native tooling without immediately dropping a traditional binary.

Initial execution path and payload staging

In a sample like this, I would expect the JavaScript to do some combination of the following:

• decode an embedded blob
• build a command string dynamically
• write a file to a temporary location
• invoke a second-stage script or command interpreter
• hide its intent behind harmless-looking variable names and string splits

A pattern I watch for is the script assembling a command piece by piece instead of spelling it out directly.

const parts = ["pow", "er", "shell"];
const cmd = parts.join("") + " -ExecutionPolicy Bypass -NoProfile ...";

// suspicious if the script then launches it dynamically

That alone is not proof of malware, but it is the kind of structure that deserves attention when paired with file drops, environment checks, or encoded payloads.

PowerShell as the bridge to shellcode

PowerShell is the bridge because it gives the attacker access to Windows-native APIs, download capability, memory manipulation, and process control. In practice, the script often uses it to fetch the next payload, decode it, or execute it in memory.

The key question is simple: does PowerShell touch a benign installer, or does it move into memory-only execution?

If the answer is shellcode, then file reputation becomes much less useful. You need process telemetry, script block logging, AMSI visibility, and memory-focused analysis.

What makes this campaign harder to spot

This is a script-heavy chain with multiple low-friction transitions. That makes it harder for defenders who still rely on a single control point.

Common detection gaps in script-heavy attacks

The gaps I see most often are:

Another problem is fragmentation. One product sees a script, another sees a child process, and neither one connects the dots.

Why shellcode changes the response playbook

Once shellcode is involved, you stop treating this as a simple “delete the file” incident.

You need to assume:

• in-memory execution may have occurred
• process injection or reflective loading may be used
• the final payload may not leave a stable executable on disk
• forensic recovery may depend on volatile telemetry

That changes containment. I would isolate the host, preserve memory if possible, collect PowerShell logs, and inspect parent-child process chains before cleaning.

How I would analyze it safely

Extracting and normalizing the JavaScript

I start by deobfuscating the JavaScript in a controlled environment. Not by running it on a workstation, and definitely not by double-clicking it.

Useful steps:

1. Extract the script from the delivery artifact.
2. Normalize whitespace and string concatenation.
3. Search for eval, Function, atob, fromCharCode, unescape, and filesystem or WMI calls.
4. Rewrite obvious decoders into standalone helper functions.

A small amount of normalization usually reveals the real command flow.

Tracing PowerShell behavior and child processes

Next, I trace the PowerShell command line and its descendants. The main things I want are:

• exact command line arguments
• encoded or hidden execution flags
• spawned child processes
• downloads, temp-file writes, and registry changes

If you have Sysmon, event ID 1 and event ID 11 are a good starting point. PowerShell operational logs help too, especially script block logging when it is enabled.

Identifying clipper behavior in the final payload

For the final payload, I look for clipboard access and transaction tampering. Crypto clippers usually monitor clipboard content for wallet-like strings and replace them with attacker-controlled addresses.

Behaviorally, that often looks like:

• clipboard polling
• regex matching on target strings
• silent replacement before paste
• persistence to keep the watcher alive

That means the visible symptom is often a failed payment or a pasted address that looks right until you compare it character by character.

Detection ideas for blue teams

YARA-style patterns for the JavaScript stage

For the JS dropper, I would not rely on one signature. I would combine multiple weak signals.

Possible patterns:

• long encoded blobs
• repeated string concatenation around process names
• suspicious use of eval, Function, or setTimeout with strings
• embedded PowerShell keywords
• file-write plus process-launch in the same script

Pseudo-rule idea:

rule JS_Dropper_Powershell_Bridge {
  strings:
    $a = "powershell"
    $b = "ExecutionPolicy"
    $c = "FromCharCode"
    $d = "eval("
  condition:
    2 of them
}

That is intentionally broad. In practice, I would tune it to your normal script inventory.

PowerShell telemetry and process-chain rules

PowerShell detections should focus on execution context, not just the presence of PowerShell itself.

Watch for:

• -EncodedCommand
• -ExecutionPolicy Bypass
• hidden windows
• unexpected parent processes such as script hosts, browsers, or archive handlers
• child processes that should not come from PowerShell in your environment

A simple rule like “JavaScript host -> PowerShell -> network access” is often more useful than a single hash.

Network and clipboard signals

The network piece may be noisy, but it still helps:

• downloads from newly seen domains
• short-lived URLs
• unusual user-agent strings
• outbound requests shortly before clipboard activity spikes

For clipboard monitoring, alert on repeated clipboard reads or writes by a process that should not be handling transaction text. That is especially useful on endpoints used for payments or treasury work.

Defensive controls that matter here

Script control, logging, and application allowlisting

The strongest improvement is boring and effective:

• enable PowerShell script block logging
• keep module logging where feasible
• use application allowlisting for script hosts where practical
• block or constrain unsigned scripts from common delivery locations
• enforce Constrained Language Mode where it fits your environment

If your environment still allows arbitrary scripts from user-writable folders, you are giving this chain a place to start.

Endpoint and email/file delivery hardening

The front door matters too:

• detonate attachments in a sandbox
• restrict script-capable attachment types
• block risky archive execution paths
• train users not to trust “invoice” or “document” files that launch script hosts
• monitor for archive-to-script-to-PowerShell chains

The backend defense is not just detection. It is preventing the first stage from ever becoming executable in the first place.

Conclusion

This campaign works because it is modular. JavaScript provides flexibility, PowerShell provides reach, and shellcode reduces visibility. Each stage is ordinary enough to slip through a weak control, but together they create a chain that is much harder to inspect after the fact.

If you are defending against this class of attack, focus on the chain, not the single artifact. Track the script, the process tree, the memory behavior, and the clipboard impact as one incident. That is where the real signal is.