Signature Updates & Threat Database

It has been a very active month for those that pay attention to the signatures as they are released, you might have noticed a sudden spike about two weeks ago in signatures from 2,500’ish to the now 4,425 mark. The vast majority of these signatures were put up in MD5 format as a great many are variants of “known” malware and were extracted through processing historical threat data for the last 90 days, sorted by unique hashes, from I also did some leg work in my processing scripts which has allowed them to handle base64 and gzip decoding of POST payloads from IPS data which is generating a marked increase in new malware and known malware variants. Together, this has added 1806 MD5 and 31 HEX signatures in the last 45 days bringing us to the current mark of 4425 (2808 MD5 / 1617 HEX) total signatures.

In addition to the above, the daily processing scripts have been rewritten and combined into a single task on the processing server, this has brought together what was previously 9 different scripts into a single, streamlined and much more efficient task. The reason that things got to the point where there was 9 different scripts to update various elements of the back end processing server is that the LMD project developed very fluidly over the last year, meaning that every time I had a new idea or added a new feature, I in turn created a new script to support the idea/feature — over time this naturally was not sustainable and now what we have is exactly that — sustainable.

For those interested, here is the output report generated and sent to my inbox at the end of each daily malware update task:

started daily malware update tasks at 2010-09-13 00:09:35
running daily malware fetch... finished in 710s
running daily ftp malware fetch... finished in 6s
regenerating signatures from daily malware HEX hits... finished in 95s
propagating signature files... finished in 2s
generating sqlfeed data... finished in 88s
running mysql inserts for sqlfeed on praxis... finished in 42s
syncing & updating malware source data (master-urls.dat).... finished in 27s
syncing & updating irc c&c nets... finished in 15s
rebuilding maldetect-current... finished in 3s
pushing maldetect-current and signatures to web... finished in 4s
completed daily malware update tasks at 2010-09-13 00:26:05 (990s)
processed 156 malware url's
retrieved 40 malware files
extracted and hashed 16 new signatures
extracted 59 new irc c&c networks
queued 24 unknown files for review

An important part to streamlining the daily update tasks was also in rewriting some of the basic processing scripts to better log and store information on malware sources, such information includes date, source url, file md5, sig name, top level domain, online state, ip, asn, netowner and more. All malware is also now processed through an IRC extraction script that checks for irc server details in malware files and adds it to a irc command & control list with details such as date, source file md5, source file sig name, irc server, irc port, irc chan, online state, ip, asn, netowner and more. The “online state” fields in both the malware source and IRC c&c databases perform active checks, for the malware source this is simply verifies a URL is still active and/or domain still resolves, for the IRC c&c database this is a bot that manually connects to the irc network and verifies the network and channels are online & populated. All irc users, host masks and a sampling period of channel activity is also recorded from each active IRC c&c network, this information at this time is not included in the database as allot of it requires sanitizing as many IRC c&c networks dont mask connecting hosts and the channel activity reveals exceedingly sensitive information about actively vulnerable web sites and servers, this is something I am working on adding but its a difficult task so it will take some time. The malware signatures database has also been populated but requires a little more work, mainly adding meta data to describe each signature in a format that is longer than the single-word descriptions included in the signature naming scheme.

Together, the malware signature database, the malware source database and the IRC C&C networks database will all tie together into a single threat portal to be released in the next couple of weeks (I hope) allowing correlation between data in all 3 databases seamlessly. For example one could query all malware sourced from a specific IP, ASN or Netowner or you could find all the source URL’s for a specific malwares MD5 signature, or you could query the signature database to find more information on a specific signature, etc… there are a great many options that will be available for reviewing, cross referencing and exporting data from the databases.

These databases are all already completed, active and receiving updates, all that is left for me to do is create the front end that will find its home on The signature database, as expected, has 4,526 entries, the malware source database has 7,859 entries and the IRC C&C database has 386 entries. There is currently 511 files pending review in the malware queue, there has been 3,592 malware files reviewed in the last 45 days, of those 1,806 were unique files and the 511 files in queue for review represent files that could not be auto-hashed against a known threat or variant threat from HEX pattern matches.

The biggest pitfall of all these changes has been the explosion in the review queue that I must tend with daily, it has started to back up on me as I am in the middle of moving from Michigan to Montreal but as soon as I am done with my move in a couple of weeks, I plan to get that queue under control and work on some more back end scripts to help streamline its processing slightly.

Well that’s it for now, keep an eye out for details to come on the site, its going to be exciting 🙂

Understanding Signatures

The signature naming scheme for LMD is a little confusing and something I’ve received more than a few questions about, more so about what the *.unclassed signatures mean. The naming scheme (to me) is straight forward and breaks down as follows:


The ‘SIG_FORMAT’ is either HEX or MD5 reflecting the internal format of the signature, the ‘lang/vector’ is the language or attack vector of the malware, ‘type’ is a short descriptive field for what the malware does (i.e: ircbot, mailer, injection etc…), ‘name’ is a short descriptive name unique to the piece of malware and ‘ID#’ is the internal signature ID number.

What some people appear confused about is signatures such as ‘{HEX}base64.inject.unclassed.7’ that use the term “unclassed” for the name field. Essentially, signatures that are unclassed represent a group of malware that is not necessarily unique from each other but that follows the same attack vector, such as base64 encoded scripts; there are hundreds of these scripts and in encoded form it doesn’t really matter what they do, we are detecting the encoded format not the decoded, so they get lumped together. In other instances, I will throw some malware into an unclassed group when it is very new and I have not had time yet for processing it into its own classification, for example the web.malware.unclassed is a dumping ground for allot of malware that is newly submitted, which I have reviewed and confirmed IS MALWARE but have not yet classified it or determined if it is a variant of an existing malware classification.

