It looks like Microsoft’s tactics for taking down the Waledac Botnet have been extremely successful and even rendered my Waledac Tracker pretty much dead in the water, which is a good thing.  With that there are now thousands of Waledac infected Zombie computers out there still serving up the last binary payload they received before the take down went into effect.  To pseudo track these zombies I have turned my Waledac Binary scraping scripts back up.  If the botmaster’s are unsuccessful at regaining control of there botnet the MD5 sum calculation I perform for the binary payload I grab from these zombie’s should never change.  Right now it is: 8a542087ff572182bb25c36e88ce9de2.  If the botmaster’s somehow figure out a way to regain control of the Waledac Botnet I am sure one of the first tasks they will perform is a binary payload update, so this should be a fairly decent method for monitoring the zombies.  Now since my binary scrapping scripts are pretty dumb/lame a corrupted download could cause an MD5 sum calculation to change from time to time, but the overall trend should easily allow us to identify these corrupted binary downloads.   An example of this would be the download I grabbed at “2010-02-27 04:26:11″ with the following Md5: d31c54578951c4ff3114f008256e1a97.  It is easy to spot in the following snapshot of this morning’s table display shown here:

I would also assume that spam is probably still being pushed out of the zombies as well, but I haven’t really done any investigations into this, so I can’t say for sure.  From what I have gathered from other security folks is that the global spam trackers haven’t really seen an impact yet.  I guess only time will tell what the next step is for the Waledac authors and how they plan to deal with this beheading.

The Waledac binary changes fairly often to avoid Antivirus Detection and modify the seeded IP addresses hard coded into the binary.  There are normally 30 hard coded IP addresses within the Waledac binary, which are used to establish the initial communication with other infected nodes on the botnet.  Once this initial communication within the botnet occurs a larger list of IP addresses is exchanged in a HTTP P2P fashion to ensure reliable connectivity to other botnet nodes even when multiple infected nodes go offline or are cleaned up.

So how often does the binary change?
I created a new table view into my database just to answer this question (Waledac Update Cycle).  This new view displays only binaries (distinct MD5 sums) that have been seen more than once to eliminate the inclusion of the corrupted binary downloads performed by my Waledac tracking scripts.  Here is a snapshot of the table for reference:

The table is pretty self explanatory, and the key column is the last column.  This Lifetime column shows in Hours:Minutes:Seconds how long a Waledac Binary has been in place.  With the default sort applied to the Last Seen column you can also visually see the approximate time a new binary was pushed out by the Waledac authors.  So back to the original question what is the average update cycle for Waledac binaries?  Averaging the the last column I came up with 15 Hours, 48 Minutes, and 21 Seconds.  Obviously this is not an exact calculation in that I am not retrieving a new Waledac binary every second of the day, but it does provide a fairly decent approximation.

I was also hoping this new view may have been able to identify a pattern in the binary update times as well, but I do not really see a clear pattern other than the authors seem to prefer evening updates over morning updates in the CST timezone.  This isn’t always the case though, as there are several binary updates that occurred during the morning hours as well.  Maybe over a longer period of time a pattern will surface, who knows.  Since there is no apparent pattern or single hour in which the updates occur I would venture to say that the binary updates are being performed manually by the authors.  I venture to say this in that if the authors had a script or cron job scheduled performing these updates for them on a regular bases the updates would most likely occur at the same time everyday.  This is not the case, so I would assume they are performing the updates manually.

As always feel free to comment or suggest new view points into my data, as I am always interested in hearing how this data can be improved upon or viewed in a new an interesting way.

I had completely rewritten my Fast Flux tracking scripts a few weeks ago, and have finally found the time to write a new web interface for the statistics and data I am gathering with these new scripts.  There are some interesting statistics  in all this data being generated that contradicts some of my initial thoughts on the Waledac Trojan, such as which country I was seeing the most infections for.  I originally had thought the United States was leading the way, but today’s data snapshot shows China out in front, followed by the Republic of Korea, and then the United States.  Here is a nice little GChart showing the top 10 Countries by IP count generated by my new Waledac Tracking Web Interface to demonstrate this.

Obviously this data could change as more hosts are indexed, but I found it interesting none the less.

