{
	"id": "36454bb3-2753-4f48-ba1f-8233f0b06665",
	"created_at": "2026-04-06T00:14:32.688317Z",
	"updated_at": "2026-04-10T03:21:04.288273Z",
	"deleted_at": null,
	"sha1_hash": "e837e58ac7fc88383168bf288559e79caf575518",
	"title": "Living off the Orchard: Leveraging Apple Remote Desktop for Good and Evil | Mandiant",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 955030,
	"plain_text": "Living off the Orchard: Leveraging Apple Remote Desktop for\r\nGood and Evil | Mandiant\r\nBy Mandiant\r\nPublished: 2019-10-09 · Archived: 2026-04-05 21:58:41 UTC\r\nWritten by: Jake Nicastro, Willi Ballenthin\r\nAttackers often make their lives easier by relying on pre-existing operating system and third party applications in\r\nan enterprise environment. Leveraging these applications assists them with blending in with normal network\r\nactivity and removes the need to develop or bring their own malware. This tactic is often referred to as Living Off\r\nThe Land. But what about when that land is an Apple orchard?\r\nIn recent enterprise macOS investigations, FireEye Mandiant identified the Apple Remote Desktop application as\r\na lateral movement vector and as a source for valuable forensic artifacts.\r\nApple Remote Desktop (ARD) was first released in 2002 and is Apple’s “desktop management system for\r\nsoftware distribution, asset management, and remote assistance”. An ARD deployment consists of administrator\r\nand client machines. While the administrator app must be downloaded from the macOS App Store, the client\r\napplication is included natively as part of macOS. Client systems must be added to the client list on an\r\nadministrator system manually, or they can be discovered via Bonjour if they are in the same local subnet as the\r\nadministrator system. In a typical enterprise environment deployment, managers would be the ARD administrators\r\nand have the ability to view, manage, and remotely control their managed personnel’s workstations via ARD.\r\nLateral Movement\r\nMandiant has observed attackers using the ARD screen sharing function to move laterally between systems. If\r\nremote desktop was not enabled on a target system, Mandiant observed attackers connecting to systems via SSH\r\nand executing a kickstart command to enable remote desktop management. This allowed remote desktop access to\r\nthe target systems. The following is an example from the macOS Unified Log showing a kickstart command used\r\nby an attacker to enable remote desktop access for all users with all privileges:\r\nhttps://www.fireeye.com/blog/threat-research/2019/10/leveraging-apple-remote-desktop-for-good-and-evil.html\r\nPage 1 of 11\n\nFigure 1: Kickstart command example\r\nDuring an investigation, you can use a few different artifacts to trace this activity. Execution of the kickstart\r\ncommand modifies the contents of the configuration file /Library/Application Support/Apple/Remote\r\nDesktop/RemoteManagement.launchd to contain the string “enabled”. SSH login activity can be found in the\r\nApple System Logs or Audit Logs. Execution of the kickstart command can be found in the Unified Logs, as seen\r\nin Figure 1.\r\nAn ARD administrator has a substantial amount of power available to them, similar to compromising an\r\nadministrator account in a Windows environment. By compromising an account that has access to ARD\r\nadministrator system, an attacker can perform any of the following actions:\r\nRemotely control VNC-enabled machines, including in “Curtain Mode” which hides the remote actions\r\nfrom the local workstation’s screen\r\nTransfer files\r\nRemotely shut down or restart multiple machines simultaneously\r\nSchedule tasks\r\nExecute AppleScript and UNIX shell scripts\r\nApple’s ARD web page and the ARD help page contain more details about ARD’s capabilities.\r\nARD Reporting as a Forensic Force Multiplier\r\nAlong with remote system control functionality, Apple Remote Desktop’s asset management capabilities include\r\nconducting remote Spotlight searches, file searching, generating software version information reports, and more\r\nimportantly, generating application usage and user history reports. The reporting process generally follows these\r\nsteps:\r\n1. Client systems compute reports and cache the data locally before transferring them to the administrator\r\nsystem (the default policy is to begin this at 12:00 AM local time, daily).\r\n2. Data received from clients is cached on the administrator system. Alternatively, a macOS system with the\r\nadministrator version of ARD installed can be set up as a “Task Server” for a centralized collection option.\r\nhttps://www.fireeye.com/blog/threat-research/2019/10/leveraging-apple-remote-desktop-for-good-and-evil.html\r\nPage 2 of 11\n\n3. Cached data is written to SQLite database on the administrator system\r\nThe cached data is stored in various subdirectories under the /private/var/db/RemoteManagement/ parent\r\ndirectory. The directory has the following structure:\r\nFigure 2: /private/var/db/RemoteManagement/ directory structure\r\nThis directory structure is present on all systems, but which files exist in which directories depends on whether the\r\nsystem is an ARD client or administrator system.\r\nArtifacts from ARD Client Systems\r\nThere is one directory that is the focus for investigations on client systems:\r\n/private/var/db/RemoteManagement/caches/. This directory contains the following files, which are the local client\r\ndata cache that is periodically reported to the administrator system. Do note, however, that these files are routinely\r\ndeleted by the system, so they may not be present. These files are typically deleted from the client system once\r\nthey are transmitted to the administrator system. Once transmitted, the data is stored on the administrator system.\r\nhttps://www.fireeye.com/blog/threat-research/2019/10/leveraging-apple-remote-desktop-for-good-and-evil.html\r\nPage 3 of 11\n\nFile Description\r\nAppUsage.plist plist file containing application usage data\r\nAppUsage.tmp\r\nBinary plist file containing application usage data, often the same as or less thorough than\r\nAppUsage.plist\r\nasp.cache Binary plist of system information\r\nfilesystem.cache Database containing an index of the entire file system, including users and groups\r\nsysinfo.cache Binary plist containing system information, some of which is also present in asp.cache\r\nUserAcct.tmp Binary plist containing user login activity\r\nTable 1: ARD cache files\r\nIn our experience, the most useful information available from these files is application usage and user activity.\r\nApplication Usage\r\nThe RemoteManagement/caches/AppUsage.plist file contains one key per application, where each key is the full\r\npath of the application, such as file:///Applications/Calculator.app/.\r\nEach application key contains a dictionary that includes a “runData” array and a “Name” string, which is the\r\nfriendly name of the application, such as “Calculator”, as seen in Figure 3.\r\nFigure 3: AppUsage.plist structure\r\nhttps://www.fireeye.com/blog/threat-research/2019/10/leveraging-apple-remote-desktop-for-good-and-evil.html\r\nPage 4 of 11\n\nEach “runData” array contains at least one dictionary consisting of the following keys and values:\r\nKey Value Format Description\r\nwasQuit\r\nBoolean: true or\r\nfalse\r\nIndicator of whether or not the application was quit prior to the last\r\nreport time. This field may not exist if the value is not “true”.\r\nFrontmost\r\nNumber of\r\nseconds\r\nTotal duration which the application was “frontmost” on the screen\r\nLaunched\r\nmacOS absolute\r\ntimestamp\r\nTime the application was launched\r\nrunLength\r\nNumber of\r\nseconds\r\nDuration the application was run\r\nusername String User who launched the application\r\nTable 2: AppUsage.plist runData keys and values\r\nOf the two application usage cache artifacts, RemoteManagement/caches/AppUsage.plist usually contains the\r\nsame or more content than RemoteManagement/caches/AppUsage.tmp.\r\nUser Activity\r\nThe RemoteManagement/caches/UserAcct.tmp file is a binary plist that contains user activity that can be\r\ncorrelated with other artifacts on a macOS systems, such as the Apple System Logs or Audit Logs. The file\r\ncontains keys with the short name of each user logged on the system.\r\nEach key contains a dictionary that includes a “uid” string with the user’s UID, and an array for each login type:\r\nconsole, tty, or SSH. Each login-type array contains at least one dictionary consisting of the following keys and\r\nvalues:\r\nKey Value Format Description\r\ninTime\r\nmacOS absolute\r\ntimestamp\r\nTime the user logged in\r\noutTime\r\nmacOS absolute\r\ntimestamp\r\nTime the user logged out\r\nhost String\r\nOriginating host for remote login. This field has been observed to not\r\nbe consistently present.\r\nTable 3: UserAcct.tmp keys and values\r\nArtifacts From ARD Administrator Systems\r\nhttps://www.fireeye.com/blog/threat-research/2019/10/leveraging-apple-remote-desktop-for-good-and-evil.html\r\nPage 5 of 11\n\nThe data outlined in Table 1 is reported to the administrator system daily. The files are then stored in the\r\nRemoteManagement/ClientCaches/ directory. Each file is renamed to the MAC address of the reporting system\r\nand placed into the appropriate subdirectory, as seen in Table 4. The subdirectories contain the following:\r\nSubdirectory Data Contained in Each File\r\nApplicationUsage/ AppUsage.plist files\r\nSoftwareInfo/ Filesystem.cache files\r\nSystemInfo/ Sysinfo.cache files\r\nUserAccounting/ UserAcct.tmp files\r\nTable 4: /private/var/db/RemoteManagement/ClientCaches/ subdirectories\r\nAdditionally, there is a plist file, RemoteManagement/ClientCaches/cacheAccess.plist that contains keys of MAC\r\naddresses with values of more MAC addresses. The purpose and context for this file has yet to be determined.\r\nThe Gold Mine\r\nAll the aforementioned data, with the exception of the filesystem.cache files, is added to the main SQLite database\r\nRemoteManagement/RMDB/rmdb.sqlite3 (“RMDB”). The RMDB exists on all ARD systems but is only\r\npopulated on the administrator system. It houses a wealth of information about the systems in the ARD network\r\nover a significant timespan. Mandiant has observed data for application usage timestamps from over a year prior\r\nto when we acquired a database on a live system.\r\nThe RMDB file contains five tables: ApplicationName, ApplicationUsage, PropertyNameMap,\r\nSystemInformation, and UserUsage. The following sections detail each table within the database:\r\nApplicationName\r\nThis table is an index for the applications on each system, where each application is assigned an item sequence\r\nnumber (“ItemSeq”) per system. This data is used for correlation in the ApplicationUsage table.\r\nColumn Value Format Description\r\nComputerID String Client MAC address, no separators\r\nAppName String Friendly application name\r\nAppURL String Application URL path (i.e. file:///Applications/Calculator.app)\r\nItemSeq Integer\r\nID number for each application, per ComputerID, used for the\r\nAppName table\r\nLastUpdated\r\nmacOS absolute\r\ntimestamp\r\nLast report time of the client\r\nhttps://www.fireeye.com/blog/threat-research/2019/10/leveraging-apple-remote-desktop-for-good-and-evil.html\r\nPage 6 of 11\n\nTable 5: ApplicationName table columns\r\nApplicationUsage\r\nThe AppName table is unique in the fact the “Frontmost” and “LaunchTime” values in the table are swapped. The\r\nresearch at the time of this blog post was verified on MacOS 10.14 (Mojave).\r\nColumn Value Format Description\r\nComputerID String Client MAC address, no separators\r\nFrontMost macOS absolute timestamp Application launch time\r\nLaunchTime\r\nNumber of seconds to 6\r\ndecimal places\r\nTotal duration the application was “frontmost” on screen\r\nRunLength\r\nNumber of seconds to 6\r\ndecimal places\r\nTotal duration the application was running\r\nItemSeq Integer\r\nItemSeq number for the respective ComputerID, referenced\r\nin the ApplicationName table\r\nLastUpdated macOS absolute timestamp Last report time of the client\r\nUserName String User who launched the application\r\nRunState Integer\r\n“1” for “running”, or “0” for “terminated” at the time of the\r\nlast report\r\nTable 6: ApplicationUsage table columns\r\nPropertyNameMap\r\nThis table is used as a reference for the SystemInformation table.\r\nColumn\r\nValue\r\nFormat\r\nDescription\r\nObjectName String\r\nVarious elements of a macOS system, such as Mac_HardDriveElement,\r\nMac_USBDeviceElement, Mac_SystemInfoElement\r\nPropertyName String\r\nProperty names for each element, such as ProductName, ProductID,\r\nVendorID, VendorName for Mac_USBDeviceElement\r\nPropertyMapID Integer ID number for each property, per element\r\nTable 7: PropertyNameMap table columns\r\nhttps://www.fireeye.com/blog/threat-research/2019/10/leveraging-apple-remote-desktop-for-good-and-evil.html\r\nPage 7 of 11\n\nSystemInformation\r\nThere is a substantial amount of system information collected in this table. This table can be leveraged to extract\r\nUSB device information, IP addresses, hostnames, and more, of all the reported client systems.\r\nColumn Value Format Description\r\nComputerID String Client MAC address, with colon separators\r\nObjectName String\r\nElements of a macOS system outlined in the PropertyNameMap\r\ntable\r\nPropertyName String Properties per element outlined in the PropertyNameMap table\r\nItemSeq Integer\r\nID number for each element, i.e. if there are 4\r\nMac_USBDeviceElement data sets, each one will have an ItemSeq\r\nnumber, 0-3, to group the properties together\r\nValue String Data for the respective property\r\nLastUpdated\r\nyyyy-mm-ddThh:mm:ssZ24 hour local time, last report time of the client. Example: 2019-08-\r\n07T02:11:34Z\r\nTable 8: SystemInformation table columns\r\nUserUsage\r\nThis table contains the user login activity for all the reported client systems.\r\nColumn Description of Value\r\nComputerID Client MAC address, no separators\r\nLastUpdated macOS absolute timestamp, last report time of the client\r\nUserName Short name of the user\r\nLoginType Console, tty, or ssh\r\ninTime macOS absolute timestamp, time the user logged in\r\noutTime macOS absolute timestamp, time the user logged out\r\nHost\r\nOriginating host for remote login. This field has been observed to not be consistently\r\npresent.\r\nTable 9: UserUsage table columns\r\nFilesystem Cache\r\nhttps://www.fireeye.com/blog/threat-research/2019/10/leveraging-apple-remote-desktop-for-good-and-evil.html\r\nPage 8 of 11\n\nThe RemoteManagement/ClientCaches/filesystem.cache file is a database that indexes the files and directories\r\nfound on a macOS computer’s file system. Rather than using SQLite like the RMDB, ARD uses a custom\r\ndatabase implementation to track this information. Fortunately, the database file format is fairly simple, consisting\r\nof a file header, six tables, and entries that point to string values. By interpreting the information in the filesystem\r\ncache file, an investigator can recreate the directory structure of an ARD-enable system. Mandiant uses this\r\ntechnique to identify and demonstrate the existence of attacker-created files.\r\nThe database header, identified by the magic value “hdix”, contains metadata about the database, such as the total\r\nnumber of indexed folders, files, and symlinks. Pointers from this header lead to the six tables: “main”, “names”\r\n(file names), “kinds” (file extensions), “versions” (macOS app bundle version infos), “users”, and “groups”.\r\nEntries in the “main” table contain references to entries in the other tables; by walking these references, an\r\ninvestigator can recover full file system paths and metadata.\r\nIn practice, the filesystem.cache file may be tens of megabytes in size, tracking dozens or hundreds of thousands\r\nof file system entries. Figure 4 shows truncated content of a parsed file system cache file; these entries are for the\r\nartifacts discussed in this article!\r\nFigure 4: Screenshot of filesystem.cache contents, listing ARD artifacts\r\nhttps://www.fireeye.com/blog/threat-research/2019/10/leveraging-apple-remote-desktop-for-good-and-evil.html\r\nPage 9 of 11\n\nOn a macOS system, the program “build_hd_index” traverses the file system and indexes the files and directories\r\ninto filesystem.cache. Figure 5 shows a portion of the documentation for this tool; as expected, the default output\r\ndirectory is [/private]/var/db/RemoteManagement/caches/.\r\nFigure 5: Documentation for build_hd_index\r\nIronically, internet message board posts going back to at least 2007 complain of the performance impact of this\r\ntool. A post by “Anonymous” indicates that “build_hd_index” was designed to support file indexing on OS X\r\nPanther (2003), which didn’t have Spotlight. Now, 16 years later, we can exploit these artifacts during an incident\r\nresponse.\r\nIntroducing: ARDvark\r\nIt was evident that if this artifact exists in a future investigation, leveraging its wealth of data will be critical to\r\nidentifying attacker activities. In some scenarios, investigators may be able to generate reports directly from an\r\nARD administrator system, but this may not always be the case. If not, then investigators would have to rely on\r\nmanually acquiring and extracting information from the RMDB file on the ARD administrator system. ARDvark\r\nis a tool that extracts all user activity and application usage recorded in the RMDB and outputs the data in an\r\nanalyst-friendly format.\r\nARDvark will also process the AppUsage.plist and UserAcct.tmp files found on ARD client systems under\r\n/private/var/db/RemoteManagement/caches/. Additionally, ARDvark has the capability to parse the\r\nfilesystem.cache files to produce a file system listing, as well as all users and groups present on the respective\r\nsystem. Please see the FireEye Github for more information.\r\nhttps://www.fireeye.com/blog/threat-research/2019/10/leveraging-apple-remote-desktop-for-good-and-evil.html\r\nPage 10 of 11\n\nDetecting and Preventing ARD Abuse\r\nTo detect suspicious ARD usage, organizations can monitor for anomalous modification of the\r\n/Library/Application Support/Apple/Remote Desktop/RemoteManagement.launchd file to identify remote desktop\r\naccess enablement where ARD is not used. Analyzing the Unified Logs for evidence of unexpected kickstart\r\ncommands during threat hunting missions can uncover suspicious ARD usage as well.\r\nMitigating ARD abuse is reliant upon the principle of least privilege. Mandiant recommends allowing as few\r\nremote control privileges as possible, and only allowing administrator privileges to necessary accounts. Apple\r\nprovides guidance on setting privileges, and authenticating without using local accounts with ARD in the help\r\npage and in the ARD user guide. ARD administrators can then routinely generate reports in the ARD application\r\nto ensure no changes are made to administration privilege settings.\r\nA Bushel of Evidence\r\nApplication usage artifacts for macOS are few and far between. To date, some of the best artifacts for application\r\nusage include CoreAnalytics files and the Spotlight database, but none of these artifacts provide the exact time of\r\nexecution of all applications. While ARD artifacts are not present across every macOS system, if ARD is deployed\r\nin an enterprise environment it may provide some of the most valuable data for investigators which you would not\r\nuncover otherwise.\r\nUser login activity typically exists in the Apple System Logs and Audit Logs, but short log retention is frequently\r\nan issue when the average attacker dwell time in 2018 was 78 days. The RMDB provides a potential source of\r\napplication usage and user login information that is over a year old, long outliving typical log retention times.\r\nThe system information available in the RMDB includes IP addresses, USB device information, and more which\r\nmay be useful to investigators. Also, the file system cache files that are collected contain an extensive file listing\r\nof multiple macOS systems, which allows investigators to identify files or users of interest on other systems\r\nwithout having to collect data from the suspect system directly.\r\nARD is an excellent example of how remote administration tools provide an attack surface for abuse while\r\nsimultaneously providing a vast amount of data to help piece together malicious activity, all from a single system.\r\nIf your organization utilizes ARD, consider reviewing the information available through the reporting\r\nfunctionality during threat hunting and future investigative purposes, as the artifact doesn’t fall far from the tree.\r\nPosted in\r\nThreat Intelligence\r\nSecurity \u0026 Identity\r\nSource: https://www.fireeye.com/blog/threat-research/2019/10/leveraging-apple-remote-desktop-for-good-and-evil.html\r\nhttps://www.fireeye.com/blog/threat-research/2019/10/leveraging-apple-remote-desktop-for-good-and-evil.html\r\nPage 11 of 11",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://www.fireeye.com/blog/threat-research/2019/10/leveraging-apple-remote-desktop-for-good-and-evil.html"
	],
	"report_names": [
		"leveraging-apple-remote-desktop-for-good-and-evil.html"
	],
	"threat_actors": [],
	"ts_created_at": 1775434472,
	"ts_updated_at": 1775791264,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/e837e58ac7fc88383168bf288559e79caf575518.pdf",
		"text": "https://archive.orkl.eu/e837e58ac7fc88383168bf288559e79caf575518.txt",
		"img": "https://archive.orkl.eu/e837e58ac7fc88383168bf288559e79caf575518.jpg"
	}
}