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 its three findings on one timeline, and that is the first thing worth looking at: a short upload window near the start, a polling channel running for 17 minutes after it, and a late low-severity indicator for Apple’s push service.

PcapAI’s finding windows: one concentrated upload window early in the capture (F01), the polling channel that follows it (F02), and a late low-severity indicator (F03).

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 21 requests to 94.232.249.129 (Netherlands, Psb Hosting, AS214927) over HTTP on port 80, 19 of them the same GET at a near-constant 56-second interval. Three things make this unambiguous beaconing rather than ordinary traffic:

The smoking gun, straight from the report: one curl/8.7.1 client polling the same /api/tasks path on a bare IP, raised as a High-severity C2 threat (T1071.001).

None of it is encrypted. Cleartext HTTP carries 66.6% of the captured bytes, about 12 MB; TLS and QUIC carry most of the rest. 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 (T1048.003)

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). PcapAI reports the file uploads as finding F01 — three requests carrying a ZIP archive, 11.0 MB in total, sent by a script to a bare IP — a High-severity threat mapped to T1048.003, because this server is not the one the malware polls.

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 signals honestly (port 5223, DNS-SD, NXDOMAIN)

Automated analysis earns trust by being right about the ambiguous parts, so here is the honest read on the third finding. PcapAI raises one Low-severity indicator: TLS on port 5223 to 17.57.144.89 and 17.57.144.92. Both answer as courier.push.apple.com — Apple’s push notification service, which every Mac keeps open. The report files it as an indicator, not a threat, and that is the right weight.

The capture also holds 10 DNS PTR (reverse-lookup) queries 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” looks like T1018 Remote System Discovery, on an Apple endpoint it is indistinguishable from stock OS behavior. The report raises no finding for it, and I would not escalate on it either.

The 36% NXDOMAIN rate is the same story: it clears a common “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, and PcapAI’s DGA check, which counts distinct generated-looking names under one domain, stays quiet. A finding is a pointer to evidence, not a verdict. The C2 and exfiltration findings hold up under that scrutiny; the noise around them 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 data theft (T1048.003) from one endpoint, with the Apple background traffic as noise. PcapAI scores the overall risk 83/100, Severe, from two High-severity threats — and, more useful than the number, it puts them in one incident: the polling and the uploads come from the same host and the same curl client, not two unrelated events.

The report’s executive summary for 10.5.11.101: polling to one server, uploads to another, one incident, and two thirds of the bytes in cleartext HTTP.

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 (56s 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.