Threat Level: green Handler on Duty: Johannes Ullrich

SANS ISC: InfoSec Handlers Diary Blog InfoSec Handlers Diary Blog


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

Malware Sample Delivered Through UDF Image

Published: 2019-04-17
Last Updated: 2019-04-18 06:13:34 UTC
by Xavier Mertens (Version: 1)
1 comment(s)

I found an interesting phishing email which was delivered with a malicious attachment: an UDF image (.img). UDF means “Universal Disk Format” and, as said by Wikipedia[1], is an open vendor-neutral file system for computer data storage. It has supplented the well-known ISO 9660 format (used for burning CD & DVD) that was also used in previous campaign to deliver malicious files[2].

Here is a copy of the mail:

From: <redacted>
To: <redacted>
Subject: Overdue Invoice
Valued customer,
Attached is your invoice as scheduled, your credit/debit card will be charged. Your bill will be delivered along with your ordered items(s).
Please review the receipt at your earliest convenience and get back to us in case of anomalies.

Thank you for your continued patronage.

Warm regards.

The attached files was called "invoice#003.img" with the SHA256 hash: 886338ebc04e728338874b07365d4fd337998e1786893b680065358e815a6d02. At the moment, the file is flagged by 23 AV on Virustotal[3]. To read the content of the archive safely, you can use the ‘loop’ driver on a Linux system:

# mount -o loop /tmp/invoice\#003.img /mnt/malicious/
# ls -l /mnt/malicious
total 1296
-r-xr-xr-x 1 nobody nogroup 1325568 Apr 14 23:45 invoice#003.exe
# shasum -a 256 /tmp/malicious/invoice*
b3aef0e1d7a71edbc858a81e66f354be1974aafdd4449f2972e4dae1c82f2b8a  /mnt/malicious/invoice#003.exe

Here, the VT score is 35[4], it’s a classic malware written in AutoIT, nothing special. It tries to connect to kingdevil[.]ddns[.]net:4156.
Let’s have a look at the UDF image:

00008220: 2020 2020 2020 2020 2020 2020 2020 2020
00008230: 2020 2020 2020 2020 2020 2020 2020 494d                IM
00008240: 4742 5552 4e20 5632 2e35 2e38 2e30 202d  GBURN V2.5.8.0 -
00008250: 2054 4845 2055 4c54 494d 4154 4520 494d   THE ULTIMATE IM
00008260: 4147 4520 4255 524e 4552 2120 2020 2020  AGE BURNER!
00008270: 2020 2020 2020 2020 2020 2020 2020 2020
00008280: 2020 2020 2020 2020 2020 2020 2020 2020
00008290: 2020 2020 2020 2020 2020 2020 2020 2020
000082a0: 2020 2020 2020 2020 2020 2020 2020 2020
000082b0: 2020 2020 2020 2020 2020 2020 2020 2020
000082c0: 2020 2020 2020 2020 2020 2020 2020 2020
000082d0: 2020 2020 2020 2020 2020 2020 2020 2020
000082e0: 2020 2020 2020 2020 2020 2020 2020 2020
000082f0: 2020 2020 2020 2020 2020 2020 2020 2020
00008300: 2020 2020 2020 2020 2020 2020 2020 2020
00008310: 2020 2020 2020 2020 2020 2020 2020 2020
00008320: 2020 2020 2020 2020 2020 2020 2032 3031               201
00008330: 3930 3431 3530 3034 3635 3430 300c 3230  9041500465400.20
00008340: 3139 3034 3135 3030 3436 3534 3030 0c30  19041500465400.0
00008350: 3030 3030 3030 3030 3030 3030 3030 3000  000000000000000.
00008360: 3030 3030 3030 3030 3030 3030 3030 3030  0000000000000000
00008370: 0001 0049 6d67 4275 726e 2076 322e 352e  ...ImgBurn v2.5.
00008380: 382e 3000 0000 0000 0000 0000 0000 0000  8.0.............

ImgBurn is a well-known Windows tool used to create CD/DVD images[5] and guess what? A stock Windows handle this type of file without any extra tool:

