How to extract BetaBot config info


In this article i will show you how to extract the configuration section of the bot, this section is encrypted inside the bot and decrypted while the bot is running.

Few months ago i built a tool that can extract the configuration of the bot in offline mode (that is without running the bot in debugger) i achieved that by reverse engineer and studying how to get the key from the bot and build  in order to decrypt the configuration section from the sample.

Lately when new versions of the bot came out i found that it is much simpler to extract the info i needed using a debugger than to update the tool, this method is what i am going to guide you through in this article.

In order to follow along you need an unpacked sample of the bot (you can get the one i am using in this article here, password is: infected).

This article targets the latest version of the bot (1.5), the technique presented here do work on earlier versions too.

Beta Stage

First step is to open the sample under debugger (BetaBot contains many Anti-Debug techniques so you should use the right plugins and the right configs in the VM and the debugger accordingly in order to avoid detection by the bot) right after that you should find the Base Address the bot has loaded into (you can get that info by looking at the memory map list of the debugger).

With the Base Address at our hands we need to open the sample in IDA and rebase the segment addresses to be the same as the Base Address we got earlier.

In later versions of the bot there is a second stage in the loading process that is done before the main code of the bot actually starts executing as EP_X0FF wrote:
second is self-made Betabot pre-loader -> purpose allocate ERW memory, decrypt main bot to it and transfer control then

If your bot contains the following commands at the entry point you are actually in the start of the second stage.

In order to pass this stage we need to search for the assembly command call using IDA (ALT+T) then set a breakpoint in the debugger at the address of the call command that is similar to this (0xE116AB).

Find the decryption routine

Right after that call we are at the real main code of the bot and now we need to dump the process in its current state to a new executable file (PE Tools full dump works great).

Right after the bot finish to run the second-stage we have a new Base Address  that is bot is loaded into hence we need to take a look again at the memoy map pane of the debugger  and find the new Base Address (mine is 0x290000).

Next let's open the dumped image in IDA (rebase if needed) and find the global variable at offset 0x3ddf8 from the current Base Address (0x290000 + 0x3ddf8) mine is at 0x2CDDF8 in the .data section.

Now we need to go to the middle xref  that this global variable is referenced, there we can see some functions that are related to the decryption routine the bot is using.

The function that we are looking for is the decryptEncrypt function at offset 0x255A from the Base Address (mine is at 0x29255A), this function is the main encryption\decryption routine the bot is using to crypt\decrypt data (even the C&C server itself is using this same encryption scheme in order to encrypt the packets it sends to the bot although that it using a different key ).

We are going to take the address of the decryptEncrypt function and set a breakpoint right at the start of the function.

Extract the data

In order to get the data that is being decrypted using this function we need to set a breakpoint at the start address of the function and let the bot run, after few seconds the debugger hit the breakpoint and stop, now the EDX register (C++ code) has the address of the destination buffer this buffer is going to contain the decrypted data right after this function finish to run.

Let's view the address contained in the EDX register at the dump pane of the deubgger.

Before the decryptEncrypt function run

Now we let the function run till return (Ctrl+F9) and you can see that the dump pane now contains the  data that has been decrypted (The EAX register contains the length of the data).

After the decryptEncrypt function run

The first hit of the breakpoint is just some code (that is going to be run in a thread the bot is creating later on) that the bot is decrypting but the second hit is the configuration information that we are looking for.

Decrypted Config Info seen at the dump pane

That's all to it, now we can copy that data to a file and have fun.

Some notes

  • The configuration information contains:
    • Address of the C&C servers:
      • b19jdn167t.in/M_jsh1/order.php 
      • n18b7273u1j.in/M_jsh1/order.php 
      • (note that usually order.php is the gate page and if you try login.php you get the login page).
    • The nickname of the owner of the bot (d8902659 in our case).
    • The file name the bot will have once it copies itself to the computer (jhgvy76765guhb in our case)
    • The key that the bot use in order to decyrpt packets it gets from the C&C server.
    • Some more info that i am not able to recognize yet.
  • When you discover the offset to the decryption routine once you don't actually need to do all the process we have done here all over again if you have a  different bot, just set a breakpoint at the appropriate offset using the global variable xref trick that i presented above by searching for the global variable in the disassembly.


The case of Win32.Filecoder Ransomware

Few days ago i have got a computer that was infected with Win32\Filecoder.NAG, this nasty ransomware has encrypted the user files and presented the following message to the user:

So basically in order to get your files back you should pay 300$.

