An analysis of AutoLog, a keylogger in AutoIt

Note: I have had this for quite a while, and the sample I had might be outdated.

AutoLog is a keylogger written in AutoIt that is UD and also is extremely popular. It uses the Jos van der Zande Obfuscator, which helps confuses the code to some point, but code structure is not changed at all. The obfuscator also prevents the output from being detected, however AVG detects any file obfuscated by the obfuscator. The obfuscator had a public deobfuscation tool, MyAutToExe, which perfectly deobfuscated the malware. However I happened to manage to extract the original unobfuscated code from the builder, so I will use that version as the variables and function names are mostly preserved already.

The code is slightly obfuscated before the use of the Obfuscator. The strings were encrypted and variables were renamed using Au3Stripper. It was trivial to automatically decrypt the strings and replace them. The Obfuscator is fairly good at ridding of detections, since with a few thousands users and me scanning on VirusTotal, it is a surprise that the stub stays under 5 detections without any updates.

The keylogging method is simple, it either used the IsPressed function or GetAsyncKeyState depending on the user’s choice. The site is used to obtain the user’s external IP address. For those of you who didn’t know, icanhazip was flagged by antiviruses quite often  due to the fact that it is commonly abused by malware. Nothing out of the ordinary here.


An interesting thing about AutoLog is that it is able to hide itself from Task Manager in Windows 7, which is done through the use of SendMessage after obtaining a handle to the GUI. A fairly creative approach, I don’t think I have ever seen it before.

The AV Killer uses a combination of a public method and a seemingly private one. First, a handle to the process is obtained via OpenProcess, the AV is then suspended using NtSuspendProcess, and then closed. I am surprised that this work, due to the fact that AVs are protected by drivers and should be able to prevent themselves from being suspended and killed. After killing the process, the Image File Execution Option is used to set a debugger for the process to prevent the process from being revived. This is done for around 270 processes which range from Kaspersky, ClamAV to KeyScrambler and WireShark (which technically aren’t AVs).

Antivirus Killing function

Antivirus Killing function

AutoLog uses the API GetAsyncKeyState to log keystroke. The hooking mechanism is taken from a Github repository. AutoLog’s persistence exploits a bug on Windows 7 and potentially under (haven’t checked) which is described here. This bug renders the process pretty much unkillable. While this bug is capable of keeping the process alive, sometimes it causes freezes and stops the malware from functioning properly. A very creative approach I must say, I have never seen anything like this before in the realm of AutoIt malware.


A comparison of AutoLog’s source code and the public keylogger source code (Left: AutoLog, Right: GitHub)

In conclusion, while AutoLog is an interesting piece of malware providing features that are often not seen on other malware samples, out of which the fact that it only has a few detections is extremely worrying as many AVs have trouble detecting AutoLog’s payload. Additionally, it is because of malware like this that public and freely available obfuscators are getting flagged up as malware.


Unpacking GhostCrypter, a not really stealthy crypter.

So today I will be unpacking GhostCrypter. This crypter is currently sold on  HackForums for $12 per month, and seems to be pretty popular. Please note that I was given this file, and I have no idea if this is actually GhostCrypter. So let’s get started.

GhostCrypter is coded in AutoIt, so MyAutToExe should be able to decompile it fairly easily. It is not packed with UPX, so there is no need to unpack anything. There are quite a few files packed inside it, which explains the 1.6mb file size. Dropping is not really stealthy after all.


The decompiled au3 file contains #endregion at the top, which is a common method to stop Exe2Aut.  It is all capitalised and the first 2 functions seemed to belong to Crypt.au3 and had all of the variables changed.`

The decompiled code can be found here: After decrypting and deobfuscating all of the variables and removing the flow obfuscation, the resulting code is fairly short. It was only 6 lines and was fairly disappointing to look at. And instead of running like that, why don’t you use ShellExecute?


OK so let’s now look at the files that were dropped. The file that was dropped as a .CMD file appears to be Microsoft Visual C++ v.10. When we look into the file that is used as an option, turns out it is an AutoIt source file. The .cmd file turned out to be the AutoIt base, as it was signed by AutoIt Consulting LTD.It is obfuscated with Flow Obfuscation, using Call() to stop strippers from working, and all of the good stuffs. The whole process of manual deobfuscation took quite long and was kinda boring (to describe) to be honest, so I will just talk about Before and After deobfuscation here.

So before deobfuscation, this is what the file looked like:


