This is in continuation with the part 1 of Analyzing Malware [ slackbot ].
In this phase of reverse engineering malware, we will look inside the code of the specimen.
We will use IDA pro, a disassembler, to open the malware exe and attempt to understand the logic behind the flow of the execution. A disassembler translates machine language into assembly language.
You can get IDA Pro here: http://www.hex-rays.com/idapro/
Fire up IDA and open up the unpacked malware exe from C:\WINDOWS\.
Once you open up the specimen, you can see the instructions in graph view or in the text form. Press Alt-T to find an occurrence of !@id in the program.
In the screen cap below, I have highlighted the code block for !@id.
The instruction at 00401B9E pushes the value !@id on to the stack. The next instruction at 00401BA3 is then putting some string value to the stack. At this point, this seems to be the command entered by the bot herder / creator or the analyst at the IRC channel #jigyaasa. The next instruction is a call to strcmp, for string comparison. It appears to be comparing the 2 values that were pushed on to stack earlier. So, simply it is trying to confirm if the string value at 00401BA3 [ i.e. the command given to the bot ] is !@id or not. If both the values match, then EAX register value is set to 0.
Later you see, the instruction at memory location 00401BAE is performing an OR between EAX and EAX. It is checking to see if the value in EAX register is 0. The logic behind OR instruction is as follows:
If A = 1 and B = 1, then A OR B = 1
If A = 1 and B = 0, then A OR B = 1
If A = 0 and B = 1, then A OR B = 1
If A = 0 and B = 0, then A OR B = 0
That is, if both the variables has a value 0, only then the output of OR operation will be 0.
Following this, you see there is a JNZ instruction. JNZ is 'Jump if Not Zero'. This means, if the EAX is NOT 0, then the execution flow will jump to the memory location 401C53. Else, the execution will continue.
In the next few instructions that follow, the time function is called. Therefore, when we entered the !@id command earlier in the Behavior Analysis phase, the bot returned the current system time as the response.
Note also, there is no other string comparison happening in this block for !@id command. It would be hence safe to consider that this command does not take any parameters.
Let's move on to a more useful command, !@login. Recall that when we entered this command in the channel earlier in the Behavior Analysis phase, we did not receive any response from the bot. It is quite possible that this command requires a parameter.
Below is the graph view of the code block for !@login.
We see in the top block, the same logic is taking place as that happened for !@id. The string !@login and another string is pushed on to the stack, strcmp is checking if both of these are equal or not and based on the output, decides the flow of execution. Hence, there are two logical response paths originating from this block.
First let's look at the left upper block. We see there are two strings - str1 and str2 - pushed on to the stack. Then there is a call to strcmp function and consequently, based on the result, either the execution continues to another code block [ follow the red line down ] without any jump Or the execution reaches the memory location 40210D, which is the second response path from the top block, on the right.
Here is the text view of the top block.
You see, at location 004020C5, there is a comment 'pass accepted'. If you follow upwards from here, you will find this response will occur when the EAX register is 0, that is the str1 and str2 values are equal.
To give a quick conclusion of !@login block observations, there are 2 comparisons happening in here:
1. First strcmp at location 00402093, confirms if the command entered is !@login or not. If it is not, then the execution jumps to location 40210D.
2. If the command is indeed !@login, then the second strcmp at memory location 004020B9 confirms whether the 2 string values - for str1 and str2, pushed to stack at memory locations 004020B5 and 004020B6 respectively - match or not. The string value most certainly is the password which is to be used to authenticate to the bot.
If the strings match, EAX = 0, and the message at location 004020C5 is printed out. Else, the execution flow jumps to location 40210D.
Do re-read the above details again before you move on to the following steps.
After this session with the disassembler, we have some understanding of how the authentication is to work in this specimen.
Now it is time to trace the process execution flow. We will use Ollydbg, a simple to use and very powerful debugger for this task.
You can get Ollydbg here:
OllyDbg is an x86 debugger that emphasizes binary code analysis, which is useful when source code is not available. It traces registers, recognizes procedures, API calls, switches, tables, constants and strings, as well as locates routines from object files and librariesStart the IRC server, and connect to the channel #jigyaasa from your analyst's / linux box.
Fire up Ollydbg and open the malware exe from C:\WINDOWS. Once it loads up in Ollydbg, press on the Start button - looks like the Play button. The execution is 'Paused' by default [ look at bottom right corner ].
From information gathered using disassembing the malware exe earlier, we know that the strcmp call which checks the two strings - str1 and str2 - in the !@login code block, is at memory location 004020B9.
This means that every time there is an authentication attempt made to the bot, the program execution will be passing through the memory location 004020B9. Therefore, we will now create a breakpoint at this location. This will help us analyze the state of registers and values at the point of authentication.
Press Ctrl+G, type 004020B9 and Ok. This will find the memory location of the strcmp call. Note that you may have to do a find twice. It's a little bug in Ollydbg.
Once you are at the memory location 004020B9, right click anywhere and create a breakpoint from the menu. Or simply press F2 key to create the breakpoint.
You can see the address turns red in color as soon as the breakpoint is set.
Now go to the IRC channel and enter !@login <any_password>. In our case, I entered !@login botpassword. You will not get any response. But look at the Ollydbg now. The breakpoint has been hit. The execution paused at location 004020B9, i.e. the strcmp call.
If you look at the stack pane of Ollydbg, which is the bottom right, you will see some interesting values. You see here that the locations 0012F7E8 and 0012F7EC point to addresses on stack where the values for strings s1 and s2 are stored. Here we are able to see the s1 which is the password we entered at the IRC channel, and s2, with which our password is being compared to. The value of s2 is "jigyaasa" and this will successfully authenticate us to the bot.
We have found the correct password. So you now go ahead and kill the malware process nwhyy.exe, and run it again, through Ollydbg.
Once the bot joins the channel, enter the command:
You see that the bot now responds with 'pass accepted'. Try to run a command remotely using:
The bot responds with 'file executed'. Let's see the screen at the Windows XP box where the bot is installed. We see the command has executed successfully and 'notepad' is opened remotely.
To conclude this exercise with today's notes, we studied some code elements of the specimen and were able to understand its command execution flow. We used IDA Pro disassembler and Ollydbg debugger to gain insight into the malware's structure and operations. In the end, we have been able to authenticate and gain control over the bot.
You can now remove the bot from the lab test machine by entering
Finally. do remember to revert your Windows VM infected with slackbot.exe to a previous clean snapshot.
Though I've tried to cover the analysis process correctly and with as much detail as possible, I am no expert. So in case you find any error, or have questions & feedback, feel free to comment. I'll appreciate it.