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.
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:
- 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
- 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:
%System%\Spool\PRINTERS\[RANDOM FILE NAME].shd
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.
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.