Ecatel’s (AS29073) BGP Issues

While I was adding some Google Charts to my SpamBot Comment tracker I noticed that SpamBots originating from the ISP and Hosting company Ecatel Network were my number one comment spam offender.  Like any other security researcher I initially performed a Google search and landed on this blog post “Atrivo, McColo and now Ecatel” by Rune at “Silent noise – about spam, trojans and other nasty stuff” which sparked my interest and lead me to diving deeper into this network.

It appears that several of Ecatel’s Network BGP peers decided to drop peering with them to include Hurricane Electric Internet Service AS6939, which from my research appeared to be their main peering point to the Internet.  The initial drop in peering caused a complete outage for Ecatel’s network, but this was short lived as they were able to obtain peering from Joint Transit.  Joint Transit appears to be their new main peering location to the Internet.  Several customers posted complainants concerning the outages on the public forum WebHosting Talk, which was also documented in Rune’s blog post.  I should also note that Ecatel still has not fully recovered and can not be reached from a few locations in the US according to this Host-Tracker report I ran while writing this blog post.  I can not reach Ecatel’s network right now through my ISP, which isn’t a bad thing.

In trying to identify what exactly occurred when the peering locations decided to stop peering with Ecatel I ran across an extremely useful tool that I had not played with before called “BGPlay” at Route Views.  Using this new toy I was able to graphically play the BGP peering route advertisements and withdrawals for the last week for any of the network subnets living on the AS29073 Ecatel Network.  Here is Ecatel’s Network before AS6939 (Hurricane) stopped peering directly with them.

As you can clearly see Ecatel’s network (AS29073) was communicating out to the Internet via the peer Hurricane (AS6939) for the large percentage of it’s traffic.  Once Hurricane (AS6939) stopped peering directly with them Ecatel scrambled to find a new main peering location which took several hours to do, but eventually they were able to pull it off.  Here is how Ecatel is peering right now:

As you can see from the image above Ecatel’s peering into the Internet is very different, but it did recover.  I am also sure Ecatel’s customers are seeing a difference in response times and through-put, as Hurricane Electric (AS6939) is ranked #46 by NetConfigs AS Rankings and  Joint Transit (AS24785) is ranked #890.

Now that Ecatel has had it’s hand slapped for harboring this collection of general badness I can only hope that they have learned their lesson and will start to clean up their network.  It is hand slaps like this that should really start getting ISPs and hosting companies attention, as a serious loss of revenue could occur if these types of actions continue to be taken.  I can only hope that the actions such as ICANN riding us of EST Domains, and the McColo and Atrivo network demise will become the norm.  These types of actions can really start to get the ball rolling in trying to clean up the Internet.  The networks that harbor this type badness really need to evaluate the costs associated with dealing with these types of customers, and the costs associated with losing Internet connectivity from actions taken against them like this.  I am sure the bad guys always pay their bills on time, but if they can’t route to the Internet I am also equally sure they will be in the same line as the good guys asking for a full refund for the services you can no longer provide.  I would also venture to say it would be more cost effective to lose a few bad customers than it would be to take a network outage with the associated bad reputation I am sure you will be labeled with.

SpamBot activities from AS29073 seen at sudosecure.net

Seventeen unique IP addresses originating from this network attempted to post 1965 spam messages since I started tracking spam with my comment spam tracker.  These IPs have been around for a while as you can see from the following table:

Note: Longevity is the number of days between the first seen date and the last seen date and not a true depiction of how long these IPs have been doing this.

Ecatel Network’s Autonomous system (AS) number is AS29073.  This AS number made up ~68% off all comment spam attempts being conducted against this blog.  Obviously the people running the actual SpamBots are not scared of being loud or standing out in a crowd.  Take a look at AS29073 vs All other AS SpamBot networks in my comment spam tracker database.

The comment spam messages being spewed out by these SpamBots varied, but I did find some interesting trends.  Seven of these IPs were either posting blank messages or garbage messages consisting of seemingly bogus domain names made of of seemingly random text strings.  Here is an example posting from my database:

