Morto Post Mortem: Dissecting a Worm
Imperva’s Tomer Bitton has dissected the Morto worm.
Morto has been in the headlines, for good reason. This worm is unique as it exploits Microsoft’s remote desktop protocol (RDP). It doesn’t exploit any specific vulnerability, it simply relies on people installing the worm and then it uses a brute force password attack to gain access to systems. It is the first time we’ve seen something like this. The malware itself is sophisticated even if the method of proliferation isn’t.
Once again, we have an example highlighting the importance of good passwords. Blocking the spread of this worm relies on using a sophisticated password that isn’t on the worm’s dictionary list. Tomer’s malware dissection shows the 103 passwords that made Morto’s dictionary, including complicated, sneaky ones like ‘111111’, ‘david’, ‘admin2’, ‘123456’ and–shockingly–‘rockyou’. Nearly two years after being published, the RockYou password list continues to be used by hackers in brute force password dictionaries.
One thing we determined from looking at the worm was origin. Looking at DNS information, the worm seems to have originated from China, Hong Kong and Australia.
Dissecting Morto: From a Memory Dump Point of View
(NOTE: Click on any image to BIGGIFY).
Morto infects Windows workstations and servers. It uses a never seen before spreading vector – RDP.
For this analysis I have decided to use the famous memory forensics framework, “volatility”.
In order to analyze Morto with volatility framework you will have first to dump out the full RAM contents. I have used my preferred tool MoonSols win32dd.exe tool.
Once my sandbox was ready I have executed my Morto sample (MD5: 2EEF4D8B88161BAF2525ABFB6C1BAC2B), waited a few seconds till I saw some network activity and some file system modifications, fired up win32dd.exe and saved the memory file as “morto_mem.dmp”
We are ready, let’s fire up volatility and start the analysis:
From [imageinfo] we know:
“If you don’t know what type of system your image came from, use the imageinfo command. Among other things, the imageinfo output tells you the suggested profile that you should Pass as the parameter to –profile=PROFILE;”
From [pslist], we know: “To list the processes of a system, use the pslist command. This walks the doubly-linked list pointed to by PsActiveProcessHead”
Note: I have used the –P switch to obtain the physical offset.
Hmmm, looks like no malicious process / processes are running….
Let’s see opened connections:
“To find connection structures using pool tag scanning, use the connscan command….”
Yep, port 3389 (RDP) and looks like PID 1064 is the trouble maker, let’s check the process name:
By its’ timestamp (2011-08-30) and its’ PPID (parent pid) we can understand that this process is a legitimate system process.
Let’s check all svchosts processes PPID:
Same timestamp and all have a parent pid of 676, which is services.exe:
If svchost.exe (PID 1064) is a legit process why are the malicious connections?
192.168.164.128:1055 -> 192.168.162.1:3389 (PID:1064)
192.168.164.128:1046 -> 126.96.36.199:80 (PID:1064)
A dll ?
Let’s see what file system modifications occurred during the infection (regshot output):
C:WINDOWSOffline Web Pages1.40_TestDdos
C:WINDOWSOffline Web Pages2011-09-07 0545
C:WINDOWSOffline Web Pagescache.txt
C:Documents and SettingsAdministratorDesktopmorto.exe
We can see that during the infection process Morto creates 4 new files on the infected system and also deletes itself.
Notice the Sens32.dll that was created; let’s check if it is loaded by a specific process:
Yep, “Sens32.dll” is loaded by our “malicious” svchost.exe process, let’s dump our malicious process:
It was reported that Morto finds a Remote Desktop server and then it attempts to login as Administrator using a list of hard-coded passwords. Let’s try to get this list:
And here is the list:
After removing duplicates users / passwords the list included 103 items:
It was reported that Morto “copy itself to the target system by creating a temporary drive under letter A: and copying a file called a.dll”: