As we reported in our Deeper Dive into macOS.Macma on Monday, a suspected Chinese-backed APT has been discovered spying on Mac-using activists and journalists with a custom-built Backdoor. The malware appears to have been crafted primarily to target Mac users running macOS 15 Catalina and visiting certain websites related to the ongoing pro-democracy activism in Hong Kong. In one version of the attack, the threat actors leveraged vulnerabilities in macOS itself to drop the Macma payload. In another, the threat actors relied on social engineering and a trojan installer to infect devices. In this post, we explain more about how macOS.Macma works, how to detect it, and how to protect against it.
Overview of Backdoor macOS.Macma
The Backdoor macOS.Macma is a malicious payload discovered by Google TAG in August, 2021 and disclosed in November, 2021. It appears to have been developed over a number of years and comes in two versions. In the more recent version, the threat actors leveraged what was at the time a remote code execution (RCE) 0-day in WebKit and a local privilege escalation (LPE) in the XNU kernel in order to drop the Macma payload with root privileges on unsuspecting Mac users in a watering hole campaign. In the earlier version, the threat actors rely on social engineering to trick users into running a trojan app that drops a similar payload.
The trojan, which appears to date from at least 2019, contains several malicious binaries and a shell script in its Resources folder. The shell script is responsible for installing and running the “client” binary (also in the Resources folder). A similar executable is also called by the persistence agent dropped in the User’s ~/Library/LaunchAgents folder, and which executes in the background every time the user logs in to their account.
Macma kills any earlier instance of itself before “reloading”
In the later 2021 version, the installation details are handled by a malicious payload executed in-memory thanks to the watering hole attack described by Google TAG.
In both versions, the LaunchAgent and the payload use the same persistence label and executable file paths:
Both versions also drop further components–including the keylogger module, kAgent–at another location:
In the 2021 version, we can see that the same routines used in the 2019 version’s shell script are now encoded in the installer binary; this includes the aforementioned unloading and loading of the persistence agent.
Macma uses launchctl to load its persistence agent
The installer then goes on to set up various UDP and TCP sockets for connectivity through a DDS framework.
Strings extracted from the 2021 version of macOS.Macma
With regards to the keylogger and other spyware components, note that in 10.14 Mojave, Apple introduced extended TCC protections to macOS such that any code attempting to access the user’s camera or microphone causes a user consent prompt. This mechanism was extended in macOS 10.15 Catalina to include keyboard input monitoring, such as a keylogger like kAgent might use.
macOS.Macma does indeed cause prompts to duly occur for Accessibility and the microphone (in our tests, only after logout and login), giving users at least some chance to recognize that these permissions are being sought.
TCC prompts occur after the user logs in again, post-infectionAccess to the microphone and Accessibility can be revoked in System Preferences
Analysis of the code used by macOS.Macma reveals other indications of the spyware’s capabilities, which as well as keylogging and audio recording include device fingerprinting, screen capture, and file download.
Code disassembly shows some of the methods used by the Macma spyware
In our tests, only the keylogger component was called into action by the UserAgent binary. As we reported previously, the keylogger captures the user’s keystrokes and stores these in text files with Unix timestamps for names at ~/Library/Preferences/UserAgent/lib/Data/.
The keylogger is run automatically by the UserAgent binary
Two other binaries are deposited in the ~/Library/Preferences/Tools/ folder but do not appear to be initiated by the UserAgent. These are the “at” binary and the “arch” binary.
Spyware modules are dropped in a separate location from the main executable
The ‘at’ binary profiles the user’s system and gathers environmental data, including the CPU info and model, Mac address, hardware UUID, disk free space and available memory.
A summary of the ‘at’ binary’s main functionality
Meanwhile, the ‘arch’ binary serves primarily to take captures of all the user’s currently open windows and save these to disk, presumably for later exfiltration.
Disassembly of the captureScreen method in the arch binary
Aside from these files, the UserAgent also executes a remote .php script in-memory in order to gather the user’s IP address.
How To Detect macOS.Macma Backdoor
While the XNU and WebKit vulnerabilities that allowed this spyware to be installed on unsuspecting users’ devices via a poisoned website have now been patched, it’s important to note that the malware could still be installed in other ways such as by social engineering, just as the earlier version was and most macOS malware in the wild typically is. The macOS.Macma payload, with the caveat of a few user prompts, will still work if the user can be manipulated into installing it even on a fully patched macOS install.
We also note that Apple’s built in XProtect scanner has not been updated to detect this malware as of the time of writing.
XProtect’s yara rules did not detect the macOS.Macma malware in our test
Apple’s built-in remediation software, MRT.app (Malware Removal Tool app), which runs at user login (among other times), also did not remove this infection on our test device after we logged out and logged back in again.
SentinelOne customers, however, are protected against macOS.Macma. The SentinelOne behavioral engine detects all the component binaries on execution.
The SentinelOne Management console alerts on macOS.Macma activity
In the demonstration video below, the agent policy is set to “Detect-only” in order to observe the malware’s execution.
For threat hunters and those without SentinelOne protection who wish to check for macOS.Macma infection, the following behavioral and file path indicators of compromise should help (where <user1> is replaced by the actual username of the account being investigated):
/Users/<user1>/Library/Preferences/UserAgent/lib/UserAgent -runMode ifneeded
chmod 644 /Users/<user1>/Library/LaunchAgents/com.UserAgent.va.plist
chmod 755 /Users/<user1>/Library/Preferences/Tools/arch
chmod 755 /Users/<user1>/Library/Preferences/Tools/kAgent
chmod u+s /Users/<user1>/Library/Preferences/Tools/arch
chmod u+s /Users/<user1>/Library/Preferences/Tools/kAgent
chown <user1>:staff /Users/<user1>/Library/LaunchAgents/com.UserAgent.va.plist
chown <user1>:staff /Users/<user1>/Library/Preferences/Tools
chown <user1>:staff /Users/<user1>/Library/Preferences/UserAgent
chown <user1>:staff /Users/<user1>/Library/Preferences/UserAgent/lib
launchctl load -w /Users/<user1>/Library/LaunchAgents/com.UserAgent.va.plist
launchctl unload -w /Users/<user1>/Library/LaunchAgents/com.UserAgent.va.plist
rm -f /Users/<user1>/start.sh
sh -c chown <user1>:staff “/Users/<user1>/Library/Preferences/Tools”
sh -c chown <user1>:staff “/Users/<user1>/Library/Preferences/UserAgent”
sh -c mkdir “/Users/<user1>/Library/Preferences/Tools”
sh -c mkdir “/Users/<user1>/Library/Preferences/UserAgent”
The appearance of the UserAgent binary in System Preferences’ Privacy pane, under both the Microphone and Accessibility panels, can also be used to check for infection. In addition, review the SentinelLabs macOS.Macma post for further information and IoCs.
How To Protect Against macOS.Macma
As we noted in our earlier post, some OS-specific vulnerabilities which allowed the threat actors to infect Mac users have been patched by Apple some months ago, and all users are highly encouraged to ensure they are on the latest patched version of Catalina 10.15 or higher.
In order to prevent infections like macOS.Macma, be sure to install a good behavioral AI engine that can recognize novel threats based on what they do. Legacy AV scanners that rely on known signatures or cloud reputation services alone will not be able to stop threats that have not previously been detected in the wild.