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:
- $HOME/Library/Application Support/com.apple.iCloud.sync.daemon/icloudsyncd
- $HOME/Library/Application Support/com.apple.iCloud.sync.daemon/process.id
- /Library/Application Support/com.apple.iCloud.sync.daemon/
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.
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.
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.
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
|SHA-1||Filename||ESET Detection name|
|SHA-1||Filename||ESET Detection name|
|SHA-1||ESET Detection name||C&C||Version|
Working as a cyber security solutions architect, Alisa focuses on application and network security. Before joining us she held a cyber security researcher positions within a variety of cyber security start-ups. She also experience in different industry domains like finance, healthcare and consumer products.