Working back to the beginning of the name now, from whence we will consider all the remaining name components, we shall start with the malware type. This simply indicates whether the malware in question is a virus, a Trojan or various other agreed classes of malware. For now, the accepted values of the malware type identifier are ‘virus’, ‘trojan’, ‘dropper’, ‘intended’, ‘kit’ and ‘garbage’.
Of particular note is that ‘worm’ and variations on it are not a recognized malware type. For now it is agreed that although a sufficiently precise differentiation between worms and viruses does not exist, it is sufficient to classify everything that some researchers consider to be worms in the ‘virus’ malware type category. Vendors deeply aggrieved by this may consider supporting the new ‘vendor-specific comment’ feature to handle this by having their products add ‘!Worm’, or whatever takes their fancy, at the end of the official name when reporting detections (see the relevant section below).
For the purposes of this document, it is hopefully not necessary to define what a ‘virus’ or a ‘Trojan’ is, but a few words are probably in order to explain the other categories. A ‘dropper’ is a program that is itself not any other type of malware (although some consider ‘Trojan’ a sufficient category) that is designed to ‘drop’ or ‘install’ or otherwise ‘deposit’ or leave behind itself one or more copies of one or more other pieces of malware. The name that follows the ‘dropper’ malware type is usually the same as the name of another piece of malware — the one dropped by this dropper. The naming scheme has currently not been extended to deal with so-called ‘multi-droppers’ which can deliver more than one piece of malware and have become quite common of late. It may be that droppers of all kinds (and thus multi-droppers) should be handled within the ‘Trojan’ malware type. This is an issue that needs further discussion and may not be resolved for some time to come. Depending on how naming hierarchies work in individual products, it may be best to not use the dropper malware type and class all droppers as Trojans until these issues are settled and better naming guidelines agreed. Finally, although researchers sometimes make a technical distinction between droppers and injectors, the latter are so rare as to be classified as droppers for the purpose of malware type identifiers.
A piece of malware that was ‘clearly supposed to be a virus’ may be classified as ‘intended’, though it need not be. As intended viruses often pose no threat whatsoever, they are often ignored by scanners. However, as a general attitude to intended viruses, this can be problematic. Depending on the intended virus type and the nature of the code flaw that prevents the recursive replication necessary for the program to be considered a virus, an intended virus can still be ‘malicious’. Sometimes just the infection routines are flawed and the rest of the intended virus’ code works as designed. Thus, an intended virus whose payload still works and triggers under the intended conditions may be a considered a perfectly functional Trojan. However, general practice in such cases is to classify it as an intended virus, especially if it is clearly a variant of an existing virus family, and this habit should be continued. Note that flawed examples of no other malware types are classified as ‘intended://’ — this is really only a shorthand for ‘intended virus’ and there is no intention to extend this malware type to cover other intendeds.
The ‘kit’ malware type designation is used for programs that are designed to ‘generate’ other malware. The difference between kits and droppers is that a kit can usually generate variants of a family of malware, whereas a dropper produces a small number of samples of specific (and possibly unrelated) forms. Kits typically generate their output algorithmically from smaller code components while droppers tend to carry complete copies of the entire thing (or things) that they ‘produce’ inside their program bodies (or they may obtain them across a network). Kits often, but do not necessarily, produce source code or code for interpreted environments, rather than producing binary samples. Although somewhat contentious, it is generally agreed that the family name of a kit should also be used as the family name of code produced by the kit. Thus, kit://Win32/VBSWG.A is one of the versions of the ‘VBS worm generator’ kits and viruses produced by this kit and its many variants are named virus://VBS/VBSWG.A, intended://VBS/VBSWG.B (many versions of the VBSWG kit produce very buggy code!), VBSWG.C, …, virus://VBS/VBSWG.J@mm and so on. Note that no effort was made to tie the generated code to the kit version here, as doing so was deemed impractical in this case (some later versions of the kit place kit version identifying comments in the VBS code they output, but this can easily be removed or changed yet we still consider the code to be generated by a member of this kit family). However, in the case of kit://W97M/VMPCK1.A, kit://W97M/VMPCK2.A, etc, it is possible to fairly reliably differentiate the viruses produced by each version of the kit. Viruses produced by these kits are thus named virus://W97M/VMPCK1.A, virus://W97M/VMPCK1.B, VMPCK1.C, etc and virus://W97M/VMPCK2.A, virus://W97M/VMPCK2.B, VMPCK2.C, etc. Note that the kit’s version is reflected in the family name. This is a rare exception to the general recommendation to not use numbers in family name identifiers and if numbers are used thus an effort should be made to keep the numeric part of the family name short relative to the alphabetic part of the name. This type of usage should be reserved specifically for kits where analysis shows that reliably determining the kit version that produced some generated code is possible — this is rare.
Truly execrable code that would normally never grace the inside of a virus analyst’s debugger may be classified as ‘garbage’. This is usually reserved for particularly flawed examples of intendeds – code in files that are so corrupted that they cannot be successfully loaded and executed by their host platform, grievously flawed code that bears insufficient resemblance to any known working family as to otherwise be considered a new family, etc, etc. Normally such ‘garbage’ code is resigned to the scrap heap of malware research history and, quite correctly, ignored. Unfortunately, some circulates for years in the many low-quality, high-volume ‘virus collections’ available on the web and from some underground sources, and smatterings can even be found – years after they should have been removed — in the ‘virus’ collections of some respectable testers and developers. Thus, the ‘garbage’ classification allows us to name things that really are not malware and really should not hold our attention, but that sloppy research from others or sloppy testing practice necessitates we discuss and occasionally even name. Also, it is not uncommon for research labs to have ‘trashbin’ applications (or special DAT/DEF/etc files purely for lab use) that identify much of this material to ease the processing of large collections. Although this detection information is never shipped to users, it is convenient to have some classification for all the ‘junk’ detected thus and again, the garbage malware type may be a convenient choice. Note however, that although we provide a mechanism for naming such ‘garbage samples’, use of this malware type in shipping product detection is heavily discouraged. Do not classify, name and ship detection of every piece of rubbish code sent to tech support by your users. The use of the garbage ‘malware type’ is reserved for those especially unfortunate cases where non-detection of a non-malware ‘sample’ results in (persistent) downgrading of a product in a test or persistent support calls of the ‘why don’t you detect’ nature. The hope is that selective use of this ‘malware type’ may embarrass others to reduce the sloppiness of their work.
Finally, note that one piece of malware may exhibit more than one of the foregoing types of behaviour. In such cases the ‘worst’ type is used to classify the malware. The hierarchy is, from worst to ‘least bad’: virus, dropper, intended, trojan, kit, garbage.