It appears that the non NATed Waledac Trojan infected nodes serve three main functions: Web Proxy, DNS, and Spam Template relays.  Since these non NATed nodes can serve as both a DNS server and a domain destination I thought it would be interesting to separate out the Name Server IP addresses from the normal domain IP addresses.  Basically what I did when I revamped the back end tracking scripts was separate the NS records from the A records, which provided a very different statistical distribution than I would have initially guessed.  I originally would have guessed that the Name Server IP addresses would have been a lot less statistically distributed than the Domain IP addresses in this Double Fast Flux network.

As you can see my guess was wrong and the distribution of Name Servers IPs is right in-line with the distribution of Domain IPs with China leading the way, The Republic of Korea following in second place, and then finally the United States in third place.  All of these Countries seem to show about the same number of NS records as they do A records.  It would appear based on these numbers that the Waledac Trojan authors distribute both NS record and A record changes/rotations evenly throughout their botnet distribution.

Now for a little more information about the web interface I wrote to summarize and share this data with the public.  The major design objective I strived to achieve was to allow anyone to view the overall statistics in summarized table formats, with the ability to drill down and/or search out targeted interesting views as they saw fit.  Almost every table being displayed in this web interface has the ability to be searched with a text input field and the drop down box at the top of every page.  There are no wild cards per say, but all search strings are matched in a loose manner.  Let me explain this with an example.  Lets say you own the following Class C IP space “221.226.85.0/24″ and wanted to see if my data set contained any of your nodes.  You can enter “221.226.85″ into the search field like this:

Click the “Submit Query” button and your results should look something like this:

This type of “loose” matching is not just for IP address ranges, and can be performed on any of the drop down fields for you convenience.  Another feature I tried to accommodate was the ability to drill down on data via clicking individual fields.  Any field that is underlined and in bold face type can be clicked on to drill down on that particular piece of data providing a more targeted view.  This can be handy for drilling down on Counties, Regions, Cities, and/or ASNs.

The last portion of the web interface I want to go over is the Menu at the top of every page, which looks like this:

Here is a little overview of what each section can provide you.

• Tracker Summary – This is the index page or summary view of the data in the database.  You will find GCharts, Most Seen Statistics, and Last Seen Statistics on this page.  Many of the fields allow for you to click through to drill down into the highlighted statistic quickly and easily.
• Binaries – Waledac Trojan Binary Data Statistics and Summaries
  • Harvested – Summary data of all the binaries retrieved default sorted by last seen date.
  • Activity – Summary data of binaries retrieved grouped by IP and sorted by number of binaries retrieved from a particular IP address.
  • Names – Summary data based on the binaries name and sorted by the last date seen.
  • Longevity – This data represents the current life span of an IP. This number is based on the number of days seen between an IP’s first seen date and it’s last seen date.
• Fast Flux IPs -Waledac Trojan A record Nodes Data Statistics and Summaries
  • Harvested – Summary data of all the IPs and their associated information specifics sorted by the last seen date.
  • Activity – Summary data of all the IPs and their associated information specifics sorted by the number of times seen.
  • Domains – Summary data of all the Domains and their associated statistical summary information sorted by last seen date.
  • Countries – Summary data of all the Countries and their associated statistical summary information sorted by number of times seen.
  • ASNs – Summary data of all the ASNs and their associated statistical summary information sorted by number of times seen.
  • Longevity – This data represents the current life span of an IP.  This number is based on the number of days seen between an IP’s first seen date and it’s last seen date.
• Name Server IPs – Waledac Trojan Name Server Nodes Data Statistics and Summaries
  • Harvested -Summary data of all the IPs and their associated information specifics sorted by the last seen date.
  • Activity – Summary data of all the IPs and their associated information specifics sorted by the number of times seen.
  • Domains – Summary data of all the Domains and their associated statistical summary information sorted by the last seen date.
  • Countries – Summary data of all the Countries and their associated statistical summary information sorted by number of times seen.
  • ASNs – Summary data of all the ASNs and their associated statistical summary information sorted by number of times seen.
  • Longevity – This data represents the current life span of an IP.  This number is based on the number of days seen between an IP’s first seen date and it’s last seen date.
  • Name Servers – Summary data of all the Name Servers and their associated statistical summary information sorted by the number of times seen.

That is a basic overview of what is available via the new Waledac Trojan Tracking Web Interface, and I am always open to suggestions if your not seeing a statistic that would be of some use to you.  I do have a few more modifications or updates that I would like to implement the next chance I get, but I figured that the interface was complete enough to go ahead and make it publicly available.  As always if you have any questions or comments feel free to leave them here or hit me up via email.

