I was shocked this morning when my Waledac Tracker shot me an email saying new binaries were being retrieved and this little menace known as Waledac woke up from it’s dormant state. After almost a month of inactivity the Waledac botnet has risen from the dead in an “Independence Day” themed spam run. This new theme for Waledac is very similar to past “Storm Worm Independence Day” we saw last year. I simple spoof of “You Tube” video, which is just waiting for you to click on and deliver a nice little copy of the Waledac Trojan in a executable format (binary). Here is a screen shot of the current page being served up:
I do not see any exploit code or iframe re-directions on the current page, but of course this could easily change at anytime. Without the exploits or iframe re-directions to awaiting exploit packs, a victim of Waledac will have to execute the binary all by themselves. This new binary comes with no real Antivirus Detection with Virus Total results like this: Result: 4/41 (9.76%). I am sure once the Antivirus companies realize what is going on this will improve, but until then we must rely on the education of our users and hopefully some good software installation restrictions and policies to prevent this for now.
First off let me say that writing this post was a very difficult decision for me to make, as I normally try to work with vendors, companies, and organizations to fix issues like this one I am about to disclose without ever really disclosing them to the public, but in this case it just never worked out. I have tried for the last 18 months to contact just about everyone I could think of at Brainbench to disclose this issue to them, but none of my emails were ever returned. I utilized their bug reporting “Contact Us” form several times over this time period, but still no one even acknowledged the receipt of my emails or submissions. I even tried emailing common email addresses such as these: support@brainbench.com, security@brainbench.com, security-alert@brainbench.com, info@brainbench.com, webmaster@brainbench.com, admin@brainbench.com, and postmaster@brainbench.com to name a few, but again no response, well unless you count a few bounced emails for accounts that do not exist. I have sent them a copy of “Full Disclosure Policy (RFPolicy) v2.0” a few times telling them they had 5 days to contact me before I release this information, but like I said they never return any of my emails. This to me is just plain ridiculous and irresponsible on their part, as what I am about to provide you all with is information on how their core business objective for providing assessment products is just plain flawed, and cannot be relied on to accurately trust their assessment results.
I have personally been forced to take several of Brainbench’s assessment tests during both the interviewing process and continual certification processes that Brainbench offers for a fee to companies looking to evaluate, assess, and/or validate future and current employee’s skill sets. Here is a direct quote from Brainbench’s website:
Brainbench, a PreVisor company, has served over 5,000 corporate and 6 million individual customers. The company was founded in January 1998 with the same mission it has today: Delivering easy-to-use assessment products that predict success on the job.
Here are some statistics, again copied directly from their website:
Number of Brainbench customers serviced in the US: Over 4,000
Number of countries where Brainbench has tested people: Over 120
Average Small Business Sale: $6000; 2 week sales cycle
Average Mid-Size Business Sale: $20,000; 4 week sales cycle
Average Large Business Sale: $120,000+, 10 week sales cycle
Brainbench customer renewal rate: 85%
Average renewal contract value: 140%
So as you can see they really appear to take pride in their ability to provide corporations and individuals with assessments that can aid in selecting the right candidate for a position or validate a current employee’s skill set. This is why I could not comprehend their actions or lack of actions when I attempted to contact them in regards to this issue, which defeats their assessment engines validity. Well I think I have provided enough background details and such, so lets get to the meat and potatoes of the issue at hand.
JavaScript injection is a simple technique that can be utilized to manipulate client side rendering and code, HTML forms, cookies, and/or just about any parameter on a web page after it has been rendered by the browser. To perform this type of attack all that is needed is a web browser and the address/location bar built into all web browsers. To perform this attack all that is done is the clearing of the address/location bar and entering in JavaScript functions and/or code in it’s place. A sample alert message can be rendered on any page by clearing the address/location bar and adding in this code:
javascript:alert(”Hello World!”);
JavaScript injections conducted in the address/location bar must always be started off with “javascript:”, but several commands and or code segments can be entered into the address/location bar by ending each one with a “;” to terminate each section and/or segment. A really nice write up on JavaScript injections with some really cool functions can be found here: “How to Use Javascript Injections“.
It is clear that JavaScript executed in the address/location bar isn’t really a bug or security vulnerability by itself, as it can only be seen on the client side, but it can be utilized to perform some interesting things and/or actions such as web form manipulation and parameter modifications. This is why no one should ever trust inputs from a client and JavaScript validation by itself is just not enough to secure your data. Server side validation must occur for every single input received from the client to ensure it is valid and safe to process.
Brainbench’s assessment engine relies solely on a JavaScript function to process a test/assessment takers time spent on each question. This time is normally restricted to 3 minutes or 180 seconds, which sounds like a pretty nifty feature to ensure test/assessment takers are answering questions based off knowledge. Given more time a test/assessment taker could easily Google the answer or even reference a book for the correct answer, which sort of defeats the purpose of the assessment. So let us take a little journey into this JavaScript code utilized by Brainbench’s assessment engine, and see if you can’t spot the issue before you get to me just spelling it out for you. Here is the function in question:
Now is the issue or vulnerability at hand apparent yet? I can think of a few ways to defeat this code, but I am only going to demonstrate one very simple and straight forward method for “Stopping” and “Starting” the timer at will. To stop the timer simply copy and paste the following code into the address/location bar of your browser and hit the “enter” or “return” key while you are taking the assessment/test and the timer will stop:
javascript:void(doTimer=false);doOnload();
To start the timer back up simply change the “false” parameter to “true” and hit “enter” or “return” to execute the code once again. Like magic the timer will start up again where it left off.
Very simple right? So what harm does something like this do? Well your not going to get “root” or “own” Brainbench, but now how valid are these assessments and/or exams? By stopping the timer at will a test/assessment taker can easily go look up the answer to a question he or she has absolutely no knowledge of, and score a perfect score in areas that the test/assessment taker has no knowledge of. This completely defeats the validity of the assessment, and now these certifications and/or assessment results can no longer be trusted. Now if I was an organization reading this article and utilizing these assessments I would immediately contact my sales representative and pose the same question, but hey that is just me. If I took pride in holding these certifications and paid to take these assessments, I would also call or email Brainbench to pose this question to them as well. This really hurts and/or questions the overall validity of these assessments and certifications. Maybe if enough people and/or organizations seek out Brainbench’s response and/or support in regards to this matter it can be fixed quickly.
So how can they fix this? Simply validate or remove the client side “timer” input variable. Removing it would ensure the timer variable has no impact on the actual exam time and/or timer. To validate the timer a server side function and/or timer to compare with could be utilized. The visual timer makes for a good reference for the test/assessment taker, and should not be removed in my opinion, just don’t trust it to be accurate. Removing the “doTimer” variable would be a good idea as well, since I really can’t come up with a valid reason for having this functionality or variable. Just start the timer and let it run, no need to check if the timer should be running when a test/assessment taker is actually taking the exam. I could be wrong here since I didn’t write the code, but then again I could be right too.
Just as a historical reference since I am optimistic that Brainbench will fix this issue in the near future I have recorded a video demonstrating that this vulnerability really did work, and as of today still works.
As always if anyone has any questions or would like to share their comments feel free to do so, or just send me an email.
As many of you already probably know the Waledac Botnet Social Engineering theme changed to a “SMS Spy on your Partner” theme at approximately 0500 CST or 1000 UTC/GMT on April 15th. This was first brought to my attention by Bob Burls from Cranfield University in the UK, and he was also kind enough to share with me this screen shot of the new campaign.
Thanks Bob for the screen shot and the information!
Interesting enough this theme is very similar to the “Couponizer Theme” we saw in late February, as it is a spoof from a legitimate company’s web site. The image and theme are based off the SPY-SMS website, which appears to offer mobile phone spy software.
I pulled a few interesting statistics from my database and thought I would share them with everyone. Over the last 30 days the Waledac Botnet infections appear to be very steady or normalized, as there are very little differences in the number of new infections found by my Waledac Tracker scripts depicted here:
New Infections By IP Count Last 30 Days
IPs
Date
74
2009-04-17
88
2009-04-16
226
2009-04-15
94
2009-04-14
99
2009-04-13
154
2009-04-12
151
2009-04-11
179
2009-04-10
220
2009-04-09
201
2009-04-08
337
2009-04-07
359
2009-04-06
374
2009-04-05
530
2009-04-04
326
2009-04-03
258
2009-04-02
221
2009-04-01
200
2009-03-31
252
2009-03-30
273
2009-03-29
222
2009-03-28
247
2009-03-27
235
2009-03-26
182
2009-03-25
236
2009-03-24
303
2009-03-23
317
2009-03-22
272
2009-03-21
301
2009-03-20
259
2009-03-19
In comparison here is a table of the most active days by new IP counts:
Most Active Days By New IP Counts
New IPs
Date
1326
2009-02-07
1297
2009-02-08
1236
2009-02-01
1138
2009-01-22
1080
2009-01-24
1075
2009-01-23
1047
2009-02-09
1044
2009-02-06
974
2009-02-02
954
2009-02-04
Another interesting statistic I pulled was the number of unique binary names seen every day for the last 15 days:
Unique Binary Name Counts for Last 15 Days
Date
Unique Names
2009-04-17
9
2009-04-16
9
2009-04-15
10
2009-04-14
6
2009-04-13
6
2009-04-12
6
2009-04-11
6
2009-04-10
6
2009-04-09
6
2009-04-08
6
2009-04-07
6
2009-04-06
6
2009-04-05
6
2009-04-04
6
2009-04-03
6
2009-04-02
6
As you can see these stats look fairly normalized or evenly distributed. As a comparison here is the top five dates with counts for the number of unique binary names seen in one day:
Top 5 Dates By Unique Binary Name Counts
Date
Unique Names
2009-02-22
27
2009-02-17
26
2009-02-19
25
2009-02-13
23
2009-02-15
23
As you can see the “Couponizer Theme” campaign during the end of February consisted of a larger variation of binary names, when compared to the last two campaigns.
The last statistic I am going to post is the number of IPs that were last seen by my Waledac Tracking scripts in the month of April.
Number of IPs By Last Seen Date Counts for April
IPs
Date
567
2009-04-17
72
2009-04-16
202
2009-04-15
143
2009-04-14
162
2009-04-13
120
2009-04-12
103
2009-04-11
171
2009-04-10
221
2009-04-09
149
2009-04-08
465
2009-04-07
453
2009-04-06
437
2009-04-05
500
2009-04-04
552
2009-04-03
281
2009-04-02
244
2009-04-01
For a comparison here are the most active last seen days in my database.
Most Active Last Seen Dates By IP Count
IPs
Date
1408
2009-02-08
1177
2009-02-07
1161
2009-01-22
1099
2009-01-23
1058
2009-02-04
Looking at this last table I would assume that during the end of January and beginning of February the Waledac Binary was well detected by Antivirus Companies, as it looks like a number of systems were cleaned up during that time period. Now these statistics may or may not show the true depiction of the Waledac Bots, as I am crawling the Bots that have public IP addresses and not the Spamming Bots with NATed IP addresses.
Looks like the Waledac Authors wore the Couponizer theme out, and have now switched to a new headline “Terror Attack” theme. Headline News themes are nothing new to botnets like Waledac, as the Storm Worm used them a few times with fairly decent infection rates. Another note of interest with this attack is the continued usage of GeoIP data to customize the news article for visitors. I utilized several web proxies and the Waledac GeoIP database seems to provide extremely accurate IP to Location results. Take a look at a screen grab I took while I was utilizing a Woodstock web proxy.
Another interesting touch are the two non malicious web links at the bottom of web page. One leads to the “Dirty Bomb” wikipedia page and the other leads to Google search results pertaining to “Your GeoIP City” and the key words “Terror Attack”. The normal iframe hidden link can still be found in all the Waledac web pages I viewed. The common URL structure for this iframe right now is http://xxxxxx/tds/Sah7 , so some simple URL filtering or logging with your proxies may help to identify users that have visited a Waledac web page and possibly received some malicious exploit attempts passed through this hidden iframe.
If anyone is interested in just how well the Antivirus Companies are doing in keeping up with the Waledac Authors and polymorphic packer here are a few links to VirusTotal’s Static file scan results for some of my recently collected binaries:
It appears that the Waledac authors have decided the share the “love” theme has worn itself out, and have updated the website template to a new theme I have titled the “Couponizer”. This new theme is right inline with the “sharing” social engineering trickery we have grown to expect from malware authors. This theme offers to share with you the unsuspecting website visitor money saving coupons that can only be found by downloading and installing their binary, which is really the Waledac Trojan. So instead of them sharing money saving coupons, the end user ends up sharing their bandwidth with the Waledac authors to aid in distributing more of these money saving spam emails and other spamming campaigns. All of this of course in done free of charge to the compromised host, unless your paying for bandwidth under a pay per usage format. Ouch, if you are having to use one of these outdated plans as I can only hope those types plans have long disappeared for your normal residential service connections. Imagine your phone bill if Waledac could infect your handheld device and utilize minutes on your wireless data plan. Not a pretty picture if you ask me.
Anyways let me provide you all with a snapshot of the current web page template, so that we can send out our administrative spam warning our users not to download and install anything from a site that looks like this:
So as we can see the theme is not lacking in professionalism. The major dead give away for this template and many of the other Waledac Trojan templates is that every item on the page is really an image. There is really no real text, unless you count the unseen “iframe” lurking behind the scenes hosting several well structured exploits and redirections. Back to the images, all of the images on the page are hyperlinked to a binary file, so this again is a dead give away. We should warn our users to never install executable content from websites like this. Hey better yet, why are we still allowing our users to install binaries anyways? You know that if we followed the hundreds if not thousands of hardening guides found all over the Internet I am sure one of the first steps found in almost everyone of them is to remove administrator rights from normal usage accounts and create a software distribution and installation policy. So why are campaigns like this still so effective? Most likely because we know what the right thing is to do, but many times there are roadblocks in the way that prevent us from implementing policies like these. On that note, if the DOD can force you to glue your USB ports with some sort of Epoxy I would venture to say removing administrator rights from your users should be an easy accomplishment. Now if your part of the DOD don’t go sending missiles to my house as this was just an observation, and no pun intended.
It also looks like the polymorphic generation of the Waledac binaries and the rotation of binary names we have seen since the 6th of February, which may I add was exactly 2 days after I posted that the update cycle for the Waledac binaries appeared to be ~15 hours (shame on me), is still well on it’s way to causing the best of the best Antivirus Companies and Malware detection companies to stay up late at night or just give up all together. I definitively do not fault the Antivirus industry for this poor detection rate, as how do you create static file signatures on something that is constantly changing? The fault of successful malware campaigns such as Waledac should lie directly on the shoulders of the system security plan authors, ITSMs, CTOs, and security professionals chartered with securing computers and networks. Stopping Waledac is almost trivial if you will put into place a good patch management system, and take away administrative rights for general usage accounts. Teach those that require administrative rights such as system administrators to use the “run as” functionality in Windows, it is there for a reason. Stop making excuses on why you can’t do these things, and just do it. I am sure you will feel the pains that all of us that have already removed our users administrator rights have felt in dealing with users that believe they need to run their daily accounts as an administrator. Nobody said computer and network security was an easy task, so lets just buckle down and fix the fundamental issue here instead of blaming others for our problems such as the Antivirus industry. Hmm, that sounded like a “rant”…
In the mean time if you can’t pull administrative rights feel free to utilize the Waledac Tracker on my site to put into place content filters, DNS blackholing, Firewall rules, and IDS/IPS signatures to match on content downloads or IP addresses. I don’t think this is an effective solution, but hey sometimes you just have to make due with what you got. On that note I have been supplying one of my favorite projects “EmergingThreats.net” IP addresses from my Waledac Tracker for IP addresses that have demonstrated some sort of activity in the last 72 hours. Matt has put into place a mechanism to update his compromised host ruleset with these IP addresses every 24 hours, so you may want to take advantage of this and start using this projects rulesets if you don’t already. EmergingThreats.net has come along way over the last few years, and I can say from personal experience in the IDS world their rulesets do a very good job at detecting botnets, and other malicious content that can’t be seen when only running the Snort.org VRT rulesets. Nothing wrong with the VRT ruleset either, so I would recommend running both of these rulesets and updating constantly.
As always feel free to contact me if you have any questions or comments.
UPDATE: 22 Feb 2009 ~6:00 PM CST (GMT-6)
Much to my surprise there is a legitimate “Couponizer.com” site in which the Waledac Authors stole their latest theme from. Give it a look-see here: The Couponizer. I just sent the admin contact for “The Couponizer.com” website a short note letting them know their reputation is being tarnished as we speak. Not much they can do about it except maybe put out the standard news release stating they have no involvement with the Waledac Trojan.
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.
Now that I have collected quite a bit of data for the Waledac botnet, I thought it would be interesting to see if I could visualize this data in a meaningful way. Visualizing data has really taken off in the last few years especially when looking at network flows and it can reveal some really interesting characteristics that may not be all that apparent when data is presented in tabular format or with charts. All of the graphs or visualizations I am posting today were generated using a combination of the Afterglow.pl script and the Graphviz command line tools. Another note these graphs generated were extremely large in file size, so I took JPG snapshots of these graphs and placed them in this post to aid in page loading speeds. The more detailed graphs are linked via the images to PDF files that can be downloaded to zoom in for a more detailed view.
The first relationship I took a look at was IP addresses -> Name Servers -> Domain Names. The density of red nodes for each clover visually depicts the number of IP addresses associated with a specific Waledac domain name. The density of red nodes for each leaf in the clovers depicts the number of IP addresses associated to a specific Name Server within that Waledac domain. As you can see some Waledac Domain names are more popular than others. Another interesting characteristic demonstrated by this graph is that there are some Name Servers that are a little more popular than others for a few domain name’s being utilized by Waledac, but overall IP addresses within each domain appear to be fairly evenly distributed between Name Servers. The last characteristic I would like to point out is that the blue rectangles depict the Name Servers within each domain name, and if you count them their are exactly 6 Name Servers for every Waledac domain name.
The next view I looked at was the reverse of the previous view: Domain Name -> Name Server -> IP. This should result in about the same overall graph, but it reverses the colors and clearly demonstrates that there are in fact 6 Name Servers for every Domain Name. The Blue rectangles are the Waledac Name Servers and by reversing the colors the IPs are now in a neutral color making the Name Servers easier to count.
The next data set relationship I looked at was IP -> ASN -> Country. The higher density of red nodes in a clover represents a larger number of IPs seen in a particular country. If you focus in on the individual clovers the density of red nodes in relation to the density of blue rectangles depicts the number of IPs seen per ASN. If nothing else, this graph represents another view point into the Waledac botnet IP distribution per ASN and Country.
Now lets take a look inside of some of the more popular Waledac domain names according to my Waledac Tracker data set in the relationship of Domain Name -> Name Server -> IP Addresses. The next three graphs are ordered by domain names: yourregards.com, yourchristmaslights.com, and newlifeyearsite.com. When I pulled these data sets they were the top 3 domain names based off IP address counts. The interesting visual correlation that can be seen within these graphs are the number of IP addresses in relation to each Name Server for that domain. The larger the red circle the more IP addresses are associated with a name server, which makes it easy to see that it had appeared with the above clover leaf clusters that the IPs were evenly distributed when in fact there are some differences.
yourregards.com
yourchristmaslights.com
newlifeyearsite.com
This last graph I generated really does not mean a whole lot per say, but I think it looked pretty interesting so I went ahead and posted it for your viewing pleasure. Its relation is based off my binary tracking scripts that retrieve Waledac binaries every 30 minutes: Binary Name -> IP. Again not real meaningfull, but it sure looks cool.
Well I hope you enjoyed the graphs, and as always if you have any questions or comments feel free to either leave them here via a comment or email me anytime.
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 had a few spare minutes today and ran some quick queries on some of the data collected by my Waledac Tracking Scripts. The first set of queries I did were for the ASN information against the IP addresses that I actually retrieved Waledac Trojan Binaries from. Here is a text file for the bulk queries I ran against the Team Cymru’s ASN whois database: asn_binary_ips. Here are some summary stats:
Country
Count
US
140
EU
6
AU
3
FR
10
TW
8
KR
17
JP
2
RU
1
PL
15
So it appears that most of the hosts I have retrieved Waledac Trojaned binaries from are located in the US. I also have some scripts that crawl the Double Fast Flux network for NS records and A records since both of them change as the TTL expires. The Waledac Botnet seems to follow the same tactics the Storm Worm did where the malicious web servers, dns servers, and spam bots all reside on the same compromised hosts. These hosts use the Ngnix web server to proxy requests through compromised bots to the main command and control (C&C) servers to conceal their identities. Unlike the Storm Botnet, the Waledac botnet does not appear to use the P2P network to exchange bot nodes, but instead it seems to exchange bot nodes through the HTTP protocol via encrypted channels. I have not had a chance to dive deep into the Waledac Trojan’s binary, but it is definitely on my to do list. With that being said here are some stats form my Waledac crawler scripts: ips_asn.
Country
Count
US
1442
EU
117
AU
69
FR
66
TW
64
KR
206
JP
29
RU
23
PL
186
My crawler scripts are really just Fast Flux bruteforce scripts, so by no means do they represent the actual size of this botnet or it’s true geographical distribution. With that being said it looks like the US is leading the way with infected bots. For many of us the Waledac Trojan appears to be a nuisance that may be hard to shutdown, or combat with our traditional methods such as IP blocks, DNS Blackholing, Spam Filtering, and Proxies. With that being said I would recommend user training and awareness, which is one of the hardest things to actually do. We really need to get the average end user up to speed and educated on these types of malware. I am not sure what the best approach to do this is, but the dissemination of information out to your end users would be a good start. Preach to them that video codecs, ecards, and news articles do not require them to install executable’s to be viewed and if they are prompted to install these to contact the help desk or their system administrator immediately. Trojans like Waledac and the old Storm Worm use these social engineering tactics very well, but they also from time to time contain exploit packs like Mpack to hit users with an array of exploits in a structured and very effective manner. Although Mpack has been dead for a while, it is just an example and exploit packs like EL Fiesta are seen in the wild daily, so don’t let your guard down by thinking that if a user did not download the binary that they are not infected. The best advice I can give right now is to visit the machine and do some quick forensic checks to verify the host is not infected. Once I have time to really dive into this Trojan, I will post what I find to hopefully aid in identifying compromised hosts and maybe even some IDS signatures.
As always if you have any questions or comments feel free to hit me up. Good luck with this new threat, as it seems to be a presistent trojan that may be here to stay for a while.
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:
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:
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!
