Case file · anonymized · Malware · PowerShell · DFIR
JustAskJacky deobfuscated: what a tech-support scam looks like once you peel the wrapper off.
A live PowerShell deobfuscation of the JustAskJacky tech-support scam family, including two tradecraft choices most public writeups miss.
2026-07-06 · 7 min read · worked by the principal
CrowdStrike Falcon flagged "JustAskJacky" on a customer endpoint yesterday — a tech-support scam family I'd heard about but never analyzed live. The obfuscated PowerShell second stage is meaningfully cleverer than the public writeups admit.
Two design choices inside it are worth sitting with if you're hunting this family.
What JustAskJacky actually is
JustAskJacky is one brand in a rotating family — Betty, Bobby, Gilbert, Jacky — that masquerades as a helpful "AI helper" app. Recipe assistant. Image-search tool. Product-manual viewer. Distribution is paid social plus SEO-poisoned landing pages: Facebook ad, redirect through a legitimate-looking shim, installer prompt, done.
The installer drops a bundled Node.js runtime, an obfuscated JavaScript loader, and a PowerShell stager. End state is a cryptominer plus a recon-and-arbitrary-command-execution beacon talking to attacker-controlled C2.
Two users on separate hosts hit it within twenty minutes of each other. Same paid-social ad campaign, two clicks. Falcon caught it pre-execution on both endpoints. The alert preserved the full obfuscated second stage — which is what made the deeper analysis possible. EDR-blocked-and-preserved is a better forensic state than EDR-blocked-and-overwritten.
The deobfuscation
The script is 4,053 characters of y(7) + y(11) + y(15) indirection wrapping a fully functional Cobalt-Strike-flavor beacon.
Every literal — type names, the User-Agent, the cookie name, every method invocation — is built at runtime from a six-string lookup table split on the ! character, column-indexed. Decoding indices 0 through 28 produces the 29 hidden literals the beacon needs: COM object names, gzip class names, the assembly strong-name token, the User-Agent fragments, the C2 cookie prefix.
Classic obfuscator output. Gets past static scanners. Folds in about thirty minutes with a debugger.
Two design choices stand out.
1. The Invoke-Expression alias trick
The script never contains the literal string iex or Invoke-Expression anywhere on disk.
It dynamically builds the string from the fourth character of the current process name:
$cmd = "i" + ([System.Diagnostics.Process]::GetCurrentProcess().ProcessName[3]) + "X"
# For powershell.exe, character [3] is 'e' → "ieX" → case-insensitive iex
Set-Alias -Name $cmd -Value Invoke-Expression
& $cmd $payload
Static signatures grepping for Invoke-Expression or iex miss this command-execution path entirely. Sigma rules looking for the literal alias creation also miss it because the alias name itself is computed.
2. The cookie-name-as-protocol-delimiter trick
The beacon ships five cookies on every HTTP GET. All five share a 10-character prefix.
The server's reply, in the response body, is bracketed by that same prefix used as a delimiter:
RESPONSE BODY:
<noise>aBCdEf1234<actual powershell payload>aBCdEf1234<noise>
Split the response on the prefix, take the middle chunk, pipe to the alias from trick #1. Run.
The entire C2 channel is HTTP cookies and looks like benign web traffic. IDS rules that catch the weird cookie name on the REQUEST won't inspect the response BODY for the same string — which is where the actual command lives.
Above-average tradecraft for keeping the protocol noise floor low.
What the host recon actually collects
Inside those five cookies, every twenty seconds, the script ships:
- Username
- Computer name
- Domain
- Full operating-system caption
- Every environment variable under 100 characters
- Every running process name
- Every visible window title — titles routinely contain credentials and reset codes pasted into Notepad
- Recent Documents list from the Shell namespace
- Full drive enumeration with byte-level utilization
About 5KB of full host fingerprint per beacon. Beacons fire every 20 seconds. Roughly 4,300 beacons per day per victim.
The window-title field is the one to flag — it's the highest-value collection target in the whole stage and the cheapest signal to alert on: any process making HTTP requests with cookies containing window-title strings is anomalous.
Ten compromised legitimate sites as dead-drops
The beacon rotates over a fixed list of ten URLs, randomly choosing one per beacon. All ten appear to be compromised legitimate WordPress installs serving an attacker PHP endpoint at the site root.
The flavor of the list says a lot about modern initial-access economics:
- A Polish beekeeping supply shop
- A Singapore law firm
- A French web-publishing site
- A Turkish regional news site
- An Australian brewing-supply retailer
- A US wildlife-conservation nonprofit
- A US food blog
- A Russian publishing site
- Plus two small-business sites in the same shape
You cannot reliably block these domains without breaking legitimate use. The wildlife-conservation nonprofit is real. The food blog is real. Ordinary small businesses get compromised and reused as malware distribution, and the dead-drop list rotates faster than any blocklist can keep up with.
This is exactly why behavioral detection — the 20-second cookie-shaped beacon pattern, the AutoResetEvent-plus-WaitOne combination in PowerShell ScriptBlock logs — outperforms domain blocklists for this category of threat.
What this means for IR shops and CIOs
Three things, in order of how often security leaders underweight them.
Behavioral endpoint prevention is doing real work. Falcon caught this pre-execution, at the cmd.exe-to-node.exe transition, before the PowerShell ever ran. No amount of user-awareness training would have caught it — the lure is sophisticated enough that experienced professionals click. Endpoint behavioral prevention is not optional in 2026 and is not interchangeable with signature AV or with network-only controls.
BYOD and off-network exposure is the modern initial-access vector. Both users in this incident were on personal cellular hotspots when they clicked the scam ad. Corporate proxy didn't apply. DNS filtering didn't apply. "Require compliant device" doesn't catch this scenario — the device is compliant, and the malicious traffic is happening on a network the corporate stack can't see. The control that worked was at the endpoint, after the social engineering had already succeeded.
Speed of forensics is where MSP and MSSP value compounds. Time from alert to publishable deobfuscation on this incident was about ninety minutes. The difference between sending a customer a one-line "Falcon caught it" status at end of day and sending them a full campaign analysis — what it was, who else might be hit, what to block, what to hunt for retroactively — is the operator workflow behind the alert, not the EDR.
Obfuscation that survives a virus scanner but folds in thirty minutes of analyst time is the entire intent. The attacker is buying delivery, not security. The wrapper is just thick enough to get past the AV gate on the way in.
What you can hunt for
Three queries that surface this family in your own environment.
-
PowerShell ScriptBlock logs — alert on any block containing
AutoResetEventandWaitOneand an HTTP cookie set with 5+ cookies sharing a prefix. -
Process telemetry —
cmd.exe->node.exe->powershell.exechain originating from a user's Downloads or Temp folder. This is the exact installer footprint. -
Network telemetry — outbound HTTP GETs with cookie headers totaling >2KB, 20-second cadence, to WordPress-shaped domains the user has never visited before.
If you run an EDR and want this signature added to your hunt library — or you want the full string-table decode + the YARA / Sigma / KQL / Splunk SPL / Suricata rules — DM me.
Anonymized per our marketing policy. The customer name, geography, and exact host details are generalized; the 4,053-character figure, the 20-second beacon cadence, and the 5KB-per-beacon fingerprint are real.
Seeing this pattern in your tenant? The person who worked this case answers the email. Originally published on the Envyously blog.