OSX/Keydnap spreads via signed Transmission application

Last month ESET researchers wrote an article about a new OS X malware called OSX/Keydnap, built to steal the content of OS X’s keychain and maintain a permanent backdoor. At that time of the analysis, it was unclear how victims were exposed to OSX/Keydnap. To quote the original article: “It could be through attachments in spam messages, downloads from untrusted websites or something else.”

During the last hours, OSX/Keydnap was distributed on a trusted website, which turned out to be “something else”. It spread via a recompiled version of the otherwise legitimate open source BitTorrent client application Transmission and distributed on their official website.

Instant response from the Transmission team

Literally minutes after being notified by ESET, the Transmission team removed the malicious file from their web server and launched an investigation to identify how this happened. At the time of writing, it was impossible to tell exactly when the malicious file was made available for download. According to the signature, the application bundle was signed on August 28th, 2016, but it seems to have been distributed only the next day. Thus, we advise anyone who downloaded Transmission v2.92 between August 28th and August 29th, 2016, inclusively, to verify if their system is compromised by testing the presence of any of the following file or directory:

• /Applications/Transmission.app/Contents/Resources/License.rtf
• /Volumes/Transmission/Transmission.app/Contents/Resources/License.rtf
• $HOME/Library/Application Support/com.apple.iCloud.sync.daemon/icloudsyncd
• $HOME/Library/Application Support/com.apple.iCloud.sync.daemon/process.id
• $HOME/Library/LaunchAgents/com.apple.iCloud.sync.daemon.plist
• /Library/Application Support/com.apple.iCloud.sync.daemon/
• $HOME/Library/LaunchAgents/com.geticloud.icloud.photo.plist

If any of them exists, it means the malicious Transmission application was executed and that Keydnap is most likely running. Also note that the malicious disk image was namedTransmission2.92.dmg while the legitimate one is Transmission-2.92.dmg (notice the hyphen).

Similarity with KeRanger

If this modus operandi sounds familiar, you are totally correct. In March 2016, Palo Alto Networks published a blog post warning about the first OS X ransomware observed. In fact, Keydnap used the same technique to spread itself.

In both cases, a malicious block of code is added to the main function of the Transmission application. The code responsible for dropping and running the malicious payload is astonishingly the same.

Transmission’s main function dropping OSX/KeRanger

Transmission’s main function dropping OSX/Keydnap

Just like in the KeRanger case, a legitimate code signing key was used to sign the malicious Transmission application bundle. It’s different from the legitimate Transmission certificate, but is still signed by Apple and bypasses Gatekeeper protection.

# Malicious Transmission.app
$ codesign -dvvv /Volumes/Transmission/Transmission.app
Executable=/Volumes/Transmission/Transmission.app/Contents/MacOS/Transmission
Identifier=org.m0k.transmission
Format=app bundle with Mach-O thin (x86_64)
CodeDirectory v=20200 size=6304 flags=0x0(none) hashes=308+3 location=embedded
Hash type=sha1 size=20
CandidateCDHash sha1=37ffe70260919ee70e9f2a601d5ad00e2dd5a011
Hash choices=sha1
CDHash=37ffe70260919ee70e9f2a601d5ad00e2dd5a011
Signature size=4255
Authority=Developer ID Application: Shaderkin Igor (836QJ8VMCQ)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Signed Time=Aug 28, 2016, 12:09:55 PM
Info.plist entries=38
TeamIdentifier=836QJ8VMCQ
Sealed Resources version=2 rules=12 files=331
Internal requirements count=1 size=212

# Clean Transmission.app
$ codesign -dvvv /Volumes/Transmission/Transmission.app
Executable=/Volumes/Transmission/Transmission.app/Contents/MacOS/Transmission
Identifier=org.m0k.transmission
Format=app bundle with Mach-O thin (x86_64)
CodeDirectory v=20200 size=6304 flags=0x0(none) hashes=308+3 location=embedded
Hash type=sha1 size=20
CandidateCDHash sha1=a68d09161742573b09a17b8aef05f918a1cebcac
Hash choices=sha1
CDHash=a68d09161742573b09a17b8aef05f918a1cebcac
Signature size=8561
Authority=Developer ID Application: Digital Ignition LLC
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=Mar 6, 2016, 3:01:41 PM
Info.plist entries=38
TeamIdentifier=5DPYRBHEAR
Sealed Resources version=2 rules=12 files=328
Internal requirements count=1 size=180

ESET has notified Apple about compromised code signing key.

Beside the distribution method, Keydnap and KeRanger features some similarity in its code such as the C&C URL resource path and parameter.

• KeRanger: /osx/ping?user_id=%s&uuid=%s&model=%s
• Keydnap: /api/osx?bot_id=%s&action=ping&data=%s (parameters as POST data, encrypted with RC4)

Keydnap now at version 1.5

While reporting to the C&C server, Keydnap included an internal version. The one we observed in the new binary is 1.5.

It is still packed with the modified UPX described in our first article about Keydnap. The patch we published on Github to unpack the executable file still works with the new variant.

A significant change in the new version is the presence of a standalone Tor client. This enables Keydnap to reach its onion-routed C&C server without the need of a Tor2Web relay such asonion.to.

Inside Keydnap, curl is set to use the local Tor client as a proxy

There is only one additional command compared to the previous version we analyzed. This new command, with id 10, allows the C&C server to be set to a different URL and saves it on the disk.

The RC4 key used to encrypt HTTP POST data and decrypt the response changed to “u-4&LpZ!6Kgu^=$a“.

The hardcoded C&C URL is now hxxp://t4f2cocitdpqa7tv.onion/api/osx

IOCs

Transmission bundle

OSX/Keydnap dropper

OSX/Keydnap backdoor