WithSecure published an analysis on 4 November 2026 of the Phexia macOS stealer, a modular backdoor and information stealer for Macs. Its author, a WithSecure incident response investigator, says several threat actors buy the malware and use it mainly in ClickFix campaigns. WithSecure dates the first use to late 2025 and reports a growing number of infections since early 2026.
This post follows the infection in order, from the pasted command to the data that leaves the Mac, and then turns the same chain into detections. Everything below comes from the WithSecure report unless it is marked as our advice. The report lists indicators in appendices, and we do not reproduce them here.
How Does a Pasted Command Become an Infection?
ClickFix pages ask the visitor to run a command themselves, so no software flaw is involved. Our malicious copy and paste technique page describes the pattern, and an earlier ClickFix news roundup shows how varied the lures are. For Phexia, WithSecure could not identify the lure behind most infections. It cites public reporting of typosquatted domains, shopping listings and fake CAPTCHA pages, and ties infections on 6 July 2026 to a publicly reported typosquat route.
The command is short. It uses curl in silent mode to fetch a shell script from a random-looking subdomain and pipes it straight into bash. The script is usually called update.sh, and script.sh, clear-cache.sh and Terminal.sh also appear. WithSecure lists eight delivery hosts that change between waves.
- Pasted Terminal commandMaccurl fetches a script and pipes it to bash
- AppleScript dropperMacosascript writes a per-user LaunchAgent
- Loader reads Polygon contractOperatorpublic RPC call returns the command server name
- Backdoor polls for tasksOperatorstealer, shell and miner modules arrive
- Archive uploadedOperator
What Does the Dropper Leave Behind?
The shell script starts an AppleScript dropper through osascript. The dropper writes a LaunchAgent plist into the user’s LaunchAgents folder, sets KeepAlive to true and, in earlier builds, RunAtLoad as well. It then runs launchctl unload and launchctl load on the same file, which refreshes the entry on every repeat run.
The loader itself never exists as a readable script. The plist’s ProgramArguments call /bin/bash with a command that decodes an embedded Base64 loader and pipes it to osascript. A file scan of the disk therefore finds only a plist.
The label changed over time. Builds from June to mid-September 2026 used the prefix com plus 16 lowercase letters. From October 2026 the prefix is com.Apple plus 16 lowercase letters. WithSecure reads that as an attempt to pass for a system item.
The October builds also pad the AppleScript with junk variables and arithmetic. Readable AppleScript was the norm in the June builds.
Reinfection matters here. WithSecure saw a 27 October infection leave an older LaunchAgent running beside the new one, and the older command server kept issuing tasks for more than 20 minutes. A cleanup that removes one plist can leave the other alive.
How Does Phexia Find Its Command Server?
Phexia uses a dead drop resolver on a public blockchain, a technique WithSecure calls EtherHiding. The loader sends an eth_call request to public Polygon RPC endpoints and receives the command server name from a smart contract. Our dead drop resolver technique page covers the general idea.
WithSecure describes Polygon testing from May 2026 and weaponization from late May to early June. From 14 June to 22 October 2026 all recorded lookups in its telemetry queried one contract through a function named getServerURL(), selector 0x2686ecea. A build installed on 27 October used a second contract. The report lists four RPC endpoints, tried in order with up to 15 seconds each.
The design has a clear cost for defenders. The operator changes one on-chain value and new lookups point to a new domain, without touching any deployed malware.
WithSecure counts 14 command domains first seen between 14 June and 27 October 2026, and says older domains stayed active for weeks. One was still polled through 23 July. A domain blocklist alone ages quickly.
How Is the Login Password Captured?
The backdoor shows a fake System Preferences password dialog, according to public analysis that WithSecure cites. It checks each answer with dscl . authonly, first testing for an empty password. Valid passwords are saved in plain text to a hidden file named .passphrase in the home folder, and the build identifier goes to a file named .txid.
WithSecure measured the timing. Captured passwords appeared between under a minute and about eight minutes after execution. Delayed checks began about 22 hours after infection and came back on later days.
One detail helps defenders. The password travels as a command-line argument, so any process logging or SIEM collection that records command lines will also record the user’s password. Treat those logs as sensitive and restrict who can read them.
What Data Leaves the Mac?
The stealer modules go after the stores that give access to everything else. The table lists what WithSecure names. Our credentials from password stores page covers the technique, and the session cookie entry explains why cookies matter.
| Target | What WithSecure reports |
|---|---|
| Browser keys | Safe Storage entries for Chrome, Edge, Brave, Opera and Vivaldi, read with security find-generic-password |
| Browser profiles | Cookies, History, Login Data and Web Data files |
| Password-manager extensions | LastPass and NordPass IndexedDB stores |
| Keychain | The login keychain file, login.keychain-db |
| Safari cookies | An AppleScript has Finder copy Cookies.binarycookies into a temporary folder, which avoids direct access to the protected container |
| Crypto wallets | Directory checks for desktop wallets; the report does not confirm that wallet contents were taken |
| Host details | Hardware and software data from system_profiler, plus a public IP lookup |
The stolen files are archived with ditto into a zip file under /tmp with a long hexadecimal name. A multipart curl POST sends the archive to an upload.php page on the command server over HTTPS, with a 90 second limit and the build identifier as a form field. A second upload goes to a separate server over plain HTTP.
The backdoor also runs tccutil reset All. WithSecure says the purpose is unknown.
What Else Does the Operator Run?
The backdoor fetches a module named bmodule first and then polls for tasks. WithSecure names smodule (full stealer), lmodule (light stealer), ledger and shell. From 20 October an init task uploads the build identifier, hardware UUID, user name and a list of installed apps, which WithSecure assesses with moderate confidence helps operators pick tasks.
The ledger and shell tasks ran the XMRig miner, version 6.26.0 for macOS arm64, downloaded from the official GitHub releases. WithSecure treats the download itself as legitimate context. The working folder was renamed to resemble an Apple item, first rigupdater and then applecomlistupdate, and the quarantine attribute was removed from the download. The miner used 13 threads and two pools over the period.
How Do You Detect the Phexia macOS Stealer?
Hashes help little, because each build is obfuscated differently and the stage that does the work lives inside a plist. The reliable signals are behaviours that follow the chain above. The first five come from WithSecure’s guidance, and the last two are our additions.
- A shell launched from Terminal that downloads a script and then starts osascript, followed by a new file in the LaunchAgents folder.
- LaunchAgents with a com or com.Apple label plus 16 lowercase letters whose arguments decode Base64 and pipe it to osascript. Do not rely on the label alone, since WithSecure warns that labels are not enough.
- Polygon JSON-RPC eth_call traffic from osascript or its child processes, especially with the reported selector.
- curl POSTs carrying a txid field, particularly where the response is piped to a shell.
- dscl . authonly, Safe Storage queries or tccutil reset All inside an AppleScript process tree, plus zip files created under /tmp and uploaded with curl.
- Our addition: alert on any Terminal child process that reaches the internet within seconds of a paste, since ClickFix depends on that step.
- Our addition: audit LaunchAgents across the fleet with your management tool and flag plists that call bash or osascript with an encoded argument.
What Should You Do If a Mac Ran the Command?
WithSecure’s response order is worth following exactly. Work from a trusted device, because the login password on the infected Mac is already exposed. The steps below follow the report, and the closing advice on awareness is ours.
- Preserve telemetry, the LaunchAgent plists, the .txid and .passphrase files and staging data before cleaning. Handle the plain-text password file carefully.
- Find every malicious persistence item, since reinfection can leave old and new builds together.
- Unload each malicious job from its launchd domain before deleting its plist.
- Stop confirmed malicious scripts and miners and remove payloads, credential files and staging data, without touching unrelated system processes.
- From a trusted device reset passwords, revoke sessions and tokens, and review password-manager and wallet exposure.
- Reboot, then watch for returning persistence, command traffic or mining. Rebuild from a trusted baseline if the scope cannot be confirmed.
Our advice for users: a website that tells you to paste a command into Terminal is asking for the one step the attacker cannot do alone. Add that rule to security awareness training, and see our notes on infostealers for what stolen browser data is used for afterwards.
What Is Still Unclear?
WithSecure does not give victim counts or a total number of builds. It could not identify the lure behind most infections. It also does not know why tccutil reset All runs or whether wallet contents were collected. The report notes that the Polygon contract set seen so far is small, with only two contracts observed.