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.

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.

I was recently introduced to UploadMalware.com, which is a site made up of several security professional volunteers. They actively accept your Malware binary submissions and submit them to several Antivirus companies to help in speeding up the process of identifying, classifying, and the development of Malware signatures, which may I say benefits everyone. You can find a list of vendors they work with here: Vendors. In support of what these volunteers are attempting to do I have created a small Perl script that will allow anyone to submit suspicious binaries to their site without having to use the web interface. I have included all of the options available to you via their web form. All options except for the binary file are optional when submitting binaries to them, but I would encourage you to provide as much information as possible. They also offer an IRC channel where many of these professionals can be found hanging out willing to talk with you about your submissions or anything else Malware and/or Security related. You can find their channel “#uploadmalware” on the WyldRyde IRC Network, or use their instant chat web client located on their website.

If you have a honeypot or harvest Malware, may I suggest using this script to automatically submit binaries by creating a cron job or writing a small wrapper script. Just a suggestion.

Here is a link to the script I created: uploadmalware_submit_pl. As always if you have any issues with this script or find any bugs feel free to contact me anytime.

After talking it over with a few colleagues and friends I have decided to release the script I utilize to extract the peer IP addresses and ports from the Storm Worm ini/config file, as I think it may benefit others. The current configuration file for the Storm Worm is “aromis.config” and it holds the IPs for bot peers the infected computer can communicate with. This will not be the entire list of IPs infected with the Storm Worm, as the Storm Worm breaks it’s bot networks up into small sub-network like structures. This is why it has been so hard for Security Professionals to combat the worm, and gather an accurate number of hosts infected with this worm.

Something to consider before using script is I can not guarantee it to work on new configuration files, as the authors of the Storm Worm could change this file at any given time. If they do decide to modify the configuration file structure I may or may not decide to update the script to reflect these changes. I think once you see how simple it is, you may just want to update it yourself. I am not a professional programmer nor a Perl guru, so if you find anything insane in the code I welcome your fixes and/or improvements.

With all that being said run it at your own risk as I provide no warranty! Well here you go: storm_config_decoder_pl. The output from this script is very simple “ip address:port” for example “192.168.0.1:1234″ with the last line of output telling you exactly how many unique ip addresses it was able to identify. Oh, I almost forgot to mention it can parse multiple files just use the “*” as a wildcard character or specify the files with a space between them. This option has been very useful to me in combining the configuration files from several different infections over a period of time such as the last 24 hours. Try it as you may get some intresting results

As always if you have any questions or comments regarding this post or script feel free to contact me at anytime at jeremy [at] sudosecure [dot] net. Enjoy!

Since my release of the ThreatExpert.com Perl script to aid in the batch processing of Malware binaries and automating the submission of these binaries for analysis I have written two more. One for the CWSandbox and one for Anubis. If you haven’t used either of these sandboxes for a quick analysis I would really recommend them as they can provide a very fast and detailed report for suspected Malware binaries using a combination of automated static analysis and behavioral analysis techniques. One of the major advantages in utilizing them is you won’t have to set up your own lab/sandnet to analysis suspicious binaries, and there is no risk of infecting your network during the analysis. Most of these sandboxes have established relationships with Antivirus companies to aid in the development of antivirus signatures through the sharing of submitted Malware binaries, so again I would encourage all of you to utilize them for the “greater good”.

With that being said, I tend to favor the CWSandbox due to the wealth of information they provide in their reports. They provide options to down load a pcap file of network activity during the execution of the binary, a cab file of the analysis, an xml report, or just browse the results in their easy to navigate web interface. The pcap files can be downloaded and used to aid in writing snort signatures to feed your IDS solution, which would then aid in identifying other computers on your network that could possibly be infected with the same Malware. The detailed report of system modifications can also be used to search out possible computers infected with this Malware without an IDS solution in place.

Well enough rambling, so here you go two more scripts that I hope you can find useful: cwsandbox_submit_pl and anubis_submit.pl.

As always I do not warranty these scripts in any shape or fashion and you assume all risk in running them. Although if you have any questions, bug reports, or comments feel free to shoot me an email at: jeremy [at] sudosecure [dot] net.

Over the weekend I was working on some long over due tasks that desperately needed my attention on my honeypot, and wrote a short Perl script to allow me to submit files to the ThreatExpert sandnet for analysis. It is a fairly simple script that will accept wildcards to submit several files or a specific file name to submit individual files. With a wrapper script or some simple modifications it could easily be modified to run via a cron job or in a never ending while loop to submit new files as they are seen by your honeypot. My version does this, but I didn’t want to realase that code just in case someone used it to cause a DOS attack on ThreatExpert by submiting hundreds of files without realizing what they were doing.

I can’t guarantee this script will run tomorrow, because if ThreatExpert decides to modify there web form submission structure this script will begin to fail. I don’t really see them doing this as they offer a free Windows GUI to do this same task and a modification would break that application as well.

Anyways you can get the script here: ThreatExpert Submit Script, just change the extension from “.txt” to “.pl”. Here are a few examples of how to run it:

submit the three specified files to ThreatExpert.com and receive an email report at my.email@notta.com
./threatExpert_submit.pl -e my.email@notta.com -f badFile1 badFile2 badFile3

submit the entire directory /malware to ThreatExpert and receive an email report at my.email@notta.com
./threatExpert_submit.pl -e my.email@notta.com -f /malware/*

submit all files that start with “bad” to ThreatExpert and receive an email at my.email@notta.com
./threatExpert_submit.pl -e my.email@notta.com -f bad*

If you have any issues running it or just have questions feel free to contact me at jeremy [at] sudosecure [dot] net anytime.