W32.Morto.B – Morto Adds File Infection to its Arsenal

W32.Morto first surfaced in August 2011 causing a stir when it targeted weak passwords on Remote Desktop Protocol Connections in order to propagate across networks. W32.Morto.B, the new variant, now has the ability to infect executable files on a compromised computer. Let’s take a look at the infected files in a bit more detail.

Figure 1. W32.Morto.B file infection schematics
Before infecting a file, W32.Morto.B will check for an infection marker. This is to ensure it doesn’t attempt multiple infections on the same file, a common check performed by file infecting threats. The marker it looks for is stored in the MZ header and can be seen in Figure 2 below:
Figure 2. W32.Morto.B file infection marker
If this marker is not present, it will proceed to insert the viral body into the last section of the file and update the attributes of this section so that it is run when the file is executed. As a final step it will modify the original entry point to point to the newly inserted viral code. 
Once the infected file is executed, instead of executing the original code path – the inserted viral code will execute first. The entry point of the worm contains a small decryption routine, which decrypts the viral body and then executes it.  Once completed, the worm will return execution to the original entry point of the file and the original application will continue to execute as normal.
Figure 3. Code extract showing flow of execution from viral entry point
We are currently investigating this threat for any additional functionality and will be updating this blog as details become available. Ensure that your anti-virus is up to date to protect against this latest evolution of the Morto worm.

Printer Madness: W32.Printlove Video

Recently we have received several customer issues about garbage being printed on their network printers. During our investigation, we came across a new worm that causes the garbage print jobs. Symantec detects this worm as W32.Printlove. W32.Printlove uses the Microsoft Windows Print Spooler Service Remote Code Execution Vulnerability (CVE 2010-2729) discovered in 2010 to spread across networks. We have created a video that demonstrates how it accidently prints garbage.


In the preceding video we demonstrate two scenarios where the threat will act differently based on whether a computer on the network is patched against CVE 2010-2729 or not. We tested the threat on a simple network consisting of two computers and a shared network-printer that was connected by a switch.

Computer A configuration: Windows XP Professional. The computer is patched against CVE 2010-2729 and is compromised by W32.Printlove. It does not have a local or shared printer added to it.

Computer B configuration: Windows XP Professional. In the first scenario the computer is un-patched and in the second scenario it is patched. It has a shared network printer.

Computer A must have permission to submit print jobs on Computer B. Guest access to shared print services is enabled by default on Windows XP; for subsequent operating systems Computer A should be authenticated by Computer B.

The two scenarios in which this threat may work are as follows:

  1. W32.Printlove running on Computer A will search for a printer resource on the network. Once found, it transfers itself to Computer B using a StartDocPrinter request (Figure 3). The Print Spooler vulnerability allows any file transferred through the print spooler to be copied to any directory. The threat successfully launches itself on Computer B after exploiting this vulnerability. Figure 1 below shows the first scenario.

    Figure 1. First scenario, remote code execution


  2. W32.Printlove running on Computer A will act in a similar manner and transfer itself to Computer B. As Computer B is patched, the worm will be unsuccessful in exploiting the vulnerability. The manner in which the vulnerability is patched does not allow a printer request to print to a file in any directory. Due to this, the worm is unable to copy itself to the system directory and run itself using the exploit. Instead it is saved in Computer B’s print spooler directory as an .spl file (%System%\Spool\PRINTERS\[RANDOM FILE NAME].spl). Computer B starts printing the file on its shared printer. Figure 2 below shows scenario 2.

    Figure 2. Second scenario, print jobs

Figure 3 below shows the threat transferring itself over the network using StartDocprinter Request.

Figure 3. Exe file being sent to a shared printer resource

W32.Printlove keeps connecting to the remote computer and periodically tries to infect it through the print spooler vulnerability. Computers may be re-infected or multiple garbage printouts may occur until the worm is completely removed from the network. Tracking down the source of these junk print jobs can be more complicated when there are multiple infections on the network. Network administrators can identify the compromised computer on the network by viewing the .shd files located in the print spooler directory of the computer sharing the printer, normally located here:


SHD files are created by the OS and contain the printer job details. The file can be viewed using a tool called SPLViewer. Since the files are locked by the Print Spooler Service, the service has to be stopped in order to access the .shd file. Administrators can spot the compromised computer on the network by looking at the Computername field (Figure 4), which indicates the origin of the printer job.

Figure 4. SPLViewer shows the job file origin

Garbage printing is a side effect experienced by hosts who are patched against CVE 2010-2729 but are attacked by W32.Printlove. Symantec customers are protected against the threat with the latest antivirus definitions.

Note: It is a possibility that there is a link between Trojan.Milicenso and W32.Printlove, but we have not confirmed this yet. We intend to continue our investigation to confirm any relationship between the two threats.

If you are curious about what the garbage printout looks like, here is a picture of one of them. The printer is effectively trying to print the binary code of the executable file that is dropped. For a Windows executable file, this starts with the text "MZ" indicating the start of the so called "MZ" header.


Morto worm sets a (DNS) record