It needs to be understood that the processing of malware is mostly a manual task, though there are some elements of it that are automated, the actual review of each malware file is done by hand to remove the chance of false positives — keeping LMD accurate and reliable. As such, not all malware makes it into a classification group right away, the important part is that malware is reviewed, verified and signatures generated for it in a timely fashion. I process malware daily from the network edge IPS system at work, from user submitted files and from various malware news groups / web sites and the priority is getting the signatures up for in the wild threats. The signature name/classification serves informative purposes, yes it is important but not as important as the actual verification and signature generation.

Signature Updates: Month In Review

Since I will be busy this coming week with other priorities, I am posting an early month in review blog on signature updates.

In the last 3 weeks we have not seen a whole lot of action on in-the-wild malware, most of what is propagating at the moment are variants of already detected content. That is however not to say there has not been new signatures extracted, allot of this months signatures have come from account level compromises on vulnerable e107, wordpress and joomla installations along with user submissions. There is not a whole lot of ground breaking malware threats, it is more of the usual such as mass mailers, perl/php command shells, irc bots and php socket flooding tools.

In total, the 3 weeks ending Sat July 24th, there has been 128 new signatures in 54 classifications with 65 signatures being added in the last 7 days. This brings us to a total of 2,588 (1002 MD5 / 1586 HEX) signatures, an increase of 117 signatures over the last blog post on signature updates. For those paying attention, there is a discrepancy of -11 signatures between the 128 new signatures and the +117 change since the last update, this is because there has also been 11 signatures removed for poor performance/false positives.

As always new signatures are automatically updated daily or can be manually updated with the -u|–update command line options. The 128 new signatures fall into the following classification groups:

base64.inject.unclassed    exp.linux.unclassed
perl.cmdshell.n0va         perl.ircbot.Arabhack
perl.ircbot.BaMbY          perl.ircbot.devil
perl.ircbot.fx29           perl.ircbot.genol
perl.ircbot.karawan        perl.ircbot.oldwolf
perl.ircbot.plasa          perl.ircbot.putr4XtReme
perl.ircbot.rafflesia      perl.ircbot.UberCracker
php.cmdshell.antichat      php.cmdshell.avi
php.cmdshell.aZRaiL        php.cmdshell.c100
php.cmdshell.DxShell       php.cmdshell.h4ntu
php.cmdshell.hackru        php.cmdshell.KAdot
php.cmdshell.lama          php.cmdshell.Macker
php.cmdshell.mic22         php.cmdshell.myshell
php.cmdshell.NCC           php.cmdshell.r3v3ng4ns
php.cmdshell.r57           php.cmdshell.s72
php.cmdshell.Safe0ver      php.cmdshell.SimShell
php.cmdshell.SRCrew        php.cmdshell.Storm7
php.cmdshell.unclassed     php.cmdshell.winx
php.cmdshell.wls           php.cmdshell.xakep
php.cmdshell.ZaCo          php.cpcrack.Aria
php.exe.globals            php.include.remote
php.ircbot.NewLive         php.mailer.DALLAS
php.mailer.unclassed       php.mailer.YoUngEST
php.nested.base64          php.pktflood.unclassed
php.rshell.0wned           web.malware.unclassed

Projects: The personal costs

When you do open source development, especially as an independent developer, there is a constant struggle that must be balanced between that of work and personal obligations. As any open source developer will tell you, 99% of the time, the projects we develop fall strictly into the realm of personal time, no matter how much they may apply to our work field. It is difficult to justify the time that is required in maintaining one let alone a series of active projects when you also work a full-time job while trying to have some semblance of a life.

So, when you are faced with something you are truly passionate about, that constantly rubs up against a barrier that is your job and ever limited personal time, you start to question or more importantly look for change, in how you manage that passion. That is what I am currently faced with, the projects at the moment consume an increasing amount of my personal time on evenings and weekends — which has been that way for a long time — but recently, priorities and life have changed such that I can no longer allow that to be the case. I have managed these projects for almost 8 years, which I would not change for anything, I have and still do love working on them. However, the time has come that I need to start setting measurable, tangible, goals on the cost of maintaining these projects which will allow me, permitting donations or sponsors, to create dedicated time within my work week to manage the projects with focus strictly on them.

That said, I am seeking about $1,000 USD per month in donations or month-to-month sponsorships (which all sponsors will be duly pimped out on the site with a widget and on each project page); at the moment donations only average about $50-200 per month, it varies widely month-to-month towards the lower end. How did I come up with this amount? well it is simply a goal, a target, that reflects the amount of time I spend on the projects per-month (about 60hrs) and what I believe would allow me to take time out of other areas of my life to dedicate consistently that amount of time every month. This would make continuing to work on the projects much easier on me personally, easier on those in my life and easier on me occupationally/financially.

There is a donation tracker widget now on the right sidebar of the site, it simply uses paypal as the checkout process, the tracker will reset every 30 days. If you are interested in becoming a regular contributor or sponsor, please email me at ryan at to discuss it. Thank you in advance for your understanding. In Numbers

Yup, nothing to see here except numbers…

2,018: Downloads of the newest project, Linux Malware Detect, month to date.
2,294: Signatures for Linux Malware Detect.
6,207: Downloads for all projects for the month to date.
14,176: Google results with link backs to or related domains (i.e:, etc..).
30,061: Active APF installations relative to unique IP’s fetching the reserved.networks file daily.
70,826: Project downloads for the last 12 months, May 2009 – April 2010.
133,931: Total visitor session to, month to date.
258,154: The number of web sites protected by APF (passed unique install IP’s to
1,231,604: Total hits to, month to date.