Introduction
This is the sordid tale of how a lone computer virus opened the door for millions of spam emails every day worldwide. In order for the reader to understand how this happened, this paper will explain some concepts in spam, viruses and backdoors. Viruses sometimes leave backdoors, also known as "trojans" on systems they infect; this is nothing new. The idea is to give the virus writer control over a large quantity of infected computers, establishing a virtual army of computers to do his or her bidding. The author of the virus discussed in this paper had a different idea: using a virus as the delivery mechanism, install anonymous proxy servers on thousands of computers worldwide. Instead of seeking to control the hosts, the virus author merely intended to establish a network of relay points through which they could direct their own connections, concealing their true origin wherever they went on the Internet. Whether or not the author intended it for the purpose of spam, this proxy network has been co-opted by spammers who use it to constantly flood the Internet with a variety of unsolicited commercial email while hiding from potential retribution.

The Evolution of Spam Methodology
In the beginning of spam, spammers would simply send their email from their own ISP account. This quickly changed as the spammers were hunted down by angry users and sysadmins. They soon turned to new methods to conceal their origins.

The Disposable Dialup Account
The first method, which served them well for many years, was the throwaway dialup account. A spammer would sign up for an account with an ISP on Friday, and let loose a torrent of spam over the weekend. By the time users complaints reached the ISP's sysadmins on Monday morning, the spammer would have already abandoned the account. However, dialup accounts require a credit card to sign up, and the spammers found their credit was no good with any ISP after a while.

The Open SMTP Relay
When the Internet was non-commercial, people would set up their mail (SMTP) servers to allow anyone to send email through them, regardless of the destination. Spammers quickly discovered that this would allow them to leverage the bandwidth of large servers to send email for them. Instead of having to send each email slowly over the dialup line, they could drop a single copy onto a relaying SMTP server along with a list of recipients to copy the message to. This allowed for quick distribution with no cost to the spammer. Unfortunately, the cost was offloaded onto the relaying mail administrator, as spam would clog up the system and prevent it from sending legitimate email. Eventually the net adapted to the problem and many ISPs began blacklisting SMTP servers which acted as open relays. Upon being blacklisted, the SMTP mail administrator would usually fix the problem and kill off the spammer's access. This began to be a problem for the spammers. Another problem was that, even though the relay did all the work, the spammer's origin would still be logged. Spammers responded by injecting phony headers into the message in order to obscure the true origin, but by-and-large their IP addresses would be still be identified by spam-hating admins. They would then lose the account they were spamming from, causing an endless churn of work as they had to constantly open new accounts to spam from.

Broadband and the Proxy Era
With the advent of high-speed Internet access, spammers began to see that they no longer needed to use the dwindling list of open SMTP relays. They could send email just as fast from a cablemodem or DSL line. However, usually there are only one or two providers of high-speed Internet access in a given locale, so one could not afford to have their account shut down, since it would be nearly impossible to get high-speed access again without moving to a new town. The spammers needed to hide their IP addresses completely, to prevent complaints from reaching their ISP.

At this point, they took a cue from something hackers had long done to hide their identities while attacking systems. They began to utilize proxy servers. Ordinarily proxy servers are set up for users of a network to speed access to frequently accessed pages, or to provide authentication for authorized-only web access. When misconfigured (as they often are by default) they allow users to proxy from anywhere, not just inside the private network they serve. Spammers learned how to pipe SMTP connections through HTTP and SOCKS proxies, completely obscuring their true origin. Lists of open proxy servers are all over the Internet, so a constant stream of proxies could always be found. Using proxy servers to make a connection directly to a victim's ISP spammers found another advantage; they could personalize each message with the name of the victim or add web bugs to track when an email was read and who it was read by. They could also maintain a cleaner list of addresses, as they were able to tell when an address was bad. None of these advantages was available under the old open relay dump method where they merely sent out one copy of an email with thousands of different recipients at a time.

It didn't take long for the spam-fighters to catch up and implement blocking of hosts running open proxy servers. Since proxy servers generally run on only a few different well-known ports, a mail server could test connecting back on those ports to any host which tried to send mail to it. If a proxy port is found, the mail is rejected. Soon "blackhole lists" of open proxy servers were implemented, causing the spam to be slowly choked off again. In January 2003, the Win32 virus "Sobig.a" appeared on the scene. It was a virus that would download a specially modified proxy server and run it on infected machines. The proxy server would run hidden on the infected systems, listening on completely non-standard ports and logging none of the traffic passing through it. This is what the spammers had always needed, and it was handed to them by a virus. We may never know if the author of the Sobig.a is actually one of the spammers or was paid by a spammer to write the virus. The best we can do is to analyze the system the virus uses to install the proxy servers and undermine its ability to remain hidden on the Internet by sharing that information.

The Metamorphic Trojan
Spam fighters have known of the existence of the hidden proxy server installed by Sobig.a. Reports of a mysterious installation of a proxy server listening on odd ports have been found dating back to August 2002. This shows that the author was experimenting with other delivery systems prior to the introduction of Sobig.a in January 2003. So far however, no one has made a direct connection between the hidden proxy server and Sobig.a. This is probably because the author of the trojan took care to conceal parts of the system in a distributed manner, using various websites and tactics. What we are left with can be best described as a "metamorphic trojan". This is appropriate because the complete installation happens in stages, sometimes over several days. In the end, the subsequent stages completely replace the first stage. Once the second stage has taken over, the virus is removed and will no longer spread from that host. At that point it has completely evolved from a virus into a trojan.

