Tuesday, December 27, 2016

Analysis of August stealer malware

NOTE: This blog has been merged with WordPress. You will be redirected to this article on the WordPress site in 10 seconds...

If you want to go there now, click here - https://hazmalware.wordpress.com/2016/12/27/analysis-of-august-stealer-malware/

August malware is designed to steal various data from compromised systems. It was observed appearing for sale around 10/20/2016. According to the malware authors post on underground forums it has the ability to steal various passwords, cookies, bitcoin wallets, RDP and FTP saved connections, and can even grab specified files. At the time of this writing the latest version can steal data from the following applications:

Mozilla FireFox
Google Chrome
Comodo IceDragon
Vivaldi Browser
Mail.Ru Browser
Torch Browser
Dooble Browser
U Browser
Amigo Browser
Yandex Browser
Opera Browser
SRWare Iron
CoolNovo Browser
RockMelt Browser

FTP Clients:
Total Commander

Email Clients:
MS Outlook <= 2013
Mozilla Thunderbird

IM Clients:
Windows Live

Bitcoin Wallets:

RDP remote connection files

Any specified files/documents

Here is a look at the admin panel of this malware:
The malware has been observed being delivered in malspam emails that have word document attachments. It is the typical phishing type email that entices the user to open the attachment. The word documents contain VBA that will use powershell to download the malware payload from a remote URL where it is encoded into a byte array in the webpage. It is then programmed to load the byte array and decode it with an exclusive or (XOR) and call the main function from the loaded executable.

This post is geared more towards the binary analysis of the August malware, but the great people over at Proofpoint have done a fantastic job on an overview of the threat - you can read it on their blog here. So let's continue with our analysis.

Running the strings command on files can often give you quite a bit of interesting information regarding the sample you are analyzing. You have to be careful though, because strings can sometimes be misleading as malware authors can put junk strings in to confuse analysis -- remember to validate anything you find. Here are a few of the interesting strings I found in this sample:
You can see that there appears to be some strings related to crypto functions, encryption, decryption, HTTP functions, and even some anti-debugging. There are many, many more but we have to consolidate for the post. One of the more interesting items is the strings 'ConfusedByAttribute' and 'Confuser v1.9.0.0'.

Confuser is a packer / obfuscation tool for .NET applications. It offers a variety of obfuscation methods such as anti-debugging, anti-memory dumping, anti-decompiling, encrypting constants,  methods, and resources, etc.

When analyzing an unknown binary it is always good to verify what type of file you are dealing with. PEiD shows that this is a .NET executable designed for 32 bit computers.
DiE (detect it easy) is another good tool to analyze exe files, especially if you think it might be packed. Looking at our sample it shows again that this is a .NET executable and it was designed for 32 bit. It also shows that this sample was packed with Confuser v1.9.0.0 - just like we saw in our strings.
It is good practice to not just rely on a single source of information, but to verify with multiple sources. CFF Explorer is one of my favorite apps for analyzing binary files because it gives you so much detailed information. Looking at this in CFF shows much of the same.
We see that the File Type is listed as a Portable Executable 32 .NET Assembly and File Info shows Microsoft Visual Studio .NET. So we are probably dealing with a .NET file... but let's do a little more analysis just to make sure. Do not pay attention to the created/modified/access times as these are when this binary was copied to the windows analysis computer... remember windows MAC time rules.

The Dos Header shows the 4D5A MZ magic number indicating that this is an executable file.
Checking the Optional Header info we can see the 2 byte value 010B (PE32) indicating that it is designed as a 32 bit application.
In the Data Directories section, under NT Headers -> Optional Header, we can see that .NET MetaData Directory RVA & Size on the right details page both contain values. These are good indications that we are indeed dealing with a .NET executable.
One last thing to verify - .NET files only have 1 import and 1 function imported. Here we see mscoree.dll and _CorDllMain, respectfully:
We can now confidently say that we are dealing with a .NET executable file.
There are a couple of other items of interest that we will take a look at. The exe compile datetime that shows the date and time the project was compiled from VisualStudio. This can easily be changed by anyone with a little knowledge. The compile time for this binary shows the following
Which converted becomes
Given other indicators going on for this around the same time, confidence is pretty high that the compile time is legit. The other item of interest is the module directory that shows the name of this file at compile time. Because anyone can rename a file at anytime, this entry will often show the original name of the file the malware author had set at the time it was compiled. Here we see it was indeed called 'August@.dll'
Now that we know we are dealing with a .NET file, we can open it up in a decompiler and see what we get.
All of the methods and assemblies are encrypted by the Confuser packer that was identified earlier.
Looks like we're going to have to decrypt it first before analyzing. For this we can use a program called NoFuser to help with decryption. Running our binary through NoFuser shows that it detected Confuser v1.9 as well and successfully cleaned our binary.
Now open it back up in side the decompiler and we should have readable data.
Moving into the Main() method, because this is where code execution starts, we see that right away the malware hides itself by setting the FileAttribute to 'Hidden'.

Next it has functions to check whether there are analysis programs currently running as processes, and will sleep for 20000ms if it finds any (roughly 30 seconds).
It then gathers some information about the computer that it has just infected, such as the type of CPU, amount of RAM, networking info, etc.

It also grabs the username of the person currently logged in
It then encrypts the data and sends it to the pre-programmed C2 server via the following web request

We can see that it is using a POST method and has a timeout value set to 100000ms. The C2 URL value is completely configurable and will change from sample to sample.

After checking in with its C2 the malware immediately begins its data exfiltration routines. Checking through the code shows functions for all the data exfil types listed at the beginning of this post. I will not list all of the code here for brevity sake.
All-in-all this is a pretty interesting sample. I am still analyzing and learning more about it, but I think that about wraps it up for this post!

The sample analyzed in this post was found on hybrid-analysis over here.
FiletypePE32 executable (DLL) (console) Intel 80386 Mono/.Net assembly, for MS Windows

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.