One of the very funny thing about the script is that it uses _Crypt_DecryptData to decrypt strings, however next to the line, there are comments which tell us what the encrypted strings are. However it could be meant for deception, so I will just create an automated tool to decrypt the data and removing the flow obfuscation that was applied.

So after deobfuscation, the script is 232 lines in length and is fairly plain. It looks like the variable $encrypted declares the path to the encrypted file, which is decrypted, and then injected using a shellcode. Simply using FileWrite and _Crypt_DecryptData with the same parameter extracted the original file. The original file is an MZ Executable file, if you don’t know what that is, Google it.


One of the runtime techniques used by GhostCrypter is dynamic Startup. Normally, GhostCrypter uses the RunOnce startup key to hide from MSConfig, but this often prompts for confirmation on AVs such as Kaspersky, 360 Security,… So when processes such as mbam, avpui GhostCrypter creates a .lnk file inside the startup directory instead. The anti analysis is also fairly bad, it only detects 3 processes, 1 for VMWare, 1 for VirtualBox and 1 for SandBoxie. Furthermore, it stores the file in a variable, not use it at all, and use the _Crypt_DecryptData function with the first parameter of FileRead(@AppDataDir & “\QHWXHYbdLYDG”) instead of the $encrypted variable which shows the path to the file. And after being used, the variables are not set to Null to free up memory. Bad coding practices here.
That is my take on GhostCrypter. If you have any other malware samples, feel free to send them to me and I will take a look at them.


The Healer new release

Version is now available!

Added features: Persistent File Remover and FileAssasin.

Removed feature: Kaspersky Installer, since it is too heavy

Now there is only 1 version, since Kaspersky is removed.


Download here:


Inside the panel of the Andromeda Botnet

Recently, I have managed to obtain myself a stub of a still active Andromeda Botnet, and have sucessfully obtained access to the panel (Don’t ask how, even though when you are a botmaster you really should be getting a strong password xD). The botnet is hosted on a seemingly BulletProof server, and the Domain Registrar refused to sinkhole the domain name due to them ‘Not being able to monitor the traffic, as they are not the web host’. So I guess I can’t really sinkhole it except for killing the bots, and changing the encryption key and password to mess up the current progress by the botmaster.

Andromeda is a pretty old botnet from 2012, but is still commonly used. The botnet has a Rootkit, a Formgrabber, as well as a Socks Proxy plugin. But what I will be going in today is not the functionalities, but the interesting things about the stats of the botnets.

The compromised Andromeda Panel

The compromised Andromeda Panel

First of all, most of these bots are 32 bit, and not 64 bit. This clearly shows how the infection focused mostly on not so new machines, and probably not tech-savvy users. Windows 7 contains around 80% of the bots, and there are still Vista and XP bots. Also most of the bots are from third world countries such as Vietnam, Indonesia,… In fact, 1 third of the bots are from Vietnam.

stats by country

Interesting stats

You see, these countries are not rich countries, and therefore their cyber-defense and education budget is not really large. Parents here are generally not computer experts either, and therefore are easily tricked into installing malware on their system. Kids are not really educated about cyber security, so there is a high chance that search queries for game hacks will probably not end well.

There currently is only one task, and it is to download a file called XD.exe from the server. Closer looks will be taken at it in the next post. Good bye and see you again.



Getting your own host is better than using Direct Exe Hosting.

Direct Exe hosts are commonly used by malware as they allow a Downloader to work properly (I mean, if you used MediaFire, the HTML page will be downloaded, duh?). Despite getting blacklisted fairly fast, they are all still very popular as blacklist usually only affects the browser. However, what they DON’T know is that most Direct Exe hosts are highly vulnerable.

One fairly good example is


This direct Exe hosting is currently blacklisted by 18/68 AntiVirus engines on VirusTotal, and is advertised on HackForums. Despite the good design, the host is not really secure. All of the URLs are in the simple format of, where abc consists of 3 random numbers/letters. With 5 minutes of scripting, I made a scraper that would try to bruteforce the url, and obtained around 8 samples in a mere 3 minutes. The only problem was that Nevergreen does not remove files that are older than 1 month, therefore I am also getting samples that are as old as almost a year. File extension is another problem since some of the files might be .RAR, so I had to use ExeInfo PE to figure out what it is..

Another vulnerable host is The full vulnerability is mentioned by L!NK in his video at

Those are just the 2 direct exe hostings that I havve been looking at. So don’t rely on these hosts, since anyone can obtain your stub with ease.


An analysis of Razor Crypter, a HackForums product

