Threat Level: green Handler on Duty: Didier Stevens

SANS ISC: InfoSec Handlers Diary Blog - Internet Storm Center Diary 2019-05-01 InfoSec Handlers Diary Blog


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

Another Day, Another Suspicious UDF File

Published: 2019-05-01
Last Updated: 2019-05-02 06:22:18 UTC
by Xavier Mertens (Version: 1)
0 comment(s)

In my last diary, I explained that I found a malcious UDF image used to deliver a piece of malware[1]. After this, I created a YARA rule on VT to try to spot more UDF files in the wild. It seems like the tool ImgBurn is the attacker's best friend to generate such malicious images. To find more UDF images, I used the following very simple YARA rule:

rule ImgBurnedFile
{
    strings:
        $s1 = "ImgBurn v2" nocase wide

    condition:
        all of them and new_file
}

I received some false positive hits but one file looked particularly interesting. In YARA rules, when you specify the keyword “wide”, YARA will search for strings encoded with two bytes per character (read: Unicode).

The file that I spotted was indeed in Unicode text and scored "0" on VT (SHA256: bef7985aa8bda67e628de4100ce5d7f1e26754199578d7fc72ddbe00f3427c9f)[2]

$ file bef7985aa8bda67e628de4100ce5d7f1e26754199578d7fc72ddbe00f3427c9f.bad
bef7985aa8bda67e628de4100ce5d7f1e26754199578d7fc72ddbe00f3427c9f.bad: Unicode text, UTF-32, little-endian

I decoded the file with the iconv tool and got an ISO9660 image:

$ iconv -c -f UTF-16LE -t ASCII bef7985aa8bda67e628de4100ce5d7f1e26754199578d7fc72ddbe00f3427c9f.bad \
    >bef7985aa8bda67e628de4100ce5d7f1e26754199578d7fc72ddbe00f3427c9f-decoded.bad
$ file bef7985aa8bda67e628de4100ce5d7f1e26754199578d7fc72ddbe00f3427c9f-decoded.bad
bef7985aa8bda67e628de4100ce5d7f1e26754199578d7fc72ddbe00f3427c9f-decoded.bad: ISO 9660 CD-ROM filesystem data 'NEW_FOLDER'

But it was impossible to mount the image:

$ mount -t iso9660 -o loop \
    bef7985aa8bda67e628de4100ce5d7f1e26754199578d7fc72ddbe00f3427c9f-decoded.bad /mnt/udf
mount: /mnt/udf: wrong fs type, bad option, bad superblock on /dev/loop3, missing codepage or helper program, or other error.

While discussing about this file with Didier, he found that the file was also converted from UNIX to Dos (with 0x0A’s replaced by 0x0D0x0A’s). I found 52 occurences of ‘\r\n’ in the file:

$ grep --binary "\r\n" -c bef7985aa8bda67e628de4100ce5d7f1e26754199578d7fc72ddbe00f3427c9f-decoded.bad
52

I converted them using dos2unix:

$ dos2unix -f -n bef7985aa8bda67e628de4100ce5d7f1e26754199578d7fc72ddbe00f3427c9f-decoded.bad \
    bef7985aa8bda67e628de4100ce5d7f1e26754199578d7fc72ddbe00f3427c9f-decoded-unix.bad
dos2unix: converting file bef7985aa8bda67e628de4100ce5d7f1e26754199578d7fc72ddbe00f3427c9f-decoded.bad to file \
    bef7985aa8bda67e628de4100ce5d7f1e26754199578d7fc72ddbe00f3427c9f-decoded-unix.bad in Unix format...

Once again, no luck, the image could not be mounted. As Didier likes to work more with Windows tools, he decoded the file on his side with UltraEdit and successfully mounted the image via the tool UltraISO. Finally, it was possilble to extract the PE file ‘SHIPMENT.EXE’ (SHA256: 22238c4b926d3c96d686377d480e5371d22a5839367db687922242c45c8321dc). The PE file is corrupted probably due to the aggressive search/replace of all ‘\r\n’ in the file. The PE file is a compiled AutoIT script. I uploaded the sample by myself on VT and it got a score of 11/71[3].

The next question is: Why was the initial file encoded? It is to download it as a second stage in a stealthy way? The stage one should then decode it properly (but how to not corrupt the PE file?). Did you already seen the same kind of malicious UDF images, please share!

[1] https://isc.sans.edu/forums/diary/Malware+Sample+Delivered+Through+UDF+Image/24854/
[2] https://www.virustotal.com/#/file/bef7985aa8bda67e628de4100ce5d7f1e26754199578d7fc72ddbe00f3427c9f/detection
[3] https://www.virustotal.com/#/file/22238c4b926d3c96d686377d480e5371d22a5839367db687922242c45c8321dc/detection

Xavier Mertens (@xme)
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key

0 comment(s)

VBA Office Document: Which Version?

Published: 2019-05-01
Last Updated: 2019-05-01 20:37:14 UTC
by Didier Stevens (Version: 1)
0 comment(s)

In some cases, like malicious Word documents without VBA source code, you want to know which version of Office was used to create the VBA macros. Because compiled macros (VBA) don't run on all versions.

This information can be found inside the _VBA_PROJECT stream:

The 3rd and 4th bytes in this stream are a little endian word, whose value indicates the version of Office that was used to create the VBA code. This is all documented by Microsoft, except for the field values themselves.

Here is a list I compiled for different Office versions (Windows):

Office Version 32-bit 64-bit
95 0x0004 N/A
XP 0x0073 N/A
2003 0x0079 N/A
2007 0x0085 N/A
2010 0x0097 0x0097
2013 0x00A3 0x00A6
2016 0x00AF 0x00B2
2019 0x00AF 0x00B2

 

 

 

 

 

 

 

 

 

If you have other info for other versions, please post a comment or submit a sample.

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com DidierStevensLabs.com

Keywords: maldoc vba
0 comment(s)
Diary Archives