After one year of total absence for various reasons from my blog, I'm returned here to present my one recent research in my new blog ;).
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.
[ Contact me for sample. ]
Malware Identification
Below I report how this malware is identified by some AV:
- 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:
- morto.exe is launched;
- Creates:
- clb.dll in C:\WINDOWS ( this is the payload );
- ntshrui.dll in C:\WINDOWS\temp;
- Sens32.dll in C:\WINDOWS\system32;
- 1.40_TestDdos in C:\WINDOWS\Offline Web Pages;
- cache.txt in C:\WINDOWS\Offline Web Pages;
- ~MTMP<4RandomDigits>.exe, example ~MTMP657C.exe.
- Operates some Registry modifications:
- rename at next reboot Sens32.dll to cache.txt through key HKLM\SYSTEM\ControlSet001\Control\Session Manager\PendingFileRenameOperations;
- hides any type of error message thorugh key HKLM\SYSTEM\ControlSet001\Control\Windows\NoPopUpsOnBoot;
- install ntshrui.dll and Sens32.dll as service;
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:
.text:004019A8 push eax ; nShowCmd
.text:004019A9 push esi ; lpCmdLine
.text:004019AA push ebx ; hPrevInstance
.text:004019AB push ebx ; lpModuleName
.text:004019AC call ds:GetModuleHandleA
.text:004019B2 push eax ; hInstance
.text:004019B3 call _WinMain@16 ; Jump to WinMain function
.text:004019B8 mov [ebp+var_68], eax ; Dig Deeper
.text:004019BB push eax ; Code
.text:004019BC call ds:exit
Step into (F7) to dig deeper and we land here, at 401BE0 address in
AfxWinMain like every application built with MFC:
.text:00401BE0 push [esp+nShowCmd] ; int
.text:00401BE4 push [esp+4+lpCmdLine] ; char *
.text:00401BE8 push [esp+8+hPrevInstance] ; struct HINSTANCE__ *
.text:00401BEC push [esp+0Ch+hInstance] ; struct HINSTANCE__ *
.text:00401BF0 ; AfxWinMain(HINSTANCE__ *,HINSTANCE__ *,char *,int)
.text:00401BF0 call ?AfxWinMain@@YGHPAUHINSTANCE__@@0PADH@Z
.text:00401BF5 retn 10h
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 ;) :
009FE8A2 55 PUSH EBP
009FE8A3 8BEC MOV EBP, ESP
009FE8A5 53 PUSH EBX
009FE8A6 8B5D 08 MOV EBX, DWORD PTR SS:[EBP+8]
009FE8A9 56 PUSH ESI
009FE8AA 8B75 0C MOV ESI, DWORD PTR SS:[EBP+0C]
009FE8AD 57 PUSH EDI
009FE8AE 8B7D 10 MOV EDI, DWORD PTR SS:[EBP+10]
009FE8B1 85F6 TEST ESI, ESI
009FE8B3 75 09 JNE SHORT 009FE8BE
009FE8B5 833D 75D8A300 0 CMP DWORD PTR DS:[0A3D875], 0
009FE8BC EB 26 JMP SHORT 009FE8E4
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!
[ Update: 29/09/2012 ]
Ok, time is passed and I didn't write 2nd part of the Morto Analysis as I said in the last part of this tutorial. Write about it now doesn't make sense but, at least, I can list main payload operations once it's allocated in memory, decrypted, re-allocated again and started by dropper.
Below the operations:
- Morto tries to connect to infected computer and exploits
Remote Desktop connection ( RDP protocol ) to the
3389 port. The usernames used are listed below
1
actuser
adm
admin
admin2
administrator
aspnet
backup
computer
console
david
guest
john
owner
root
server
sql
support
support_388945a0
sys
test2
test3
user
user1
user5
with follow passwords
!@#$%
%u%12
*1234
000000
111
1111
111111
123
123123
123321
12345
123456
1234567
12345678
123456789
1234567890
1234qwer
168168
1q2w3e
1qaz2wsx
369
520520
654321
666666
888888
aaa
abc123
abcd1234
admin
admin123
letmein
pass
password
server
test
user
It's clear now because I said "weak passwords". ;)
- Morto downloads
r.reg file, and through it starts rundll32.exe with Administration privilege to execute
clb.dll malicious DLL at next OS startup. All this by way of the
\\tsclient\a
- Malicious domains contacted by Morto below
210.3.38.82
jifr.info
jifr.co.cc
jifr.co.be
jifr.net
qfsl.net
qfsl.co.cc
qfsl.co.be
- Morto is also capables to download new components and new payload variants, which moreover it's installed also as Windows Service named
6o4.
- More, Morto has hardcoded string like these:
ACAAS
360rp
a2service
ArcaConfSV
AvastSvc
avguard
avgwdsvc
avp
avpmapp
ccSvcHst
cmdagent
coreServiceShell
ekrn
FortiScand
FPAVServer
freshclam
fsdfwd
GDFwSvc
K7RTScan
knsdave
KVSrvXP
kxescore
mcshield
MPSvc
MsMpEng
NSESVC.EXE
PavFnSvr
RavMonD
SavService
scanwscs
SpySweeper
Vba32Ldr
vsserv
zhudongfangyu
which is used to stop some processes of most popular security software.
Ok, I want to clinch that this update is only to conclude the post in different way because I hadn't time to publish the payload analysis made by me one year ago. Again, this update didn't add new informations compared to that you can find reading other analysis.
The new/last variant
The new Morto variant mainly has added file infection capability through Code Injection but the goal is the same of the first variant;
compromise RDP connections with weak Admin password.
Morto Injects its code to
svchost.exe Windows OS file system, then creates a Mutex, to avoid multiple injections to the same file, named
Global\_PPIftSvc.
The file infected, after injection, has in the MZ Header
PPIF string as Infection Marker.
Malicious domains contacted by Morto to download other files, updates, etc are:
d.ppns.info
e.ppift.net
e.ppift.com
e.ppift.in
In addition to these operations, there are no significant changes compared to the previous variant of the malware, so this is all.
Greetings
Greetings goes to Quequero, Evilcry, Giada and all other UIC members! =)
Antelox