macOS ClickFix Stealer: A PCAP Walkthrough

The lure: ClickFix from a fake Claude page

ClickFix is the delivery technique, not the malware. A fake page tells the victim to “fix” a problem — a broken install, a CAPTCHA, a missing dependency — by running a command the page has conveniently copied to their clipboard. On macOS that command is almost always a curl … | bash one-liner that pulls a second stage. The clever part and the weak part are the same: the victim runs it themselves, so there is no exploit and no download-time dropper to catch — but every step after that touches the network.

That framing matters for packet work. The capture will not show you the ad or the clipboard; it shows you what the installed stealer does next. macOS stealers of the AMOS/Atomic lineage that these campaigns deliver do a predictable set of things: read the Keychain, browser cookies and logins, crypto-wallet files and Notes, archive the loot, POST the archive to a collection server, and run a separate channel that beacons for tasking. The last two are loud on the wire. Let us find them.

What is in the capture

One host does effectively everything: 10.5.11.101, an Apple device (MAC 1c:f6:4c:57:46:99), with no DHCP hostname, sitting behind a Netgear SOHO gateway at 10.5.11.1. It accounts for about 18.8 MB of the roughly 18.9 MB total — the rest of the LAN is background noise. 92% of packets are TCP, and 80% of external bytes leave for the United States with a smaller slice to the Netherlands.

PcapAI lays the three findings on one timeline, and that is the first thing worth looking at: a short exfiltration burst near the start, a long C2 channel running across the whole capture, and a late blip of “discovery.”

PcapAI’s correlated timeline: persistent C2 (orange) plus a concentrated data-theft window (red) early in the capture.

The shape already tells the story — persistent control plus one concentrated theft window. Now the evidence for each.

Sign 1 — C2 beaconing over plain HTTP (T1071.001)

The host sends 20 requests to 94.232.249.129 (Netherlands, Psb Hosting, AS214927) at a near-constant ~54-second interval, over HTTP on port 80. Three things make this unambiguous beaconing rather than ordinary traffic:

The smoking gun, straight from the report: a single curl/8.7.1 client, an /api/tasks control plane, and 67% of bytes sent in the clear.

None of it is encrypted. 67% of captured bytes (12 MB) are plaintext HTTP; only 33% is TLS. For the analyst that is a gift — request and response bodies are right there in the capture — and for the victim it is a second exposure stacked on top of the theft.

Sign 2 — 11 MB of HTTP exfiltration in 10-second bursts (T1020)

The C2 channel is small and slow. The exfiltration is the opposite. The same host uploads 11.58 MB to a different IP — 165.245.215.18 (US) — in four sessions spaced about 10 seconds apart, again over plain HTTP/80. The traffic-volume graph spikes hard here: a peak of ~448 KB/s at T+230s, with the burst window packed into the first minutes of the capture (T+140s–T+240s).

Two tells separate exfiltration from an ordinary upload:

• Direction. The byte ratio is overwhelmingly outbound — the host pushes a large body up and gets tiny acknowledgements back. A software update or a cloud backup has the same shape, so direction alone is not proof — but paired with the destination it is.
• The destination. 165.245.215.18 has no DNS name in the capture, no CDN, no prior session reputation — the host simply starts shipping megabytes to a raw IP over HTTP. That is the archived Keychain, browser, and wallet loot leaving the machine. The 10-second spacing is the malware chunking the upload, not a person clicking “send.”

This is why the capture is dominated by one host: the exfiltration alone is roughly 60% of all bytes on the wire. Everything else — Apple Push, iCloud, a little Google — is the normal macOS background hum the device kept making while it was being robbed.

Sign 3 — read the noisy findings honestly (T1018 / NXDOMAIN)

Automated analysis earns trust by being right about the ambiguous parts, so here is the honest read on the third finding. PcapAI flagged T1018 Remote System Discovery from 10 DNS PTR (reverse-lookup) queries, plus a high 36% NXDOMAIN ratio. Both are real observations. Neither is a slam dunk.

The PTR queries are for names like db._dns-sd._udp.0.11.5.10.in-addr.arpa and …mshome.net. That is DNS-SD / mDNS — Bonjour service discovery — which macOS runs on its own to find printers, AirPlay targets, and file shares. On a quiet SOHO segment it produces exactly this kind of low-volume PTR traffic and exactly these NXDOMAIN failures. So while “the host is enumerating the local network” is technically true, on an Apple endpoint it is indistinguishable from stock OS behavior. I would not escalate on T1018 here by itself.

The 36% NXDOMAIN rate is the same story: it clears the “investigate” threshold (>20%) and could be a DGA — malware cycling through generated domains to find a live C2 — but in this capture most of the failures are the mDNS lookups above. The lesson is not that the tool is wrong; it is that a finding is a pointer to evidence, not a verdict. The C2 and exfiltration findings hold up under that scrutiny. This one resolves to macOS being macOS — and saying so is what makes the other two findings worth trusting.

The verdict

Stacked together, the capture is an open-and-shut compromise: a persistent HTTP C2 channel (T1071.001) and active, automated data theft (T1020) from one endpoint, with the discovery noise as background. PcapAI scores it Security Risk 65/100, Shadow-IT 75/100, and the overall posture CRITICAL — and, more useful than the numbers, it correlates the findings into a chain: the C2 channel is what is driving the exfiltration, not two unrelated events.

Executive risk dashboard and MITRE ATT&CK detections for 10.5.11.101 — C2 and exfiltration to two separate servers, correlated into one kill chain.

The remediation writes itself, and the report spells it out: isolate 10.5.11.101 now, add egress blocks for 94.232.249.129 and 165.245.215.18, then image the host for the dropper and assume every credential on it is burned. Those 10-second exfil bursts mean you treat the Keychain and browser logins as already gone — rotate them, do not wait.

Indicators of compromise

From this public sample — treat as historical, since infrastructure rotates quickly:

Catch it in your own captures

You do not need this exact infrastructure to catch the next one. The behaviors generalize, and each is a one-line hunt:

• curl / wget / python User-Agents to external IPs. Legitimate desktop apps rarely use them. http.user_agent contains "curl" surfaces this whole class in one filter.
• Fixed-interval requests to a bare IP. Group by source/destination and look at the time deltas; a tight cluster around a constant (54s here) is a beacon, whatever the port or protocol.
• Plain HTTP carrying megabytes outbound to an IP with no DNS name. Updates and backups have names and reputations; loot servers usually do not.
• One host that is ~100% of your external bytes. In a compromised-endpoint capture, the victim stands out on volume alone.

Doing this by hand on every capture is the job. Doing it in under five minutes on every capture is the point of automating it — PcapAI runs these checks and 40+ others, maps each hit to its MITRE ATT&CK technique, and hands back a PDF you can attach to the ticket.