This was bound to happen, after all, in an open environment like this where people’s abilities are limited by their intentions. The C&C appears to manage infections on the basis of the computer hostname sent in the request; a unique hostname yields the malcode URL to update:

<br>http://XX.XX.76.85/aa.exe</br>

In this case aa.exe is a PCClient backdoor to the infected PCs. When you come back, at this time you just get the word “cmd”. It’s unclear to be what additional commands the C&C can issue to clients.

A quick analysis of the original malware doesn’t reveal any additional functionality, just the downloader bits. (See below) Google’s been contacted for the AppEngine to be taken down, and the site hosting the second stage malware has been contacted for takedown, as well.

UPDATE Google has confirmed the malicious AppEngine is now down.

UPDATE 2 Actually, looking at the sample reveals that it talks to a host in China using what at first blush appears to be a Grey Pigeon protocol.

UPDATE 3 Found another URL the app used, but i’m not sure what it was used for:

http://xiaoiboxip.appspot.com/getip?speed=100

The google cache of the results suggest it reads something like “Today visited 42 times this month, visited 587 times.” It’s unclear if that’s the size of the botnet or what.

The analysis here looks at the three month quarter just ended a few weeks ago for trends in fast flux. This year’s seen a huge uptick in Avalanche domains, and the release of notes from ICANN on the Fast Flux Working Group as well as a specific note around Avalanche. Arbor, like a few others, has been actively working with registries to address fast flux. So, the question is then: how are those efforts doing?

Comparing to Q2 (see below), the biggest gainers are .tk and .eu, with .uk coming in as a new top 10 player. We’ve been trying to work with .eu as they are being targeted, along with .uk, by the Avalanche guys. However, our efforts in .eu are largely fruitless while Nominet in the UK has defended .uk quite handily. The .tk stuff we’re looking at, as it could be a false positive due to the way that .tk hosts stuff.

Across all domain names, in Q3 we saw more TLDs hit, some 34 (against Q2’s 26 distinct TLDs). The attackers are striking at more TLDs in hopes of finding the soft spots, ones that just don’t respond. The average lifetime of a fast flux domain name: 418063 seconds, or about 9.7 days. CN domains are taken down within 7.8 days, EU domain names within 1.6 days, COM domains within 7.23 days, and TK domains within 1.44 days.

For comparison: Q2 2009

Here’s some numbers from the second quarter of this year to serve as a comparison to the Q3 numbers above. The TLD piechart shows a dramatic uptick in .tk domains in Q3 (which we continue to investigate, may be false positives that crept into our system).

Average lifetime of all domains in Q2: 21 days. Three weeks! That’s success now that we’re down to under 10 days.

A cursory examination of this data suggests that while numbers are up, response times are getting better. This may be something worth cheering.

Also, it appears that fast flux is still being used for the same old stuff: phishing, malware, malvertising, child porn, and the like.

This year?

In a dramatic reversal of long-term IPv6 stagnation, global IPv6 traffic globally grew more than 1,400% in the last 12 months. Even more remarkable, this growth is due primarily to one application and one ISP.

We’ll explain in a moment, but first some background: Both our 2008 work and this IPv6 study used traffic statistics from 110 ISPs participating in the Internet Observatory. Though the Observatory is capable of collecting native (i.e. not tunneled) IPv6 traffic statistics, only six ISPs out of the 110 in the study currently have routers and collection infrastructure with native IPv6 enabled. As a result, our data generally includes only IPv6 traffic through Teredo and 6to4 tunnels. Further, since only a handful of Observatory participants use monitoring infrastructure with payload visibility, our study sees only the UDP Teredo control traffic (i.e. not the data portion).

The above technical limitations and our somewhat dismal 2008 assessment of IPv6 deployment engendered a bit of criticism. The main critique (such as this posting) seems to be that we significantly under counted IPv6. In particular, many pointed to the Amsterdam Internet Exchange (AMS-IX) switch statistics which show a Gigabit or more of IPv6 traffic (far more than we found in our study). Others pointed to the high rate of IPv6 address allocations as evidence of broader IPv6 deployment.

