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.

As many of you have probably read today Microsoft initiated a large scale take down operation called “Operation b49″ to behead the Waledac Botnet.  This take down effort has definitely made a visible impact on the botnet as seen here in this recent image taken from my Waledac Botnet tracking scripts.

I applaud their efforts with this take down and now only time will tell if their strategy will have lasting impacts on this menace of a botnet.  Waledac is a peer-to-peer botnet, so simply taking out command and control servers would not have a lasting impact and the botnet would quickly recover.  By taking down the botnet at the domain (“.com”) level the individual peers within the botnet will no longer receive peering list updates, command and control instructions, and spam templates, but Waledac is resilient by design so additional actions have to occur for this take down to be completely successful and/or lasting.

The group and/or groups behind Waledac are most likely still scrambling to understand what occurred and where they went wrong, but with ties to the extinct “Storm Worm” of the past and the Zeus Trojan which has recently made the news headlines it is doubtful this will end their criminal efforts.  Time will only tell us what the groups next move will be and with that I guess I will have to find another botnet to monitor, so I will be on the look out.

KUDOS to Microsoft and the behind the scene folks within the security community that aided in this effort!

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.

Don’t be a victim and have a “Happy 4th of July”!

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

In comparison here is a table of the most active days by new IP counts:

Most Active Days By New IP Counts

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

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

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

For a comparison here are the most active last seen days in my database.

Most Active Last Seen Dates By IP Count

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:

• Result: 8/39 (20.51%)
• Result: 6/39 (15.38%)
• Result: 7/39 (17.95%)
• Result: 6/39 (15.38%)
• Result: 6/39 (15.38%)
• Result: 6/39 (15.38%)
• Result: 6/39 (15.38%)
• Result: 6/39 (15.38%)
• Result: 6/39 (15.38%)
• Result: 10/39 (25.64%)
• Result: 6/39 (15.38%)

Not looking all that good, if you ask me.

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:

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.

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.