Lab summary questions

1. Considering malware analysis as a whole, how important is it to a general aspiring analyst to complete this chapter’s exercises?

2. What did doing the lab exercises teach that was not gained from reading the chapter?

Challenges encountered in the labs

Lab Walkthrough (includes answers!)

7.1

Analyze the malware found in file Lab07-01.exe.

Questions to answer as we go on:

1. How does this program acheive persistence?

   By installing a service known as MalService that runs a malicious function.

2. Why does this program use a mutex?

   It runs a mutex to see if a thread needs to be created or not. If the function obtains the mutex, then the program quits. Otherwise, the program attempts to create the mutex and proceeds to attempt to spin up a malicious thread. (This seems counter-intuitive at this point… see the post-answer-reading section below for a more detailed explanation of this.)

3. What’s a good host-based signature for detecting this malware?

   • Having a service named Malservice on the system.
   • Identifcation of a mutex called HGL345.

4. What’s a good network-based signature for detecting this malware?

   • User agent of just the string Internet Explorer 8.0
     • Connection under that user agent to http://malwareanalysisbook.com/

5. What’s the purpose of this program?

   It looks like this program will attempt to connect to a specific website at a certain time. I believe it’s a program that will turn infected computers into elements of a botnet, which will attack a site at a unified time.

6. When will this program finish executing?

   At some time very close to the turn of the 22nd century.

First, let’s review and apply static analysis techniques and dynamic analysis techniques from chapters 1-3 before doing too much with Ida.

CFFExplorer

The malware loads three DLLs: ADVAPI32.dll, WININET.dll, and KERNEL32.dll.

• From ADVAPI.dll: we have CreateServiceA, OpenSCManagerA, and StartServiceCtrlDispatcherA. The book previously described CreateService and OpenSCManager (see ch7 notes in a previous blog post), but I don’t recall seeing the start service function. Luckily, the book again proves its usefulness with Appendix A– the function is used by a service to connect to the main thread of the process to the service control manager. Any process that runs as a service must call this function within 30 seconds of startup. Locating this function in malware tells you that the function should be ran as a service. (This is insightful for question 1.)

• From WININET.dll: we have InternetOpenUrlA and InternetOpenA. We know from the book that these functions are used to establish a connection with a specific internet location and to initialize high-level Internet access functions from WinINet. Conveniently for us, InternetOpen requires a user agent parameter, and InternetOpenUrl requires a URL (imagine that). These is insightful for question 4, as each of these could act as network-based signatures if they’re consistent.

• From KERNEL32.dll: There are lots of functions being imported, but the ones that come to mind as notable are:

  • CreateMutexA and OpenMutexA as this will require a mutex name, which could act as a host-based signature. I predict the code around this function call will provide the answer to question 2.
  • CreateThread, as creating threads for various reasons was discussed in depth in the notes for this chapter.
  • GetCurrentProcess. This will permit the malware to do things with itself.
  • GetCommandLineA tells the process how it was called. This could be used to determine if it’s called as a service or if it’s called to install.
  • WriteFile saves data into a file! Files are always great host-based indicators.

There may be more note-worthy functions used, but none of the others jumped out at me as areas that should be further explored at this moment in time.

Resource Hacker

ResourceHacker found no resources in this file.

Strings.exe

In addition to all the imports, strings.exe highlights two notable strings: http://www.malwareanalysisbook.com and Internet Explorer 8.0, which I expect to see utilized as the C&C server and the user agent respectively.

Ida Demo

The first thing we see when opening this file in Ida is how it establishes persistence.

We see that the name of the service is pushed (MalService) and then a function pointer is pushed. This mimics the structure expected as a parameter to the function, according to MSDN. As such, we can conclude that sub_401040 is what will be called as a service from here on out, which acheives persistence and answers question 1.

Looking at the function passed to the call above….

A mutex HGL345 is attempted to be opened (with all access rights– that’s what the constant 0x1F0001 does) first thing. If the call returns 0 (i.e. NULL), that means the function failed to obtain the mutex, perhaps because it doesn’t exist or because it’s in use. If the call does NOT fail, then the program exits, which is sort of strange. Otherwise, the program proceeds to create the mutex. (Note that if the mutex exists, CreateMutex simply returns a handle to the mutex).

It makes a service as it has concluded a service doesn’t exist for itself.

It waits for some time. Not sure what “FileTime” is at this point, but it seems to wait, perhaps for a specific date, say, of a planned out DDoS.

If WaitForSingleObject returns nonzero, the program proceeds to go into an infinite (i.e. INT_MAX) millisecond wait loop. If WaitForSingleObject returns 0 (i.e. it has received a signal that it’s done waiting), a thread is created in which more malicious code is called– Ida calls it StartAddress. What does this do?

It appears to just establish a connection with a domain. Considering the fact that it looks like the previous code waits to create a thread until a specific time, and combined with a little cybersecurity intuition, I believe there’s enough evidence to suggest this program’s purpose is to DDoS a computer at a hardcoded time.

When? I’m not sure of specifics, but the date pushed to CreateWaitableTimerA includes the year 2100 and the rest of the parameters are 0, which makes me think somehwere around the turn of the century. More in-depth analysis may help me figure this out specifically, but I believe it would be more beneficial to read the answers to this and move on to the next sample of malware.

Realizations made after reading the book answers:

