Aside from all of the foregoing, there are several further guidelines a malware analyst should keep in mind when looking to assign a name to an entirely new piece of malware (i.e. one that is not a variant of an existing family). For example, none of the identifiers that have specified values should be given any other value. Should this seem necessary, consider very carefully what you are doing and discuss the issue with several other experienced malware researchers. History shows it is very easy to make poor choices, requiring you to turn around later and rename malware. If there a perceived need to devise, say, a new platform name, that is driven by something ‘exciting and new’ that your employer is likely to make a press release about, getting the naming right is even more important, as there are people in the industry who delight in lampooning ill-conceived and just plain wrong naming choices (perhaps even using them as examples in papers like this). Avoiding having such people ‘rain on your parade’ can be achieved by the simple expedient of carefully considering the options open to you before your employer’s PR department puts pen to paper…

A good example of a badly chosen platform name is SWF. It was chosen without consulting the rest of the AV community by a vendor who was sent the first virus known to ‘infect’ SWF files. That developer promptly created a new, but grossly incorrect platform name then made a press release publicizing this new platform name. This is also a good example of ignoring the usual approach of naming malware platforms after the actual executable or interpreter platform needed to run the code and taking the easier route of naming a platform after a file format that is involved. So-called ‘SWF/LFM.926’ is actually a multi-component virus whose only infective code is in a DOS COM file. LFM.926 also has active ActionScript code, which is stored in .SWF files, required to close the infection cycle. ActionScript is a component part of an SWF player and is not present in all SWF players. This alone, obvious from the fact that LFM.926 only worked when infected .SWF files were opened in the full version of the player software or the ‘Director’ player, but not in the web browser plug-in for playing SWF files, should have alerted the analysts concerned that ‘SWF interpreter’ was not the actual platform here. The virus’ FSMN is thus ‘virus://{DOS,ActnS}/LFM.926.A’. As the DOS platform is not usually reported to users, vendors currently using ‘SWF/LFM.926’ should adopt either ‘LFM.926’ as the name reported for both components, or ‘LFM.926’ for the infective .COM component and ‘ActnS/LFM.926’ for the ‘dropper’ component transported inside SWF files.

This mess would easily have been avoided had the analysts concerned discussed the issue of minting a new platform name with other researchers outside their own labs. As bad naming habits have a nature of being self-sustaining, and ‘fixed’ naming components such as platform names have to be widely agreed across many developers, engaging in such cross-vendor discussions is a sign of healthy naming practice.

Another thing to consider while devising new identifiers, be it at the family or platform level, is that the values of all ‘fixed’ identifiers are forbidden from use as a value in any other name component. Hopefully this is obvious – who would be silly enough to suggest, say, virus://Win32/Trojan.1234.A as a name for a new virus? Unfortunately, while that may be ‘obvious’, many variations on it are not. For example, you should also avoid using any other likely future virusable platform name as an identifier. Thus, just because there is not currently (when this was written) any 64-bit Windows malware does not mean ‘Win64’ is a good identifier to use as a new family name. In similar vein, a lot of common computer-related terms make poor identifiers – terms such as ‘disk’, ‘hard drive’, ‘network’, ‘printer’, ‘floppy’, ‘CD’, and on and on and on make incredibly poor if not outright stupid names. The original author’s long-time favourite in this class of poor names is ‘VBS/Network’ — a commonly employed misnoner for the virus://VBS/Netlog family. Of course, several vendors were not content that ‘VBS/Network’ was already a poor example of malware naming, so had their scanners report it as ‘VBS/Network.worm’.

Other ‘problem’ terms to avoid, or at least consider very carefully, include things like ‘unknown’, ‘new’, ‘copy’, ‘replicate’, ‘infect’. For example, recently a remote access Trojan whose writer calls it ‘The Infector’ was actually given the family name ‘Infector’ by some AV labs. One really has to wonder what is running through someone’s mind when ascribing a name that technically expands to trojan://Win32/Infector.A and is reported by their scanner as ‘Troj/Infector’ or ‘Backdoor.Infector’ — is it a Trojan or a virus?

« MultiValueIdentifier · Naming scheme · NamingConclusions »