I have done a little bit of reverse engineering of this ransomware in order to try to find a way to get the key without paying the ransom.

Here are the facts i found:

Once the malware is installed it generate the key with the following algorithm:

Key generation algorithem

Afterwards the malware create two files on the %APPDATA% directory, the first file (named Setconf in this variant) contains the generated key, and after the malware done with the encryption it encrypt this file too (and add .crypt to the extension name) and then delete this file from the computer, so it is difficult to get this file back (although that in case you have "previous versions" feature turned on and it took snapshot in the right time you can get this file).

The second file (named ok.txt in this variant) contains the words "Thank you!".

After it generate the key the malware then sends that key using a POST method to the C2 server (in my case it was hxxp://infominfo.net/add/add.php) and in the answer from the server it get the ID and the email address that the victim is suppose to use in order to contact with the operator.

It then saves that ID and email address in the following registry path:
HKEY_CURRENT_USER\­SOFTWARE\­Microsoft\­Windows NT\­CurrentVersion\­Winlogon

Then the mlaware proceed to the encryption phase and encrypt all of the user's files using an AES algorithm   and add to each file extension name the word .crypt .

After the encryption of all the files is done the second file the malware has been created in the %APPDATA% directory (named ok.txt.crypt now) is being used by the malware in order to make sure the victim has entered the correct key.
Once the user has entered a key the malware is trying to decrypt this file and if the file content is  equal to "Thank you!" (as it was before the encryption) the malware knows that the user has entered the correct key and it proceed to the decryption phase (yes it really decrypt the user's files if you have the correct key) if it doesn't equal to "Thank you!" the malware knows that an incorrect key was entered.

The key the malware uses is 15 bytes long and it is consist from mixalpha (a-z&A-Z) letters, initially thought to brute force the key in order to get the files back but after some calculations i came to the conclusion that it will take long time to do that and unless i have many (many) computers that brute force the key in parallel i can't get that key and the files of the user are gone.

The AES library that the malware is using to encrypt the files is probably taken from this open source code at the google code site (Thanks to Fabian Wosar for pointing me to it).

My conclusion on this was that i am can't get the encrypted files back unless i have a log of the network traffic so i can get the password that was sent to the C2 server.

By the way i found that the C2 server is responding to arbitrary POST requests with an id and email address:

A little python script that will send POST request to the server in a while loop will not hurt anybody especially if the Brute Force method above didn't work that will work for sure:

The md5 hash of the file i have analyzed is:
14724a3dafa927ebee51e72c5e02f9c1 VT 31/47

Have a nice Day!


Elite Keylogger Detection and Analysis

Elite Keylogger is a kind of malware (from the victim POV) that is sold by a company called WideStep, this company are marketing this product as being "100% undetectable" as you can see in info page:

Invisible to anti-virus software

It’s no secret that anti-virus and anti-spyware applications will constantly try to detect and block even legitimate monitoring applications like Elite Keylogger. Elite Keylogger does a great job hiding its own modules from anti-virus, anti-rootkit and anti-spyware apps. Elite Keylogger ensures it's not detected during regular scans and even after you update your anti-virus software. It implements a number of unique algorithms to stay hidden.
Here i will show you how to detect if this keylogger is installed on the computer and how to access its configuration GUI interface in order to see all of the configuration the attacker has set.

The version this article address is the latest version (5.0.183) currently being sold by WideStep.


First off this keylogger is in the opposite side from "100% undetectable", the keylogger is injecting a DLL file to almost every process currently running and hook the usual functions keyloggers are hooking (i.e. GetMessage, PeekMessage...).

The fact that this keylogger using such awkward method of injecting DLL to almost every process makes this keylogger very noisy. I was able to detect that a keylogger was installed just by launching an anti rootkit software which protect itself by preventing DLL injection into its address space:

Rootkit Unhooker warning message

Here are the hooks this DLL implementing:

Hooked functions

In my particular case i needed to know what kind of keylogger is insalled on the computer, so in order to continue the investigation i looked at the strings in the DLL file that is being injected and as you can see in the follwing picture there is strings that contains the name of the company that sells the Elite Keylogger:

The string in the file point you to widestep.com

Now we know that Elite Keylogger is installed on the computer, the next step is to download this keylogger installer and install it on a VM in order to investigate how to get in to its configuration window.


Every installation of the keylogger put files at different locations in the file system (Windows 7):
  • C:\Windows\System32\

  • C:\Windows\System32\drivers\
  • ADS in C:\ProgramData\TEMP

There are more files ( in the %TEMP% directory) that being created during the runtime of the keylogger as well as a file that is being injected with a set name of thunk.dll, but since my goal here isn't to anaylse these files i wouldn't cover it in great detail.

From what i have seen at every installation of the keylogger the file names are different except for the last three letters (on the driver it seems like only the two last letters) of the files name that aren't changing, so you can detect the keylogger files in other computers using the last three letters as identifier.

The data and time of the files are interesting it seems to me that they are based on the time you get your installation file from the web site and not on the time the keylogger has been installed, hence i have made the date and time of the files in the pictures above blurred (.....), As we will see later you can actually detect the installation date and time of the keylloger using a different method.


In order to read the configuration of the keylogger and see where it is sending the data it captures we have to access its GUI interface. The exe file at C:\Windows\System32\openfsvr.exe (the "openf" letters are random) will lead us to the UI of the keylogger, but simply double click the exe file doesn't going to open the GUI interface since the keylogger has a protection that require you to type a special string in the Run box in order to be able to access the GUI interface.

The string that you need to type in the run box is set by the attacker at the installation phase so in order to open the UI we need to find another way.

To bypass this protection you should open the exe file with the following parameter:

"C:\Windows\System32\openfsvr.exe" VIEW

Once you open the interface you should type in a password in order to access to the configuration window, to bypass that we should open the keylogger's process in a debugger.

I have used OllyDbg v2.01 (Beta 2 update H)  in order to pass the password requirement, i have tried to use OllyDbg v1 or Immunity Dbg without success (probably the keylogger is detecting it somehow).

After you open the debugger to the keylogger's password window you should set breakpoints in the following locations:
  • 0x0064E0D5
  • MessageBoxEx (A and W)
Then type in a dummy password and hit the Unhide button, now the debugger should break at one of these locations depending on the version of the keylogger:
  • Paid version will break on the MessageBoxEx, then you should set the EIP to 0x0064E0D7 and keep running (F9).
  • Demo versions will break right on 0x0064E0D5 and we should toggle the ZF (to be 1) and keep running (F9).
Afterwards you can access the GUI of the keylogger and see every configuration that was set by the attacker (i.e. where the captured data is sent to, what is being captured and so on).

bypass the password requirement

 If you are lucky enough and the attacker used FTP server as one of its target to upload the captured data you can see the username and the password of the FTP server since it isn't encrypted.

Time of installation

Since this keylogger try to be "100% undetectable" it deletes the logs related to its installation and operations in the system so that you can't see anything (almost) related to it using Event Viewer.
As you can see in the product info page:

Invisible to other users

Elite Keylogger stays absolutely hidden to other users of the monitored computer. They won't find Elite Keylogger among running processes, in the list of installed applications, in the history of used programs, in the Start Menu, or anywhere else! Guaranteed!

But i found one log that is left behind and you can get from this log the right date and time of when the keylogger has been installed by the attacker.

As part of the installation process the keylogger require you to restart the computer in order to finish the installation and start the key logging activity, when the user agree to restart the computer the event is written to the system logs.

The log gives the time of installation

As you can see in the Event Viewer the log is pointing you to the file name that triggered the restart of the system, and as we can see the file name is the same as file of the keylogger GUI (main file).

With that evidence you can conclude that this keylogger has been installed on 30/4/2013 by user user-PC\user.


In this article i have tried to conclude the steps i have taken in my analysis of this keylogger, as you can see my goal was to gain access to the configurations of the keylogger and not on the analysis of the keylogging itself.

This keylogger isn't the usual keylogging activities we see in malware, since this keylogger require a proper installation with admin rights (although there is a silent installation procedure that you can use), as you can see in their website they actually call this kind of program "monitor software" so that a parent can monitor his children but you can call any RAT a monitor software.

Since AV vendors detect this Elite Keylogger as a keylogger variant and protect the end user against it hence i decided to analyze it here.



Warbot C&C Panel

This bot doesn't have many capabilities besides DDOS attacks, in addition it let you run other files on the victim machine so it has a Loader capabilities too. This bot is cracked and available to download online.

In this specific server the mysql server was wide open (root, toor) hence i was able to add another user to the warbot database and since warbot has the its user list on the database i was able to login.
529 bots isn't enough?!
Warbot abilities

The attacks this guy was doing

Attack targets


SpyEye Trojan Analysis - Part 2

After the trojan has been started using the CreateProcess call from explorer.exe (injected code, read part 1 for more details) it checks that it runs from the usual location it is suppose to be run (which in our case is C:\algonic\algonic.exe) :

Branch to second stage

Afterwards it start to decrypt its config.bin file, this file is encrypted using XOR algorithm. After it decrypt the file it uses the password from its C->C3 resource to open it (this file is a ZIP file protected with a password), this file contains the configuration and plugins of the trojan. Here is the content of the file after decryption:

The files in the decrypted config.bin file

Here is the password for the ZIP file in the original algonic.exe file resource section:

Zip password found in C3 resource

In the sample from the Honeynet.org project you have another config.bin file that contains more plugins, this particular file is encrypted with the same XOR algorithm as the original config.bin file was.

I have wrote a simple Python script that decrypt this file, you can use it with any config.bin that uses the same XOR byte or you can change the byte at the source code to tweak it to your needs:

import os, sys, argparse

args = 0

def TakeArgs():
    global args

    parser = argparse.ArgumentParser(description = "Decrypt the config.bin file of common SpyEye Trojan.")
    parser.add_argument("EncryptedFile", type=argparse.FileType('rb'), help="The config.bin file path")
    parser.add_argument("DecryptedFile", type=argparse.FileType('wb'), help="The decrypted file path")
    #parser.add_argument("XORbyte", help="The XOR byte used to decrypt the file [usually 0x4C]")
    args = parser.parse_args()

def main():
    xor = int(0xC4)
    EncData = bytearray(args.EncryptedFile.read())
    counter = 0

    for idx, byte in reversed(list(enumerate(EncData))):
        if idx == 0:
        var = byte ^ xor
        EncData[idx] = (var - EncData[idx -1]) & 0xFF


if __name__ == "__main__":

EDIT: i have added the code in a bitbucket repo.

Afterwards the trojan injects another payload to explorer.exe and if this injection succeeded the algonic.exe process exit, otherwise the process algonic.exe by itself proceed to run the payload.

Branch of the third stage injection

This payload is responsible to inject code into every process in the system and hook some system function in order to do other nasty stuff (in Part 3 i will cover this hooking), in addition to that at this stage it will create the GUID of the bot and send it to the server.


SpyEye Trojan Analysis - Part 1

Here i am going to analyze the SpyEye trojan, this was actually a challenge at Honypot.org site and you can download the sample there, this version of SpyEye is 1.3.10.

This sample was packed 3 times by two different packers UPX and ASPack, the first layer was UPX afterwards it packet with ASPack and lastly again with UPX.

I am not going to concentrate on the unpacking process rather i will show you the actual analysis of this bot.

When the trojan first run it create a mutex and name it algonic, this mutex is created in order to be sure that only one instance of the trojan is running.

In the picture you can see that it uses the TIB (located at FS:[18]) in order to the for the last error code.

Afterwards the trojan check the path from where it is being run, if it is other than the path it suppose to be once installed (C:\algonic\algonic.exe) it take its dropper path otherwise it proceeds to the actual infection path, as you can see in the following picture it uses the strcmp function to check the paths and if it takes the dropper path it load its SC->SC1 resource which contains code that the trojan is going to inject into explorer.exe process.

The trojan then inject the code from its resource (SC1) into explorer.exe process, in order to inject the code into explorer.exe it uses the usual functions to enumerate the processes at the system (createtoolhelp32snapshot() ...) and search for the explorer.exe process then it uses ZwWriteVirtualMemory() in order to write the code into the remote process memory.

Allocate memory on explorer.exe:

Write code into allocated memory:

After the injection of the code it uses CreateRemoteThread() with the address of the injected code in order to make explorer.exe run the payload.

The injected code copy the file to (C:\algonic\algonic.exe) then delete the original file and start the trojan from the mentioned path.


In order to make itself resistent to computer restart the trojan write itself at the under the registry key:
there it adds a key name algonic with the value of C:\algonic\algonic.exe

On this part we covered just the part of the code that is in the dropper category, on part 2 we start to see how the trojan decrypt its configuration file.

That's it for now, see you on part 2.


VertexNet Loader 1.2.1 C&C Panel

Today we see the C&C panel of VertexNet Loader 1.2.1.

Login page:

Victims (it seems like that guy has abandoned it as it has just 3 offline victims):

Command list, this is the list of the commands the operator can send to each victim as you can see it is more like a RAT than a Bot.

The guy(s) who created the VertexNet Loader is the same guy(s) who created the DarkComet RAT maybe that's why you can see some RAT features.