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 named Transmission2.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.

keranger_main

Transmission’s main function dropping OSX/KeRanger

 

Transmission’s main function dropping OSX/Keydnap

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 as onion.to.

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

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

keydnap_v1.5_c2

How to remove OSX/Keydnap

To remove Keydnap v1.5, start by quitting Transmission. Then, in Activity Monitor, kill processes with any of the following names:

– icloudproc
– License.rtf
– icloudsyncd
– /usr/libexec/icloudsyncd -launchd netlogon.bundle

Remove the following files and directories:

– /Library/Application Support/com.apple.iCloud.sync.daemon/
– /Library/LaunchAgents/com.apple.iCloud.sync.daemon.plist
– /Users/$USER/Library/Application Support/com.apple.iCloud.sync.daemon/
– /Users/$USER/Library/Application Support/com.geticloud/
– /Users/$USER/Library/LaunchAgents/com.apple.iCloud.sync.daemon.plist
– /Users/$USER/Library/LaunchAgents/com.geticloud.icloud.photo.plist

Remove Transmission from your system and redownload it from a trusted source. The Transmission website and binaries are now hosted on Github. You can verify the hash and the signature of the legitimate binary package with:

– “shasum -a 256” and compare with the one on the site and
– “codesign -dvvv” and verify if is signed by “Digital Ignition LLC” with team identifier 5DPYRBHEAR.

IOCs

Transmission bundle

SHA-1 Filename ESET Detection name
1ce125d76f77485636ecea330acb038701ccc4ce Transmission2.92.dmg OSX/Keydnap.A

OSX/Keydnap dropper

SHA-1 Filename ESET Detection name
e0ef6a5216748737f5a3c8d08bbdf204d039559e Transmission OSX/TrojanDropper.Agent.A

OSX/Keydnap backdoor

SHA-1 ESET Detection name C&C Version
8ca03122ee73d3e522221832872b9ed0c9869ac4 OSX/Keydnap.A hxxp://t4f2cocitdpqa7tv.onion 1.5

Author , ESET

Follow us

Copyright © 2016 ESET, All Rights Reserved.