Last updated on: September 6, 2020
Morto is a self-replicating malware, i.e. a worm that exploits Windows servers with weak passwords through the Remote Desktop Protocol (RDP). It was first detected in July of 2011 and was held responsible for a 200-fold increase in RDP scanning activity from approximately 500 sources to over 100,000 sources . In typical malware fashion it looks for common security software and disables their function, once it has successfully infiltrated the machine. Then it connects to its command & control server to wait for instructions and receive software updates.
Even though the number of Morto infections was not considered high   compared to other notorious malware types, Morto has interesting algorithms in its internals, and this article will focus on of them. Also, there was rumor  about a possible version of Morto and this will be discussed in the section titled Morto Variant.
More details about Morto’s history and its activities can be found at  and .
Morto can be divided in three components, as shown in Figure 1.
Figure 1: Morto Architecture
The dropper is the executable file, which, in order to call the loader, drops the embedded malicious DLL into the system and calls regedit.exe, which is the application that executes the loader. Once the loader is executed, it creates a service in the system and drops another malicious DLL, which is then called by the malicious service. This second DLL is responsible to call the payload.
Most of the available public analysis, such as  and , describe Morto’s activities and its three components: dropper, loader and payload. However, little is known about how the components are interacting between them. This article will focus on how the dropper and loader work in conjunction to execute the payload.
In particular we will analyze and answer the following questions regarding Morto:
- Why delete HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU registry key, which stores the list of executed programs through the run dialog?
- How is regedit actually executed in order to load malicious DLLs?
- How does the loader execute the payload?
- What is sens32.dll?
- What is HKLM\SYSTEM\WPA\sn?
- Why is it called “Morto”, which means dead in Portuguese? Actually, we don’t know the answer to that one.
In the next sections, each component will be described in more details focusing on its internal algorithms.
The dropper is divided in three parts as shown in Figure 2.
Figure 2: Dropper
Part one removes obfuscation in the data section, turning it into a “plain” code which is executed later by the entire malware. Part two stores data into the registry which is used later by the malware. Finally, part three drops the loader into the system and executes “regedit.exe”. The three parts are described in more details below.
Dropper – Part one
It starts by allocating memory through ZwAllocateVirtualMemory and copying itself into this area. At this time, the code in memory is obfuscated, and being so, Morto will then de-obfuscate the code and copy the “plain” code to another memory area, allocated through VirtualAlloc. Now, the code is ready to be executed, and Morto finally calls it.
Dropper – Part two
Part two calculates a random number using function GetTickCount, srand and rand, which is then stored in HKLM\SYSTEM\WPA\id. It then attempts to read HKLM\SYSTEM\WPA\md which does not exist yet, on a non-infected machine. It continues its execution by allocating memory and copying obfuscated data into it, which is later stored in HKLM\SYSTEM\WPA\md. Also, another block of memory is allocated and a DLL is copied into it. Then, it executes GetSystemTime and stores its results in HKLM\SYSTEM\WPA\it as well as creates a file under c:\windows\offline web pages\ with its name based on GetSytemTime. Once the plain code execution finishes, a call is made to a function which receives “Drop” as its parameter. This function returns an address which is the third part of the dropper, that will be discussed in the next section. It is interesting here that the malware itself confirms that it will “drop” something onto the system calling that function. Figure 3 shows the call to the function which received “Drop” as a parameter.
Figure 3: Call to drop loader
Dropper – Part three
Part three of the dropper starts by attempting to create a file in \\tsclient\a\ whose name is constructed by a fixed prefix ID plus the random value obtained in part two, which was saved in registry key HKLM\SYSTEM\WPA\id. The malware does not even check if a RDP session is opened or if the drive is already mapped: an attempt to create this file could be a way to check if the system is already infected, but since the ID is random this might not be the case. It then deletes the registry key HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU, but the reason for that is still unclear. Next, it creates the registry key HKLM\SYSTEM\WPA\md and adds to it the data that was allocated in part two: this seems to be the payload. Then the DLL c:\windows\clb.dll is created, using the data copied by part one, and its MAC times (modification time, access time and creation time) are changed based on the valid DLL c:\windows\wmi.dll. This is used to fool an analyst who would look for last changed files on the system. Figure 4 shows malicious DLL c:\windows\clb.dll after the MAC times change.
Figure 4: clb.dll after change its MAC times
Finally, regedit is executed to load the malicious DLL c:\windows\clb.dll. This is when things gets really interesting. Instead of just calling regedit.exe through common functions such as System, the dropper enumerates windows until finds a run dialog window, then changes its text to regedit.exe and clicks on button “OK”. The user does not see any window opening; however, if we open run dialog ourselves, regedit.exe is clearly visible. Figure 5 shows run dialog window before button “OK” is executed.
Figure 5: regedit.exe being executed
The use of the run dialog window explains why it previously deleted registry key HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU which lists the commands executed through the run dialog.
Before we continue with the loader analysis, it is important to understand how the malicious DLL clb.dll, which is placed under c:\windows, is executed by regedit. This is done by the search order which Windows looks for DLL as described at  and explained from a malware standpoint at . But basically, once an application loads a DLL, if its name is not listed under HKLM\System\CurrentControlSet\Control\Session Manager\KnownDLLs, Windows operating system will check on the application’s path. Since clb.dll is not listed under the KnownDLLs registry key and regedit.exe is placed under c:\windows, it will look for clb.dll under c:\windows directory and execute its version of the clb.dll, that is the malicious one, instead of the original c:\windows\system32\clb.dll. Using the sysinternals tool  procmon we can clearly see the malicious DLL clb.dll getting executed by regedit.exe, as depicted by Figure 6.
Figure 6: Malicious clb.dll being executed by regedit.exe
The loader is also divided in three parts, as shown in Figure 7.
Figure 7: Loader
Part one checks if the calling process is rundll32.exe, which is responsible for load DLLs into the system, and tries to open an existing file probably for Morto to check if the system has been already infected. Part two has the same function as dropper’s part two; however in this case, it reads the registry key HKLM\SYSTEM\WPA\md. Part three simply calls the payload. The next sections will describe the three loader parts.
Loader – Part one
First, the loader checks if the calling process is rundll32.exe. Since I executed the loader through OllyDBG debugger , loaddll.exe was used instead of rundll32.exe because loaddll.exe lets us debug a DLL instead of just execute it such as rundll32.exe. But on the payload, Morto executes rundll32.exe in order to execute malicious DLL on an infected system. If this part was called by rundll32.exe, the malware would try to open the existing file \\tsclient\a\moto, which where the name Morto came from and that is most likely to be used to check if system has been already infected. It also reads the first 4 bytes of c:\windows\winhlp32.exe, but if it does not exist, it tries to read the first 4 bytes of c:\windows\system32\write.exe. The first 4 bytes are 0x4D, 0x5A, 0x90, 0x00, which are common for every PE file. One may initially thought that such bytes would be inserted at beginning of HKLM\SYSTEM\WPA\md to and make it an executable. However, that was not the case, and so those 4 bytes might be used by the payload itself for another reason that is still unclear or they are were just another trick used by the author to fool the analyst.
Loader – Part two
The part two has almost the same function as the dropper’s part two: the only difference is that here the HKLM\SYSTEM\WPA\md already exists and its contents are read and placed into a buffer. Again, a call is made to a function which returns the address for where the execution will be jumped to and represents the part three. Regarding the parameter, at this time the string “Load” is used as parameter instead of “Drop”: this parameters shows that the malware is attempting to execute the loader.
Loader – Part three
Part Three deletes again the registry key HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU and then copies the valid file c:\windows\system32\wmi.dll to c:\windows\temp\ntshrui.dll. Then, a service named “6to4” is created which is the first string returned by a query on HKLM\Software\Microsoft\Windows NT\CurrentVersion\Svchost\netsvcs. The binary path of service is set to C:\WINDOWS\system32\svchost.exe –k netsvcs, and then the service parameter is changed to c:\windows\temp\ntshrui.dll. After that, the real malicious c:\windows\temp\ntshrui.dll is created. At this time, we have a service created that, when executed, loads another malicious DLL that seems to be the payload. Figure 8 shows the malicious service created while on stopped state.
Figure 8: Malicious service 6to4
Before the potential payload (DLL c:\windows\temp\ntshrui.dll) gets executed, the loader still changes some configuration on the service Sens, which is responsible for monitor system events , loader will first copy the valid file c:\windows\system32\sens.dll to c:\windows\system32\Sens32.dll, change HKLM\SYSTEM\CurrentControlSet\Services\Sens\DependOnService to NULL and HKLM\SYSTEM\CurrentControlSet\Services\Sens\Group to SchedulerGroup, and finally lastly modify the parameter stored at HKLM\SYSTEM\CurrentControlSet\Services\Sens\Parameters\ServiceDll to c:\windows\system32\sens32.dll. This service might be used later by the payload.
Looking at ntshrui.dll, it is clear how the payload is executed: Morto checks if the calling process is svchost.exe and, if so, another part of the plain code is called and a thread is created pointing to the real payload.
There was a rumor about a new Morto variant , we executed and analyzed it but concluded it is innocuous since it does not perform any change on the system, nor any network activity. Also, the malware does not check if it is running on a virtual environment or any other thing that would make it not execute. Probably, it was considered a possible Morto variant for two reasons:
- It creates a Mutex object , which is commonly used by malware to check if a machine has been already infected, with the name “_MOTOCCATK_”. Figure 9 shows assembly code responsible to create Mutex.
Figure 9: Mutex
- It reads contents from the HKLM\SYSTEM\WPA registry key which is used by Morto. Figure 10 shows Morto variant reading the registry key HKLM\SYSTEM\WPA.
Figure 10: Morto variant reading registry key
Then, we developed a little tool named check_mutex.exe which helps detect malware that uses mutex. Basically, once a malicious mutex is known, just run check_mutex.exe passing the malicious mutex name as a parameter, and it will check if a process is running with the given mutex name, and if so, it will display its process ID. Then, even though Morto variant does not attempt to harm the system, we put a breakpoint after a call is made to CreateMutexA function and executed check_mutex on the system to make sure it is working properly. Figure 11 shows check_mutex in execution.
Figure 11: check_mutex
Thanks to ISC Handlers who provided us sample for analysis. Thanks to @Ivanlef0u who developed code to list handles, and made it public, which helped a lot on check_mutex development.
Despite its interesting payload, the way Morto is executed is also very interesting. First, placing a malicious DLL into %SystemRoot% directory and calling the valid executable regedit.exe instead of a malicious executable is an interesting choice of execution, probably designed to bypass malware detection algorithms. Second, the way that it executes regedit.exe is uncommon, most likely used to avoid detection as well. Third, it uses another malicious DLL as a service to get it executed. In conclusion, as malware evolves we need to make sure protection mechanisms are in place to detect such behaviors, not only analyzing its payload but also how it gets executed. This will allow us to develop mechanisms to defend against these threats independently of its activities.
 Sysinternals – http://technet.microsoft.com/en-us/sysinternals/bb545021