AutoIT Malware. A detailed analysis

This is a sample that came to my hands by a spam campaign, and caught in a corporate honeypot. Make a comment under this post with your email if you want a sample.

Sorry for some false positive AV alarms while browsing this post.. It was due to some code listings. I removed the AutoIT script, but it can be found here: https://www.dropbox.com/s/xu1ra236lx8n5dc/clean.au3?dl=0 .

~ Due to big amount of requests, I uploaded the sample here too. Pass is “malware” ~
Here is an overview of what you’re going to see in this post:

3) LoadPE method (by the AutoIT script) using an encrypted drop
– making a custom script to decrypt the drop (RC2 encrypted usign CryptoAPI)
– analysis of the final malware. What data does it collect, which format, how does it send them and where.
– reveal some console log messages of the app by just changing it’s IMAGE_SUBSYSTEM byte from PE Header

..so let’s go..

1) First malware file

The mail attachment, contained this file. An executable with a custom icon. After a fast static analysis, it is recognised to be a WinRAR SFX executable with some dummy comments.

Mail attachment is a WinRAR SFX

WinRAR SFX Contents

Executing the SFX, drops those 4 files in %userprofile%yzvf382a42256 with hidden and system attributes. Then, the update.exe file is being executed.Notice the BIG file in the sfx file.. 331MB file with .PBS extension

2) Drops: update.exe and other 3 files..

First of all, with a fast static analysis (strings and resources) update.exe seems to be the AutoIT script interpreter. For those who know about AutoIT, the executable’s icon witnesses the AutoIT existence.

So there is an interpreter, and there must be the source file to execute.. Searching the 3 files, the AutoIT script file is jqanjzruzb.PBS … The 331MB file. Opening the file we can see (after the time of editor’s stack time 😛 ) that the script is there.. but we can’t clearly see and analyse the source cos of many tab characters, and dummy comments! Author probably used that method as a type of obfuscation for the script file.

I made a python script to “deobfuscate” that AutoIT script source of 331MB .. It counts and removes the tab chars, recognises and removes the “dummy comment” and some dummy new lines.. Python script receives as argument 1) the AutoIT obfuscated file (the big one) and 2) the new file of the clear/deobfuscated script. Then the result is a clear AutoIT source script. The python script that deobfuscates the file, is this:

The script file before deobfuscation is 331MB and looks like this in the AutoIT editor (notice the scrollbar):

AutoIT script with tabs.In the original state

This is how the deobfuscation is done (i call the script clean_script.py) and lasts about 6 minutes:

python cleaner command line args

After the "clean" operation, the clean file is 55kbyte in size! And has the following contents:

File has been removed due to false positives from AVs! Sorry..
Uploaded here for everyone who is interested:
https://www.dropbox.com/s/xu1ra236lx8n5dc/clean.au3?dl=0

..a bit of AutoIT script analysis

There is a lot of source code in this script, lot of functions, and huge functionality. The most important sections, is where the script "decides" which will be it's functionality, how does it protect itself (persistence, process protection), what is it's main functionality and how does it communicate with the cybercriminals.

First of all we have to analyse the other dropped files...! There are total 4 files dropped by the SFX. The one is the update.exe (AutoIT interpreter) the other is the above script, and the other two not mentioned yet.. Well here they are:

1) oziryzkvvcpm.AWX - which has a small size, looks like an INI file.. probably some settings recognised by the AutoIT script.2) sgym.VQA - a binary with random data.. Maybe another encrypted malware executable/payload !

Above you see the code that is responsible for reading the INI file oziryzkvvcpm.AWX which decides for the AutoIT functionality. The example above, shows what does those INI sections mean.

- The 5242747 section means persistence. The malware calls the startup function which adds the classic registry key for system startup (HKCU64SoftwareMicrosoftWindowsCurrentVersionRunOnce) and a shortcut to Start menu -> Programs -> Startup.
- The antis1 section is not present in the INI file, meaning that the antis function will not be executed. It means anti-protections. Like VM protections etc. It is an example of the many functionalities, which is not used in this malware!
- The 8472254 section means bsod anti-hook/process protection method! This functionality, sets the AutoIT executable as a critical section, and if it is killed, we have a bsod. This method is used for process protection by lot of malware authors. Detailed method can be seen here.
- The 5152433 section means that the AutoIT executable will check for the vbs script (which is dropped by this AutoIT script, and used to run the update.exe giving as argument the AutoIT script) existence, and also checks/adds the registry persistence keys.
- The 9537477 section contains a decryption key! If you follow the function _crypt_decryptdata you'll recognise that there are calls to Windows CryptoAPI and decrypts the sgym.VQA file using RC2 algorithm, and key the string "yzvf382a42256" taken from the ini file (which is also the name of the malware's folder). The decrypted file is probably a PE cos later in code, it injects it in memory (LoadPE method) of another process (RegSvcs.exe, RegAsm.exe, etc)

Let's make sure that the final file sgym.VQAis an encrypted executable.. The fast way to recognise that, is Ollydbg. We have to break in the correct point (breakpoint on CryptDecrypt function of advapi32.dll) of the process update.exe (the interpreter of the above AutoIT script AFTER the malware is running.) while the malware is running (update.exe with "jqanjzruzb.PBS" argument)

Notice: Our goal is to reverse the malware.. NOT the AutoIT interpreter!

This is the point where Olly breaks while the AutoIT script is running, and CryptDecrypt is called to decrypt the potential encrypted malware from sgym.VQA file:

When olly breaks on CryptDecrypt API

The 5th argument of CryptDecrypt is the most interesting, it is the buffer containing the crypted data. Also the 6th arg contains the length of the encrypted data, and after the function returns, it will contain the length of the decrypted data. When we have a break (before the decryption) the size is 0x6F008 what means 454664 in decimal, which is the exact size of the sgym.VQAfile. We are sure that it will be decrypted after the call! After pressing CTRL-F9 in Ollydbg :

After CryptDecrypt Decrypts the data..

And yes it's a PE..! The first thing is to dump it from Olly memory. It will work that way. It is a .NET executable.. I made an AutoIT script which will decrypt the sgym.VQAfile from disk. I ripped some code from the malware's AutoIT script, and read some functions from the official AutoIT site for their functions and finally made the decryption script. It reads the encrypted filename given in a global var, and writes the decrypted file data in a filename given in a global var too. In order to run the script you have to download AutoIT from here and give the correct in/out filenames in globals to the following script (change "encrypted.bin" to "sgym.VQA" to match this case) :

3) Analysis of the final decrypted PE

VirusTotal gives a result of 29/54 today. A static analysis results in an unpacked executable, compiled with .NET containing many interesting strings and .NET functions/classes (via IDA Pro) which gives us the impression of a monitoring tool cos of the extended functionality (ripper of many apps/browsers etc, keystroke hooker, ..).

The tool is the commercial Keylogger named "Limitless Logger" and here seems to be it's site (author ended the product's support). Here is a video explaining the functionality of the tool by the tool's autor (Mephobia). In the video we can see it's whole functionality, which explains everything about the classes/functions we see in IDA . Here is a sample random shot from IDA showing the product's banner:

Limitless Logger in IDA

While I was exploring the tool's code, I noticed that there are plenty of console messages, even if the app is compiled for windows gui. For example:

A console WriteLine proof. The app has console messages

In order to see those console messages, let's change the PE Header byte from Windows GUI to Console app as shown in the pic:

Changing the IMAGE_SUBSYSTEM byte so I can see the console messages

...and yes here they are... Limitless Logger has full console messages on every single step.. :

Console messages of Limitless Logger, after changing the IMAGE_SUBSYSTEM byte from PE Header

After setting ApateDNS pointing to a Linux INetSim honeypot (inetsim's SMTP had to be set up to port 587 instead of 25), I sniffed a whole conversation of the .Net tool's traffic and the SMTP server (the tool sends the data to the cybercriminal via mail - smtp to address "ontherun4sales@yandex.ru"). Depending on the user's settings, the tool sends several feedbacks about the keystrokes of the user, screenshots, recovery data (saved passwords from several applications/browsers). This is a sample of the smtp communication data sniffed, and DNS requests made by the tool:

Limitless Keylogger TCP Stream 1

Limitless Keylogger TCP Stream 2

Limitless Keylogger DNS requests

The tool, in the 1st tcp stream uses totaly base64 encoded data, what doesn't happen in the 2nd stream. The SMTP used is yandex.ru (also shown in the DNS reqs) without providing password 😀 .Also bot.whatismyipaddress.com is used so the tool can get our inet global ip address in plaintext format, and also the ebis.pro is used cos of web spam using our default browser (there is a setting for that, in the tool's video)

Between "Sleep()" there is a nag web page (the guy compiled the Limitless Logger to visit the site: www.ebis.pro/images/invoice_img.png) which is an invoice corresponding the body of the spam campaign ("..you have to pay a bill.. etc" :D) :

fake invoice nag page

Final Thoughts

The guy who made the spam campaign in order to infect a victim with all these, obviously did it in the AutoIT way cos of FUDing from a static analysis.. Update.exe is a legit interpreter, text files (autoit script) are not detectable by AVs, and so the completely random data do (sgym.VQA - the Limitless Logger RC2 crypted PE). The method had lot of probs.. AVs will detect the drop of the .vbs scripts and behaviour of the processes (update.exe, RegSvcs.exe, ..). The starting functionality of the malware is in a pseudo-obfuscated plaintext file, where it can easily get back in clear state and we can discover the whole functionality. Probably most of the parts of this AutoIT script, are taken from their forum where there are discussions about process injections etc, and there are exactly the same snippets of code (even the comments of the script are the same). Also there are lot of functions that are not used. For example the "antis" functions, where there were some anti-vm code. Also we can see that the guy if the case here, used an open relay smtp server (yandex.ru) which seems that changed policy, cos server can't let you relay messages in unencrypted format, even if the authentication is successful.

If we de-base64 the traffic send by the Limitless Logger via mail, and search the pattern in google, you can find some interesting things.. 😀