Interpreting Antivirus Detection Names

Malware Analysis
1

Identification vs Detection

The primary goal of antivirus software today is detection and not identification of malware. Detection means that the AV product makes the decision that a file is malicious or potentially unwanted. Identification means telling you which kind of malware or even malware family was found on the system.

The usual customer just wants their systems to be protected and doesn’t care too much about the kind of malware that was found by the AV product. Furthermore new threats appear in such numbers that automated signature creation is necessary to keep up with it. Automation is often not able to identify malware.
Both are contributing factors to focus on detection rather than identification.

Naming Conventions

In 1991 there was a committee at CARO that introduced a naming convention for viruses. A lot of security vendors use a similar convention to the CARO one, so it is worth looking into it. Please note that CARO’s naming convention was made with one specific malware type (viruses) in mind. The convention is not applicable 1 to 1 for malware but influenced most of the detection names for today’s AV vendors.

Every antivirus vendor uses different conventions for their detection names, but they have usually the same components: Platform, Type, Name and Variant. Sometimes additional information is added.

Microsoft example:

Worm:Win32/Brontok.R@mm

(Note: @mm is here a subtype for massmailing worms)

Bitdefender example:

Gen:Variant.Dyzap.13

Avira example:

TR/Crypt.ZPACK.177986

ESET example:

Win32/Spy.Zbot.ABW 
 
The following sections cover each component.

Component: Platform

This may specify the operating system and architecture the malware runs on, e.g. Unix, Win32, Win64. But it may also specify the programming language the file was written in if this language is commonly interpreted or run in a virtual machine like Java. Sometimes umbrella platforms are used, e.g. the platform can be Generic (no platform specified) or Script (for any text-like file).

Examples:

  • PHP
  • Java
  • Powershell
  • Win64
  • Win32
  • MSIL
  • Generic
  • Script

Component: Malware Type

This component characterises what the malware does or how it behaves. Examples are:
  • Malware
  • Trojan
  • Downloader
  • Dropper
  • Spy
  • Stealer
  • Backdoor
  • Virus
  • Worm
  • Application
  • Adware
  • PUP
  • PUA

The last four examples are not malware, but so called potentially unwanted software. The difference to malware is that these are legal programs, but often not useful, annoying, or a risk to the user’s computer.
Which programs belong to this category is sometimes subjective. But generally their usefulness is in no good relation to the harm, risk or annoyance they pose and most users, who have been informed about the disadvantages, will not want these programs.

One odd thing to note about malware types is that the term Trojan in detection names is mostly used in the sense of Malware instead of it’s actual meaning of a trojan horse (being a seemingly useful program that comes with malicious code). Malware and Trojan are often default values for any automatically created signatures. So both of them don’t tell you anything about the type of malware that is actually there.
Default type values for legal programmes (PUA/PUP) can be Application, PUP, PUA or may be noted by an additional description saying not a virus or potentially unwanted.

If a malware has several types the most severe and specific one is used.
E.g. a malware that is adware and a trojan will get the Trojan type because the Adware type is usually for legal programmes (PUP) and being a malicious programme (trojan) is more severe.
A malware that is a trojan and a virus should have the Virus type, because a virus is more severe.
A malware that is a trojan and a dropper will get the Dropper type, because it is more specific (keeping in mind that “trojan” isn’t used in the sense of a trojan horse here).

Component: Name