Here are the 7 IPs posting these types of messages:

• 200.63.42.136
• 94.102.60.151
• 94.102.60.152
• 94.102.60.153
• 94.102.60.182
• 94.102.60.43
• 94.102.60.77

I am not exactly sure why these SpamBots would be posting such random messages, but I do have a few theories.  My guess is that these few IPs are probing SpamBots that crawl the Internet looking for Blogs, Forums, or any other website that has comment posting capabilities.  Once these probing SpamBots receive a good server response demonstrating that they are capable of posting spam to a website they most likely log the website.  These logs are then used to feed URLs to SpamBots that carry the real spam messages and badness associated with them.  Let me explain why I think this is a technique used by these spammers.  Most websites will block IPs or subscribe to SpamBot tracking databases to create these filters.  If a the SpamBot operator sends out these very loud and aggressive probing SpamBots to do the dirty work it will be these IPs that get added to the ACLs.  This will then allow the real SpamBot to operate in a more effective manner only spamming the websites that have been identified as being susceptible to spam postings.  This technique aids in keeping the real SpamBot from being placed in ACLs and Blacklists.  This also allows the SpamBot operators to accurately predict how many spam messages can be posted at any given time by their SpamBots and also aids in advertising these capabilities to the organizations that buy SpamBot time.  SpamBot operators are businessmen too, so they try to get the most out of their efforts.  Again this is just my theory and I have no real evidence that this is the actual technique being utilized here.

The next set of 3 IPs spammed pharmaceutical type messages leading to wordpress 2.5.1 templates containing pharmaceutical messages and information spam as well.  Here is a sample from one of the spam messages:

Here is a list of the 3 IPs posting similar messages:

• 200.63.42.141
• 94.102.49.14
• 94.102.60.127

The wordpress templates house some obfusticated JavaScript used to redirect the user to another website.  There is some interesting code used to ensure visitors are not being lead to this site via search engine results.  Here is the interesting portion of the code:

Basically the author of this JavaScript is checking to see if any of the major search engines is in the referrer string or if the visitor does not have a referrer string set.  If either of these conditions are true the value of “gogo” will remain false and the visitor will be presented with the “404 page not found” page.  If these conditions are false the visitor is redirected in this case to abapharm.net with a few variables being passed in the URL.  The last three messages posted from these SpamBot IPs redirected to the following domain names:

• bestcasinogroup.com
• abapharm.net
• asiatradefinance.com

These domains seem to be rotated on a regular basis and lead to either pharmaceutical websites or pay per click search redirecting.  The pharmaceutical site I was redirected to during this research was “trustedtabletsworld.com”.  Nothing real interesting there, but the pay per click search redirection sites proved to be a little more interesting.  All of the pay per click hijacking sites we redirecting through one IP:

• 64.111.196.117

A quick google search for this IP lead me to an outstanding article documenting this type of tunneling called “Double-Funnel” by a few Microsoft Security Researchers back in March of 2007.  I am not going to go into the details of how this “Double-Funnel” redirecting tunneling spam stuff works, as this article does a very good job of describing this technique and has some really interesting statistics that I would recommend reading: Spam Double-Funnel: Connecting Web Spammers with Advertisers.  That was the interesting part!

The last set of SpamBot IPs were posting porn spam messages which lead to more of this Double-Funnel pay per click search redirecting.  I noticed that this set of SpamBot IP addresses all started off with the initial JavaScript redirection pointing to “xxx.whatsdirect.cn”, which then again redirected to the actual pay per click tunneling server/site.  These two SpamBot IPs (94.102.60.166, and 94.102.60.162) had errors in the initial spam message links pointing to “xxx.whatsdirect.com” instead of “xxx.whatsdirect.cn”, so if your the paying spam customer utilizing this SpamBot provider to propagate your garbage over the Internet you may want to make sure you get a discount next time as this typo most likely caused you to lose some money.

