Microsoft says MacSync Stealer rotates domains too fast to block. All 31 in its own list share one registrar and none was registered this year

What Microsoft published

Microsoft Defender Experts and Microsoft Security Research published an analysis of MacSync Stealer on 18 August 2026, extending earlier work by RST Cloud. It is a macOS information stealer delivered through ClickFix social engineering, where the victim is talked into pasting a command into Terminal.

The report's method is the interesting part, and Microsoft is careful to say the headline number is not the point:

Applying this standard linked more than 30 domains, making the domain count an outcome of the behavioral methodology rather than the primary finding.

The behaviours that stayed constant while domains changed are specific enough to hunt on: recurring URI paths /curl/, /dynamic?txd= and /gate?buildtxd=, a macOS User-Agent, an api-key header, curl invoked with -k -s --max-time, and chunked uploads over HTTP PUT carrying upload_id, chunk_index and total_chunks.

RST Cloud contributed the sharpest single detail, and it is the one to remember: a static API-key value shared across four confirmed C2 domains, while the build token rotated per deployment. The operator rotated the identifier a defender can see in a URL and left the one sitting in a header alone.

The chain Microsoft observed, and what each phase leaves behind

1. 1

   Payload retrieval

   An interactive zsh session runs curl against a /curl/ path, then decodes with base64 and gunzip.

2. 2

   AppleScript execution

   osascript launches sh, cp, rm, curl, mkdir and killall, blending macOS scripting with Unix tooling.

3. 3

   Collection

   Keychain material, browser Safe Storage keys, cookies, SSH keys, AWS credentials, Kubernetes configs, Apple Notes, wallet artefacts.

4. 4

   Staging

   Data staged under /tmp/sync* and compressed into /tmp/osalogging.zip, then split into chunks.

5. 5

   Chunked exfiltration

   curl -X PUT --data-binary uploads each chunk with upload_id, chunk_index and total_chunks to a /gate path.

6. 6

   Cleanup

   Temporary archives, staging folders and lock files removed to reduce on-disk evidence.

Their own indicator list answers a question the report does not ask

Microsoft's defensive argument is that rotating infrastructure decays static domain blocking, so hunt on request shape instead. That is right, and this site would not argue with it.

It does raise a question neither report addresses: where do the replacement domains come from? Every one of the 31 domains in Microsoft's indicator table was queried against Verisign's RDAP service on 18 August 2026 for this briefing. The answer is not what the word "rotating" suggests.

All 31 domains were bought before the campaign was ever reported

Verisign RDAP · 18 Aug 2026

263 days, no domain in the list registered

8

3

6

Sep 2024

26 Sep 2025

18 Aug 2026, report

31 of 31

at a single registrar, Unstoppable Domains

0

registered at any point in 2026

14 of 31

registered on just two days, 26 Sep and 28 Nov 2025

All 31 sit with a single registrar. Not one was registered in 2026. The newest is 28 November 2025, 263 days before the report was published, and the oldest goes back to October 2024. Fourteen of the 31 were registered on just two days: eight on 26 September 2025 and six on 28 November 2025.

So the rotation is real and the registration is not. The operator is cycling through stock bought in batches up to a year in advance. Rotation and registration are different activities, and the report describes the first without touching the second.

Why that matters more than it sounds

A newly-registered-domain block would have caught none of this. Blocking or scoring domains by age is one of the most widely deployed controls in enterprise filtering, it is cheap, and against this campaign it is worth nothing, because by the time any of these domains served a payload it had been sitting in a drawer for months.

The registrar is a stronger pivot than the report offers, and a cheaper one. Microsoft's behavioural pivots need process ancestry, command lines and network telemetry correlated together, which in practice means an EDR product and someone to write the queries. A registrar plus a registration window is a DNS-log query. It is coarser and it will produce false positives, because a large registrar has many legitimate customers. It is also available to teams who have none of the telemetry the report assumes.

And the innocuous names are not what they look like. A defender scanning that list sees dogtrainersgeorgia.com, newjerseypetsitter.com, oaklandwaterdamage.com and reasonably concludes these are small business sites that got compromised. The registration data does not support that reading: those three were registered on the same day, at the same registrar, in the same batch of six. They are purpose-registered cover, not victims. That distinction changes what you do when one appears in your logs, because there is no third party to notify and no compromised site to remediate.

What rotates and what did not, across the same 31 domains

Attribute	Behaviour across the campaign
C2 domain	Replaced quickly after public disclosure. The reason static blocking decays.
Build token, buildtxd	Rotates per deployment, per RST Cloud.
API-key header	Static across four confirmed C2 domains, per RST Cloud.
URI paths and upload parameters	Unchanged across more than 30 domains, per Microsoft.
Registrar	One, across all 31 domains in the indicator table.
Registration window	August 2024 to November 2025. Nothing in 2026, and 14 of 31 on two days.

What to do with this

The position

The Microsoft report is good work and its central claim is correct: behaviours outlive infrastructure, and hunting on request shape beats matching domains. The piece of advice underneath it is the one worth carrying, which is that the pivots you can rely on are the ones the attacker cannot change without rebuilding their tooling.

What the same data shows, and what nobody wrote down, is that the attacker did not have to change much at all. The API key stayed static across four C2 domains, the URI paths stayed static across more than thirty, and the domains themselves were bought in bulk before the campaign was ever reported. Rotation looks like agility from the outside. From the registry it looks like inventory management.

This is the third briefing this week where the published artefact is accurate and answers a narrower question than the reader is asking, after a status page that named components and never a cause and an advisory that said no user action was required. Here the gap is smaller and more forgivable, because an indicator table is not supposed to be an analysis. It is still worth noticing that the answer was sitting inside the evidence both vendors published.