How Threat Actor Names Differ Between Vendors

Origin and history

The practice of security vendors assigning different names to the same threat actor or campaign originates from the commercial cybersecurity industry of the late 20th and early 21st centuries. This naming divergence became a significant operational issue as the number of private security firms tracking advanced persistent threats (APTs) and cybercriminal groups proliferated in the 2010s. There is no single governing body that mandates a universal taxonomy, leading to the development of independent, proprietary naming conventions by each major vendor. The problem is rooted in the competitive nature of threat intelligence, where vendors seek to differentiate their research and branding. Historical examples, such as the group known variously as APT28, Fancy Bear, and Sofacy, demonstrate how these disparate labels emerged from parallel research efforts. This lack of coordination has created a persistent challenge for defenders attempting to correlate reports and intelligence across different sources.

What it is for

Vendor-specific threat actor naming serves primarily to label and catalog malicious cyber entities within a company's own intelligence ecosystem. These names function as internal identifiers that allow security researchers to reference a set of related activities, tools, and infrastructure consistently across their own publications and product alerts. The naming conventions are designed to convey certain attributes, such as the suspected geopolitical alignment (e.g., using nation-state monikers), perceived threat level, or technical characteristics associated with the group. For the vendors themselves, these names become brand assets, signifying their unique discovery and analysis capabilities to their customer base. The names are not intended for cross-vendor interoperability but rather for effective internal communication and external marketing of a firm's threat intelligence prowess. Ultimately, the system aims to help security teams using a specific vendor's products to understand and mitigate threats as defined within that vendor's framework.

Overview

This issue refers to the non-standardized landscape where multiple cybersecurity companies assign different aliases to the same malicious hacking group or campaign. A single threat actor may be tracked under three, four, or more distinct names by different industry leaders, creating a significant barrier to information sharing and unified defense. The naming schemes themselves vary widely, with some vendors using numerical designations like APT41, others employing evocative names like Lazarus Group or Wizard Spider, and some using technical indicators such as codenames derived from malware families. This inconsistency extends beyond actor names to encompass campaign names, malware variants, and even vulnerability identifiers in some cases. The core problem is the absence of a neutral, authoritative registry for threat actor nomenclature, leaving coordination to informal industry alliances which often fail to achieve full consensus. This fragmented state requires defenders to maintain a mental or documented mapping of aliases to accurately synthesize intelligence from diverse sources.

What to know

Security analysts must know that vendor-specific names are not unique identifiers but rather labels that require translation when working with multi-vendor environments. It is critical to understand the key naming conventions of major intelligence providers, such as Mandiant's APT numbering, CrowdStrike's animal-themed names (e.g., Panda, Kitten), and Microsoft's elemental designations (e.g., Mercury, Zinc). One should be aware of resources like the MITRE ATT&CK framework, which uses its own group identifiers (e.g., G0007) and maintains alias tables, though it does not enforce naming standardization. Knowing that names can also change over time as vendor understanding evolves or for branding reasons is essential to avoid confusion. Defenders must prioritize tracking the underlying techniques, procedures, and infrastructure (TTPs and IOCs) rather than relying solely on the actor name, as these technical details are more consistent across reports. Furthermore, understanding that different vendors may have different visibility and thus may be tracking overlapping but not identical subsets of a group's activity is a key nuance in interpreting these names.

Common questions

A common question is why the cybersecurity industry does not simply agree on a single naming standard, to which the answer involves commercial competition, intellectual property, and the challenge of achieving global consensus among dozens of firms. Practitioners often ask how they can reliably map one vendor's threat name to another's, pointing to the need for curated cross-reference tables maintained by communities or certain vendors themselves. Another frequent inquiry concerns whether one vendor's name is more "correct" or authoritative than another, but no single vendor's designation holds official status, though some gain wider adoption through media reporting. Organizations wonder if this naming confusion impacts the efficacy of security products, and while automated controls like signatures work on code, manual threat hunting and intelligence correlation are significantly hindered. Questions also arise about whether government agencies use their own secret names, which they do, further adding to the proliferation of aliases not seen in public reports. Finally, users ask if newer collaborative initiatives will solve the problem, but while efforts like the Cyber Threat Alliance improve sharing, fundamental naming disparities persist due to entrenched practices.

Pros and cons

A pro of multiple vendor-specific names is that they can reflect different analytical perspectives or highlight distinct facets of a threat group's activity discovered by that vendor. The competitive naming landscape can drive vendors to conduct deeper, more distinctive research to justify their own unique label and associated findings. A significant con is that it creates immense operational overhead for security teams, who must waste time and resources deciphering and aligning reports instead of acting on them. This fragmentation actively impedes effective industry-wide communication and collaboration during incident response, slowing down collective defense. A common mistake is for organizations to purchase multiple intelligence feeds without allocating staff to manage the alias mapping, leading to missed correlations and a false sense of having broader coverage than they actually do. Many security operations center (SOC) managers regret the complexity this introduces, as it becomes a persistent source of confusion for junior analysts and complicates reporting to executive leadership who seek clear, singular threat names.

Who it suits

This disparate naming environment primarily suits the business models of individual cybersecurity vendors, as it allows them to build branded threat intelligence portfolios that are not easily interchangeable with a competitor's. It suits niche research teams who focus on a specific geographic or technical area and develop a proprietary naming scheme that fits their specialized view of the threat landscape. The situation does not suit enterprise security teams operating a best-of-breed strategy with tools and feeds from multiple vendors, as they bear the full burden of translation. It is particularly unsuited for sectors like critical infrastructure or government agencies that rely on rapid, clear information sharing across organizational boundaries, where ambiguous naming can cause dangerous delays. Consolidated security platforms that offer a single vendor's entire stack are somewhat better suited, as the naming problem is contained within one ecosystem, though this creates vendor lock-in. Ultimately, the current system suits an industry state where competitive differentiation is valued more highly than universal clarity for defenders.