Morto Malware Analysis

From UIC

Morto Malware Analysis

Morto Malware Analysis
Author:	Antelox
Email:	antelox@yahoo.it
Website:	antelox.wordpress.com
Date:	05/09/2011 (dd/mm/yyyy)
Level:
Language:	English
Comments:

Introduction

Today we're going to analyze Morto.A a malware which, in this weeks, is spreading in many Internet places. It's a worm that allows unauthorized access to an infected computer and tries to compromise administrator passwords for Remote Desktop connections, through RDP protocol, on a network. Indeed this threat infecting computers by targeting accounts that have "weak" passwords.

Tools & Files

We'll need a few tools:

• VMware, VirtualBox, Parallels or any other virtual machine with Windows installed (I used Windows XP SP3)
• LordPE or any other memory dumper (OllyDump will do as well if you use OllyDbg v1.10)
• OllyDbg, any version
• RegShot
• SysAnalyzer
• CFF Explorer
• Sample, password is: infected

Malware Identification

This is a report of how the various AV are detecting this malware:

• AhnLab-V3 -> Win-Trojan/Npkon.49969

• AntiVir -> TR/Agent.49969.1

• Antiy-AVL -> Worm/Win32.Morto.gen

• Avast -> Win32:Malware-gen

• Avast5 -> Win32:Malware-gen

• AVG -> Agent3.ACOR

• BitDefender -> Win32.Worm.Morto.A

• ByteHero -> Trojan.Win32.Heur.Gen

• CAT-QuickHeal -> Worm.Morto.a

• ClamAV -> Worm.Morto

• Commtouch -> - Not detected

• Comodo -> TrojWare.Win32.Trojan.Agent.Gen

• DrWeb -> BackDoor.Tsclient.1

• Emsisoft -> Worm.Win32.Morto!IK

• eSafe -> Win32.Dropper

• eTrust-Vet -> Win32/Morto.A

• F-Prot -> - Not detected

• F-Secure -> Worm:W32/Morto.A

• Fortinet -> W32/Morto.B!worm.im

• GData -> Win32.Worm.Morto.A

• Ikarus -> Worm.Win32.Morto

• Jiangmin -> Backdoor/DsBot.dov

• K7AntiVirus -> Riskware

• Kaspersky -> Net-Worm.Win32.Morto.c

• McAfee -> W32/Morto

• McAfee-GW-Edition -> W32/Morto

• Microsoft -> Worm:Win32/Morto.gen!A

• NOD32 -> Win32/Morto.B

• Norman -> W32/Morto.D

• nProtect -> Worm/W32.Morto.49969

• Panda -> Trj/MereDrop.B

• PCTools -> Trojan.Dropper

• Prevx -> - Not detected

• Rising -> - Not detected

• Sophos -> Mal/Morto-A

• SUPERAntiSpyware -> - Not detected

• Symantec -> Trojan.Dropper

• TheHacker -> Trojan/Agent.syl

• TrendMicro -> - Not detected

• TrendMicro-HouseCall -> WORM_MORTO.SMA

• VBA32 -> - Not detected

• VIPRE -> Trojan.Win32.Generic!BT

• ViRobot -> Backdoor.Win32.DsBot.53076

• VirusBuster -> Trojan.Agent!MYoVp4jcZjs

This is Virustotal result: 37/ 44 (84.1%). Good rate detection, isn't it uh?

Other additional information are:

MD5 Hash: 2EEF4D8B88161BAF2525ABFB6C1BAC2B
SHA-1 HASH: 0BBB014657BF4459FAA2E6FAF11D0559B196187C

to uniquely identify our malware.

Before Analysis

Power on your Virtual Machine, set up your best reversing malware tools, disable Drag'n'Drop and any Shared Folder, finally take a Snapshot of your clean machine so you can go back everytime you want.

Now take also another snapshot, this time of your Windows Registry so that you can compare it with another one after launching the malware, to see any change and every modification performed. For this RegShot is helpful ;)

So now that it's all ready let's start the malware analysis.

Morto Analysis

Before we run malware and make a dynamic analysis with SySAnalyzer, open morto.exe in CFF Explorer to see if it give us some interesting information. As you can see, Morto it's compiled with Microsoft Visual C++ 6.0. This inform us that it isn't packed/compressed (hopefully :P). You can also scan the executable with any packer detector for the sake of curiosity like PEiD, ProtectionID, RDG Packer Detector, etc...

Than let's go to the Import Directory and you notice 3 imported libraries:

• MFC42.dll
• MSVCRT.dll
• Kernel32.dll

There isn't doubt that this malware was built with MFC framework. If you don't know what is MFC framework just ask Google. It isn't really good news because applications builted with MFC Framework are very boring to reverse but don't worry, just read Pn's Tutorial about Basic MFC Reversing and continue reversing.

Open SysAnalyzer, choose morto.exe and Start; morto.exe is running.

Make a second snapshot with RegShot and compare with the first one to see the differences.

In short:

