Sobig.e - Evolution of the Worm
- URL: http://www.secureworks.com/research/threats/sobig-e
- Date: June 30,2003
- Author: Joe Stewart
Introduction
This paper is a follow-up to an earlier paper describing Sobig.a. If you haven't read that paper, you may want to take the time to do so now. It gives background on spamming methodology and other information as a basis to understand the Sobig worm family. This paper concentrates on the differences between the original worm and the incarnations since that time. The information in these two papers is the result of months of first-hand investigation into the Sobig worm family by SecureWorks' security research team, so check this page for updates as more information is learned.
The Sobig Family Tree So Far
Sobig.a - The original worm, introduced in January 2003. Its purpose was to spread a proxy server trojan the author had cobbled together in 2002. It was quite successful at this until details of the scheme were made public and the sites it relied on to download the second and third stages were shut down. In spite of this, thousands of proxy servers were surreptitiously installed on computers worldwide. It is now largely believed that the purpose of this proxy network is to serve spammers - giving them a way to hide their true IP addresses while they spew spam all over the globe. The reasoning behind the use of proxy servers instead of the more familiar open SMTP relay is explained in the first Sobig paper, and will not be rehashed here.
Sobig.b - In May 2003, a new worm initially known as "Palyh" set records for the quickness of the initial spread. The Palyh worm was soon renamed to Sobig.b after it was realized from analyzing the code that Sobig was back for another round. This time the worm had a shelf-life; a built-in timer to stop it from spreading after a certain date, unlike the first Sobig, which is still circulating in the wild today even though it is unable to deliver its secondary payload. Sobig.b had a couple of problems - the timer was based on the local computer's clock, which meant if one infected system's clock was set to the wrong day/month/year, it would continue to try and spread. However, a much bigger problem for the author was the fact that Geocities removed the pages the worm depended on very quickly, making it impossible for the second and third stage payloads to be delivered to infected machines.
Sobig.c - On May 31, the day that Sobig.b "expired", the author corrected the bug in the timecheck routine with a new release. Instead of relying on the system clock, Sobig.c now consulted a list of public NTP (Network Time Protocol) servers around the world. These servers deliver accurate timestamps to clients so they can synchronize their system clock with it. Instead of setting the system clock, Sobig.c merely read the time from the received packet, compared that time with the programmed-in stop date/time, and discarded the packet. All Sobig variants that followed continued to check the time in this way.
Sobig.c still had a dependence on Geocities to host the information the worm needed to find its second and third stages, and Geocities was becoming increasingly quicker in shutting down pages the worm contacted. In order to combat this, the Sobig author began to encrypt the strings inside the executable. The encryption was fairly trivial, but the author hoped it would buy some time while the payload was delivered. But Geocities again removed the sites the worm used with lightning speed.
Sobig.d - Those who were tracking the Sobig variants knew that the author would probably stop using Geocities at this point. They were right - the next variant released a couple of weeks later used a stronger encryption algorithm, and no longer contained references to Geocities, or any other URL. The author moved to a slightly more sophisticated and covert method of getting the information needed in order to prevent the download sites from being shut down too quickly. Between 7:00 pm and 11:59 pm UTC, the worm would periodically send a packet on UDP port 8998 to a list of 22 IP addresses contained in the executable's encrypted strings. The packet contained an 8-byte key identifying itself as coming from a Sobig infectee.
These IP addresses were all on cable modems, some or all of which were probably hacked either by the author or the author's cohorts to serve answers to these incoming packets. Upon receiving the magic packet on port 8998, some of the cable host servers returned garbage strings as a further subterfuge, but others returned an encrypted URL. Upon receiving the reply, Sobig.d would decrypt the URL and retrieve a file from that site. This file was the second stage payload.
The advantage to using cable hosts is obvious - even on ISPs that don't offer static IP addresses cable modem users will often keep the same IP address for months at a time, making them ideal for setting up temporary servers. By the time you contact the 15 different ISPs involved and get them to investigate and shut the systems down, the payload has already been delivered. Even if you take all but one of the cable hosts offline, the last one can finish the job. The worm writer learned two lessons from the endless cycle of Geocities closing the sites - stealth and redundancy.
However, Sobig.d was largely a flop, but not because it had any particular flaws. It just didn't circulate to enough people. Since it used exactly the same spreading mechanisms as the last 2 variants, this may seem strange unless you consider that those variants were probably seeded via a very large initial mass-mailing. Since no such mass-mailing seemed to occur with Sobig.d, we are left to speculate that it may have either been a test or accidental release.
Sobig.e - This release hit on June 25, before the expiration date of Sobig.d, further evidence that Sobig.d may have been premature. There were no major changes to the functionality since Sobig.d except the attachment was now zipped. This was probably in order to bypass mail gateways that deny executable attachments but allow zip files. Because the initial seeding was so large, the chances of being caught by a virus scanner on the first day were small - only virus scanners that do heuristic scanning as well as signature-based scanning would pick up on the fact that it was a worm and block it.
So we now have the more effective second-stage delivery combined with massive global spread - a deadly combination that serves the same purpose as the original Sobig.a: to create a massive network of anonymous proxy servers for the purpose of spam.
Second Stage - Lala
Since the "b","c" and "d" variants were largely failures, it serves us only to examine the second stage of the "e" variant, which is (unfortunately for the rest of us) very likely to succeed as the author hoped. As before with Sobig.a, the second stage is a trojan known as "Lala". It has been updated to try and evade detection but still has the functions for which it has been known:
- Removes the spreading component of Sobig and associated registry entries of the initial infection.
- Copies itself to the system folder and adds a registry entry to run at startup.
- Downloads an ".ini" file with details including URLs used to download and upload information.
- Reports infected system details, passwords and installed status of certain programs to a cgi script at a URL in the .ini file.
- Anytime Internet Explorer is open to a page containing the text "e-gold Account Access", "Account Access", "Bank", "My eBay", "Online Service", "bank", "E*TRADE Financial" or "PayPal - Log In", a keystroke logger is activated to steal usernames and passwords. These are later delivered along with all the user's browser cookies to a cgi script at a URL in the .ini file.
- Downloads the third-stage trojan from a URL in the .ini file and runs it.
Third Stage - Wingate
This stage silently installs the Wingate proxy server much in the same way as Sobig.a. However, the port numbers have all changed, probably due to the unwanted publicity of the first paper where we revealed the port numbers. This enabled mail hosts who check senders for open proxies to be aware of the fact that these proxies were running on non-standard ports, so they were able to adjust their checking scripts. These ports will probably be changed in the next variant after this paper is published, but we feel it is important that the public have knowledge of the port numbers, because they are going to be in widespread use by spammers. In fact, we have seen evidence that some existing Sobig.a proxy servers were upgraded by the author to use these new port numbers and that multiple spammers are aware of this fact and are using the proxies on these new ports on a global scale already.
The proxy ports used by the Sobig-installed Wingate server are listed below. Servers who check incoming connections for open proxies will be most interested in checking TCP ports 2280, 2282 or 2285.
- Port 1555 - RTSP Streaming Media Proxy
- Port 2001 - Remote Control Service
- Port 2280 - SOCKS Proxy server
- Port 2281 - Telnet Proxy server
- Port 2282 - WWW Proxy server
- Port 2283 - FTP Proxy server
- Port 2284 - POP3 Proxy server
- Port 2285 - SMTP Server
Here is a graphic depicting the different stages of a Sobig release:

Snort Signatures
These signatures will pick up any Sobig.e infections on a monitored network. Note that they do not detect inbound Sobig-infected emails, as this will be quite common and not necessarily a problem if you have an updated anti-virus scanner. Your AV solution should be detecting the inbound emails, not an IDS.
alert tcp any any -> any any (msg:"Sobig.E Worm File Transfer"; content:"|50 45 00 00 4C 01 04 00 91 9A F8 3E|"; content:".aspack"; reference:url,www.secureworks.com/research/threats/sobig-e; classtype:trojan-activity; sid:1000020; rev:1;)
alert udp $HOME_NET any -> $EXTERNAL_NET 8998 (msg:"Sobig.E Trojan Site Download Request"; content:"|5c bf 01 29 ca 62 eb f1|"; dsize:8; reference:url,www.secureworks.com/research/threats/sobig-e; classtype:trojan-activity; sid:1000021; rev:1;)
Removal
The Sobig.e initial infection is removed by the second-stage trojan. If you have been infected with Sobig.e 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\SSK Service=%Windir%\winssk32.exe
Make sure that there is not a shortcut to winssk32.exe in the startup folder, then reboot. After rebooting, delete winssk32.exe from the Windows directory.
The second stage trojan is run by the following registry key:
HKLM\Software\Microsoft\Windows\CurrentVersion\Run\Cgtask Services=cgtask.exe
The third stage (Wingate) is run by:
HKLM\Software\Microsoft\Windows\CurrentVersion\Run\MMtask Service=mmtask.exe
As before, remove the registry keys listed above, reboot, then remove:
C:\%Windir%\%system%\cgtask.exe
and
C:\%Windir%\%system%\mmtask.exe
Summary
Have we seen the last incarnation of Sobig? Probably not. This is likely a financial endeavor for the author alone or perhaps in concert with a gang of criminals, supporting themselves through spamming, identity theft and bank fraud. Unfortunately, it seems that more and more worms are being created to support other types of electronic criminal activity, so they have added incentive to continue to plague the Internet. Curbing the threat somewhat is possible, by broadly employing heuristic virus-scanning technology at the email server as well as on the desktop. However, time has shown that cyber-criminals have the ability to adapt and evolve, so we can only wait and see what happens next - our only defense in the long term is vigilance.
Update:
The story continues in Sobig.f Examined.