Disclaimer:

This data is collected by dumb scripts and may or may not be 100% accurate.  If you have any issues with the data feel free to contact me, and I may choose to fix the issue or may choose not to fix the issue, as it depends on whether or not I feel your request is valid and/or pertinent.  When using this data please understand that some IP ranges utilize things like DHCP, and could cause issues with the accuracy of the data contained with in this data set.  Just because an IP is listed here, does not with a 100% sure accuracy deem that it is infected with the Waledac Trojan.  I have attempted to make this data as accurate as possible, but like all things in life I am not perfect and don’t claim to be.   This data also does not represent the true size or complete Waledac botnet, as I can not reach out to NATed Spamming nodes.  This data is offered “as is” with no guarantees or warranties, expressed or implied, as to the accuracy, reliability or completeness of the furnished data.  I reserve all rights to the availability of this data and will block anyone that is attempting to automate the retrieval of this data.  If you would like an automated solution for retrieving this data contact me and we may be able to come up with a way to meet your needs.

I received a request earlier today to start tracking the Waledac Trojan like I had the Storm Worm, and well since they both use the same tactics I figured why not.  I just finished modifying my Storm Binary Tracking scripts to monitor the Fast Flux network of Waledac and it’s web pages.  You can find the data from the binary tracking scripts here: Waledac Tracker.  I don’t know yet how much time or effort I will put into tracking this Trojan, but since I am publishing this data I will go through a quick summary of what the Waledac Trojan is.

The Waledac Trojan is delivered as a URL link inside spam messages.  The current web page looks like this:

The web page is really just one large GIF image “img.gif” that links to “postcard.exe”.  This ensures that any stray user clicks on the web page will prompt the user to download the “postcard.exe” binary, which is the Waledac Trojan.  There is also an IFRAME embedded in the web page that points to “hxxp://seocom.mobi/rotate/c.php?eb0h”, but when I went to retrieve this page I got a 403 error stating I didn’t have permission to access this page.  From other articles and blog posts I have read this is where the Waledac Trojan tries multiple exploits, but since I can’t access the page right now I can’t confirm this. One thing I did note that I haven’t seen posted yet is that although the Waledac Trojan web page is being served up by Nginx/0.63.4 the seocom.modi site is being served up on an Apache 1.3.41 server.  Here are some settings I found for the Apache server:

Apache/1.3.41 (Unix) PHP/4.4.9 mod_log_bytes/1.2 mod_bwlimited/1.4 mod_auth_passthrough/1.8 FrontPage/5.0.2.2635 mod_ssl/2.8.31 OpenSSL/0.9.8b

The Shadowserver Foundation has a really good write up on this Trojan and if you haven’t read it yet here it is: Waledac is Storm is Waledac? Peer-to-Peer over HTTP.. HTTP2p?. They also have a nice collection of current domain names being used to host the web pages, so if nothing else grab those domains and start implementing DNS Blackholing or add them to your proxy configurations to prevent your users from even visiting these sites.

So far I have seen 142 IPs with my tracking scripts:

