{
	"id": "311a8c51-25c8-4f85-bd27-64595b6e56d9",
	"created_at": "2026-04-10T03:21:05.870949Z",
	"updated_at": "2026-04-12T02:22:14.033597Z",
	"deleted_at": null,
	"sha1_hash": "a810e451e4553e884dca8ab1b33f1a61fc703c9b",
	"title": "Malware Naming Hell: Taming the mess of AV detection names",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 272926,
	"plain_text": "Malware Naming Hell: Taming the mess of AV detection names\r\nBy Karsten Hahn\r\nPublished: 2020-03-02 · Archived: 2026-04-10 02:06:07 UTC\r\n08/12/2019\r\nReading time: 9 min (2423 words)\r\nEveryone who deals with malware will know this: Malware names are a convoluted mess. AV scanners will show different\r\ndetection names for the same file. This confusion is also reflected in media coverage. Is there a way out of this mess?\r\nBefore we start our expedition into this muddled place, let's get the terminology right. \"Malware name\" might refer to one of\r\nthe following:\r\n1. AV detection name\r\nThose are the names an Antivirus product will show in a pop-up or log screen if it found an infection on the\r\nsystem. Those are also the names you see on multi scanning services like Virustotal.com.\r\n2. Malware family name\r\nA malware family describes all malicious samples whose payloads have the same or similar source code as\r\norigin. There is no clear line when a derivation of the malware source code creates a new family or when it is\r\nanother variant of the same family.\r\nThe family name can be, but doesn't have to be, part of the AV detection name.\r\nThe first part of our series examines Antivirus detection names. The second part is a dive into malware family names.\r\n1. The past: CARO virus naming conventions (1991)\r\nThe first attempt to make malware naming consistent was in 1991, when a committee at CARO created A New Virus\r\nNaming Convention. This was a time where all or almost all existing malware was also a virus. The naming scheme has\r\ninfluenced today's detection names. Most AV vendors use the same or similar components that CARO suggested but often\r\nwith their own terminology and ordering.\r\nThe full name of a virus consists of up to four parts, desimited by points (‘.’). Any part may be missing, but at\r\nleast one must be present. The general format is\r\nFamily_Name.Group_Name.Major_Variant.Minor_Variant[[:Modifier]\r\n(CARO, 1991, A New Virus Naming Convention)\r\nThis article will not describe all of these components in detail but highlight some points. The best description is in the\r\nconventions themselves on CARO's website.\r\nThe Family_Name portion of the detection name doesn't always denote an actual malware family. CARO's conventions\r\nprovide four umbrella names for insignificant viruses:\r\n1. \"Trivial\" for viruses smaller than 100 bytes of code. The infective length is appended as number to the Family_Name.\r\nhttps://www.gdatasoftware.com/blog/2019/08/35146-taming-the-mess-of-av-detection-names\r\nPage 1 of 9\n\n2. \"Silly\" for viruses that \"do not contain anything particular that can be used to name them\". Modifiers are appended to\r\nFamily_Name to denote boot sector viruses or types of files that are infected by Silly, e.g., SillyRC for resident\r\nviruses that infect COM files, or SillyB for DOS boot sector infectors\r\n3. \"HLLO\" for overwriting viruses written in high-level languages.\r\n4. \"HLLC\" for companion viruses written in high-level languages.\r\nThe Group_Name represents a sub group of malware in the same family employing the same rules and does and don'ts as the\r\nFamily_Name.\r\nThe Major_Variant and Minor_Variant create even more specific sub groups. Often the infective length of the virus or\r\nconsecutive letters or numbers are used for these components.\r\nThe Modifier is applied to the detection name if the threat actor used a third-party component to conceal their virus, e.g., a\r\npolymorphic engine or a compression tool.\r\nCARO's naming conventions are well-conceived. The format pattern starts with the most generic information and becomes\r\nincreasinlgy more specific. The does and don'ts listed for the Family_Name portion of the format make sure that the names\r\nare easy to remember, well-readable, don't interfere with each other, don't offend any third parties (companies, people), and\r\ndon't use mutable characteristics to describe a family (e.g. activation dates). They were created with forethought and are still\r\napplicable today.\r\n2. Detection naming conventions today\r\nThe malware landscape has changed since 1991, and so have the means of detecting malware, which might be one reason\r\nthat the CARO conventions didn't work out in the long run.\r\nNowadays:\r\nviruses are rare, most malware does not infect files. Detection naming conventions must consider the currently wide-spread malware types.\r\nthe file length has lost its meaning for malware identification and grouping, thus, it plays no part in detection names\r\nanymore.\r\nmost malware is packed.\r\nmore generic and heuristic methods are used to detect malware, e.g., instead of identifying a malware family,\r\nproducts may just identify malicous behavior. A lot of signatures are created automatically, resulting in detection\r\nnames that contain information about the detection technology instead of describing the malware itself.\r\nEvery AV vendor has their own detection name conventions, but most of them use similar components. They usually\r\ninclude: platform, malware type, malware family, a variant component and additional information that is prepended or\r\nappended to the name.\r\nThe platform, if it is part of the detection name, specifies the execution environment for the malware. This may be the\r\noperating system and architecture (e.g., Win32), a framework (e.g., MSIL for malware using .NET framework), or a\r\nprogramming language (e.g. Powershell). Unspecific terms for unknown execution environments exist too, e.g. Script may\r\ndenote any text-like file.\r\nThe malware type tells something about the behavior of the malware.\r\nThe malware family component in a detection name is either the actual family name of the malware or an umbrella name for\r\na broad range of families if the family is not known.\r\nhttps://www.gdatasoftware.com/blog/2019/08/35146-taming-the-mess-of-av-detection-names\r\nPage 2 of 9\n\nThe variant in a detection name is mostly just a counter to distinguish different signatures from each other whereas in the\r\nCARO conventions it was meant as an actual variant of the malware family. The variant may consist of numbers or letters or\r\nboth. In automatically created detections the variant portion may also be generated from the file itself, e.g., via hashing.\r\nThe modifier component is optional. It adds additional information about the detection. It may further specify the malware's\r\nbehavior or type or add a characteristic about the signature, e.g., it may state that the signature is heuristic or generic.\r\nThe table below lists some Antivirus vendors with links to their official detection naming conventions (if available) and their\r\nformat using the components above.\r\nAV vendor Format Example\r\nAvast Platform:Type1-Modifier \\[Type2\\] VBS:Downloader-ARK [Trj]\r\nAVG Type Family.Variant Trojan horse Crypt8.BHVG\r\nAvira Modifier/[Type.]Family.Variant\r\nTR/Inject.xbbeicg\r\nTR/AD.SodinoRansom.wcoir\r\nBitdefender\r\n[Modifier:\r\n[Platform.]]Type.Family[.Modifier].Variant\r\nGen:Trojan.Mresmon.Gen.1\r\nDeepScan:Generic.Ransom.Sodinokibi.5460CDF8\r\nESET\r\n[Modifier] Platform/[Type.]Family.Variant\r\nType\r\na variant of MSIL/TrojanDropper.Agent.BPM\r\ntrojan\r\nG DATA Platform.Type.Family.Variant[@Modifier] MSIL.Backdoor.Yantac.A@susp\r\nKaspersky [Modifier:]Type.Platform.Family[.Variant] HEUR:Trojan.Win32.Nymaim.gen\r\nMcAfee\r\nPlatform/Family Type\r\nPlatform/Family.Variant.Modifier\r\nRDN/Generic BackDoor\r\nW32/HLLP.11042.gen\r\nMicrosoft Type:Platform/Family.Variant[!Modifier] Trojan:Win32/Gandcrab.AF\r\nTrendmicro\r\n(old)\r\nType_Family.Variant TROJ_GEN.R002C0WGH19\r\nTrendmicro\r\n(new)\r\nType.Platform.Family.Variant.Modifier  \r\nSymantec PlatformOrType.Family.Variant Trojan.Gen.MBT\r\n3. Tips and tricks for interpreting AV detection names\r\nhttps://www.gdatasoftware.com/blog/2019/08/35146-taming-the-mess-of-av-detection-names\r\nPage 3 of 9\n\nAV detection names can contain useful information. However, everyone working with them must be aware that often they\r\ndon't, and sometimes the information in them is wrong. So if you have a scan result listing of a service like Virustotal, how\r\ndo you know which detection names can be trusted? A rule of thumb:\r\nThe more specific detections from different scanning engines exist that are consistent with each other, the more likely the\r\ninformation is correct.\r\nThe sections below examine how to differentiate specific from non-specific detections and explain how to interpret certain\r\nkey words used in detection names.\r\nUnderstood what you just read? We are looking for you!\r\n3.1. Antivirus terminology is quirky but you need to know it\r\nThe inconsistency and shift of meaning for terms used by the antivirus industry makes communication difficult. A well-known example is the use of the term \"virus\". Initially this was the most common or only malware type that existed. Peter\r\nSzor defines a virus as follows:\r\nA virus recursively replicates itself by infecting or replacing other programs or modifying references to these\r\nprograms to point to the virus code instead. A virus possibly mutates itself with new generations.\r\n(cf. [Szor05, p.27, 36])\r\nAntivirus products were true to their name because they protected systems from viruses. Nowadays, antivirus products\r\nmostly protect systems from malware regardless if they are viruses or not. Yet, the term \"virus\" has become synonymous\r\nwith \"malware\" in mainstream media.\r\nThe word \"trojan\" is another example. The \"trojan horse\" describes a way malware can be delivered to the target system by\r\npretending to be a useful and benign program or even providing useful functionality and tricking the user into execution (cf.\r\n[Szor05, p.37]). Thus, it describes a specific infection vector. It is in most cases not an inherent characteristic of a malware\r\nfamily but a way third parties make use of the malware. However, in detection names and in mainstream media the term\r\n\"trojan\" is used synonymously with \"malware\". We can often see that \"trojan\" is used as default value for the type\r\ncomponent in unspecific detection names. Maybe that is why mainstream media picked up the term to describe any\r\nmalware.\r\nApart from these quirks there are also certain key words in the malware family component of detection names which have\r\nspecific meanings. Umbrella names that include several malware families based on common characteristics will be\r\nexplained in the second part of this series. However, some keywords in the malware family component don't have anything\r\nto do with the characteristics of the malware family itself. They are default values, detection technologies, or describe the\r\nmalware's protection mechanism that was added by a third party. These are in the table below.\r\nKey words Meaning\r\nKryptik, Krypt, Cryptik,\r\nCrypt, Packed\r\nPacked file\r\nObfus Obfuscated file, mostly used for malicious script files\r\nInjector, Inject Packed file that injects into a process, usually via RunPE\r\nhttps://www.gdatasoftware.com/blog/2019/08/35146-taming-the-mess-of-av-detection-names\r\nPage 4 of 9\n\nKey words Meaning\r\nAntiXY\r\nProtection mechanism against XY, e.g. AntiAV means the file might incapacitate AV\r\nprogrammes, AntiVM means it might refuse to run in a Virtual Machine\r\nFakeXY, XYFake\r\nThe file imitates XY, e.g. FakeAdobe imitates an Adobe product. This is often done via\r\nthird party tools that change the icon and version information of the file\r\nCorrupt, Corrupted,\r\nMalformed\r\nThe file is corrupt.\r\nPatched The file was modified which makes it suspicious.\r\nAgent Default name for unknown or insignificant malware family\r\nRazy, Kazy, Zusy, Graftor Unknown malware family, detected by certain Bitdefender technology\r\nWisdomEyes Unknown malware family, detected by certain Baidu technology\r\nArtemis Unknown malware family, detected by certain McAfee technology\r\n3.2. Be aware of third party scanning engines\r\nIf you evaluate a sample in Virustotal, you might see an image similar to the one below.\r\nThere are at least six scanners that have the exact same detection for this file, including the same variant portion which is\r\nusually a vendor specific value. The reason for this is simple: The results stem from one and the same engine -- in this case\r\nBitdefender's engine.\r\nhttps://www.gdatasoftware.com/blog/2019/08/35146-taming-the-mess-of-av-detection-names\r\nPage 5 of 9\n\nAV products may often incorporate engines of other AV vendors additionally to their own. AV Comparatives has a list of AV\r\nvendors and the third party engines that they use. Bitdefender, Kaspersky and Avira appear as third party engines in this list.\r\nThat means if you evaluate multiscanner results, and you see that several vendors have the exact same detection name,\r\nincluding the variant portion of the name, it is probably just one and the same scanner. The detection in question should\r\nrather count as one detection instead of six (like in the sample above) while considering how valuable and informative the\r\nresults are. E.g., a sample that has six detections from one and the same engine is more likely a false positive than a sample\r\nwith six detections of six different engines.\r\n3.3. Prefer specific over unspecific detection names\r\nThe more specific a detection name is, the more information you can draw from it. Unspecific names are those with default\r\ncomponents. Descriptive components and umbrella names are a bit more specific. Actual identification of a malware family\r\nis the most specific.\r\nLet's take a look at this packed Ursnif sample[1].\r\nGreen: specific detection names with malware identification; blue: descriptive detection names without\r\nidentification\r\nThe detection names that are marked green identify the malware family Ursnif aka Gozi. \"Wastenif\" used by Microsoft\r\nseems to be an alias for Ursnif as well. The blue detection names don't provide the malware family but other information.\r\nTrojan.FakeMS: \"Trojan\" is here a default value for unspecified malware. \"FakeMS\" is a file that pretends to be a\r\nMicrosoft file. If you look at the \"File Version Information\" (e.g. in the \"Details\" tab in VirusTotal), you will see that\r\nthe file has indeed \"Microsoft Corporation\" in the \"Copyright\" metadata.\r\nhttps://www.gdatasoftware.com/blog/2019/08/35146-taming-the-mess-of-av-detection-names\r\nPage 6 of 9\n\nTrojan.Win32.Krypt: \"Trojan\" is again unspecified malware. \"Win32\" usually stands for 32-bit Windows PE files.\r\n\"Krypt\" tells us that the file is packed.\r\nWin32/Trojan.Spy.fd1 and Spyware ( 0052a9701 ): \"Trojan\" is unspecified malware. \"Spy\" or \"Spyware\" stands for\r\na malware that monitors the system for useful information like entered passwords and sends this information to the\r\nthreat actor. The variant portion of the name is of no use for us.\r\nAll of the other detection names don't provide any information about the malware except the platform (Win32) in some\r\ncases.\r\nTrojan.Agent.DGAT: This detection name appears several times because it from Bitdefender. \"Agent\" is the default\r\nfamily name for any unidentified malware family.\r\nArtemis!15B2A3D1E076: \"Artemis\" sounds like a malware family, but has a special meaning for McAfee\r\ndetections. \"Artemis\" was the previous name of the Global Threat Intelligence Technology (GTI) by McAfee.\r\nDetections which are created by GTI contain the name \"Artemis\". An explanation is also on this site.\r\n3.4. Results are better for non-packed files\r\nPacked malware has generally less detections and less specific detection names than their non-packed counterparts. This\r\nmakes sense because packing is used by threat actors to evade AV detection.\r\nBut even if the packed file is fully detected, results for the unpacked file usually provide more accurate information about\r\nthe malware identity. The scanners on Virustotal don't use the full technology set that is available for the actual antivirus\r\nproduct. They mostly rely on detection signatures that hit on the file without executing it, whereas in-memory scanning\r\ntechnologies like DeepRay aren't involved. Identification for packed files is often not possible or difficult if they aren't\r\nexecuted.\r\nTherefore it is recommended to unpack the malware before scanning to get better results. An example is in the pictures\r\nbelow.\r\nThe packed file[2] is detected by only two engines. Both detection names indicate that it is a script file which is packed. The\r\nunpacked file[3] in the second image is detected by ten engines and seven of them state it is a downloader written in\r\nVBScript. F-Secure claims it is a JScript which will download Teslacrypt ransomware. That means the unpacked file's\r\ndetection names reveal its actual behavior -- downloading other malware. Small downloaders like this one often don't get\r\ntheir own malware family name.\r\nReferenced samples\r\nDescription Detection name SHA256\r\n[1] Packed\r\nUrsnif\r\nTrojan.Agent.DGAT 7a8e75dd59b0c9633c9976bb3f07a53fe5fdbd3330ce8ba90153697edff4fff1\r\n[2] Packed\r\nVBScript\r\nmalware\r\nScript.Malware.KryptikPuf.A c6e7f80c08b456f2786454c59dc0f3138c1c17b070d5f02b6acc814ac740d128\r\nhttps://www.gdatasoftware.com/blog/2019/08/35146-taming-the-mess-of-av-detection-names\r\nPage 7 of 9\n\nDescription Detection name SHA256\r\n[3]\r\nUnpacked\r\nVBScript\r\nmalware\r\nScript.Trojan-Downloader.VBS.TIOAOR\r\nf43748608c9e904dd67ea5eb5650c15d0b62a1d3b1f917defef09ef946a0f553\r\nReferenced book\r\n[Szor05] Peter Szor. The Art of Computer Virus Research and Defense. Addison Wesley Professional, February 2005.\r\nRelated articles:\r\nKarsten Hahn\r\nPrincipal Malware Researcher\r\n Content\r\n1. The past: CARO virus naming conventions (1991)\r\n2. Detection naming conventions today\r\n3. Tips and tricks for interpreting AV detection names\r\n3.1. Antivirus terminology is quirky but you need to know it\r\n3.2. Be aware of third party scanning engines\r\n3.3. Prefer specific over unspecific detection names\r\n3.4. Results are better for non-packed files\r\nReferenced samples\r\nReferenced book\r\nRelated articles\r\n Topics\r\nTips and tricks\r\nTechblog\r\nMalware\r\nSecurity products\r\nMicrosoft Windows\r\nhttps://www.gdatasoftware.com/blog/2019/08/35146-taming-the-mess-of-av-detection-names\r\nPage 8 of 9\n\nSource: https://www.gdatasoftware.com/blog/2019/08/35146-taming-the-mess-of-av-detection-names\r\nhttps://www.gdatasoftware.com/blog/2019/08/35146-taming-the-mess-of-av-detection-names\r\nPage 9 of 9",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://www.gdatasoftware.com/blog/2019/08/35146-taming-the-mess-of-av-detection-names"
	],
	"report_names": [
		"35146-taming-the-mess-of-av-detection-names"
	],
	"threat_actors": [],
	"ts_created_at": 1775791265,
	"ts_updated_at": 1775960534,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/a810e451e4553e884dca8ab1b33f1a61fc703c9b.pdf",
		"text": "https://archive.orkl.eu/a810e451e4553e884dca8ab1b33f1a61fc703c9b.txt",
		"img": "https://archive.orkl.eu/a810e451e4553e884dca8ab1b33f1a61fc703c9b.jpg"
	}
}