The first thing I looked up was an explanation behind the wonky-seeming mutex business. It goes like this:

1. If the initial mutex call OpenMutex succeeds, then the program exits. Otherwise, it continues.
2. If the program continues, the first thing it does is it attempts to create the mutex. The book says that if a copy of the malware was already running, then the first call to OpenMutex would have succeeded.

I get it now. The program runs forever, so it creates a mutex but does not obtain access to it. This is an indicator to all future instances of the program that it’s already running. Nothing else will obtain this mutex (or if it is obtained, it’ll be released very soon as the program will obtain it and then exit, which will, I presume, free the mutex). The mutex will simply act as a gatekeeper of sorts.

But what if the computer restarts? Will the mutex persist? If it will, then, since the function called by the service manager contains the initial mutex check, the service should theoretically end. Is this a bug, or is it author-written protection for newbie malware analysts, or am I just not understanding something? Hmmmm…..

The answer to this question is answered here. From what I can conclude, mutexes will not persist after handles to them are closed, so if the computer restarts, the service will recreate the mutex and go on its merry malicious way.

Anyway. Moving on:

One thing I did not pay close attention to was how the threads were created. I see now that it moves 20 into esi and then calls CreateThread until esi is 0. I believe that, since the startAddress is passed to each thread, we will have 20 different instances of connection requests, per bot in the botnet.

Furthermore, I see now that the program will not end, as in any case, push INT_MAX followed by a sleep occurs.

Lastly, looking more carefully at StartAddress will help one see that the loop that attempts connections with http://www.malwareanalysisbook.com will unconditionally repeat, meaning we will have 20 * unlimited connection attempts, per bot.

7.2

Questions to keep in mind as we go on:

1. How does this program acheive persistence?

2. What’s the purpose of this program?

3. When will this program finish executing?

This time, the first thing I did was open this program in Ida. Upon opening, we see this:

;

So, the COM library will be initialized, which hints that COM objects will be used. A few other functions will be used, and it’s worth looking them up to get the general idea of what they are used for before diving into the details.

• CoCreateInstance: Per MDSN docs, this creats a single uninitialized object of the class associated with a specified CLSID. It would be worth looking into what the passed-in CLSID is and see what that corresponds to. Note that the interface pointer created by the function is stored into var ppv.

• VariantInit: This function creates a variant. I believe that a variant is simply a data structure that supports many different data types, according to Microsoft.

• SysAllocString: Allocates a new string and copies the passed string into it. We should look into what is passed to this.

• SysFreeString: Frees an alloc’d string.

Let’s talk about what’s passed to CoCreateInstance. A CLSID is a 128 bit hex number. That’s 128 / 8 = 16 bytes.

We have a four-part structure here: a DD (define double word), a DW (define word), another DW, and then 8 DB (Define bytes). DD’s are 4 bytes, DWs are 2 bytes, and DBs are 1 byte. The 6 dup (0) just means we have 6 duplicate bbytes of the data 0.

dd	dw	dw	db	db	db	db	db	db	db	db
0002DF01	0000	0000	C0	00	00	00	00	00	00	46

So if we google this CLSID 0002DF01-0000-0000-C000-000000000046, we get a bunch of results that are basically meaningless. Instead, I just found the registry key that contains CLSIDs: HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID. In here, all the CLSIDs are organized (thank goodness).

So this CLSID corresponds to Internet Explorer.

Now let’s talk about the RIID. The RIID is a reference to the identifier of the interface to be used to communicate with the object returned by CoCreateInstance. It has the same byte-age as the above CLSID in memory.

dd	dw	dw	db	db	db	db	db	db	db	db
D30C1661	CDAF	11D0	8A	3E	00	C0	4F	C9	E2	6E

I threw the string D30C1661-CDAF-11D0-8A3E-00C04FC9E26E into Google and up pops a Microsoft page that tells us this corresponds to the IWebBrowser2 interface.

By now it’s quite evident that this program is interfacing with Internet Explorer. Further, it doesn’t appear there is any evident persistence mechanism at this time. We just need to figure out what exactly this program is doing and when it’ll finish executing.

Moving on. Let’s direct attention to this chunk of code.

.

The most important thing to note from this part of the code is that the COM object itself is being used to make a special function call. At the time of the call dword ptr [edx+2ch], the object is in edx (see how it was dereferenced from [eax] into edx earlier), and the offset 0x2c specifies a function offset from the beginning of the object. Identifying what function that offset corresponds to is explained on page 156 of the book. It says to go to the structures subview and then hit insert and then click “add standard structure.” I was able to add the structure but I didn’t see a way to utilize this information to identify the function being called in the assembly. Perhaps this is an Ida pro specific feature.

Either way, based on the fact that we are interfacing with Internet Explorer and we have a string that contains a URL, we can perhaps safely conclude that this program will end up having IE go to the website. Since the URL takes us to a page called “ad.html”, we can conclude this is probably adware. (Of course in the real world, we can’t validly make this assumption since anything could be called “ad.html,” but for purposes of this training, I think it’s acceptable in the interest of time.)

The program ends immediately after performing these actions, which suggests persistence is not acheived and that it won’t run forever or anything like that. It’s a simple baby adware program.

7.3

I’m putting this sample on the backburner for now, as I need to move on and learn about some malware obfuscation techniques in lieu of finding a thesis project of some form. Check back later on.