How Long is the Waledac Binary Update Cycle?
Posted by jeremy on February 4th, 2009
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.

February 5th, 2009 at 6:42 am
Very nice tracker about Binary Update Cycle.
I have one little problem when i use repoort filter about Fast Flux IPs Harvested
I tried to filter the data in the report Fast Flux IPs Harvested for LAST SEEN, but I get this error after the first page
Example:
flter for last seen -> 2009-02-05
result is: 67 found by search. Page 1 of 2 [Next] [Last Page]
Page 1 show correct, if i choose page 2 i receive this error —> Error, query failed
Edgar
February 5th, 2009 at 7:14 am
Should work now for you.
Thanks for the catch.
February 5th, 2009 at 9:37 am
Yes
Now is OK
Many thanks
Edgar
February 6th, 2009 at 2:38 am
I make a little comparison between the ip detected in interval 5 hours from the tracker and my AutoIt script
The results seem to be very close
http://edetools.blogspot.com/2009/02/botnet-waledac-alcune-verifiche.html
Edgar
February 6th, 2009 at 9:02 am
Edgar, one thing I should make clear is that to optimize the database the IP->Domain relationship for my tracker is last associated Domain. What I mean is several of the Waledac IPs are shared between domain names, so if an IP is seen in a order of say X domain, Y domain, and Z domain the tracker will show that IP associated with Z domain and not X domain and Y domain. So comparing a single domain name walk with your whois tool to the results found in my Tracker is not 100% accurate.
February 6th, 2009 at 10:11 am
I understand and also some Waledac Domain names are more popular than others.
Thinking of this I created a script that does not make a whois on a single domain but on a number of domains between the more ‘popular and I want to see if the results change.
I have a question for you:
What do you think about Chinese and Korean domains that now are disappeared from the reports ?
Becouse i think Korea and China have one big numbers of infected computers.
Edgar
February 6th, 2009 at 10:26 am
Edgar, I am not sure what to think of this… It does appear as though the authors are experimenting with the segregation of their botnet though. If I have sometime in the next few days I may create some new view points into the data that will track these types of things. Maybe it will provide some interesting statistics or data views for us.
February 7th, 2009 at 1:39 am
For curiosity ‘I made a script that uses various domain names waledac and not just only one in whois test.
The result is’ that whois show different domains always associated with groups of a same IP address
http://edetools.blogspot.com/2009/02/botnet-waledac-alcune-verifiche-parte-2.html
Edgar
February 11th, 2009 at 10:01 am
Now Waledac pages have iframe with link a other waledac domain with code and links a page software in russian – english language.
more info at http://edetools.blogspot.com/2009/02/aggiornamento-waledac-11-febbraio_11.html
Edgar