1. morto.exe is launched;
2. Creates:
   1. clb.dll in C:\WINDOWS ( this is the payload );
      
   2. ntshrui.dll in C:\WINDOWS\temp;
      
   3. Sens32.dll in C:\WINDOWS\system32;
      
   4. 1.40_TestDdos in C:\WINDOWS\Offline Web Pages;
      
   5. cache.txt in C:\WINDOWS\Offline Web Pages;
      
   6. ~MTMP<4RandomDigits>.exe, example ~MTMP657C.exe.
      
3. Operates some Registry modifications:
   1. rename at next reboot Sens32.dll to cache.txt through key HKLM\SYSTEM\ControlSet001\Control\Session Manager\PendingFileRenameOperations;
      
   2. hides any type of error message thorugh key HKLM\SYSTEM\ControlSet001\Control\Windows\NoPopUpsOnBoot;
      
   3. install ntshrui.dll and Sens32.dll as service;
      
   4. write some encrypted code in HKLM\SYSTEM\WPA\ ( This code is used then by clb.dll ).
      

Just for information and to clarify, clb library is a legitimate and benign Microsoft system dll which is used with regedit.exe to perform operations in Windows Registry, so the name has been chosen for this reason.

Now that we have gathered enough information let's go to analyze our malware in OllyDbg.

Debugging Session

Once opened it we land to the EP. Being builted with MFC Framework we must find WinMain function, indeed it's at 0x4019B3:

Step into (F7) to dig deeper and we land here, at 401BE0 address in AfxWinMain like every application built with MFC:

Step into (F7) when you arrive to the AfxWinMain. We land in the JMP NEAR DWORD PTR DS:[<&MFC42.#1576>], Step Over (F8) and we arrive into AfxWinMain function:

Now we'll get the address of VFT, that is the Virtual Functions Table! Why? Because you can see there are some call [EAX+XXh]. Indeed in EAX there will be the VFT address so then, added with a specific constant, we'll obtain a precise function. In our case the address is 0x402110. Open morto.exe also in IDA disassembler to get more info, let's go to 402110 address and you can see the VFT. So the first call in disassembler is the InitInstance function of CWinApp class (MSDN for more information) because 402110 + 8C = 40219C, now back in IDA, scroll down till 40219C address and you can verify that it corresponds to InitInstance. Through same reasoning you get information about other function calls.

The call that execute important tasks is CALL NEAR DWORD PTR DS:[EAX+58], Step into...

Through call at address 40165F we obtain the address of a encrypted block. This encrypted block is the one which will be copied in wpa registry key and it is contained in morto.exe. This address in my PC is 8F1796. Step by step and you will understand more better all this. See follow:

After this call there is a malloc function which allocates a memory block of BBDFh (48095d bytes) size. Once executed it, in EAX there's the address of this memory block ( in my PC is 3339C0, keep in mind! ) Than there are some important things, look below:

- First it prepares ESI and EDI register with address of previously encrypted code and memory block allocated before respectively;

- Second it prepares ECX counter register for REP instruction.

Properly with 2 REP instuctions it moves the content of encrypted block into memory block allocated by malloc before; from 8F1796 to 8FC375 hence from 3339C0 to 33E59F. Take a look at the ESI and EDI registers and follow them in dump to verify!

The call at address 40169C do nothing of important, replace the content of some stack address with 0s.

Another important call is the call at address 4016b2, hence step into and when you meet next call F7 again and we land here in one important piece of code:

As you can see, first through a loop it's rewritten the encrypted block, then there is a VirtualAlloc API which commits a region of pages. In my PC the address of this committed page is 9F0000 with excecutable-read-write permits (XRW flag in LordPE). All this it's important because in this committed page there will be write the clb library, that is the payload. The next call instead writes some things into committed page. Let's continue the analysis.

As in all other cases, after VirtualAlloc API follow LoadLibrary and GetProcAddress to write IT (Import Table), step now into the call at address 40110D and you will see the code below:

Comments on the image and your debugging steps will be the icing on the cake to understand much more!

If you continue debugging you'll arrive to call EDX. This instruction call the dll (in this case cld.dll) which it was prepared through previously explained steps. Now it's time to use LordPE to dump the dll to analyze further. To do that, step into call EDX and we land here, EP of dll ;) :

Now, open LordPE -> select our morto.exe -> right click -> Dump Region and select the address 9F0000, the only with XRW flag. This is the memory region before being committed by VirtualAlloc (see above if you don't remember) Give a name at dump, then open it with one HexEditor and delete everything before MZ signature and save it, i.e. as clbDump.dll. As I said before this dll is the payload, that performs most of the main actions, said with simple words.

If you open it in CFF Explorer you can confirm that it's a dll, just look in File Header -> Characteristics -> 'File is a DLL' is checked.

Once call EDX is executed morto.exe "jump" into clb.dll to perform the most important features, but we'll deal with it in the next tutorial!

Greetings

Greetings goes to Quequero, Evilcry, Giada and all other UIC members! =)

Antelox

Disclaimer