From the perspective of a year later, we stand by our 2008 IPv6 findings. A July 2009 news server outage confirmed suspicions that AMS-IX IPv6 traffic mainly consisted of file sharing through the free AMS-IX based IPv6 news servers. And a PAM paper earlier this year found both minuscule levels of IPv6 traffic in a tier1 network and confirmed that registry allocations provide a poor indicator of IPv6 usage. As a side note, the PAM paper also found that the small amount of tier1 IPv6 traffic consisted mainly of DNS and ICMP (i.e. test traffic and not real IPv6 usage).

So in August of 2008 real IPv6 Internet traffic was mostly non-existent.

And then things changed…

The above graph shows IPv6 traffic (Teredo and 6to4) as a normalized weighted average percentage of all Internet traffic between July 2007 and July 2009. In July of 2007, IPv6 represented less than 0.002% of Internet traffic. Beginning in August of 2008, tunneled IPv6 traffic begin to grow dramatically followed by an abrupt and even larger jump in April of 2009 (the E. Karpilovsky et al. PAM paper also observed this first 2008 jump in traffic but did not speculate as to the causality).

What happened?

This stark August 19, 2008 warning to the NANOG mailing list by Nathan Ward provides a strong clue:

Sit up and pay attention, even if you don't now run IPv6, or even if you don't ever intend to run IPv6.
Your off-net bandwidth is going to increase, unless you put some relays in.
As a friend of mine just said to me: "Welcome to your v6-enabled transit network, whether you like it or not ;-)".
uTorrent 1.8 is out, as of Aug 9.


Nathan was mostly right. While uTorrent never generated the expected flood of new traffic (at least by IPv4 standards), the introduction of IPv6 P2P succeeded where most previous IPv6 inducement efforts had failed (i.e. liberal peering, high quality IPv6 porn, IPv6 ASCII animation of Star Wars, etc.). In the space of ten months uTorrent helped drive IPv6 traffic from .002% to .03% of all Internet traffic (a dramatic 15x jump).

But the more interesting (and from an infrastructure perspective, far more important) IPv6 traffic increase came on April 21, 2009 with Hurricane Electric’s turn up of a global anycast’ed Teredo relay service. Hurricane Electric enabled 14 Teredo relays in Seattle, Fremont, Los Angeles, Chicago, Dallas, Toronto, New York, Ashburn, Miami, London, Paris, Amsterdam, Frankfurt and Hong Kong.

More details of Hurricane Electric’s infrastructure is available in this May 2009 LACNIC presentation.

Historically, IPv6 connectivity across the Internet has been, well, abysmal. Inefficient routing, multiple IPv6 tunnel encapsulations and overall lack of coordination between Teredo and 6to4 relay providers added latency, loss and played havoc with jitter (i.e. mangling VoIP). Frequently, a traceroute between two providers at the same exchange could traverse multiple countries or continents en route. For added background, see this 2009 Google IPv6 Conference presentation, this 2008 RIPE study and related 2007 study.

By all accounts, Hurricane Electric’s Teredo service significantly improved the IPv6 goodput for the average Internet end user over night. In particular, Microsoft Windows users got a big boost. Though Windows has shipped with a Teredo client (on by default) since XP, Microsoft never provided a public relay service. teredo.ipv6.microsoft.com now uses Hurricane’s 6to4 relays. And the dramatic improvement in Teredo and 6to4 relays seems to have lead to a corresponding jump in IPv6 traffic.

This is good news.

Finally, in the below graph, you can see the impact of both uTorrent and Hurricane’s relay deployment by region. We again show IPv6 tunneled traffic as a weighted normalized percentage of all Internet traffic. The most important take away is that the IPv6 growth after August 2008 is a global phenomena (with Asia at the forefront follow by Europe).

We look forward to revisiting IPv6 traffic in another year as relays improve, meaningful IPv6 content becomes available and more providers offer native IPv6 service.

Editor’s Note: This blog is the fourth in a series of weekly posts leading up to the publication of the joint University of Michigan, Merit Network and Arbor Networks “2009 Internet Observatory Report”. The full technical report goes into detail on the evolving Internet topology, commercial ecosystem and traffic patterns — available this October. Next week: “How Big is Google?”

In the first half of this post, we showed unlike European Internet traffic which peaks in the early evening and then drops off until the next day’s business hours, US Internet traffic reaches its peak at 11pm EDT and then stays relatively high until 3am in the morning.

