BitTorrent Client ‘Transmission’ Dropping Keydnap Malware on Mac Devices



POPULAR BITTORRENT CLIENT TRANSMISSION GOT THEIR WEBSITE INFECTED WITH KEYDNAP MALWARE — THE SAME MALWARE WAS DETECTED A COUPLE OF MONTHS AGO TARGETING MAC USERS.
In July this year we reported on Keydnap malware targeting Mac users, stealing OS X system keychain and maintaining a permanent backdoor. Now, researchers have discovered the same malware in the website of a BitTorrent client called Transmission and yet again target is none other than Mac users.
The IT security researchers at ESET were the first one to discover this malware back in July and this time, it’s the same researchers who have exposed the OSX/Keydnap with additional capabilities of using Transmission BitTorrent client through its official website.
“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.”
Currently, it is unclear how Transmission website was distributing OSX/Keydnap but according to ESET researchers, the malware has been removed from the site however those who downloaded Transmission client in the last couple of days should scan their Mac if it has been infected by Keydnap or not.
Remember, other than stealing OS X system keychain, the Keydnap malware keeps a permanent backdoor that can allow attackers to remotely target an infected Mac device. 
If you have download Transmission BitTorrent client, check if your 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
Transmission has also started a Faq section dedicated to answering its users about Keydnap malware according to which:
“It appears that on or about August 28, 2016, unauthorized access was gained to our website server. The official Mac version of Transmission 2.92 was replaced with an unauthorized version that contained the OSX/Keydnap malware. The infected file was available for download somewhere between a few hours and less than a day.”

This is not the first time when Transmission was found delivering malware on Mac devices. In fact, the first ever Mac ransom malware was also spreading itself through Transmission’s website.



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.dmgwhile 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 asonion.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
IOCs
Transmission bundle
SHA-1FilenameESET Detection name
1ce125d76f77485636ecea330acb038701ccc4ceTransmission2.92.dmgOSX/Keydnap.A
OSX/Keydnap dropper
SHA-1FilenameESET Detection name
e0ef6a5216748737f5a3c8d08bbdf204d039559eTransmissionOSX/TrojanDropper.Agent.A
OSX/Keydnap backdoor
SHA-1ESET Detection nameC&CVersion
8ca03122ee73d3e522221832872b9ed0c9869ac4OSX/Keydnap.Ahxxp://t4f2cocitdpqa7tv.onion1.5
soure: hackread . welivesecurity
Share on Google Plus

About ANON JEKLOY

    Blogger Comment
    Facebook Comment

0 comments:

Post a Comment

loading...