MacSync Stealer: the domain list was the output, not the hunt

Microsoft Defender Experts published a hunt for MacSync Stealer, a macOS information stealer that relies on changing infrastructure to deliver payloads, talk to compromised devices and move data out, and connected more than 30 domains by correlating recurring endpoint and network behaviour instead of collecting indicators ^[1][3]. It matters because the same telemetry also confirmed the infrastructure was doing active collection, staging and exfiltration, not just beaconing, which is a different severity conversation than a blocklist update ^[3][7].

Start with the honest framing Microsoft itself uses: the domain count is an outcome of the methodology, not the finding ^[11]. Earlier reporting by RST Cloud identified the threat through a limited set of domains and documented rapid command-and-control replacement once the activity was publicly disclosed ^[2]. That is the failure mode of indicator-led coverage in one sentence. Publish the domains, lose the domains.

The behaviours that survived rotation are unglamorous. Execution began in an interactive shell session consistent with ClickFix social engineering, where a user is talked into pasting commands into Terminal ^[4]. The session used curl to pull attacker-controlled payload content, then script-driven execution and outbound communication ^[5]. Afterwards the malware called home using recurring URI paths, macOS User-Agent strings, API-key headers and specific curl command-line options, and those request traits stayed consistent while the domains underneath them changed ^[14]. Collection then went after macOS Keychain material, browser data, locally stored credentials, cloud and SSH credentials, and sensitive files from common user directories ^[6].

Exfiltration is where the pivots get sharp. Data was staged under temporary paths, compressed into an archive, split into chunks and uploaded via HTTP PUT using curl with the --data-binary argument ^[8]. The upload parameters upload_id, chunk_index and total_chunks are themselves huntable and can be correlated with process, command-line, file and network telemetry across the chain ^[9]. Microsoft reports the related infrastructure shared URI patterns including /curl/, /dynamic?txd= and /gate?buildtxd=, plus curl invocations using -k, -s, --max-time and --data-binary ^[16]. The strongest pivots combined the shape of the network request with the endpoint execution context ^[15].

The discipline is the interesting part. A domain was only treated as related when multiple behaviours aligned across process ancestry, command lines, request paths, headers and upload parameters, spanning payload retrieval, check-in and exfiltration ^[10]. That is a deliberately expensive bar, and it is what makes the resulting set worth something. For contrast, RST Cloud surfaced eleven additional candidate domains from recurring URI patterns alone, and found a static API-key value shared across four confirmed C2 domains while the build token rotated per deployment ^[12]. Microsoft's behaviour-led set is roughly 2.7 times that candidate list ^[17].

Microsoft's own conclusion is the one to hold: rotating infrastructure weakens static domain blocking and retrospective IOC matching, while repeated request patterns and process behaviours stay usable ^[13].

What to watch: whether your macOS estate produces the telemetry these pivots assume. Process ancestry, full command lines and outbound request headers from Terminal-initiated shell sessions are the minimum. If curl with --data-binary to an unfamiliar host is not a detection you can write today, the 30 domains are irrelevant to you ^[8][16].