The question is what are Internet users doing after dark?

The answer: long after Exchange and Oracle business traffic slows to a crawl, Internet users turn to the web to surf, watch videos, send IM’s and happily try to kill each other.

We illustrate these trends with graphs of four application categories below.

The top two graphs show the daily average traffic fluctuations of TCP / UDP ports related two popular online game multi-player platforms: World of Warcraft and Steam (which includes many popular first person shooter games like Half Life). The bottom two graphs show common video and instant messaging protocols. As in earlier analysis, we take the average of North American consumer / regional providers traffic over 10 weekdays in July. To make the graph more readable, we show traffic as a percentage of peak traffic levels. All times are EDT.

Some observations:

• Gamers Come Out at Night: Unlike most Internet applications which peak midday or late afternoon, online game traffic grows by more than 60% after 2pm. Gaming prime time appears to be between 8pm and 11pm EDT weekday nights (corresponding to the traditional and now declining television prime time hours). By comparison, web traffic levels remain relatively constant through the late afternoon and peaks much earlier at 5pm.
• A Guild that Plays Together Stays Together: Unlike other online game traffic, World of Warcraft’s Battlenet shows a distinct 30% jump exactly at 8pm EDT every evening. In-house WoW level 80 colleagues suggest 8pm is a common time for guilds to set out on quests. Also unlike other game traffic, WoW declines rapidly after 11pm every night. Again, we suspect WoW traffic patterns are related to the more large group, social nature of World of Warcraft.
• Midnight Video: Of all Internet applications, streaming video protocols reach their traffic peak the latest around midnight EDT every evening. We do not have very good visibility into what Internet users are watching this late, but correlation with large content site traffic patterns (below) provides some clues.
• Always in Touch: Beginning at 9am EDT at lasting though midnight, Internet users IM constantly. The IM graph above shows traffic reaches 80% of peak by 10am and stays above 80% until midnight (with a 5pm EDT peak — perhaps related to millions of users making dinner plans). Interestingly, email exhibits a very different pattern and plummets by more than 30% immediately after 5pm EDT.

As mentioned earlier, we do not have detailed visibility into what Internet users are watching at midnight but ASN level traffic analysis provides some hints. Predictably, traffic grows dramatically to consumer sites like Google’s YouTube and large CDN / video providers. Also not surprisingly, we see a large jump in traffic to colo / hosting companies with adult content such as a 40% jump to ISPrime (AS23393) between 10pm and 1am EDT. We will explore one of the fastest growing and largest nighttime sites, Carpathia Hosting (AS29748), in an upcoming blog.

Editor’s Note: This blog is the third in a series of weekly posts leading up to the publication of the joint University of Michigan, Merit Network and Arbor Networks “2009 Internet Observatory Report”. The full technical reports goes into detail on the evolving Internet topology, commercial ecosystem and traffic patterns — available this October. Next week: “Who Put the IPv6 in My Internet?”

But before we get too carried away with metaphor and innuendo, some background.

In our last post blog post, we found (somewhat unexpectedly) that the pattern of North American daily Internet traffic differs from Europe and Asia. Unlike European Internet traffic which peaks around 7pm GMT and then quickly drops off until morning business hours, US Internet traffic reaches its peak at 11pm EDT and then stays relatively high until 3am in the morning (i.e. stays above 60% of peak or more).

This uniquely American traffic pattern holds true across dozens of individual ISPs, tens of millions of subscribers, and petabytes of daily Internet traffic.

The question is what are Americans doing at night?

To begin answering this question, we first recap Internet Observatory data from our earlier post. The below graph shows the daily average traffic fluctuations of 40 North American consumer / regional providers (taking the average of 10 weekdays in July). To make the graph more readable, we show traffic as a percentage of peak traffic levels. All times are EDT.

The way to interpret the graph above is that at 6am EDT North American traffic volumes are at 50% of their daily peaks. Traffic then climbs to a local maxima at 4pm and then a daily peak around 11pm EDT before again dropping during the early morning hours.

To understand the two North American traffic peaks at 4pm and 11pm graphed above, it helps to look only at consumer Internet traffic (i.e. as opposed to enterprise and tier1 transit). Below we overlay in yellow the average daily traffic from only US and Canadian consumer providers (i.e. only showing cable / DSL and excluding tier2, research, content, tier1, etc.).

