In the last two parts, available here and here, we looked at the dropper and one of its components (a small EXE file) in quite some detail. In this part we will now look at another of its components, called SkypeLauncher.exe. This file seems to be available on Offensive Computing; so if you want to download it and play around with it, here it is. There was a comment on my first article requesting I provide a link to the initial malware; here it is. I’m going to go through this part a little quicker than the other two parts, but the techniques I use will be the same. In case there is something new, of course, I will go through it a little slowly. Let’s start. Details Opening the EXE in IDA shows us that the EXE ‘starts’ at 402E70. Olly says it is something different though; very similar to the previous parts. With the help of the Hit Trace feature we quickly find out that the first call to 402E70 is made at 409622. We need to start from here.
A mutex is created by the name ICP_Launcher_34943. The reason a mutex is created is so that a specific resource (code, memory, image etc.) can be accessed by only one thread at a time. Once the first thread finishes executing, the next thread can access that same region. The process continues once the mutex is signaled; this happens inside CALL 403B60.
The next significant event is CALL 403A80 where a thread is created in Suspended state and activated immediately.
The thread, once started, will call a function at 403AC0 as defined by the 3rd argument of the CreateThread function. Notice that Olly 2.01 has already entered ‘Callback‘ as a comment, confirming the fact that this function runs when the thread executes. Put a breakpoint on 403AC0, so you know exactly when it triggers. You don’t know when it will run, so for now just put a breakpoint.
The code then searches for the DLL previously copied into %APPDATA% of that particular user (mfc42ul.dll). This is probably so it can invoke certain functions exported by that DLL.
The code does a CALL 402910 and seems to delete copies of mfc42ul.dll00 to mfc42ul.dll99 from the user’s %APPDATA% directory. It isn’t clear why it does this. Once this is done, it does a CALL 401800 and tries to read the malicious DLL using CreateFile. It then however closes the file handle without doing anything with it. Hmm.
A little later the current running thread is made to sleep and an old suspended thread is resumed. Olly helpfully tells us this as shown below.
Hmm. Can you think of any old suspended threads? Certainly. Remember the ‘Callback’ thread which we set a breakpoint on a while ago? Maybe its that thread which is NOW trying to run. Let us see if our old breakpoint is triggered….
Perfect!! The calling thread goes to sleep and the old thread takes over. This is all ‘handled’ by the OS; it decides which thread runs and when. Before moving on, set a breakpoint on the instruction after the sleep. It is there that the code will return after this thread stops running.
Let us see what this thread does now. Just 2 instructions in, it makes a call to 402C70. It checks if SkypeLauncher.exe and SkypePMLauncher.exe are present in %APPDATA%. It also seems to check for the presence of the registry keys in CurrentVersionRun; these ensure that the program is restarted every time the machine reboots. I would like to take a small detour at this point, to show you how it is possible to speed reversing up a little. If you look at the code inside 402C70 you will notice calls to 403AB0. Stepping into this call shows you that all this function does is call sleep with a relatively large value as an argument. Now if you’re reversing, trying to understand something and you’re stopped by a sleep each time, it can get irritating very very fast. So you want to do something that will prevent the machine from sleeping so long on each pass.
The cleanest way is to modify the code to reduce the time argument passed to the sleep function. So we change PUSH 0EA60 to PUSH 1 instead. This means that the code will sleep for an extremely small time interval; it will be barely noticeable. This process is called ‘patching an executable’.I won’t show you how to make this permanent, you can read up a little about the ‘Copy to executable’ feature in Olly 1.10.
Now, use the Animate Over features [Ctrl+F8] and see what happens. You’ll notice that there is a lot of activity between 402C91 and 402CA7. The code never exits the loop though. So hit ESC to stop this process and now hit F9 to run the program. All of a sudden, you will notice that the previous breakpoint at 402F30 is triggered; remember I’d asked you guys to set a breakpoint just after the sleep? If you didn’t, go ahead and set it now and restart the program .
Again, set a breakpoint just after the JNE loop at 402CA9. This is so that you know the exact point at which control returns to the earlier thread. Use this logic anytime there are multiple threads.
Before we get back to analyzing the malware, I want to tell you that you can view all the current threads by clicking on the ‘T’ button or typing Alt+T in Olly 2.01. Double clicking on any of these entries takes you to the exact spot where the thread currently is. Now back to analyzing stuff at 402F30.
The main thread makes a CALL at 402F60; stepping into this will eventually reveal further CALLs made to 403220 and then to 403190, 403370 and finally 40F3B0. The code inside 40F3B0 checks whether Skype is running by comparing skype.exe against a list of currently running processes.
Hmm. The malware is searching for Skype. As it turns out, while I’m not going into details, it also searches for explorer.exe, SkypePM.exe, msnmsgr.exe and yahoomessenger.exe. As of now it is not clear why it does this. The next CALL is to 4027C0. If the process by any of those names above is already running, then this function is relevant, otherwise it isn’t. A call to 402070 gets API addresses for OpenProcess, WriteProcessMemory, CreateRemoteThread and VirtualAllocEx. Funnily enough, it tries to start up a new process for some reason with the same name and path as the running process. This is done at 40166B. If the process is not running, this bit is skipped completely.
The next bit is interesting. A CALL to 4024A0 is made; and at 402595 a call to 4023E0 is made. At 402415 a call to OpenProcess is made to try and inject some malicious content into explorer.exe. Note btw that the addresses for the functions were again requested for the functions shown below.
The OpenProcess returns a handle which can be used by other functions which want to ‘talk’ to the process which was ‘opened’. VirtualAllocEx allocates some memory inside Explorer.exe, WriteProcessMemory writes some content to the allocated space, and finally CreateRemoteThread starts a thread in the memory space of Explorer.exe. I strongly recommend you read the MSDN help for all of these APIs, otherwise a lot of this might just pass over your head; I know it did for me, the first time I did this stuff .
I’m sure you guys must be thinking what exactly WAS written into explorer.exe’s address space. Right? Look at the 3rd argument of WriteProcessMemory; it’s a pointer to a buffer which contains the content to be written. In other words, the content to be injected is the 3rd argument. So what is the 3rd argument… Can you try and guess? Come on… try!
The screenshot isn’t great but you should be able to read it if you zoom in. What it is though is a pointer the DLL that was dropped (in Part 1), namely mfc42ul.dll. So effectively, the malware is injecting mfc42ul.dll INTO the memory space of the running explorer.exe. The destination is the 2nd argument to WriteProcess. So what exactly happens after WriteProcess writes mfc42ul.dll into explorer.exe? CreateRemoteThread is called; the 4th argument is the start address of the function to run after creating the thread; the 5th argument is a parameter that is passed to this function. Here, the 4th argument is the address of the LoadLibrary call and the 5th argument is the address where mfc42ul.dll has been written (00D80000). Too fast? So as soon as CreateThread runs, it immediately calls the function LoadLibrary(%APPDATA%mfc42ul.dll); this is what loads the DLL into explorer.exe’s address space.
Let’s use a little tool called LordPE (There are many other tools, this isn’t the only one; use whatever you’re comfortable with) to look at what DLLs are actually loaded by explorer.exe. If we’ve done everything right, mfc42ul.dll ALSO must be loaded. Let us check.
Perfect!! Let us now dump this DLL to disk and compare its approximate size with the initial mfc42ul.dll which we got from the 1st article. Right click on the DLL in LordPe and select ‘Dump Full’. Compare the sizes; you’ll see both are approximately the same size. The exact hashes won’t match (probably because LordPe added some info to it while dumping it to disk) but it does look like the entire DLL has been injected into the running process.
Now delete all the breakpoints except the one for OpenProcess at 402415. I want to show you another little feature that the malware has. It waits indefinitely and as soon as a process with any of the five names as listed earlier start, it tries to inject mfc42ul.dll into the memory of that process. Let us do a little experiment to confirm this. First look at the list of DLLs that calc.exe exports in LordPE. You should see all System DLLs there. Now rename calc.exe to msnmsgr.exe and start it. Also make sure that the malware is running inside Olly with only 1 single breakpoint at 402415 and it looks like its waiting for some input.
The moment this starts, the breakpoint is triggered, thus showing that the malware listens for msnmsgr.exe as well. So to sum up, it seems to look for skype.exe, skypePM.exe, explorer.exe, msnmsgr.exe and yahoomessenger.exe. So much like described publicly, this seems to be malware which intercepts a user’s private communications when the user uses any of those programs.
Now what actually does happen when a DLL is injected? Well, an application has an entry point from where it will start its execution. Similarly a DLL has a section called Dllmain from where execution starts. So for example: I could write a simple function inside Dllmain which just pops up a message box ‘Inside DLL’. Now if I inject this DLL into the memory of a running process using CreateRemoteThread as described earlier, a thread will be created inside the memory of the running process. The thread will call LoadLibrary(‘Dllname’) and the Dllmain function inside the DLL will get called and a message box will pop up saying ‘Inside DLL’. So to map that back to this discussion, the code in Dllmain() of mfc42ul.dll will get triggered as soon as LoadLibrary(‘mfc42ul.dll’) is called inside the memory of explorer.exe. To find out what exactly is happening, the DLL itself will have to be reversed. I won’t go too deep in this article and try and reverse mfc42ul.dll; I’ll leave that for the next article. However, for anyone who has been following this series closely I’ll give you a very quick peek into the injected DLL. All we will do is look at what strings have been hardcoded into the DLL that we dumped [dumped_mfc42ul.dll]. This isn’t any proof by its own, of course, but gives us a quick peek into what we can expect when we reverse the DLL. Here is a snapshot of a few strings inside the DLL, which lists out the programs and browsers that it possibly targets.
And here are some strings which are related to calls being made through Skype or some other program.
I can go on but I’ll stop here; that’s enough to show you what is possible. If you can’t wait for the next series, you can step through these three parts and have a shot at reversing the DLL yourself. Yeah, why not? Conclusion You see how we’re slowly getting closer and closer to the heart of the program? We had a dropper, we reversed it. We listed all the other files the dropper dumped on to our hard disk. We reversed a little EXE in part 2 and found two more files (both similar hashes) during that exercise. We reversed one of those here today (Skypelauncher.exe) and found out that its purpose is to run each time the user boots his/her machine up and inject a malicious DLL into the memory of certain targeted processes. In part 1 we established that the Bundestrojaner seemed to be a German government Trojan designed to collect info from suspicious computers. Well, it most certainly seems to be well on the way to doing that!! SkypeLauncher.exe seems to use the exact same techniques that we discussed in the first two parts but we certainly learned a little bit more about the malware. In the next two articles I will look at mfc42ul.dll and winsys32.sys. Don’t ask me why it is taking so long. I’m learning as I go along as well . 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; it is a really nice bunch who’s helped me many a time] DLL Injection – http://www.securitytube.net/video/801