Here is a chart to demonstrate how active the individual SpamBots are when compared to one another:

While researching the Ecatel Network (AS29073) originating SpamBots I ran across several forum posts, blog posts, and websites complaining about these IP address ranges.  I even found that several of the well know Spam Blacklists had some of these subnets completely blocked.  The Spamhaus project has some interesting listings for the Ecatel Network in which connections with Russian Malware, ROKSO Spammers, and even the recent Mac OS X Trojan DNSChanger are documented.  Here is the Spamhaus Report and Jose Nazzario’s blog post at Arbor documenting the new Mac Trojan.  Here is a link to my SpamBot Comment spam Tracker sorting out the AS29073 network which will be automatically updated as Ecatel SpamBots continue to hit this blog.

As always if you have any questons or comments regarding my postings feel free to post a comment or contact me via email.

With all the talk over the recent Adobe CVE-2008-2992 vulnerability being exploited in the wild, I thought it would be a good time to document how I go about analyzing PDF files and shellcode.  Before I get into how I go about doing this type of analysis I would like to thank all the contributors to MalwareDomainList.com, as they supplied me with several malicious PDF files and links to malicious PDF files.  I should also note that PDF file analysis is a new subject for me, and I have spent the last few days really diving into the what exactly makes up a PDF file, and the additional functionalities made available by Adobe for PDF files.

The very first thing I do is take a look at the PDF file using either “less” or “more” to display the contents of the PDF file out to the terminal windows just to see if I can spot anything out of the ordinary.  The stream sections in a PDF file can be compressed, and will usually show up looking something like this if they are:

To decompress the stream data and clean up the formating in the PDF file I use a tool called pdftk, and decompress the file using the following command:

pdftk bad.pdf output bad_dumped.pdf uncompress

This command takes the “bad.pdf” file as input and outputs it to “bad_dumped.pdf” while decompressing it.  The really cool thing about the uncompress argument is that you really don’t need to know whether the PDF file is compressed or not, as it will not hurt anything or error out if it isn’t.  So as a rule of thumb I usually just provide the uncompress argument.  pdftk will also attempt format the PDF file making it easier to read using a text editor or the “less” command.  Taking a look at the bad_dumped.pdf file now using the “less” command we can see the compressed stream was really obfusticated JavaScript set to run when the PDF is opened.

To extract the obfusticated JavaScript I simply highlight it, copy and paste it into a text editor, vi in my case.  To deobfusticate the JavaScript I normally use SpiderMonkey or Malzilla.  This time I choose to utilize SpiderMonkey and simply replaced the “eval” calls with “print” calls, and after several iterations the obfusticated code was deofusticated.  The two significant portions of the deofusticated code are:

As you have probably figured out already the first image demonstrates this is one of the exploits currently targeting the Adobe  CVE-2008-2992 vulnerability, and the second image is the shellcode being passed into the util.printf function.  Now to take a look at the shellcode.

To extract the shellcode I simply highlight it, copy and paste it into a text editor for manipulation.  I prefer to use vi, so to clean up the shellcode I normally use regular expressions and substitutions.  To clean up this particular instance I simply executed these two commands in vi:

