OSX Ransomware Spread via a Rogue BitTorrent Client Installer

Published: 2016-03-07
Last Updated: 2016-03-07 10:42:18 UTC
by Xavier Mertens (Version: 1)
5 comment(s)

More a tool, a platform or an environment is popular, more it will be targeted. Those who still think that they are safe with their OSX environment are wrong. Manuel wrote a diary two months ago about a ransomware written in JavaScript (and that could affect different environments). Yesterday, a native malware for OSX has been detected and analyzed by Palo Alto Networks. It is called "KeRanger" and is spread via a malicious installation package of Transmission, a popular BitTorrent client. The malicious file was available for download on the official Transmission website which suggests that it was maybe compromised.
 
Once installed, the ransomware will wait three days before activating itself. It communicates with its C2 via Tor. The ransom is 1BC (~$400). Note that the binary is signed with a legit developer certificate and that it also attempts to encrypt TimeMachine backups (which are very popular and used by most OSX users!). 
 
The malicious file MD5 is 24a8f01cfdc4228b4fc9bb87fedf6eb7 and its current VT score is 0!

Xavier Mertens
ISC Handler - Freelance Security Consultant
PGP Key

5 comment(s)

Another Malicious Document, Another Way to Deliver Malicious Code

Published: 2016-03-07
Last Updated: 2016-03-07 10:09:15 UTC
by Xavier Mertens (Version: 1)
2 comment(s)

I’m operating several catch-all mailboxes that help me to collect interesting emails. Besides the classic spam messages which try to sell me colored pills and to promise me millions of revenue, I’m also receiving a lot of malicious documents. For a few weeks, I can see a huge peak of emails: 

Most of them are the same and belongs to the massive waves of campaigns that try to hit as many victims as possible. If we see an increase of JScript files (.js) for a while, VBA macros in OLE documents remain classic. If the very-first macros tended to download a malicious executable from a 3rd party compromised website via Microsoft.XMLHTTP, some attackers are embedding the payload directly to the Office document. I already wrote a diary about the analysis if such document. By using this technique, the victim does not “phone home” to the wild Internet and computers without a network connectivity can also be infected. This time, I found another one that also embedded the payload but the technique was different.
 
The file that I received was called “walmart_code.doc” and its original VT score was 5/54 (yesterday, it reached 23/54). Let’s have a first look at it. When you open the file, it asks you to enable macros if not already done. Always the same method to entice the user to activate them.
Let's have a look at the file content:
# file walmart_code.doc
​walmart_code.doc: Composite Document File V2 Document, Little Endian, Os: Windows, Version 6.2, Code page: 1251, Template: Normal.dotm, Revision Number: 1, Name of Creating Application: Microsoft Office Word, Create Time/Date: Wed Mar  2 10:50:00 2016, Last
Saved Time/Date: Thu Mar  3 13:49:00 2016, Number of Pages: 1, Number of Words: 6, Number of Characters: 36, Security: 0
# oledump walmart_code.doc
  1:       114 '\x01CompObj'
  2:       284 '\x05DocumentSummaryInformation'
  3:       404 '\x05SummaryInformation'
  4:      8706 '1Table'
  5:     17276 'Data'
  6:       482 'Macros/PROJECT'
  7:        65 'Macros/PROJECTwm'
  8: M    1645 'Macros/VBA/Module1'
  9: M    4408 'Macros/VBA/ThisDocument'
 10:      3054 'Macros/VBA/_VBA_PROJECT'
 11:       565 'Macros/VBA/dir'
 12:    158418 'ObjectPool/_1518536137/\x01Ole10Native'
 13:         6 'ObjectPool/_1518536137/\x03ObjInfo'
 14:      4142 'WordDocument'
 
We have two macros that perform malicious code. They are simple and strings aren’t obfuscated with high-level techniques. The function used is: 
Public Function WejndHw(vbhs As Integer)
    WejndHw = Chr(vbhs)
