Lab01-02 Analysis

This program is packed using UPX and can be easily unpacked.

At the start we see a call to ‘StartServiceCtrlDispatcher’ which is used to implement a service and the service control manager will call the service entry point provided. In here I have labeled the service entry point as ‘ServiceMain’. The name of the service created would be ‘Malservice’.


‘StartServiceCtrlDispatcher’ API takes an pointer to the array of ‘SERVICE_TABLE_ENTRY’ structure.

BOOL WINAPI StartServiceCtrlDispatcher(
  _In_ const SERVICE_TABLE_ENTRY *lpServiceTable
);

The ‘SERVICE_TABLE_ENTRY’ structure looks something like this. ‘lpServiceName’ contains the name of the service and ‘lpServiceProc’ contains the pointer to the service entry point.

The pseudo code of the main function of this malware would look something like this.

int _tmain (int argc, TCHAR *argv[]) {

  SERVICE_TABLE_ENTRY ServiceTable[] = {
    {L”Malservice”, (LPSERVICE_MAIN_FUNCTION) ServiceMain},
    {NULL, NULL}
  };

  StartServiceCtrlDispatcher (ServiceTable);

  return 0;
}

In the service entry point we see API calls to ‘OpenMutex’ and ‘CreateMutex’. This is to make sure only one instance is running. This snippet creates a new mutex as ‘HGL345’. If ‘OpenMutex’ succeeds the program will exit.

if (OpenMutex(MUTEX_ALL_ACCESS, NULL, L”HGL345”))
  ExitProcess(0);
CreateMutex(NULL, FALSE, L”HGL345”);

Next the malware calls the ‘OpenSCManager’ API which will open a handle to the service control manager which allows it to add or modify services. We can see the malware uses ‘CreateService’ API to create a new service as ‘Malservice’. The ‘GetModuleFileName’ API is used to get the location of the malware and it is passed as the ‘lpBinaryPathName’ parameter.
Furthermore we can see the ‘dwServiceType’ as ‘SERVICE_WIN32_OWN_PROCESS’ and ‘dwStartType’ as ‘SERVICE_AUTO_START’. This service will run in it’s own process and will be started automatically by the service control manager.

The pseudo code will look something like this.

	TCHAR lpszBinaryPathName[1000];
	LPCTSTR lpszServiceName = "Malservice";
	GetModuleFileName(NULL, lpszBinaryPathName, sizeof lpszBinaryPathName);
	SC_HANDLE schSCManager = OpenSCManagerA(NULL, NULL, SC_MANAGER_ALL_ACCESS);
        CreateService(
		schSCManager, // SCManager database
		lpszServiceName, // name of service
		lpszServiceName, // lpszDisplayName service name to display
		SC_MANAGER_CREATE_SERVICE , // desired access
		SERVICE_WIN32_OWN_PROCESS, // service type
		SERVICE_AUTO_START, // start type
		SERVICE_ERROR_IGNORE, // error control type
		lpszBinaryPathName, // service's binary
		NULL, // no load ordering group
		NULL, // no tag identifier
		NULL, // no dependencies
		NULL, // LocalSystem account
		NULL // no password
	);

In the above disassembly we can lots of code dealing with system time. We see an API call to ‘SystemTimeToFileTime’ which will convert system time to file time. You can check MSDN for more details on this API. We can see the structures ‘SystemTime’ and ‘FileTime’. They look something like this.

At the start we see edx is being zeroed out and the ‘SystemTime’ structure’s fields are initialized with ‘0’ except the ‘wYear’ field.

.text:004010BC                 xor     edx, edx

The ‘SystemTime.wYear’ will contain the value ‘2100’.

.text:004010D8                 mov     [esp+40Ch+SystemTime.wYear], 834h

This malware uses the midnight time of January 1st 2010.
We can see API calls to ‘CreateWaitableTimer’, ‘SetWaitableTimer’ and ‘WaitForSingleObject’.
The pseudo code will look something like this.

HANDLE hTimer = CreateWaitableTimer(NULL, TRUE, NULL);
SetWaitableTimer(hTimer, (LARGE_INTEGER *) &FileTime, 0, NULL, NULL, 0);
if(WaitForSingleObject(hTimer, INFINITE)) {
} else { 
}

With the usage of these API calls the malware will wait till the midnight of January 1st 2010 and on that day it will create 20 threads and call the function at ‘00401150’ in which I have renamed as ‘DoS’.

.text:0040111B                 mov     esi, 14h

The counter will be stored in esi which is 20.

If we check this function at ‘00401150’ we can see it uses ‘InternetOpenUrl’ and will download the index page of ‘http://www.malwareanalysisbook.com’. This function will loop infinitely ‘InternetOpenUrl’ causing to download the page resulting in a DoS attack.

00401180   .^\EB EB         JMP SHORT Lab01-02.0040116D 

After infection we can see the installed service. Notice the constants we saw before to the ‘CreateService’ API call.

We can also check the registry for the newly installed malicious service.

HKLM\SYSTEM\CurrentControlSet\Services\

As a conclusion this malware will install a malicious service and wait till midnight of 1st of January 2100 and perform a DDoS attack to ‘http://www.malwareanalysisbook.com’ which will create 20 threads and each thread will loop infinitely.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s