There has been a lot of coverage of the recent RDP capable W32.Morto worm, but one of the more interesting aspects of the worm’s behavior appears to have been overlooked. Most malware that we have seen recently has some means of communication with a remote Command and Control (C&C) server. The actual vector of communication tends to vary between threats. For example, W32.IRCBot uses Internet Relay Chat channels whereas the recent high profile threat, Trojan.Downbot, is capable of reading commands embedded in HTML pages and image files. W32.Morto has added another C&C communication vector by supplying remote commands through Domain Name System (DNS) records.
DNS is primarily used to translate human readable URLs, such as “Symantec.com”, into numerical network identifiers ( Every URL on the Internet is eventually resolved to an associated IP address using this system, typically using a DNS A record for IPv4. The A record is what we usually think of when we discuss DNS. These records map domain names to their associated IP addresses with a PTR record used for the inverse operation of IP to host. But DNS is not limited to these records types; there are a number of record types that have been defined in various RFCs over the years to address the changing needs of the system. The record type that W32.Morto uses for its communication protocol is the TXT record. 
The DNS TXT record type was originally used to allow human readable text to be stored with a DNS record and later evolved to store machine useable data. To experiment with this, you can use the Microsoft nslookup.exe tool. By querying the TXT record type for “Symantec.com” you can retrieve the SPF information associated with the Domain. 
While examining W32.Morto, we noticed that it would attempt to request a DNS record for a number of URLs that were hard-coded into the binary. This is by no means unusual or unique, but when we examined the URLs, we noticed that there were no associated DNS A records returned from our own DNS requests. On further investigation, we determined that the malware was actually querying for a DNS TXT record only –  not for a domain to IP lookup –  and the values that were returned were quite unexpected.
The threat clearly expected this type of response as it proceeded to validate and decrypt the returned TXT record. The decrypted record yielded a customary binary signature and an IP address where the threat could download a file (typically another malware) for execution.
Once downloaded, W32.Morto immediately executes the threat and waits for a specified timeout before requesting another TXT record.
What is interesting about this method of command propagation is that there was no A record for these domains, which means that they existed primarily to serve these commands to the W32.Morto worm.  A number of other domains have been hard-coded into the worm and they all display the same unusual DNS characteristics.
W32.Morto has a number of interesting characteristics, including: the RDP propagation that has been generating much interest of late; saving encrypted payload code in the system registry; and replacing some minor system DLLs with its own payload code. The worm’s use of DNS TXT records is an unusual method of issuing commands to the remote threat while keeping the C&C vector under the radar.

Banking by Proxy with Trojan.Tatanarg

Banking Trojans are nothing new. They have been around for many years, considering detections such as the Infostealer.Bancos family date back to 2003. As more and more people moved to perform banking transactions online, Bancos created a huge and lucrative target for would be criminals to exploit.

Traditionally, banking Trojans typically just captured data traffic exchanged between the user and the online banking website. The captured information included the authentication information, which is collected and sent to the attacker by the Trojan for their use or to sell on to other parties for a profit. For as long as there has been banking Trojans, there has been a cat and mouse game between the banks and the criminals as each side respond to each other’s move to thwart the actions of the other. More sophisticated banking Trojans employ a man-in-the-browser (MITB) method that is designed to overcome defenses, such as SSL encryption and multi-factor authentication. MITB is achieved by monitoring and intercepting user activities in the browser in real time and modifying the HTML content inside the context of the browser, either to display false information to the user or to manipulate details of transactions sent from the user to the bank.

A Trojan that has come to our attention of late is Trojan.Tatanarg. As banking Trojans go, this one includes all of the expected functionalities and a few more. It is component-based, so the initial installer downloads several components that perform various functions. These functions include the following:

  • Killing other threats such as the Zeus Trojan. You may recall Trojan.Spyeye also had a functionality to kill Zeus Trojans. Zeus is clearly not only under attack from antivirus software but also from other malware, too.
  • Disrupting security software - this is relatively common in many malware samples.
  • Modifying HTML in the browser - this may be used to inject extra fields into authentication forms during login, for example.
  • Enables Windows remote access.

In addition to being able to just steal information, it also offers a back door, allowing a remote attacker to issue various commands to control the infected computer. Commands range from listing and terminating processes running on the computer, clearing browser cookies, executing arbitrary programs, to rebooting the computer.

One interesting feature of the Trojan is that it hijacks SSL/TLS connections between the browser and the bank. When an SSL connection is being established, the bank will send the client a certificate and a public key signed by the certificate that will be used to encrypt information that is exchanged. The Trojan injects itself between the bank server and the browser and forms a proxy service. On the bank side of the proxy, the Trojan uses the details provided by the bank to encrypt outbound traffic. On the browser side of the connection, the Trojan inserts its own self-signed certificate and neutralizes the certificate validation in the browser process to fool the user into thinking that the connection is secure. Users may think the site is secure because the URL will use the “https” scheme and the telltale sign that everybody is trained to look for–the closed padlock, which will also be shown in the browser.

When the user submits information in the browser, the information is encrypted using the Trojan’s details and is then intercepted and decoded by the Trojan. It also performs any manipulation required before it is subsequently re-encrypted (using the banks details) before being forwarded onto the bank for processing.

From our investigations, it appears that this Trojan may have been developed from the W32.Spamuzle code base (hence detected as W32.Spamuzle) back in Autumn 2010. Samples from October 2010 began to include features for proxy SSL connections and other more advanced features, which showed a significant change in direction. This may indicate that the makers of Spamuzle have decided that there is more money to be gained from stealing banking information instead of just sending spam emails.

In addition to our standard antivirus signatures, we have also created the IPS signature HTTP Trojan Tatanarg Activity to block back channel communications. So, users should ensure that their IPS protection is updated and active as well as antivirus signatures.

Thanks to Piotr Krysiuk and Peter Coogan for their input into this blog.