From the graph its pretty clear consumer traffic plays a large role in the midnight North American traffic peak. We also see consumer traffic tends to climb later in the day (i.e. consumer traffic crosses 50% threshold after 9am as opposed to the broader Internet average of 6am) and consumer traffic trends towards filling the bulk of after-hours traffic. Perhaps most telling is the change in slope of graphed average consumer traffic around 6pm and then again around 8-9pm — all likely related to Americans turning to the Internet after dinner and during evening leisure hours.

But though we now know it is consumers driving the late night Internet traffic peak, we still have not answered what they are doing.

In response to our last post on the somewhat mysterious differences between American and European traffic patterns, readers offered a range of theories including:

• More so than Europe, American traffic grows with web surfing and at night
• Larges surges of P2P would explain North American traffic spikes
• Americans watch more video and related adult entertainment late at night
• In general, Europeans use the Internet less at night, have better social interactions, eat better food and generally live better lives

We finish this blog post by exploring which of the above theories do not account for the large midnight spike in North American traffic. I have no way to evaluate the last bullet point around higher European quality of life (although I’m pretty sure my high school French teacher is still insisting this is true).

Web

During both the day and night the single largest Internet application is the web (52% of all Internet traffic on average).

But while web surfing plays a large role in North American traffic trends, the graph below shows web does not provide the complete explanation behind the American bandwidth peaks.

The “Daily Web Traffic” graph shows web as an average daily percentage of all North American Internet traffic. For purposes of this blog post, we define “web” as traffic on port 80, 8080 and 443. We note that web traffic includes both html page downloads as well as video and other applications running over HTTP.

From a daily low of 42%, web traffic grows by 10% at night to account for 52% of all Internet traffic. So web accounts for slightly over half of the late night traffic, but what is consuming the other half of American traffic?

P2P

Given all the press and provider angst over P2P traffic, many commenters suggested (incorrectly) that P2P is the source of the post midnight bulge in American Internet traffic. As a category, P2P is the second largest source of American Internet traffic coming in at roughly 15-20% of all North American traffic.

[Note: We'll devote an article on the evolution of P2P traffic in an upcoming post. And, of course, the upcoming "2009 Internet Observatory" report goes into far more detail on the statistics and methodology than our more casual blog postings.]

Since most P2P does not use standard ports and/or includes encryption, we extrapolate the data below using a combination of Observatory port data with statistics from application payload characterization across several large US and Canadian cable operators. We again graph P2P as an average daily percentage of all North American Internet traffic.

Unlike the web and almost all other applications, the daily average P2P cycle does not coincide with broader traffic trends. In fact, the P2P daily trend is pretty much completely inverted from daily traffic. In other words, P2P reaches it low at 4pm when web and overall Internet traffic approaches its peak. P2P traffic only bursts from a low of 8% to a high of 17% of Internet traffic after midnight and then drops off at 6am.

As a side note, the cyclical inverted traffic pattern of P2P is interesting in its own accord. The inversion is highly suggestive of either persistent congestion or, more likely, evidence of widespread provider manipulation of P2P traffic rates.

So P2P also does not explain the midnight spike of American Internet traffic. What does? Next week we’ll complete this blog post in Part II and explore the applications behind North American traffic after dark.

September 2, 2009 Update:

Given some of the comments / questions around P2P as a percentage of Internet traffic versus a percentage of peak, a new graph below:

Looking at P2P as a percentage of P2P peak traffic shows even more clearly the inverted pattern (i.e. since Internet traffic begins to climb at 6am, the earlier graph previously obscured the even more pronounced 6am peak in relative P2P traffic levels).

Editor’s Note: This blog is the second in a series of weekly (or possibly semimonthly) posts leading up to the publication of the joint University of Michigan, Merit Network and Arbor Networks “2009 Internet Observatory Report”. The full technical reports goes into detail on the evolving Internet topology, commercial ecosystem and traffic patterns — available this October. Next week: “The Internet After Dark (Part II)”

The list below shows the IP or narrow CIDR blocks we found that popped out, together with the contributions (raw number of observations and percentage of overall activity seen for the month).

8.12.206.126 263 (1.09%)

Located in AS3356 (Level 3 Communications). Appears to be related to MSN hosting. Often contacted by what appear to be a lot of games and executables of dubious repute. We get a lot of Trojan horse programs in here, no surprise they piggyback on otherwise healthy networks.

60.173.8.0/21 661 (2.73%/2.73%)

AS4134, ChinaNet Backbone. Lots of malcode hosted here that we see, and the network is a victim of its own success. Downloaders, infostealers, etc. Been seeing a lot of downloaders phoning back here that install dozens (!) of pieces of malware in one shot all hosted on the same host.

64.34.228.126 311 (1.28%)

AS13678, Peer 1 Network. A lot of search hijack and toolbars associated with this IP. A lot of “hxxp://64.34.228.126/tba/p” in our database where we see stuff like this posted:

POST /tba/p HTTP/1.1
Content-Length: 269
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; 6.0.79.0; Windows NT 5.1)
Accept-Encoding: gzip
Host: ads.netbios-local.com
.
guid=2923514082588C8C84CB8C4B77FE87C3334E&version=86442206692A&clientid=696CD7897DEF73884430&time=AE5E7DD0AE33F9&idle=925089&locale=F94122913C22&session=B10B&activeWindows=E17B02&ticksBoot=AB363FD944633BEE&ticksAlive=336CA641989A53&installTime=0F0C26&launchCount=9E3962


