I was kindly forwarded a sample of a phishing email crafted to appear as an Australia Post missed delivery noticed.

Someone is certainly trying to deliver something (which isn’t a parcel), so my goal is to figure out what that is exactly.

Note: I have included some general Phishing information. If you wish to skip, go directly to (anchored links):

• Part 1: Attack Vector
• Part 2: Binary Analysis

**Disclaimer: This is all carried out in a controlled, isolated environment. Do not try this at home. Seriously. I will not be held responsible if you infect yourself, chances are all sorts of nasty things will happen (E.G. the theft of your online banking details). **

Part 0: A few tips on identifying phishing emails:

I thought I would just include a few tips as to how this was quickly identified as phishing for any of the less-technical readers out there.

There are countless resources on the Internet, so I won’t dwell too much. If you want to skip to the juicy stuff, scroll down.

Hint #1: Prior Knowledge:

The very first thing I noticed was the layout of the email. Having received emails from AusPost previously, I know this is not what they look like. I’m tempted to say this is a poor effort, since normally the emails at least copy the formatting details of official emails.

Knowledge of what an email is supposed to look like, or more accurately gut feeling is a great help in identifying potential phish.

Tip No. 1: Does the email look like you would expect? If it doesn’t, then there’s good chance it’s phishing.

Hint #2:* Mail from: *address/domain:

Secondly, the email domain does not make sense. Why would Australia Post send from anywhere but auspost.com?

post-daily.net is suspicious and should set off an alarm bell in your head.

As it happens, post-daily.net doesn’t even closely resemble anything AusPost would use:

It’s good habit to verify the from address, but keep in mind this can be easily faked.

Tip No 2: Check the mail from address (NOTE: It is trivial to spoof this, don’t rely on it).

Hint #3: Hyperlinks:

I am naturally dubious about hyperlinks in emails, and unfortunately in this day and age I think it is useful to be suspicious and verify each link by clicking. This can be done, in general (Your mileage may vary depending on the email client), by hovering the mouse cursor over the link to display the full link.

As you can see here, the link is to the site post-daily.net. You should not go any further, as it is a reasonable assumption that the domain is not associated with Australia Post. If in doubt, get in contact with the company in question to verify the domain.

It’s also good to manually type in the official website if you are familiar with the company.

AusPost maintains a page on scams here: http://auspost.com.au/about-us/online-security-scams-and-frauds.html

Tip No 3: Always verify hyperlinks

Tip No 4: If in doubt, contact the company in question.

So lets go against everything I just said and get into the juicy stuff…

Part 1: Attack Vector

This particular email follows the traditional phishing method. An email with some text designed to be convincing, internally linked to a website which is a direct replica of the official website one would be expecting.

Constructing a replica website for these purposes is not hard to do, and basically goes something like this:

1. Visit http://auspost.com.au/track
2. Right click -> View Source
3. CTRL + A
4. Copy
5. Paste
6. ???
7. Profit!

This of course can be confirmed by checking the address you are visiting:

The website will have you enter a CAPTCHA to download your ‘package information’ (If you’re familiar with using AusPost tracking, you will know they don’t implement CAPTCHA’s to retrieve tracking info). I have not identified the relevance of the CAPTCHA – My immediate thought is to thwart automated analysis of the site, but it could simply be to make the site seem more authentic.

If anyone out there has any ideas, let me know.

Anyway, once you successfully complete the CAPTCHA you will download a file – *information_2cb992b4c981b9d36ddf1e478fa2cbff.rar *(Exact file name will vary) – and request you to install a RAR extractor if you don’t already have one. The archive extracts to pdf_information_about_your_parcel.exe

Just a little suspicious.

Information:

Packed RAR VirusTotal analysis here: https://www.virustotal.com/en/file/87612de7cde6eeb64b8a742aff7bc594c85e911383aa397254ae545f53cc35c9

Extracted PE file VirusTotal anaylsis here: https://www.virustotal.com/en/file/608dd63276415822a557ced98c3bc80aa57f6a95f02d896fd7c05c54244148cf

Initial behavioural analysis in a Cuckoo Sandbox instance (Executed on Windows XP SP3) is available for your perusal here: /files/cuckoo_task_46.html

Part 2: Payload Analysis

The downloaded executable is a Microsoft CIL (MSIL) .NET binary, written in C#. This is useful because it can be decompiled into something that resembles the original source code:

So the executable appears to be a 2-stage unpacker. The initial file contains a small amount of code and the rest of the payload is embedded within a .NET resource.

The initial program will unpack and run another unpacker from within the resources. (unpackerception?)

The code will initially extract a small binary called KazyLoader from the resources. KazyLoader is stored within the resources file, and the unpacker will iterate through each byte and load it into a byte array for execution:

Here you can see there resource files it is loading from:

I find it interesting that initially the program will create a byte array the size of the program itself (new byte[this] – though I couldn’t get my compiler to be stop complaining about that). Later, the array is reallocated with a new size matching the size of the extracted data. This is somewhat inefficient, and could be in an attempt to confuse anyone running the program through a debugger. If that’s the case though, it’s a very poor attempt as stepping through will reveal the actual size.

Initial definition of byte array:

Re-definition:

The embedded executable will then be loaded and executed:

This is the result of the extraction – “KazyLoader” is executed:

KazyLoader is a very small (4K) application which will look in the resources file for a bitmap of a certain name. Once the data is loaded, it tries to decrypt the resulting data using the cipher provided as an argument. This program accepts the name of the resources file, the name of the bitmap, the cipher and any arguments to be passed to the payload as command line arguments.

Data load from Bitmap and subsequent 3DES decryption attempt:

It is at this point the decryption fails. Not only during my analysis, but also when the malware executes as per normal in a test environment (I also tested on a vanilla physical machine, just for good measure).

A quick search for KazyLoader doesn’t turn up much, other than an association with Karagany, though the association between that and what I’m seeing here doesn’t seem that strong (Unless the encrypted data is Karagany?)

I am working on it, so more to come in Part 3 (Which will be fairly uninteresting if I can’t get the thing decrypted).

Final note: Have I made an error? Have I got the whole thing completely wrong? If you have any feedback, please let me know! Use the ‘Contact’ link at the top of the page.