So be careful with .img files! They should also be added to the list of prohibited file extensions in your mail relays or change the file association in your Windows environments to NOT open them Windowd Explorer.

[1] https://en.wikipedia.org/wiki/Universal_Disk_Format
[2] https://isc.sans.edu/forums/diary/Malicious+iso+Attachments/22636
[3] https://www.virustotal.com/#/file/886338ebc04e728338874b07365d4fd337998e1786893b680065358e815a6d02/relations
[4] https://www.virustotal.com/#/file/b3aef0e1d7a71edbc858a81e66f354be1974aafdd4449f2972e4dae1c82f2b8a/detection
[5] https://www.imgburn.com

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

1 comment(s)

A few Ghidra tips for IDA users, part 2 - strings and parameters

Published: 2019-04-17
Last Updated: 2019-04-17 00:09:44 UTC
by Jim Clausing (Version: 1)
0 comment(s)

Continuing with my preliminary exploration of Ghidra. If we continue with the call to RegOpenKeyExA from last time (yes, I know this code is unreachable as we discussed last time, but let's keep going anyway).

If we look back up at the first parameter, we see 0x80000001. Off the top of my head, I don't remember which key that is (well, actually, I've been doing this long enough that I do, but let's pretend that I don't). In IDA, I'd right-click on that hex value and choose 'Use standard symbolic constant' to replace that with the constant definition from one of the Windows header files that defines those. It turns out, Ghidra lets us do this, too. In Ghidra, right click and choose 'Set Equate' and it pops up a dialog box similar to IDA's from which you can choose the proper constant to use in place of the hex value.

Just like in IDA, if you know the constants for registry keys start with 'HKEY_' (or you looked it up on MSDN, now known as, docs.microsoft.com) you could start typing that and it would narrow down the choices. In this case, it is easily visible. So, double-click on 'HKEY_CURRENT_USER' or click and choose OK and the constant is replaced. Notice that you have the option here to just do the substitution for this one instance or across the entire program. I'm going to leave this at the default, but there may be times when you want to replace the hex value with the symbolic constant everywhere (nearly every time I teach FOR610 a student will ask me if IDA has that capability and, if it does, I'm not aware of it).

Looking above that at the second parameter, I usually want to know which particular subkey is being opened. In IDA, I just hover over the label for the string and it shows me the entire string. In Ghidra, if I hover over it, it shows me part of the string, but not the whole thing. Hmm... That is a bit of a problem. If I double-click on the label, both IDA and Ghidra take me to the place in memory where the string is located, but again, Ghidra doesn't show me the entire string. In the hex column it only shows me the first 9 bytes in hex and then gives me the ellipsis, but in the string part, it still doesn't show the whole thing. It shows the first 40-something characters and then the ellipsis.

In hunting around, I was not able to find a setting to increase that, though I'm sure there must be a way somewhere. If not in a setting, then in the code itself (which is now available on github). You can see the entire string though, if you go through the Search menu (choosing 'For Strings...' option). In this case, since I could see the CurrentVersion substring, I just searched for that and found the following.

In the end, though, I realized I didn't need to go to that much effort, there was a much easier way to see the string. Just go back to the decompiler window. As I mentioned in the previous diary, one way that the decompiler makes our lives as malware analysts much easier is it saves us the effort of having to try to match up the PUSHes or MOVes to figure out which parameter is which. This is especially true when you get into 64-bit malware on Windows which uses a lot more fastcall and the MOVes into registers may not appear in the order you expect. So, when I glance over into the decompiler window, I see this.

Very nice, it has my symbolic constant, it shows the entire string. That's just about everything I think I need to know about that API call.

I think that's enough for this diary, I have at least one more to come (probably next week). Again, as I mentioned in the first 2 entries in this series, this is all just from a very brief time playing with Ghidra. I haven't had a lot of time to dig deep yet, but so far, I'm liking what I'm finding. If you have any thoughts, comments, corrections, or tips of your own, please e-mail me or use the comments below.

---------------
Jim Clausing, GIAC GSE #26
jclausing --at-- isc [dot] sans (dot) edu

0 comment(s)
Diary Archives