{
	"id": "a42f7279-9467-44ca-a99e-0e9ec42c938f",
	"created_at": "2026-04-06T00:21:50.601074Z",
	"updated_at": "2026-04-10T03:22:13.58952Z",
	"deleted_at": null,
	"sha1_hash": "54aec50943329154d9f341af426bed0a04f78f84",
	"title": "Analyzing a watering hole campaign using macOS exploits",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 59736,
	"plain_text": "Analyzing a watering hole campaign using macOS exploits\r\nBy Erye Hernandez\r\nPublished: 2021-11-11 · Archived: 2026-04-05 22:30:47 UTC\r\nNov 11, 2021\r\n10 min read\r\nE\r\nErye Hernandez\r\nThreat Analysis Group\r\nTo protect our users, TAG routinely hunts for 0-day vulnerabilities exploited in-the-wild. In late August 2021,\r\nTAG discovered watering hole attacks targeting visitors to Hong Kong websites for a media outlet and a\r\nprominent pro-democracy labor and political group. The watering hole served an XNU privilege escalation\r\nvulnerability (CVE-2021-30869) unpatched in macOS Catalina, which led to the installation of a previously\r\nunreported backdoor.\r\nAs is our policy, we quickly reported this 0-day to the vendor (Apple) and a patch was released to protect users\r\nfrom these attacks.\r\nBased on our findings, we believe this threat actor to be a well-resourced group, likely state backed, with access to\r\ntheir own software engineering team based on the quality of the payload code.\r\nIn this blog we analyze the technical details of the exploit chain and share IOCs to help teams defend against\r\nsimilar style attacks.\r\nWatering Hole\r\nThe websites leveraged for the attacks contained two iframes which served exploits from an attacker-controlled\r\nserver—one for iOS and the other for macOS.\r\niOS Exploits\r\nThe iOS exploit chain used a framework based on Ironsquirrel to encrypt exploits delivered to the victim's\r\nbrowser. We did not manage to get a complete iOS chain this time, just a partial one where CVE-2019-8506 was\r\nused to get code execution in Safari.\r\nmacOS Exploits\r\nThe macOS exploits did not use the same framework as iOS ones. The landing page contained a simple HTML\r\npage loading two scripts—one for Capstone.js and another for the exploit chain.\r\nhttps://blog.google/threat-analysis-group/analyzing-watering-hole-campaign-using-macos-exploits/\r\nPage 1 of 5\n\nThe parameter rid is a global counter which records the number of exploitation attempts. This number was in the\r\n200s when we obtained the exploit chain.\r\nWhile the javascript starting the exploit chain checks whether visitors were running macOS Mojave (10.14) or\r\nCatalina (10.15) before proceeding to run the exploits, we only observed remnants of an exploit when visiting the\r\nsite with Mojave but received the full non-encrypted exploit chain when browsing the site with Catalina.\r\nThe exploit chain combined an RCE in WebKit exploiting CVE-2021-1789 which was patched on Jan 5, 2021\r\nbefore discovery of this campaign and a 0-day local privilege escalation in XNU (CVE-2021-30869) patched on\r\nSept 23, 2021.\r\nRemote Code Execution (RCE)\r\nLoading a page with the WebKit RCE on the latest version of Safari (14.1), we learned the RCE was an n-day\r\nsince it did not successfully trigger the exploit. To verify this hypothesis, we ran git bisect and determined it was\r\nfixed in this commit.\r\nSandbox Escape and Local Privilege Escalation (LPE)\r\nCapstone.js\r\nIt was interesting to see the use of Capstone.js, a port of the Capstone disassembly framework, in an exploit chain\r\nas Capstone is typically used for binary analysis. The exploit authors primarily used it to search for the addresses\r\nof dlopen and dlsym in memory. Once the embedded Mach-O is loaded, the dlopen and dlsym addresses found\r\nusing Capstone.js are used to patch the Mach-O loaded in memory.\r\nWith the Capstone.js configured for X86-64 and not ARM, we can also derive the target hardware is Intel-based\r\nMacs.\r\nEmbedded Mach-O\r\nAfter the WebKit RCE succeeds, an embedded Mach-O binary is loaded into memory, patched, and run. Upon\r\nanalysis, we realized this binary contained code which could escape the Safari sandbox, elevate privileges, and\r\ndownload a second stage from the C2.\r\nAnalyzing the Mach-O was reminiscent of a CTF reverse engineering challenge. It had to be extracted and\r\nconverted into binary from a Uint32Array.\r\nThen the extracted binary was heavily obfuscated with a relatively tedious encoding mechanism--each string is\r\nXOR encoded with a different key. Fully decoding the Mach-O was necessary to obtain all the strings representing\r\nthe dynamically loaded functions used in the binary. There were a lot of strings and decoding them manually\r\nwould have taken a long time so we wrote a short Python script to make quick work of the obfuscation. The script\r\nparsed the Mach-O at each section where the strings were located, then decoded the strings with their respective\r\nXOR keys, and patched the binary with the resulting strings.\r\nOnce we had all of the strings decoded, it was time to figure out what capabilities the binary had. There was code\r\nto download a file from a C2 but we did not come across any URL strings in the Mach-O so we checked the\r\nhttps://blog.google/threat-analysis-group/analyzing-watering-hole-campaign-using-macos-exploits/\r\nPage 2 of 5\n\njavascript and saw there were two arguments passed when the binary is run–the url for the payload and its size.\r\nAfter downloading the payload, it removes the quarantine attribute of the file to bypass Gatekeeper. It then\r\nelevated privileges to install the payload.\r\nN-day or 0-day?\r\nBefore further analyzing how the exploit elevated privileges, we needed to figure out if we were dealing with an\r\nN-day or a 0-day vulnerability. An N-day is a known vulnerability with a publicly available patch. Threat actors\r\nhave used N-days shortly after a patch is released to capitalize on the patching delay of their targets. In contrast, a\r\n0-day is a vulnerability with no available patch which makes it harder to defend against.\r\nDespite the exploit being an executable instead of shellcode, it was not a standalone binary we could run in our\r\nvirtual environment. It needed the address of dlopen and dlsym patched after the binary was loaded into memory.\r\nThese two functions are used in conjunction to dynamically load a shared object into memory and retrieve the\r\naddress of a symbol from it. They are the equivalent of LoadLibrary and GetProcAddress in Windows.\r\nTo run the exploit in our virtual environment, we decided to write a loader in Python which did the following:\r\nload the Mach-O in memory\r\nfind the address of dlopen and dlsym\r\npatch the loaded Mach-O in memory with the address of dlopen and dlsym\r\npass our payload url as a parameter when running the Mach-O\r\nFor our payload, we wrote a simple bash script which runs id and pipes the result to a file in /tmp. The result of the\r\nid command would tell us whether our script was run as a regular user or as root.\r\nHaving a loader and a payload ready, we set out to test the exploit on a fresh install of Catalina (10.15) since it\r\nwas the version in which we were served the full exploit chain. The exploit worked and ran our bash script as root.\r\nWe updated our operating system with the latest patch at the time (2021-004) and tried the exploit again. It still\r\nworked. We then decided to try it on Big Sur (11.4) where it crashed and gave us the following exception.\r\nThe exception indicates that Apple added generic protections in Big Sur which rendered this exploit useless. Since\r\nApple still supports Catalina and pushes security updates for it, we decided to take a deeper look into this exploit.\r\nElevating Privileges to Root\r\nThe Mach-O was calling a lot of undocumented functions as well as XPC calls to mach_msg with a\r\nMACH_SEND_SYNC_OVERRIDE flag. This looked similar to an earlier in-the-wild iOS vulnerability analyzed\r\nby Ian Beer of Google Project Zero. Beer was able to quickly recognize this exploit as a variant of an earlier port\r\ntype confusion vulnerability he analyzed in the XNU kernel (CVE-2020-27932). Furthermore, it seems this exact\r\nexploit was presented by Pangu Lab in a public talk at zer0con21 in April 2021 and Mobile Security Conference\r\n(MOSEC) in July 2021.\r\nIn exploiting this port type confusion vulnerability, the exploit authors were able to change the mach port type\r\nfrom IKOT_NAMED_ENTRY to a more privileged port type like IKOT_HOST_SECURITY allowing them to\r\nforge their own sec_token and audit_token, and IKOT_HOST_PRIV enabling them to spoof messages to kuncd.\r\nhttps://blog.google/threat-analysis-group/analyzing-watering-hole-campaign-using-macos-exploits/\r\nPage 3 of 5\n\nMACMA Payload\r\nAfter gaining root, the downloaded payload is loaded and run in the background on the victim's machine via\r\nlaunchtl. The payload seems to be a product of extensive software engineering. It uses a publish-subscribe model\r\nvia a Data Distribution Service (DDS) framework for communicating with the C2. It also has several components,\r\nsome of which appear to be configured as modules. For example, the payload we obtained contained a kernel\r\nmodule for capturing keystrokes. There are also other functionalities built-in to the components which were not\r\ndirectly accessed from the binaries included in the payload but may be used by additional stages which can be\r\ndownloaded onto the victim's machine.\r\nNotable features for this backdoor include:\r\nvictim device fingerprinting\r\nscreen capture\r\nfile download/upload\r\nexecuting terminal commands\r\naudio recording\r\nkeylogging\r\nConclusion\r\nOur team is constantly working to secure our users and keep them safe from targeted attacks like this one. We\r\ncontinue to collaborate with internal teams like Google Safe Browsing to block domains and IPs used for exploit\r\ndelivery and industry partners like Apple to mitigate vulnerabilities. We are appreciative of Apple’s quick response\r\nand patching of this critical vulnerability.\r\nFor those interested in following our in-the-wild work, we will soon publish details surrounding another, unrelated\r\ncampaign we discovered using two Chrome 0-days (CVE-2021-37973 and CVE-2021-37976). That campaign is\r\nnot connected to the one described in today’s post.\r\nRelated IOCs\r\nDelivery URLs\r\nhttp://103[.]255[.]44[.]56:8372/6nE5dJzUM2wV.html\r\nhttp://103[.]255[.]44[.]56:8371/00AnW8Lt0NEM.html\r\nhttp://103[.]255[.]44[.]56:8371/SxYm5vpo2mGJ?rid=\u003credacted\u003e\r\nhttp://103[.]255[.]44[.]56:8371/iWBveXrdvQYQ?rid=?rid=\u003credacted\u003e\r\nhttps://appleid-server[.]com/EvgSOu39KPfT.html\r\nhttps://www[.]apple-webservice[.]com/7pvWM74VUSn2.html\r\nhttps://appleid-server[.]com/server.enc\r\nhttps://amnestyhk[.]org/ss/defaultaa.html\r\nhttps://amnestyhk[.]org/ss/4ba29d5b72266b28.html\r\nhttps://amnestyhk[.]org/ss/mac.js\r\nhttps://blog.google/threat-analysis-group/analyzing-watering-hole-campaign-using-macos-exploits/\r\nPage 4 of 5\n\nJavascript\r\ncbbfd767774de9fecc4f8d2bdc4c23595c804113a3f6246ec4dfe2b47cb4d34c (capstone.js)\r\nbc6e488e297241864417ada3c2ab9e21539161b03391fc567b3f1e47eb5cfef9 (mac.js)\r\n9d9695f5bb10a11056bf143ab79b496b1a138fbeb56db30f14636eed62e766f8\r\nSandbox escape / LPE\r\n8fae0d5860aa44b5c7260ef7a0b277bcddae8c02cea7d3a9c19f1a40388c223f\r\ndf5b588f555cccdf4bbf695158b10b5d3a5f463da7e36d26bdf8b7ba0f8ed144\r\nBackdoor\r\ncf5edcff4053e29cb236d3ed1fe06ca93ae6f64f26e25117d68ee130b9bc60c8 (2021 sample)\r\nf0b12413c9d291e3b9edd1ed1496af7712184a63c066e1d5b2bb528376d66ebc (2019 sample)\r\nC2\r\n123.1.170.152\r\n207.148.102.208\r\nRelated stories\r\n.\r\nSource: https://blog.google/threat-analysis-group/analyzing-watering-hole-campaign-using-macos-exploits/\r\nhttps://blog.google/threat-analysis-group/analyzing-watering-hole-campaign-using-macos-exploits/\r\nPage 5 of 5",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://blog.google/threat-analysis-group/analyzing-watering-hole-campaign-using-macos-exploits/"
	],
	"report_names": [
		"analyzing-watering-hole-campaign-using-macos-exploits"
	],
	"threat_actors": [],
	"ts_created_at": 1775434910,
	"ts_updated_at": 1775791333,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/54aec50943329154d9f341af426bed0a04f78f84.pdf",
		"text": "https://archive.orkl.eu/54aec50943329154d9f341af426bed0a04f78f84.txt",
		"img": "https://archive.orkl.eu/54aec50943329154d9f341af426bed0a04f78f84.jpg"
	}
}