Threat Level: green Handler on Duty: Jan Kopriva

SANS ISC: Another Malicious Document, Another Way to Deliver Malicious Code SANS ISC InfoSec Forums

Participate: Learn more about our honeypot network
https://isc.sans.edu/honeypot.html

Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!
Another Malicious Document, Another Way to Deliver Malicious Code

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
 Xme

527 Posts
ISC Handler
Subscribe Mar 7th 2016
4 years ago
We fixed this a long time ago. GPO restrict to the Nth dir on %appdata%,%localappdata%, and %temp% things like java updates and what not come to be a "problem" but worth the hassle if you think of the thing you could run into. 90% of malware run in %appdata% now days let the delivery method run, the file they drop in %appdata%/somedir/some.exe get execution restriction game over.

This goes without say users should never have admin privileges as this could defeat the GPO. would also pick up on the .js attack method by disallowing or as stated in a previous article just allow edit instead of run.
 Anonymous
Quote Mar 8th 2016
4 years ago
Quoting Anonymous:This goes without say users should never have admin privileges as this could defeat the GPO. would also pick up on the .js attack method by disallowing or as stated in a previous article just allow edit instead of run.



So, how does that work with employees that must have (like in the name of sales) or field techs that must have admin privileges to do their job? The only way I have found to "keep the crap" on the other side of the FW, is put them all on DMZ on sanctioned/ stand alone machines. But that isn't 100% with exchange et al.

Fact is, I am nonplussed to see the "stupidity" of users, even after all that education with their "smart phones". <roll eyes>

Any suggestions? (that will not disrupt business continuity)

Regards,

IC
 ICI2I

63 Posts
Quote Mar 8th 2016
4 years ago

Sign Up for Free or Log In to start participating in the conversation!