X Ads Delivered a Fake Mac Cleaner. I Ran It Sandboxed.

I clicked a promoted post on X for a native Mac cleaner called Nook. The landing page looked like a real product. It cloned Mole, linked the real GitHub repo, named Tw93 as the author, and then asked me to paste one command into Terminal.

I did not run that command on a daily driver. I copied it into a sandboxed macOS environment and detonated it there. Twice. The second time I prefixed sudo, which only elevated echo and did nothing useful. The sandbox terminal printed a fake App Store URL, then:

Installation failed.
This software requires additional system components that aren't available.

That line is the malware talking. It is not Gatekeeper. It is not macOS. While that text printed, the script wrote a hidden app that claimed to be Finder and launched it.

This is the write-up of what that command actually did, what landed on the sandbox disk, and what I could and could not prove after 13 minutes of command-and-control.

The lure

The ad landed on nook.pulsenotch.com with a twclid click ID. pulsenotch.com was registered 11 days earlier, 2 August 2026, through Dominet (HK). The A record pointed at 196.251.107.204 in Seychelles, netname typed internet-secuirty. PhishDestroy already had the apex on a recent-threat list with 4 VirusTotal hits.

The site is a clone of Mole, the open-source Mac cleaner by tw93. Same five tools. Same planet naming. Same docs. The official CLI install is still:

brew install mole
# or
curl -fsSL https://raw.githubusercontent.com/tw93/mole/main/install.sh | bash

Nook swapped that for a ClickFix modal (modal.js). On macOS it fetches /install-command.txt, shows the first 74 characters in the UI, and copies the full command to the clipboard. Copying it fires an X conversion pixel (tw-rcr57-rebia). The App Store URL it echoes, apps.apple.com/app/nook-install, is a 404. The fallback Nook.dmg on the same host is also a 404.

The command

Do not run this. Not on a daily driver. Not "just to see." If you research it, isolate the host first.

Decoded, the Base64 is https://update-gateway.com/j1. That domain was registered the same day I clicked the ad, 13 August 2026 at 12:18 UTC, at Trustname / Fewmoretaps OÜ. Trustname markets itself as a bulletproof registrar for "sensitive niches." ICANN sent it a breach notice in June 2026 for failing to mitigate DNS abuse.

Without the App-Origin: Nook header, Cloudflare returns 403. With the header it returned 78,727 bytes of obfuscated JavaScript, cache-control: no-store.

What the first stage is

The script is JXA, JavaScript for Automation. Statically (string decode only, no execution) it:

• Binds ObjC / $ and imports Cocoa, IOKit, and CoreFoundation
• Calls ptrace and checks for Anka, Innotek (VirtualBox), and Corellium
• Skips Belarus (BY) and Georgia (GE), a long-running Atomic Stealer / AMOS tell
• Builds a bundle whose CFBundleName is Finder
• Writes under a .config path
• Uses an ephemeral NSURLSession
• Enables Standard Additions
• Finishes with doShellScript to close the Terminal window, then exit(0)

In the sandbox the close-Terminal step did not run. The fake error printed and the prompt stayed. That looked like an abort. It was not.

What actually landed

At 11:14:57 CDT the first stage wrote:

~/Library/Application Support/com.apple.finder.framework/Finder.app

That is not Apple's Finder. Real Finder lives at /System/Library/CoreServices/Finder.app. This one:

Two seconds later, 11:14:59, that binary was running as PID 78812, parent launchd. I found it 13 minutes later. Open files showed two UDP sockets to 104.21.16.176:443 (Cloudflare) and a lock file next to the bundle. No LaunchAgent plist. No crontab. No new login item. sudo never covered the pipe, so it ran as the sandbox user, not root.

I sent SIGTERM, moved the bundle out of Application Support, and stripped the execute bit.

The sample was submitted to Jotti on 13 August 2026. First pass: 0 of 13 engines. That is what a same-day AMOS build looks like. Jotti shares submissions with antivirus vendors. The VirusTotal permalink for the same bytes is fdbdb04cbf34d642…. Guest VT upload is recaptcha-gated, so that page will fill in once an engine or another researcher indexes the hash.

The 13-minute window

mtime on a cookie database does not prove a steal. Stealers copy files. Reads usually leave mtime alone. The useful timeline is what the sandbox filesystem and process table recorded while the binary was alive.

If this had run on a logged-in daily driver, any authenticated browser session would be in play. Cookie theft does not need to rewrite those files. That is why you do not paste ad installers into a machine that holds Cloudflare, Google, or a password manager.

What I could not prove

TCC. SIP blocks the user TCC database. Unified logs for tccd over the following 50 minutes had no hits for osascript, 93633143, Accessibility, ListenEvent, ScreenCapture, or Full Disk Access. That is not a proof of "no grant." It is the absence of a prompt-and-accept trail.

Exfil. I can prove C2 was up for 13 minutes. I cannot prove a successful upload. AMOS-class tools usually grab in the first seconds, then beacon. A late open-file listing can miss the steal.

Persistence. No LaunchAgent, LaunchDaemon, or crontab appeared. After the kill, launchctl had no leftover. Reboot would not have brought this copy back. The first run is still enough to empty a real session.

Indicators

Hosts

• nook.pulsenotch.com (lure)
• pulsenotch.com (registered 2026-08-02, Dominet HK, 196.251.107.204)
• update-gateway.com (registered 2026-08-13, Trustname, Cloudflare)

Network

• 104.21.16.176:443/udp (Cloudflare, C2 while the binary ran)
• HTTP header App-Origin: Nook on /j1

On disk

• ~/Library/Application Support/com.apple.finder.framework/Finder.app
• Executable name 93633143
• SHA-256 fdbdb04cbf34d642b4cec25fb3c59a54578aa7b4b5ecc2583adb93a35c07b752
• SHA-1 cd94f2b05f88ae6ecf5a4f6df6fc423b06840635
• MD5 fd608431c05f55153fe5b933a16055f8
• Jotti job vh93ztji3s (0/13 on first scan)

Related, not the dropper

• apps.apple.com/app/nook-install (decoy 404)
• Real Mole remains mole.fit and github.com/tw93/mole

If you pasted the same command on a real Mac

1. Disconnect the Mac.
2. Check for ~/Library/Application Support/com.apple.finder.framework. If the binary is running, kill that PID, then move the folder.
3. Check ~/Library/LaunchAgents and crontab -l for anything from today.
4. From another device, rotate Cloudflare, Google, X, Apple ID, 1Password, and anything that was logged in in the browser.
5. Assume hot wallets and browser sessions are gone.
6. Do not install Mole, Nook, or any cleaner from an ad. If you want Mole, get it from mole.fit or Homebrew, not from a Terminal one-liner an ad handed you.

I am not publishing the raw second-stage binary. The hash is enough. If you research this family, treat update-gateway.com and nook.pulsenotch.com as hostile. They were both live the morning of 13 August 2026. Detonate them in a sandbox, or not at all.

The error was a lie. The process was not.