66.220.17.154 647 (2.67%)

AS6939, Hurricane Electric. Lots of Swizzor related activity.

67.29.139.153 400 (1.65%)

AS3356, Level 3. Lots of FakeAV associated with this IP, such as this sample.

68.169.70.134 247 (1.02%)

AS23393, ISPrime. Seems to be associated with “Fake Alert” or “Renos” based on some Google searches and VTotal results for some samples.

78.108.0.0/14 281 (1.16%/1.16%)

Associated with Cutwail botnet activity, porn, and even Koobface activity. Spread over a few providers, but lumped into this /14.

94.75.207.219 293 (1.21%)

Coincident with 68.169.70.134 above, hosted in AS16265 LEASEWEB. Fake Alerts and such …

121.11.0.0/16 244 (1.01%/1.01%) and 121.12.0.0/16 438 (1.81%/1.81%)

Associated with AS4134, ChinaNet Backbone. Lots of malware in this space from random individuals.

195.2.253.240/30 328 (1.35%/2.41%)

AS12695, Digital Network JSC. Lots of malware in the family of Alureon associate with URLs in this small netblock.

209.84.29.126 273 (1.13%)

AS3356, Level 3. Looks similar to what we’re seeing on the IP 8.12.206.126 above.

209.205.196.16 286 (1.18%)

AS20228, Pacnet, S.A. de C.V. Lots of random malware, appears to be a free hosting provider in South America that kids are abusing.

216.240.157.91 305 (1.26%)

AS7796, ATMLink. More Renos and Fake Alert stuff associated with the malware we’re analyzing phoning back here.

218.149.84.0/25 251 (1.04%/1.04%)

AS4766, Korea Telecom. Lots of KwSearchGuide Adware associated with this netblock. Lots of EXEs, DLLs, and PHP scripts called here.

Which made us wonder if Europeans are any different?

It turns out — yes.

We took a look using the Internet Observatory at daily traffic through roughly 40 North American and 25 European consumer / regional providers (taking the average of 10 weekdays in July).

We graph the daily average of European and North American Internet traffic below. To make the graph more readable, we show both European and US traffic as a percentage of their respective peak traffic levels (i.e. 100% is the respective peak of each Europe and US traffic). All times are EDT. The yellow shaded area represents daylight hours in Europe and the US.

As expected, both Europe and US Internet traffic have a lot in common. Both show regular, daily cyclical traffic patterns with Internet traffic dropping at night and growing during the day.

Also expected, we see the two graph lines offset by their roughly 5 hour timezone differences, i.e. European traffic bottoms out at 12am EDT / 5am BST / 6am CEST followed by US traffic reaching its low at 5am EDT.

But what is really interesting is how the daily US and Europe Internet traffic trends differ.

To make some of these differences more obvious, we show European and North American traffic on a single daily timeline. In other words, 5am for European is 5am GMT and 5am for the US is 5am EDT.

