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