4.244.69.144
12.168.205.170
24.33.233.54
24.57.83.138
24.64.95.238
24.85.240.20
24.139.69.37
24.192.176.75
24.224.175.80
65.73.167.53
65.75.124.106
67.49.6.243
67.61.207.176
67.64.156.119
67.150.246.57
67.169.11.92
67.173.196.140
67.213.96.198
68.32.31.173
68.50.173.54
68.50.231.91
68.173.97.117
68.204.235.220
69.24.123.167
69.47.115.180
69.76.136.225
69.247.164.171
70.114.195.33
70.140.184.127
70.200.169.81
70.218.30.49
70.218.195.166
71.9.79.35
71.63.142.94
71.83.92.224
71.106.8.84
71.129.153.200
71.197.172.125
71.202.65.70
72.29.253.14
72.45.18.151
72.136.24.242
72.137.38.157
72.240.184.75
74.77.138.209
76.28.115.147
76.64.70.42
76.70.96.73
76.91.235.206
76.93.233.117
76.118.24.140
76.170.178.95
76.190.203.104
76.193.34.126
77.79.38.18
77.96.251.230
81.220.178.33
82.177.226.171
82.199.195.102
83.21.60.214
83.84.116.137
83.84.130.209
83.97.242.136
83.223.183.38
84.52.145.241
84.66.64.201
85.12.224.206
85.86.39.123
85.114.37.72
85.130.4.5
85.221.176.110
85.222.37.208
86.6.143.109
86.8.75.241
86.122.250.76
87.68.170.173
87.206.73.25
87.207.85.117
88.134.165.249
88.180.152.39
88.199.249.4
89.45.55.175
89.45.129.21
89.74.138.247
89.74.209.189
89.76.212.192
89.77.140.176
89.78.142.100
89.78.146.247
89.103.246.108
89.132.97.13
89.138.8.245
89.151.26.188
89.229.78.254
89.253.10.124
92.232.169.168
92.238.151.224
97.81.205.168
97.104.61.143
98.28.108.254
98.200.169.254
99.18.144.23
99.54.141.194
99.141.124.78
99.147.191.25
99.152.125.180
99.195.196.98
99.236.230.185
99.238.95.109
99.243.247.72
99.247.215.190
99.254.51.22
99.255.24.131
118.221.104.156
121.208.2.46
128.174.141.174
128.226.92.84
128.226.183.142
129.109.150.81
129.115.98.48
130.13.54.113
131.107.0.72
134.74.16.124
137.110.124.139
149.125.248.85
156.34.95.177
173.45.193.254
193.95.195.68
196.45.201.101
200.55.77.109
200.84.125.24
200.127.209.84
201.1.207.189
201.231.16.222
204.116.246.48
208.96.18.58
208.98.218.245
211.74.120.88
212.198.239.213
216.16.66.37
217.70.52.180
221.214.134.26

I can’t say these are all bad or related to the Waledac Trojan, but can tell you that these were IP addresses found as A records in the Waledac Trojan Name Servers. The only IPs I ever claim to be 100% sure that they are/were associated with the badness are the one’s I actually grab a binary from, and those can now be found via the Waledac Tracker.

If you have any questions or comments feel free to email me anytime, and also let me go ahead wish you all a belated HAPPY NEW YEAR!

I was notified the other date that the anubis_submit.pl script was no longer working and users were recieving 404 page not found errors.  Anubis made a few changes to the web form submission fields and the url which caused my script to break.  I have since updated the script to work with their new submission page.  Thanks for the heads up for those of you that let me know it was broken and feel free to contact me if you have any questions or comments.

I had some spare time this afternoon, so I decided to update the web interface to my Storm Tracker Database. I hope everyone finds these changes useful, as I have include several correlated data displays in an attempt to make researching the Storm Web Proxies and Binaries I have harvested a little easier and user friendly. I personally have performed most of these queries on my dataset offline, but was to lazy in the past to create a web front end for them. In addition I have also included in these new data views embedded hyperlinks that allow you to drill down on different datasets faster.

I do have some ideas for some future enhancements such as Spam tracking, Domain Name tracking, Name Server Tracking, Web Page Tracking, and a possible peers dataset. I can’t guarantee I will ever implement any of the above, but they do sound useful.

If any of you have any enhancements or data views you would like to see or think would be useful feel free to contact me with the details, as I will take them into consideration when I decide to revamp the Storm Tracker again.

I just added a search by IP feature to the Storm Binary Tracker page after talking with the guys over at Malware Domain List . If your unfamiliar with this site you really ought to go give it a serious look over as they house some really good information for anyone interested in malware and malware analysis. Boban Spasic aka Bobby, the creator of Malzilla posts there regularly about updates for his tool, and I even read in some of the forums where he was taking ideas from posters to better his tool. If your unfamiliar with Malzilla, it is one awesome tool for exploring malicious websites and you should really give it a try. When I first started trying to explore and deobfusticate malicious web pages I would use a large mixture of tools such as wget, SpiderMonkey (JavaScript Engine), miscellaneous bash tools, and a whole lot of custom Perl scripts that would do conversions for me, but now I pretty much only ever use those tools when I can’t get Malzilla to do it for me, which might I add has almost never happened since I started using it. What prevented me from using it at first is it is a Windows only application and I run Linux on most of my computers. Once I figured out how to get it to work in Wine (the Windows API for Linux), which again may I add was as simple as sucking the package down and executing it with Wine, I haven’t looked back since.