Even after we account for the multiple time zones in both Europe (3 if we exclude Russia) and the US (4 if we exclude Halifax and Alaska), European traffic really is different.

Some observations:

• We all share the same morning and evening Internet addiction: On average, European traffic starts picking up around 5am GMT / 7 am CEST and similarly US traffic takes off around the same time at 7am EDT. Internet traffic also reaches its peaks in the early evening (7pm GMT / 9pm CEST in Europe and 10pm EDT / 7 pm PDT in the US).
   

• North American’s don’t surf over dinner: Unlike European traffic, US daily Internet percentages take a small dip in the early evening between 6pm and 10pm EDT. In contrast, Europe traffic keeps climbing through the evening until a marked 9pm GMT / 11pm CEST drop off. Of course, Europeans tend towards later (and longer) dinner hours than their North American counterparts.
   

• What Europeans do at night: Actually, this bullet point should be what Europeans don’t do at night — spend a lot of time on the Internet. In contrast to North America, European traffic plummets much more steeply and reaches a lower daily minimum than US traffic (US traffic never drops below 50% whereas Europe declines more more than 60% from its peak). Apparently, North American Internet users stay up later and use the Internet longer (next blog post we’ll explore what they’re doing on the Internet late at night).

Editor’s Note: This blog is the first in a series of weekly (or more likely semimonthly) posts leading up to the publication of the joint University of Michigan, Merit Network and Arbor Networks “2009 Internet Observatory Report”. The full technical reports goes into detail on the evolving Internet topology, commercial ecosystem and traffic patterns — available this October.

While digging around I found a botnet that uses Twitter as its command and control structure. Basically what it does is use the status messages to send out new links to contact, then these contain new commands or executables to download and run. It’s an infostealer operation.

The account in question is under analysis by Twitter’s security team. I spotted it because a bot uses the RSS feed to get the status updates.

As for the original bot in question that fetches the updates, here’s the VirusTotal analysis, where you can see it’s detected by 19/41 (46.34%) AV tools under evaluation. We can look at the status messages and discover more nefarious activity; the bot’s hiding new malcode which is poorly detected this way. The original link from the malcode came from a ShadowServer nightly link report, which they make available to folks. Many thanks to them.

Let’s look at one of the update messages; it’s pretty clearly base64 encoded. What does it say?

$ echo "aHR0cDovL2JpdC5seS9SNlNUViAgaHR0cDovL2JpdC5seS8yS29Ibw==" | openssl base64 -d
hxxp://bit.ly/R6STV hxxp://bit.ly/2KoHo

OK, a couple of links. One is dead (to a pastebin), one is live.

That second link yields a base64 encoded block of text. When we un-encode it using base64 we see a PKZIP archive (which we have dumped as “out.qqq” since we don’t know what the extension would have been beforehand). We can then unpack this and see what we find:

$ unzip out.qqq
Archive: out.qqq
inflating: gbpm.dll
inflating: gbpm.exe
$ openssl md5 gbpm.*
MD5(gbpm.dll)= ceb8d7fd74da0a187cc39ced4550ddb4
MD5(gbpm.exe)= a5cc8140e783190efb69d38c2be4393f


gbpm.dll is UPX packed, so we can unpack this:

$ upx2 -d gbpm.dll.upx
Ultimate Packer for eXecutables
Copyright (C) 1996,1997,1998,1999,2000,2001,2002,2003,2004,2005,2006
UPX 2.02 Markus Oberhumer, Laszlo Molnar & John Reiser Aug 13th 2006
.
File size Ratio Format Name
-------------------- ------ ----------- -----------
263680 <- 103424 39.22% win32/pe gbpm.dll.upx
.
Unpacked 1 file.

This file looks like an infostealer. Here are some of the URLs it will send data to:

hxxp://64.79.197.110/friends/alert/new.php
hxxps://www2.bancobrasil.com.br/aapf/login.jsp?aapf.IDH=sim
hxxp://64.79.197.110/friends/post.php
hxxps://www2.bancobrasil.com.br/aapf/
hxxps://www2.bancobrasil.com.br/aapf/

gbpm.exe is packed with a different packer.

That DLL is very poorly detected, the EXE has a VTotal result of 9/41 (21.95%) and appears to be a Buzus sample according to one vendor.

