In the last article, I discussed in quite some detail how exactly the dropper for Bundestrojaner worked. In my next article what I’d been planning to do was to reverse the DLL and then the driver. There’s a slight change to those plans though. I was looking through the dropper again; and found, in the disassembly particular path that looked interesting. For some reason that bit had not got triggered at all. I reset my VM to a clean snapshot and ran the trojan again…but had to do a little patching to ensure that those paths got visited. Okay..enough of the suspense..what is this new piece to the puzzle? The dropper, as mentioned previously drops a Temp EXE file, a DLL and a driver to the disk. In addition it also drops 2 files that seem to be related to Skype in some way. These 2 files are called SkypeLauncher.exe and SkypePMLauncher.exe. Both seem to be copies of each other. This time we will study the little EXE that the dropper put into a Temp folder, and look at how the 2 Skype executables landed up on disk, as well as a little bit of Process Injection that the malware has done. And yes…I will go a little faster this time :). If you have trouble understanding anything, it is best that you look at my previous article and then come here. Lets go… Inside ~acrd~tmp.exe The file ~acrd~tmp.exe was written by the dropper to C:Documents and SettingsarvindLocal SettingsTemp~acrd~tmp~.exe as mentioned in the previous article. Lets now look at this file more closely and understand it more clearly.
So I opened it in IDA and took a quick look at the Functions. You’ll see that there are not too many custom functions (just above 20) starting with sub_ as per IDA. That itself, is an initial sign that this does not look like a very large executable.
Lets now do 2 things side by side. Let us look at the IDA-View (First Tab by default) in Graph View AND also open the EXE in Olly 2.01. Use 2.01 because I want to show you a nice little feature called the Hit Trace (older versions do not have this). If you look at the screenshots below you will see that IDA has WinMain at 401000 while Olly has its starting point at 4011DE.
Remember the last article? Something just like this happened after which we concluded that IDA was doing some magic. Is it the same here? Lets quickly find out by looking at what Olly is doing. When does it make a call to 401000; i.e the start point of IDA? Lets right click in Olly and say ‘Search for ‘ — command. Now type CALL 401000 and say OK. It will immediately jump to 4012B9 where the CALL is made.
Let’s now set a breakpoint here by selecting the line and pressing F2. We are doing this, remember, because we want to find out what all Olly “actually” does before 401000; which is what IDA has detected as WinMain. Restart the program in Olly once you have set a breakpoint. Now instead of running the program using F9 or clicking that little blue triangle button 🙂 I’d like you to click on Trace – Run Hit Trace instead. Yes it stopped at the breakpoint as expected. Do you however, see a list of all those little red dots at the start of every line in the 3rd column? That’s the path that Olly has taken to reach the breakpoint. So if you want to know what exact jumps and calls Olly has made this is a neat way to find out; I spoke about this last time too. I did blog about this a while back in a little more detail; if this isn’t clear, I recommend you go back and read this post first. Here are the exact screenshots though.
Now I’m not going too deep into this but this is a little exercise you can do. Sit down with Olly and F8/F7 your way through over each CALL that Olly makes till this point. Compare the start address of each of these CALLS with the corresponding entry in IDA’s functions list. Has IDA already named most of them? What are these names? I’ll take just one example: Look at 401279. It has CALL 40175D. Now look at 40175D in IDA; what is its name? It is __setargv. So it is basically a pattern of code which is very very standard and you do not need to go deep into. Repeat this exercise for all the functions and convince yourself that IDA’s analysis is correct. Hint: It IS correct. Almost all the functions I looked at were allocating and deallocating memory, handling threads and exceptions. Still..I strongly advise you take a look if you want to learn all this. If you’re just here for a pleasant read…read on. I will try and give you as much detail as possible 🙂 If you look at the rest of the EXE in Olly or IDA you’ll find that nothing too interesting happens even in the 401000 function. So we can reasonably conclude…that this EXE by itself is not doing anything malicious. You see here the trouble though. We haven’t looked at every single function and path that this EXE has and have to decide whether to go deeper or not. Right now..I’d say No. But can I be absolutely certain? Without looking at every path? Honestly speaking..no. It is a tradeoff though; and a reasonable one at that this time. Inside the dropper again, and a little injection In the introduction to this article, I’d mentioned the dropper also drops something related to Skype.exe here. Before looking at that, I’d like to quickly show you how I found this in the dropper. Load the trojan referenced in the previous article into IDA and scroll in the IDA view to 403F97 as shown below.
There is a decision that is made at 403F97 which decides to bypass or enter the Skype.exe code completely. Lets look at what happens by setting a breakpoint in Olly at 403F97 and checking which path it takes.
Look at the bottom of the screenshot. Jump is taken. This means its skipping that code by default and NOT dumping those files on to disk? Why? Can we force it to dump them to disk for our analysis purposes. Maybe. If you F8 through the rest of the code you will exit as expected and the files are not dumped on to disk at all. Since we WANT it not to jump we will temporarily change a little part of the program. The JNE function call checks the ‘Z’ flag in the Registers menu on the right side of Olly. If Z=0 it will Jump. Hence we will double click on the Z flag and change 0 to 1; this will result in the Jump NOT being taken and we can explore the code we talked about. Here is a screenshot.
Enter a call at 402FB8 (CALL 403230) and set a breakpoint at 40335D (CALL 4031A0) and another at 4031F5. You’ll notice that a function called CreateToolHelp32Snapshot is called right at the start which saves the current ‘process’ state. If you step into the CALL DWORD PTR DS:[EDX+4] function and F8 on to 403395 and then look at the bottom right corner of Olly, you’ll see 2 rows:- Explorer.exe and [System Process], which is the first process running on your Windows system. That should immediately give you a clue, that maybe the malware wants to check if Explorer.exe is running and is hence comparing the string Explorer.exe with all the current processes. This behavior is confirmed if you step into the call at 403395 (CALL 40AD30). I’ll give you just one little bit of proof of this behavior; F8 on till 40AD56 and you will see a CMP call, which compares ‘E’ with ‘[‘ ; the first character of both processes in question. Since there’s no match it exits, goes back and calls Process32.Next at 403204 and repeats the above loop. You can play on here :). If you’re newish to reversing I recommend you play around a little till you understand the exact call Sequence. Eventually when there is a match (and there WILL be one as Explorer.exe almost always is running in Windows) the code exits the call which we initially entered at 402FB8 at the start of the previous paragraph and eventually comes back to the initital place where we first saw “Explorer.exe”; namely 403FAB
Very similar looking calls are made with the arguments this time as Skype.exe (403FB3) and SkypePM.exe(403FCA). Now if you follow this path; you seem to normally exit the program. So when do the Skype executables get written at all? Well apparently all that code is in the call at 403FDA in CALL 403C30. This path is triggered ONLY if a CreateFile call, to write to System32, right at the start, inside 403C30 fails. It then tries to write instead into the “Application Data” folder which loads up at startup when a user logs in.
It’s some really interesting behavior in here, so I’m going to explain it in a little depth. The first thing to do is to ensure that the code is forced to jump to 403FDA and the CALL 403C30 is executed. So play around with the ‘Z’ flag like before. You can quickly scroll down now to 403CAE, highlight that line and then hit F4, which will run the code till selection. F7 into the function here and step through each line. At the end of it, when you exit from it..at 403CB3, it writes the DLL file mfc42ul.dll (which we saw last time..remember?) into C:Documents and SettingsarvindApplication Data for me. At this point, ensure ‘Show Hidden Files’ is checked. You can then open up Windows Explorer and actually see the file mfc42ul.dll copied into the %APPDATA% directory. Going into that function, you then find the same function being called thrice; for Explorer.exe, Skype.exe and SkypePM.exe. We’ve seen similar behavior earlier too.
This time though, while the call is the same, the path it takes internally is different. Lets see why and how. Enter the CALL at 403CCD, F8 till you reach 402DD5 and F7 into CALL 402C20 and set a breakpoint on 402C38. I’m aware that I’m running a little bit here; slow down a bit if you want and take it step by step. Again, it’s really important that you’re familiar with Olly and IDA to a certain degree before you do all this. Moving on.. Step in to 402C38 and go all the way down to 4029BF, set a breakpoint and F7 in to 4020B0. Its important to set your breakpoints, as you then know exactly what path was taken..at any time. Scroll right down in 4020B0 and put a breakpoint on 402161. Once you’ve set your breakpoint, F9 and then look at the value in the EAX register. It should read “Open Process”. Hmm..interesting. Go back to the previous function and step into another CALL 4020B0..at 4029DD and F9 again. You should break again, at 402161. You still have a breakpoint there..right? Look at EAX again. “WriteProces”. Another function…or at least part of it. Repeat this for every call to 4020B0 to probably get atleast part of all the function names, after which you can guess the remaining. Now..what is it doing with all these names? After all, it is not of much use unless those calls are actually made. One more breakpoint at 402A78 and F9. Now look at the Bottom Right pane in Olly. On the stack, the complete names of all the 4 functions are given. Awesome 🙂
Moving on there’s a call to GetModuleHandle to get a handle into kernel32.dll. A little lower down, there is a call to GetProcAddress to find out the address of the “OpenProcess” function…IN..IN..mfc42ul.dll. So these are signs that at some point, the malware is going to call “OpenProcess”. We’re getting closer..it seems. Will we see more similar calls? Oh yes we will. A total of 4 CALL EBX statements (all GetProcAddress) are made for each of the 4 functions you saw in the previous screenshot. The last such call is at 402AFE.
Move on and eventually arrive at 402C55. Aha. An OpenProcess call. The 3rd argument is the ProcessID. Value 794. What process is it trying to open?
Let’s look at my process list.
Oops. No 794. Huh? Well…remember…in Olly everything is Hex. So it’s 794 Hex which is Decimal 1940. And that is explorer.exe :). Nice. So it’s trying to do something in explorer.exe. What? Hop on to 402C91. VirtualAllocEx. It’s now allocating memory within Explorer.exe. Did you read that correctly? One process is allocating memory inside the Virtual Address Space of another process. The first argument to VirtualAlloc is the handle returned by OpenProcess. Hop on to 402CB0. WriteProcessMemory. Opened process. Allocated memory. Now I write into it. The 3rd argument is “from where” the data is going to be pulled. In this case…it is the DLL file mfc42ul.dll that was copied into %APPDATA% earlier :). So it is taking something from that DLL and injecting it into Explorer.exe. Neat IMO. Hop on to 402CBF. CreateRemoteThread. MSDN says it well – The CreateRemoteThread function causes a new thread of execution to begin in the address space of the specified process. Which means…the malware started a new thread INSIDE the address space of Explorer.exe. It’ll now have access to everything that Explorer.exe opens. The process now does a CloseHandle on the handle for Explorer.exe AND the new thread that it created inside Explorer.exe. This means that the malware, if it wants to access either, must use a new handle. This does NOT terminate the thread. And finally..finally it exits and goes back to 403CD2; the place where it all started. Well..most of it anyway ;)…I was just trying to be dramatic. As mentioned before the CALL 402CE0 is made twice more..to Skype.exe and SkypePM.exe. Everything is exactly the same…except that it doesn’t inject itself into the memory of Skype.exe…that’s probably because I don’t have Skype running. So almost everything is the same if you are stepping through the disassembly yourself..except one little jump which bypasses the Injection :). Jumps right over.
So if it doesn’t find Skype, it goes away? Er no. It behaves the same way for the 3rd call..SkypePM.exe and then does some more stuff at 403D02 and 403D22. Same function. Called twice. Once for Skype.exe and then for SkypePM.exe. The call at 403B36 eventually writes both Skype.exe and SkypePM.exe to disk on 2 separate passes. The call at 403BD8 writes information into the ‘Run’ key in the registry so that these files will be loaded on Startup..when the user logs in.
And that is about it :). The sizes of both SkypeLauncher.exe and SkypePMLauncher.exe seem very very similar. However we have to analyze only 1 of them and not both; since their hashes are the same.
Conclusion: Well…truth be told I wanted to start looking at the SkypeLauncher.exe this time itself. However there were a few interesting details in how the file arrived on to the disk in the first place which I did NOT want to gloss over. At the most you’ll have to read one extra article :)….bear with me. I do hope you are enjoying this little series; I try and read any feedback that is given and incorporate it the next time round if it makes sense, so please drop in a comment anywhere or Email me directly if you have something to say. Another thing that we saw was that the executable does not necessarily visit every path in the program. So you can’t just Run the executable and analyze ONLY the path it takes. You should take a look at that first..yes of course. However after you’re done with this, you should go back and look at the disassembly again…maybe there are other paths which need to be visited and studied. This was certainly true..this time. Wasn’t it? The next time I will look at SkypeLauncher.exe. Depending on how things go I plan to look at mfc42ul.dll and winsys32.sys separately as well. So that’s 3 more articles to go. Until next time…Cya 🙂 References: A series of articles for starting off in reversing – http://ardsec.blogspot.in/2011/07/reverse-engineering-6-malware-lab-setup.html [My blog :D] The IDA Pro book – http://www.amazon.com/The-IDA-Pro-Book-Disassembler/dp/1593272898/ref=sr_1_1?ie=UTF8&qid=1333485647&sr=8-1 Secrets of Reverse Engineering – Eilad Eldam – http://www.amazon.com/Reversing-Secrets-Engineering-Eldad-Eilam/dp/0764574817/ref=sr_1_2?ie=UTF8&qid=1333485647&sr=8-2 MSDN Windows Api reference – http://msdn.microsoft.com/en-us/library/windows/desktop/hh447209%28v=vs.85%29.aspx The most awesome reverse engineering forum – http://www.woodmann.com/forum/ [Do register; its a really nice bunch who’s helped me many a time]