And most parameters are passed as simple mathematical expressions like:
fdda = 7 - 8
RTQCDW = WejndHw(40 + 6)
RREW = RTQCDW + WejndHw(8 + 94 + fdaa)
RREW = RREW & "x" + WejndHw(10 + 81 + 10) .exe
UUIIW = RTQCDW & WejndHw(-6 + 110 + 10) & WejndHw(4 + 110 + 2) + "f"
Which gives us:
  • RREW = .exe
  • UUIIW = .rtf
The malicious .exe file is saved on the file system in the %TEMP% directory. But where is a payload? In this case, the OLE file has another interesting section (number 12 in the output above) that is an Object Pool. OLE documents can embed other files and are stored in the Ole10Native format. The structure of this format is:
  • First 4 Bytes – Unknown?
  • Next 2 Bytes – Usually 2 (02 00)
  • From 7th Byte, the name of the embedded file starts.
  • The original full path of the embedded file starts after that. Scan the path till null character.
  • Next 4 bytes are unknown
  • Next 4 bytes represents the length of the temporary file path before it got inserted to the document. This will be in little endian format and we need to convert it.
  • The temporary file path starts after that. We can either skip this using the length retrieved or scan the path till null character.
  • Next 4 bytes represents the size of the embedded file in little endian format. We need to convert it.
  • The actual file contents starts from here. Read the file till the length retrieved previously.
  • The next 4 bytes gives the length of the temporary location of the file in Unicode.
  • Temporary location of the file in Unicode starts from here.
  • Finally, the source file path in Unicode starts

This is exactly what we have in the section number 12 of the OLE document:

# hexdump -C 12.tmp 
00000000  ce 6a 02 00 02 00 20 00  43 3a 5c 41 61 61 61 5c  |.j.... .C:\Aaaa\|
00000010  65 78 65 5c 69 64 64 32  2e 65 78 65 00 00 00 03  |exe\idd2.exe....|
00000020  00 27 00 00 00 43 3a 5c  55 73 65 72 73 5c 4d 5c  |.'...C:\Users\M\|
00000030  41 70 70 44 61 74 61 5c  4c 6f 63 61 6c 5c 54 65  |AppData\Local\Te|
00000040  6d 70 5c 69 64 64 32 2e  65 78 65 00 00 6a 02 00  |mp\idd2.exe..j..|
00000050  4d 5a 90 00 03 00 00 00  04 00 00 00 ff ff 00 00  |MZ..............|
00000060  b8 00 00 00 00 00 00 00  40 00 00 00 00 00 00 00  |........@.......|
00000070  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000080  00 00 00 00 00 00 00 00  00 00 00 00 f8 00 00 00  |................|
00000090  0e 1f ba 0e 00 b4 09 cd  21 b8 01 4c cd 21 54 68  |........!..L.!Th|
000000a0  69 73 20 70 72 6f 67 72  61 6d 20 63 61 6e 6e 6f  |is program canno|
000000b0  74 20 62 65 20 72 75 6e  20 69 6e 20 44 4f 53 20  |t be run in DOS |
000000c0  6d 6f 64 65 2e 0d 0d 0a  24 00 00 00 00 00 00 00  |mode....$.......|
000000d0  d5 b9 cf 21 91 d8 a1 72  91 d8 a1 72 91 d8 a1 72  |...!...r...r...r|

Let’s extract the PE file by skipping the 80 first bytes:

# oledump.py -s 12 -d walmart_code.doc | cut-bytes.py 80: >12.exe
# file 12.exe
12.exe: PE32 executable (GUI) Intel 80386 system file, for MS Windows
# md5sum 12.exe
​f10ae3915fbbea438ec15ce680f670f5  12.exe

Here is the link to VT.

Xavier Mertens
ISC Handler - Freelance Security Consultant
PGP Key
2 comment(s)
ISC Stormcast For Monday, March 7th 2016 http://isc.sans.edu/podcastdetail.html?id=4897

Comments


Diary Archives