The account is presently live but under review by Twitter, and is just one of what appear to be a handful of Twitter C&C accounts.

UPDATE 14 Aug 2009

Via bit.ly, some statistics that suggest the malcode has infected a couple hundred PCs, mostly in Brazil.

Now that it’s disabled, “upd4t3″ had a similar profile on Jaiku.com:

Many thanks to the Jaiku team for reviewing and shutting this account down. Still looking for more services “upd4t3″ is abusing … looks like Tumblr has also been used by “upd4t3″:

Still poking around various micro-blogging services. I wonder why he abandoned Tumblr. (There are more microblogging tools than I had anticipated …)

As an illustration of this activity, the graph below shows a summary of attack traffic across the 77 Observatory ISPs reporting anonymized attack statistics.

Each line or rectangle represents a distinct attack (we saw over 770 attacks Thursday covering a wide variety of scale and targets). Each color represents a different ISP under attack.

Though most of the press and blogosphere focused on Twitter, Facebook and LiveJournal, from an Observatory perspective those weren’t even the biggest attacks (at least in terms of traffic rate / volume). Turns out that the 30 Gbps spike in the above graph represents a withering attack against the web portal of a 3G mobile operator in Asia.

The press and various public / private mailing lists have generated a lot of discussion (and quite a bit of speculation) on the execution and motives behind the Twitter / Facebook / LiveJournal attacks (including this Slashot overview). I don’t have much new to add to this part of the discussion, but I can share a few anecdotal bits of data the Observatory saw on these attacks.

First, some background: the Observatory monitors both coarse grain Internet traffic and attack DDoS statistics. The DDoS portion of the Observatory is designed to provide visibility into broad trends, i.e. what are the new types of attacks, how are attacks growing against specific services (and ports / protocols), etc. As part of the data data sharing arrangement with Observatory participants, the system goes to great lengths to protect the commercial privacy and anonymity of the actual companies and ISPs under attack.

So, for example, we generally have visibility into, say the growth of “Christmas Tree” attacks against web servers in Asia, but the actual victims are anonymous. In particular, this means we cannot correlate most of the attack traffic yesterday with specific sites like Twitter / Facebook / etc. (though we can monitor aggregate traffic levels to these sites using the traffic portion of the Observatory as in our previous post).

The one exception to this anonymity is outbound attacks. In other words, the Observatory does monitor the destination of an attack if the provider has explicitly configured their DDoS detection to alert when machines within their network or customer base attack services in another ISP.

Since each individual ISP in a well-distributed DDoS attack may originate relatively little traffic (i.e. the attack does not impact their infrastructure, many providers only focus detection on inbound attacks (i.e. when the attack does impact their customers or infrastructure).

The data below is an example snippet of a dozen or so such outgoing attacks yesterday (all times are EDT). Note that destinations of outgoing attacks are not anonymized but specific source addresses have the first two octets replaced with “XX”.

The first two DDoS look like small run of the mill TCP Syn attacks against a Twitter IP from both randomized sources and an individual host. The two attacks originate in an anonymous North American tier1 and MSO, respectively. The third attack example occurred later in the day (5:30pm EDT) and consisted of a 80 Kpps UDP flood.

While “Joe Job” SPAM links may have comprised a significant portion of the attacks yesterday (as others have reported), the Observatory saw a range of additional attack vectors including TCP Syn, UDP flood, and Christmas Tree attacks.

And though you could not follow the outage via tweets, Twitter’s blog announced the popular site was under DDoS.

The below graph shows Observatory data from 55 providers around the world to Twitter’s two NTT hosted addresses blocks: 168.143.0.0/16, 128.121.0.0/16.

From the data, Twitter traffic declined abruptly around 9am EDT this morning.

We generally don’t see a lot of data (i.e. it takes thousands of tweets to match the bandwidth of a single video), but 55 ISPs in the Internet Observatory were exchanging roughly 200 Mbps with Twitter before the DDoS. Then traffic dropped to a low of 60 Mbps around 10:40am and began climbing after that. As of 1pm EDT, Twitter traffic was still down by 50% at 150 Mbps (normally we see close to 300 Mbps for this time of day).

From DNS, it looks like Twitter has moved some of their infrastructure to different address blocks as of 2pm EDT.