Today we are going to take a look at Razor Crypter V2, it is a well-known crypter on HackForums. It is one of the biggest and oldest crypters that are still running. It was started 3 years ago as Razor Crypter V1 (I may cover it in a later post) and it is written in AutoIt, a language commonly used to develop malware as it is very easy to program and reFUD.

On execution, Razor Crypter’s stub creates a random number, creates a loop that add 1 to the number, check if it is prime, if it is it adds an “x” to a Variable, if not the loop is restarted. This is repeated until the number is somewhere between 10000 and 90000.

After this, the variable “NUMS” get splitted with the delimiter “x” and saved into an array called “EXP” :


The script will next take 2 random numbers from “EXP” and adds a random number.

This junk code is most likely done to prevent detection by AV, since after this the variable “EXP” is not used again.

When everything is done,it will drop another AutoIt script,and execute it via the AutoIt parameter “AutoIt3ExecuteScript”. However, the dropped script is detected by 90% of all AVs. Even though this crypter has such a big reputation on HackForums, it is just a poorly written crypter.

Another obfuscation technique employed is the renaming of pre-defined Functions. This is done using defining new functions that do nothing except for calling the pre-defined function. A very interesting method of obfuscation, however, it is easily thwarted by renaming all of the functions.


String Reverse was also renamed, however, it is custom coded. A funny thing is that the code looks copy & pasted, so I am not really sure that is a point for the coder or not.




However, since the crypter is written in AutoIt, and the coder has a lot of time on his/her hand, to reFUD the crypter, it is often FUD and it is very popular among non-skilled hackers (aka Skids). The encryption is also very weak, as Base64 is used, and since Base64 is a keyless kind of encryption (And the function was named _winapi_base6decode), it would be trivial to unpack the stub.

Virustotal link of the stub.


  • The crypter uses bad ways to be undetected, however it is updated often which means it is hard for AVs to keep up with the Scantime detections.
  • All stubs are the same, containing barely any difference.
  • Just because a crypter is old and famous doesn’t mean it is good.
  • Don’t use Base64, at least use RC4, XXTEA, AES or something with a key.

Some more analysis of AutoIt crypted malware sample

If you haven’t read my first post about this malware, please do check it out.

So today I got bored and decided to browse through my files, and was suddenly reminded of the sample I was analyzing earlier. It is barely obfuscated, and many original function names are still available. At least most custom functions are obfuscated. Another sad thing about this malware, is that the encryption key is stored in plain text, and in plain sight. Some obfuscation/encryption would have been nicer.

Encryption key of malware stored in plain sight.

So in this case, the stub simply drops the encrypted stub into the Temp Dir, and then decrypt it through reading the file. vmqjobbhqfbf is simply an obfuscated version of _Crypt_DecryptData, and 26128 stands for AES256 encryption. It was too easy to create a small snippet to decrypt the stub. The decrypted stub is 305 kb in size. However, this is the part where the malware execution goes wrong. As you can see in the screenshot, the variable $hcwywahhpctofanxhtdimbanbldxbax set to “%NATIVE%”. Closer inspection shows that Native is to indicate whether the original stub is in .NET or is it without dependencies. However, the author of the crypter made a mistake, since in the variable it is “%NATIVE%”, but in the actual injection function it is 1,2,3 or 4. Another sad mistake was that the original stub was coded in .NET, and therefore is not native at all. So even if the crypter is working properly, the built stub won’t since it will be injecting into the wrong process.


The startup uses the name “Microsoft Cooperation ZGIJJTiKhPcKTTZX”, which is located under either Run or RunOnce of HKCU. An interesting thing about the startup is that if it senses apvui.exe (Which is Kaspersky Antivirus’s process), it will choose not to modify the registry, and instead using the Startup Directory to install itself. This is probably done since KAV’s HIP detection is pretty accurate.Malware startup

The original stub is coded in .NET, and have some decent features based on the Malwr analysis:

It is fairly well detected and was easily decompiled with de4dot, however, I was not able to deobfuscate it since I am currently only a beginner at .NET (Surprised that I admitted this?). Based on what I saw, the real deal is stored inside a resource called Testing.Resources.rsx which is decrypted on the go. Because of the hooking, I suspect this might not be a RAT/Botnet and might be just a keylogger from HF(Some that uses .NET are Volt and HawkEye, but correct me if I am wrong).

So that is it for this malware analysis. If have any questions, feel free to comment down below and I will answer them. Send your malware my ways if you have any.