:%s/[\"+]//g
:%j!

The first regex simply removes all the “ and + characters.  The second simply joins all the lines together to make one long string of text.  This resulted in the shellcode now looking like this:

Now there are several different ways to analyze shellcode, but I tend to use just two.  The first way is some simple perl-fu that simply outputs the character representation of the shellcode.  The perl-fu part I got from an ISC SANS diary entry made by Daniel Wesemann.  Here is the command I execute:

cat shellcode.file | perl -pe ’s/\%u(..)(..)/chr(hex($2)).chr(hex($1))/ge’

In this case it does not work and displays the following:

Since this post is focused more on the steps I use to analysis PDF files and shellcode than this particular exploit attempt, here is an example of this technique actually working.  First the shellcode extracted from another PDF and rendered in the same JavaScript manner:

Executing the exact same command string as before:

cat shellcode.file2 | perl -pe ’s/\%u(..)(..)/chr(hex($2)).chr(hex($1))/ge’

Results in this:

As you can see the shellcode is simple in that it downloads a file into the windows system directory via urlmon and executes it.

The second method I use to analyze shellcode is with the libemu library and test application sctest.  Libemu is a library providing basic x86 emulation and sctest is part of it’s test suite.  sctest will not work in all cases, but you can extend it’s functionality by writing your own test application using the libemu library.

The first thing we need to do is parse the JavaScript encoded shellcode and write it to a file.  We can do this using the same perl-fu from above like this:

cat shellcode.file | perl -pe ’s/\%u(..)(..)/chr(hex($2)).chr(hex($1))/ge’  > shellcode.out

As you can probably see we are simply redirecting the output to a file instead of to the console window.  To verify this step worked you can compare the newly created file using a tool called hexdump.  Simply comparing the output from the following two commands will verify this:

hexdump -C shellcode.out

cat shellcode.file | perl -pe ’s/\%u(..)(..)/chr(hex($2)).chr(hex($1))/ge’  | hexdump -C

These two commands should result in the exact same output and look something like this:

The reason we can not simply just highlight, copy and paste the output from the perl-fu command above from the console window and then paste it into a text file is because the console character set can not display the full range of characters correctly resulting in “???” being displayed.  This is not the case when you redirect to a file as the characters don’t have to be interrupted and displayed to the console.  If you don’t believe me simply cat out the shellcode.out file and compare it to what it looks like when you open it in a text editor like vi.

Now that we have dumped the shellcode into a file we can pass it into sctest via a stdin redirection for analysis.  Here is the command I use:

sctest -Ss 100000 < shellcode.out

This results in the following output:

Looking at the output we can clearly see a url, which you can with a fair amount of confidence conclude that this is the url used in droping a binary using something like urlmon as we saw before.   There are plenty of more in-depth procedures in analyzing PDFs and shellcode, but I have found the procedures I explained in this post to work on about 90% of all the PDF files and shellcode I have looked at in the past.

This pretty much concludes my post on how to analysis a PDF file and JavaScript shellcode. The following are commands and links you may find useful in expanding the analysis procedures above.

PDF Related:

The following command will output PDF document Metadata, Bookmarks and Page Labels:

pdftk bad.pdf data_dump output

PDF document metadata can be very useful in finding out information about the author of the pdf document, date created, and modified dates.  Speaking of gathering information on the author and using metadata to investigate a pdf document I found the article “Shoulder Surfing a Malicious PDF Author” by Didier Stevens to be an outstanding example of what can be learned from this data.  Didier has published a pdf parsing tool written in python called pdf-parser.py, which looks to be very promising in analyzing pdf files.  I just started playing with the tool today, so I can’t really elaborate on it’s functionalities and usability, but I can say that only after a few minutes I was able to extract the same data as I did with the pdftk tool.

JavaScript Related:
Malzilla 1.2.0 was just recently released and Bobby has kindly added several new features and some documentation in the zip file.  Malzilla can be a time savor for anyone that has to deobfusticate JavaScript on a regular basis and can handle lots of obfusticated code with very little JavaScript knowledge required.  I would definitely recommend this tool to anyone wanting to get into deobfusticating JavaScript.  Another really cool option found in Malzilla is the shellcode emulator, which is a wrapper for the sctest libemu test tool.

Shellcode Related
Another tool written by Didier that I find useful is for analyzing shellcode is XORSearch.  It’s basically a small light weight application that will try to brute force shellcode that has been XORed, which is very common.  A little hint to any Mac OS X users out there, to compile XORSearch you have to remove the #include<malloc.h>  from the header, as it is depreciated and not installed.

As always if you have any questions or comments regarding this post feel free to hit me up anytime, I always enjoy hearing from someone that actually read my post. 

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.