Two vendors published three days apart. The malware shares a LaunchAgent, a repair script and a utility name
Jamf calls it PamStealer. Kaspersky calls it MacSync. Reading both reports side by side, the published artefacts overlap on at least twelve specific points, including an identically named persistence agent and the same custom decryption utility.
By Parminder Kumar Sharma · · 7 min read
The same persistence agent, in two different reports
On 22 September, Jamf Threat Labs published an analysis of a macOS infostealer it calls PamStealer, delivered through a fake cryptocurrency wallet called Wavel. On 25 September, Kaspersky published an analysis of a macOS infostealer it calls MacSync, delivered through a fake cryptocurrency wallet called Toria.
Read side by side, the two reports describe malware that installs a LaunchAgent with the same label, com.apple.finder.agent. Both describe a repair script called .repair-run. Both describe a custom utility called pkgunpack that performs a Curve25519 key exchange to unwrap the payload. Both describe injection into .zshrc and into git hooks. Both describe killing the same notification agents to suppress alerts. Both ship FAT Mach-O binaries for Apple silicon and Intel. Both use the PAM API to verify a stolen password, a technique Kaspersky dates to July 2026.
Neither report mentions the other, and neither uses the other's name.
What that does not establish. It does not establish that these are the same campaign, or the same operator. Kaspersky says MacSync is sold as a service, which means several customers can be running builds from one kit, producing identical artefacts with unrelated infrastructure and unrelated victims. It does not establish that either vendor made an error: naming is each vendor's own, tracked against their own telemetry, and there is no obligation to reconcile. And it does not establish which name is correct, because that is not a question with an answer.
What it does establish is something operational and immediate. A defender who reads one report gets one set of indicators. The artefacts that matter most for detection, the agent label, the script name, the utility, the shell hooks, appear in both. The infrastructure, the lure domains and the specific payload behaviours differ between them. Reading either alone gives you a partial picture of a threat you will meet under whichever name your vendor happens to use.
The overlap, item by item
These are the points where the two published analyses describe the same artefact. Everything in the table is quoted or paraphrased from one or both reports, not inferred from anything else.
Artefacts described in both the Jamf and Kaspersky analyses
| Artefact | Described by both? |
|---|---|
| LaunchAgent labelled com.apple.finder.agent | Yes |
| A script named .repair-run that restores missing files | Yes |
| A custom utility named pkgunpack | Yes |
| Curve25519 key exchange to unwrap the payload key | Yes |
| Injection into .zshrc for re-execution on a new shell | Yes |
| Git hooks used as an additional persistence path | Yes |
| Killing notification agents to suppress user alerts | Yes |
| FAT Mach-O binaries for arm64 and x86_64 | Yes |
| A fake cryptocurrency wallet with its own website | Yes, Wavel and Toria |
| Main stealer written in Swift | Yes |
| A separate backdoor component | Yes, Objective-C in the Kaspersky analysis |
| PAM API used to verify the captured password | Yes, dated to July 2026 |
The differences are real too, and they are the parts a shared builder would leave to the customer. Jamf's sample is delivered from a site impersonating one wallet and fetches its second stage from one host; Kaspersky's is delivered from another and, in at least one sample, pulls its commands from a public iCloud calendar. Jamf details the server side key exchange endpoint; Kaspersky details the backdoor's command set. Those read like two campaigns built from the same kit, which is exactly what malware sold as a service produces.
The part worth understanding whichever name you use
The most consequential technique in either report is the one that changes what a captured sample is worth.
Earlier versions carried the key material needed to decrypt the payload inside the script itself. This version does not. The dropper asks the utility to generate a fresh key pair per infection, sends the public half to the operator's server, and receives a wrapped decryption key in return. The shared secret is derived through a key exchange and a hash, and the payload key is unwrapped with authenticated encryption.
The consequence, in Jamf's words: "Without the server's cooperation, the DEK cannot be recovered and the payload cannot be decrypted."
So a sample pulled off a machine after the operator has taken the server down is inert. It cannot be unpacked, which means it cannot be fully analysed, which means the indicators you would extract from it do not exist. The operator has moved part of the analysis barrier onto infrastructure they control and can switch off.
Two delivery tricks worth separating from the noise
Each report carries one delivery detail that generalises beyond this family.
The first is a user interface problem rather than a technical one. The disk image contains a compiled AppleScript file, and because macOS hides file extensions by default, it presents to the user as an ordinary document. Opening it runs code. There is no exploit anywhere in that sentence.
The second is the command channel. At least one sample retrieves a public iCloud calendar and pipes the calendar file line by line into a shell reading from standard input. Most of the file produces harmless syntax errors; the lines that matter sit immediately after the event's description field and execute quietly.
That is command and control over a service no organisation blocks, from a domain no organisation would flag, in a file format no security tool treats as executable. The same idea has been done with documents, with code repositories and with chat platforms. Calendars are simply the newest one to appear in a public report.
What to do about it
Take this with you
In the order worth doing
- Hunt on the artefacts that appear in both reports rather than on either vendor's name: a LaunchAgent labelled as a Finder agent, a hidden repair script under Application Support, and a binary named pkgunpack.
- Check shell configuration files and git hooks on developer machines, because both are persistence paths here and neither is where most endpoint tooling looks first.
- Alert on processes that kill notification agents, which is a small, high signal behaviour with very few legitimate causes.
- For macOS fleets, turn off the Finder setting that hides file extensions, which removes the specific deception used to open the first stage.
- Treat outbound traffic to consumer calendar and document services from servers and developer machines as worth inspecting, since that is the current channel of choice.
- In response, collect network evidence at the same moment as disk evidence. A sample recovered after the operator's server goes quiet may be undecryptable by design.
- When two vendor reports describe similar macOS stealers, compare the persistence artefacts before deciding they are different threats.
The question this leaves
Vendor naming is not a scandal and it is not going away. Each firm names what its own telemetry shows, publishes when its analysis is ready, and has no way of knowing what a competitor is about to release. Three days apart, two of the best macOS research teams in the industry described overlapping artefacts under different names, and neither did anything wrong.
The cost lands somewhere else. A security team reads one of the two, adds those indicators, and closes the ticket. The other report contains the same persistence artefacts and different infrastructure, and if the build they meet is the other one, their detections do not fire on the half that would have caught it.
The defence against that is not better naming, which the industry has tried and failed to fix for thirty years. It is to detect on behaviour and artefacts rather than on names. A LaunchAgent pretending to be Finder, a hidden repair script and a shell hook are the same three things whichever report you read.
So the question for your own detection content: how much of it is written against a name somebody else chose, and how much against something the malware actually has to do?
Sources
- PrimaryThe PamStealer Wavel analysis of 22 September 2026, used for the chain, the cryptography and the persistence layersJamf Threat Labsaccessed 2026-09-25
- PrimaryThe MacSync analysis of 25 September 2026, used for the iCloud calendar loader, the backdoor commands and the naming historyKaspersky, Securelistaccessed 2026-09-25
- PrimaryApple's service management documentation, used for what a LaunchAgent is and when it runsAppleaccessed 2026-09-25