The name portion of the detection name can have one of the following meanings:
  1. Malware family name
  2. Umbrella term for
  • Malware type or behaviour (which is more specific than the Type portion of the detection name, e.g., “VBSRunner” for a program that executes a VBScript file)
  • File characteristic (“Small”, “Tiny”, “Packed”)
  • Programming Language (as addition to the platform, e.g, the platform might be “Script” and the umbrella term “Python”)
  • No meaning at all (default value)
    • Whether a Name is a malware family, an umbrella term or a default value depends on:
    • What the detection actually covers. E.g., the detection may not detect a malware family but a certain obfuscator or packer. An example is ESET’s Win32/Packed.Themida detection.
    • Whether the detection was created automatically or by a malware analyst. Automatic signatures are often created without knowledge of the malware family or type, thus, uses default names.
    • How much time the malware analyst puts into identification. If she does not spend any time on identification, she might just choose an umbrella name for a certain characteristic, e.g., Injector for a malware that injects itself into a process.
    • How significant the malware is. Malware that was written poorly and has not much impact will likely not even get a proper name. A default name or an umbrella name might be used instead, e.g., “Small” for a very small file.
    Because of that the malware name can tell you quite different things. It may tell you the malware family, it may tell you what the detection covers and how the detection was created, it may also tell you characteristics of the file.

    Here are some common names and their meaning:
    • Packed or otherwise obfuscated file: Packed, Kryptik, Injector, Inject, Crypt, Crypted, Obfus, Wurch
    • Executes another file: Starter, Launcher, Runner, VBSRunner, PowerShellRunner, …
    • Legitimate file was modified to contain malicious code: Patched
    • Default values for automated signatures: Agent, Artemis, Zusy, Razy, Kazy, Graftor, WisdomEyes, … (there are probably more)
    • Programming Languages: AutoIt, Python, Delf (for Delphi), VB …
    • Unspecified ransomware that encrypts files: Filecoder
    • Unspecified ransomware that locks the screen: Winlock, Screenlock, Locker, LockScreen
    • Stealer for Steam credentials: Stimilik, Steamilik, SteamSteal
    • Unspecified stealer: Thief, PassDumper, PWDump
    • File has Anti-VM techniques: AntiVM
    • File pretends to be something else: Microfake, FakeAV, FakeMS, FakeMozilla, …
    • Navigates to sites to generate clicks: Clicker, Clickbot
    • File with malicious code that doesn’t or shouldn’t run: Corrupt, Malformed
    • Has risk of being malicious or makes your system vulnerable: Riskware, Unsafe
    Component: Variant

    Malware often evolves over time. Either because the author(s) adds more functionality, changes parts of its code to evade detection, or because the malware itself generates different versions while spreading. These modified versions become variants of the original malware. All variants of a malware belong to a malware family.

    In case of detection names however, the variant is mostly just a counter for different detections and nothing else. This counter consists of numbers or letters or both. In automatically created signatures the variant portion may also be generated from the file itself like a hash.
    Sidenote: If the vendor uses letters for the variant they will take care to skip obscene combinations like fck or cnt.

    A detection in this sense is a blacklist entry, pattern, script or combination of properties used by the AV product to determine malicious files. The detection name in combination with the variant tells the AV vendor which detection or detection technology is behind the name. The AV vendor uses it to see how well certain detections work and solve any problems related to these detections.
    For this reason the variant in detection names is usually not interesting for anyone who is no employee of the respective AV vendor. The only thing you can sometimes estimate from the variant portion of the detection name is whether the detection was created automatically. This is likely the case if the variant portion is a high value, e.g., KBJAC instead of just one or two letters like in AC.

    Component: Additional Information

    Some vendors provide additional information for certain detections. E.g., they may apply a suffix or prefix that denotes if a file was detected generically or heuristically.
    The terms generic and heuristic tell something about how the decision for detecting the file was done. Both terms are covered in the sections below.

    Using Detection Names for Identification

    In general detection names are not reliable for identification of malware. Even if the name component identifies a certain malware family it might still be wrong. Security products are not tested for correct identification like they are for their detection rates. That means you can use detection names only to get a hint for what might be in a detected file, but further research and analysis is necessary to be sure.

    Some vendors are more reliable than others, though. ESET_NOD32, Microsoft and Kaspersky usually do a good job with identification.

    If you have a packed sample, it is adviseable to unpack it first and then get detection names for the unpacked sample. The detection names will be more reliable in that case.

    Keep in mind that different vendors may use different family names for the same malware family, and these are also different from the malware name that the malware developer used. It is common practice to not use the name that the malware author intended it to have. The only exception is ransomware because it shows its name to the victim and they shall be able to find information about it.
    E.g., the Remote Access Tool njRAT (as named by the malware developer) will have the family name Bladabindi by most security products. Connecting different family names the same family is only possible with (sometimes extensive and tedious) research.

    Default Values

    Default values in detection names differ for each vendor, they are usually created for automatically added entries; sometimes they might be added by malware analysts if they don’t want to think of a proper name. If you see a default name, you will know that the detection does not tell you anything about the malware’s nature.

    Typical default names are Agent or Generic (unless Generic means “generic detection”). The default malware type is mostly Trojan unless it is a legal program, then it is something like PUP or Application. The variant portion of the name has often a high value because these entries are generated in high numbers by automatic systems and each new entry gets a new variant.

    Here are some examples for detection names with default values:

    Trojan.Generic.KD.87847
    Trojan.Win32.Generic!BT
    Trojan ( 00071a9a1 )
    Artemis!5EAC6EABC66A
    Win.Trojan.Agent-691724
    Gen:Variant.Zusy.53898
    UnclassifiedMalware

    Artemis is a special case here because it is a specific default value for McAfee. This is only a default name if found by McAfee, otherwise it is more likely the Artemis backdoor malware family.
    Similar default names can be found for other vendors. E.g., WisdomEyes for Baidu and Zusy, Kazy and Razy for Bitdefender detections (Bitdefender’s engine is part of a lot of other vendors, so you will likely see Zusy and the like in other AV detections too).

    Default names tell you nothing about the nature of the malware.

    If you have a default name with a specific malware type and a relatively low variant counter, the detection was more likely created by a malware analyst, but seen as not important enough to make a special name for it. This is often the case for, e.g., macro trojan-downloaders or droppers other carriers of infections that are not sophisticated but change rapidly. These detections tell you about the nature of the malware but don’t identify it properly. The value of the malware variant is higher than usual, but not as high as it is for the automatic entries.

    Examples are:

    Win32/TrojanDownloader.Agent.RUT
    Trojan.Dropper.SF

    Heuristic and Generic Detections

    Generic detections cover all or a lot of different members of one malware family at once. If used in the true sense of the word, a generic detection will not cover more than one malware family. Generic detections are proper detections to identify malware, but they have a higher likelihood of being false positive.

    Heuristic detection methods base their decision on malicious looking behaviour or structure of the file by using a “rule of thumb”. The information of a file is gathered and then processed by specific rules. E.g. each item of information might be given a specific weight. If that the sum of all weighted items is above a certain threshold, the file is detected.
    That makes heuristic methods imperfect, but they potentially cover a lot of malware variants and malware families at once.

    Heuristic detection names might be created automatically. E.g., a file that downloads another file to temp and runs it might be classified as trojan-downloader without giving it a proper name. That way you can have a proper malware type (based on the behaviour) in combination with a default name. Heuristic detections are more likely false positives than other detections.

    Here are some examples for generic and heuristic detections:

    BehavesLike.Win32.Dropper.cc
    Gen:Backdoor.Heur.FU
    Win32.Trojan-Ransom.CryptoWall.D@gen
    Gen:Win32.Necurs
    Gen:Variant.Dyzap.13

    Note that the term “Generic” in a malware name can also just be a default value (e.g., for the platform) and may have nothing to do with generic detections.

    Riskware, Cracks, Hacking Tools

    Antivirus vendors do not care to put work into software that is used for illegal purposes. They will either not detect it, or detect it as Riskware, Crack, Keygen, Unsafe or Hacktool, regardless if the file is actually malicious in both cases (the aforementioned terms are either put as malware type or an umbrella name for the name component).

    So if you want to determine whether an illegal file or hacking tool is good or bad, you must be aware that AV detections won’t help much.
    Users of cracked software and game hacks submit such files in high numbers to AV vendors to get to know whether these files are safe to use. AV vendors will not even try to help them out.

    Same Detection Name but Different Vendors

    Often you will encounter samples that are detected by different vendors but with the same detection name. While some vendors have copied detections of others in the past, in most cases the same detection names occur because some AV products use engines of other vendors in addition to their own.

    Bitdefender’s engine is by far the most wide-spread, being used by at least 26 vendors of security products (at least 6 of those are on Virustotal). Take that into account while estimating the likelihood that you have a false positive.
    E.g., if you find a sample with a virustotal detection ratio of 6/55, but each of the 6 detections has the same name as Bitdefender, the likelihood of having a false positive is higher compared to having actually 6 different engines detecting one file as malicious.

    A list of which engines are used by which vendors is here: https://www.av-comparatives.org/av-vendors/

    Snowball Effect – Reporting False Positives Efficiently

    It is not a secret that AV vendors share samples and blacklist samples automatically based on the detection rates of other vendors. This in addition with the engine sharing of different vendors (see previous section) may cause a snowball effect; sometimes to the disadvantage of programs that are very prone to false positive detections. These are for example files from the demo scene, because they use packers and a lot of tricks in the file format to get tiny files; but also security tools which are used to fight malware, disinfect or monitor a system, because they may behave a lot like malware. Software vendors that like to protect their files too much from reverse engineering might also trigger the heuristic engines of certain AV vendors. Once a reputable AV company flags a file, the others will follow soon.

    In case of a false postive this snowball effect can also be used to your advantage. Imagine you develop a legit tool or a demo and it is detected by 20 AV vendors. All vendors give a possibility to submit files to them, but submitting your file 20 times is a pain, is it?

    My advise: Start with a report to Bitdefender, then Kaspersky, then wait for their responses.
    As mentioned above, Bitdefender sells their engine to other vendors. If a false positive is reported to Bitdefender, you will get rid of at least six other detections on Virustotal at once.
    Kaspersky is very reputable player and their engine is also used by several vendors. If they drop their detection it is much more likely that the automatic systems of the other vendors will drop theirs too or report the file as possible false positive.
    If that is still not enough to get rid of all false positives, submit the file to another reputable vendor. Then wait again for a reponse. Don’t bother with the small vendors.

    Article Link: http://struppigel.blogspot.com/2018/01/interpreting-antivirus-detection-names.html