Stage 1: Sobig.a
Sobig.a comes as an email attachment, and is instantly recognizable because the From: address is always big@boss.com. It is written in Visual C++ and encrypted using the exectuable packer Telock 0.98 in an attempt to make analysis more difficult. It has two main purposes: to spread itself to other users via email, and to download a file from http://www.geocities.com/reteras/reteral.txt . This file contains a list of URLs to download the second stage trojan from. Ordinarily, the reteral.txt file contains only one URL:

http://www.blahblahblahblah.com/

This is a completely bogus URL, used to throw off investigators that might be trying to follow the progression of the code. At certain times the author of Sobig.a will change reteral.txt to contain a real URL, removing it shortly after. The URL in question is:

http://www.loricoshop.com/users/serak/txtfile.txt

Sobig.a downloads this file (which is really the second stage trojan executable) and runs it.

Stage 2: Lala Trojan
The second stage trojan is always evolving and currently is not detected by anti-virus products. Because the author uses the URL switching deception above, the progression of the metamorphasis is largely protected from analysis except by that of dedicated researchers who check the site hourly. Keeping up with every recompile of the trojan would be daunting for any vendor. This trojan is written in Delphi, and packed with Telock 0.98. It has several components, including HTTP notification to a CGI script at: http://www.banking-concern.com/cgi-bin/index7.cgi.

Previous versions have sent notification to index6.cgi among other similarly named CGI scripts. It is reasonable to assume that we are currently looking at the seventh incarnation of the trojan, each using a different cgi script to allow the author to keep track of which infection run has produced which results. Note that the URLs the script uses to operate are probably owned by innocent third parties who have had their sites compromised by the Sobig.a author.

The Lala trojan also installs a keylogger and (in the latest versions) the Lithium remote access trojan. Access to the Lithium trojan server is only possible using the Lithium client and the password "adm123". Finally, it downloads and installs the third and final stage from ever-changing URLs, using the same hide-and-seek textfile method. At the time of this writing, the third stage was found at:

http://www.loricoshop.com/users/serak/g5aa.txt

This is saved as %windir%\g5aa.exe and is a custom installer for the Wingate proxy server, a legitimate piece of software used in violation of its license.

Stage 3: Wingate
Wingate 5.0.2 build 780 is packaged in the g5aa.exe file. The Wingate proxy is installed using a modified configuration. It runs the following TCP proxy services:

• Port 555 - RTSP Streaming Media Proxy
• Port 608 - Remote Control Service
• Port 1180 - SOCKS Proxy server
• Port 1181 - Telnet Proxy server
• Port 1182 - WWW Proxy server
• Port 1183 - FTP Proxy server
• Port 1184 - POP3 Proxy server
• Port 1185 - SMTP Server

The remote control service allows Wingate's Gatekeeper client to connect on port 608. One could conceivably monitor proxy connections including source and destination IP addresses, or disable the server remotely if they knew the Gatekeeper password for all installations of the trojan is "zaq123". This could be potentially devastating to the spammers as they churn happily away on their broadband connections thinking they are completely hidden from view.

Removal
The Sobig.a virus is removed by the second trojan. If you have been infected with Sobig.a and the second stage trojan has not been activated yet, you would need to remove the registry key below:

HKLM\Software\Microsoft\Windows\CurrentVersion\Run\WindowsMGM=C:\%WINDOWS%\Winmgm32.exe 

The second stage is run by one of the following registry keys:

HKLM\Software\Microsoft\Windows\CurrentVersion\Run\MPtask Services=C:\%WINDOWS%\%SYSTEM%\mptask.exe 
HKLM\Software\Microsoft\Windows\CurrentVersion\Run\MPtask Services=C:\%WINDOWS%\%SYSTEM%\pntask.exe 
The third stage is run by: 
HKLM\Software\Microsoft\Windows\CurrentVersion\Run\MMtask Service=mmtask.exe 

Delete all of these registry keys, reboot and then remove the associated files.

Summary
It is inevitable that the author of this metamorphic trojan will change his code and move his downloads to new websites, so the information in this paper is likely to become outdated quickly. However, now that the scheme is exposed there are likely to be far more people investigating instances of proxy spam, and developing new ways to fight it. To fight proxy spam, you can use pxytest, a free perl script which tests servers for open proxies and will already detect the proxy left by the Sobig.a virus. This could be scripted to run each time a remote hosts connects to your mailserver. In fact, some ISPs are already implementing similar solutions; however, they have been met with at least some resistance from people who feel they are being unduly portscanned. Check with the laws in your area before implementing such a solution.

Update: See Sobig.e - Evolution of the Worm for a followup to this article.

References
"Symantec Security Response - W32.Sobig.A@mm". http://securityresponse.symantec.com/avcenter/venc/data/w32.sobig.a@mm.html

"Symantec Security Response - Backdoor.Lala" . http://securityresponse.symantec.com/avcenter/venc/data/pf/backdoor.lala.html

"RE: Port 608/trojan/spam". http://archives.neohapsis.com/archives/incidents/2002-09/0193.html

"CERT/CC Vulnerability Note VU#150227". http://www.kb.cert.org/vuls/id/150227

"Exposing the Underground: Adventures of an Open Proxy Server". http://www.lurhq.com/proxies.html

Chip Rosenthal's pxytest: http://www.unicom.com/sw/pxytest/