Malware Family: Data Point Intelligence Guide
A malware family name is an analytical claim, not a fact stamped on the binary. It is the most useful and the most abused shorthand in the discipline.
A malware family name is an analytical claim, not a fact stamped on the binary. It is the most useful and the most abused shorthand in the discipline.
Understanding the Malware Family as an intelligence artifact
A malware family is a named grouping of related malicious software that shares code lineage, functional design or a common developer. The name is assigned by researchers, not by the author, and is justified by evidence such as shared code, identical configuration structures, common encryption routines, reused mutex naming or a consistent command and control protocol. It functions as a container: once a sample is assigned to a family, everything already known about that family becomes a hypothesis about the sample in front of you.
Families sit inside a messy naming ecosystem. Multiple research teams name the same code independently, producing aliases that only partially overlap. Builders, packers and loaders get named as families even when they merely wrap other payloads. Ransomware-as-a-service complicates it further, since one codebase is operated by many affiliates with different tradecraft, so family identity and operator identity must be tracked separately.
Why it matters
Family assignment converts a single sample into a body of prior knowledge: expected capabilities, configuration extraction methods, known C2 protocols, typical delivery chains, associated actors and existing detection logic. In incident response it lets you predict what to look for next before you have finished analysis. In strategic reporting it is the unit that connects technical observation to campaign and actor tracking, and to the ATT&CK techniques the software is known to implement.
What analysts actually look for
These are the concrete, observable signals that carry weight in this area of work:
- Code overlap with known samples, measured through function-level similarity, shared library statically linked, or identical decryption routines.
- Configuration structure and extraction method, which is often the most stable family fingerprint even across major version changes.
- Command and control protocol details: beacon interval, URI patterns, header ordering, encryption scheme and encoding choices.
- Consistent artefacts such as mutex names, registry keys, service names, PDB paths and hardcoded strings across otherwise different builds.
- Capability set and its evolution over time, showing which modules are core and which are affiliate or campaign specific.
- Delivery chain patterns, including the loaders, packers and initial access brokers repeatedly observed upstream of the payload.
- Victimology and targeting, which distinguishes broad commodity distribution from selective deployment by a specific operator.
- Alias mapping across vendors, which is essential to reconcile reporting and avoid double counting the same campaign.
Where the data comes from
Authoritative and openly available collection points. Always confirm licensing and terms before operational or commercial use:
- Malpedia (Fraunhofer FKIE) — Curated family library with alias reconciliation, YARA rules, samples and linked technical reporting
- MITRE ATT&CK Software — Family entries mapped to techniques, associated groups and references, giving behaviour-level expectations
- MalwareBazaar (abuse.ch) — Tagged sample corpus letting you pull recent builds attributed to a family for comparison
- ThreatFox (abuse.ch) — Community indicators linked to families, particularly command and control infrastructure with confidence levels
- VirusTotal Collections — Aggregated engine labels, relationships and community graphs that surface family candidates for a sample
- ANY.RUN public tasks — Interactive sandbox runs with configuration extraction and network detail submitted by the community
- MISP galaxy clusters — Machine-readable family and actor taxonomies with synonym mapping for consistent tagging across teams
A working method
A repeatable sequence beats ad-hoc searching. This is a practical starting workflow:
- Establish behaviour first — Characterise what the sample does through sandbox and static analysis before reading any vendor label, so the label does not anchor your analysis.
- Collect candidate names — Gather engine labels, YARA hits and community tags, treating each as a hypothesis and noting where sources disagree.
- Resolve aliases — Map candidate names through a curated alias reference so you are not tracking one family under four different names.
- Test the assignment — Compare configuration structure, C2 protocol and code artefacts against reference samples. Assignment needs concrete overlap, not a shared label.
- Pull the family baseline — Retrieve known techniques, infrastructure patterns and detection logic, then check which are present in your incident and which are absent.
- Separate code from operator — Record family and suspected operator as distinct attributes, since shared tooling does not mean shared actor.
- Feed detection back — Convert confirmed family artefacts into YARA and behavioural rules, and record the evidence that justified the assignment.
How this connects across the intelligence taxonomy
Intelligence work does not respect neat boundaries. The mission domain you are working, the disciplines you practise, and the data points you pivot on are one connected system. These are the direct relationships for this entry — every link is also a tag, so you can follow any thread across the whole library.
Collected by these disciplines
- Cyber Intelligence — Adversary Activity in Networks and Systems
- Threat Actor Intelligence — Tracking Adversary Groups Over Time
- Vulnerability Intelligence — Weaknesses, Exploitation, and Prioritization
- Technical Intelligence — Technology Capability, Design, and Exploitation
- Malware Intelligence — Understanding Malicious Code
- Signals Intelligence — Intelligence from Intercepted Communications and Emissions
- Open Source Intelligence — Publicly Available Information, Systematically Collected
- Certificate Intelligence — TLS Certificates and Certificate Transparency
Investigated in these domains
Pivots to these data points
- File Hash — Cryptographic fingerprint of a file, used for malware identification.
- CVE / Vulnerability — Common Vulnerabilities and Exposures identifier for a known flaw.
- SSL/TLS Certificate — A digital certificate binding a public key to an identity.
- File / Document — A file or document artifact — malware sample, leaked document, image, or email attachment.
- Onion / Hidden Service — A Tor hidden service address on the dark web.
- Data Breach — A known data breach or leak incident with exposed records.
Inside the platform: where Malware Family lives
The Quantus platform is 204 pages behind a 147-item sidebar organised into six working groups: Command (24 items), Dashboards (15), Threat Theaters (14), Intelligence Domains (15), Investigate (34), and Administration (45). This entry is not a page in isolation — it is a thread running through several of them.
The modules that matter most here:
hash-profile.php— Malware Family profiledatapoint.php?dp=dp_malware_family— Data point hubthreat-dashboard.php?theme=nation_state— Nation State dashboardactor-profile.php— APT / Espionage dashboardransomware.php— Ransomware dashboardsearch.php— Advanced search, filter and pivotcorrelate.php— Correlation graphcases.php— Case management
Each dashboard is local-first: it renders from the platform’s own database rather than depending on a live third-party call, so it still works when an upstream API is unreachable or rate-limited. Heavy aggregates are cached with a hard query time cap and degrade to the last good value instead of hanging the page.
Automation, playbooks and AI skills
Analysis that only happens when someone remembers to run it is not a capability. The platform ships a 30-step automation pipeline (cron.php) that collects, ingests, resolves, enriches, correlates and scores on a schedule — 25 seeders, 11 resolvers and 7 enrichment runners, all idempotent and cursor-based so a run can be interrupted and resumed without duplicating or losing work.
AI skills that apply
The 16 one-click operations in ai-skills.php are deterministic jobs, not free-text generation. The ones that matter here:
- Enrichment Runner
- Enrichment → Local
- Correlate Infrastructure
- Detection Rules
- Summarise (Copilot)
- Generate Report
Alerting closes the loop: rules in alerts.php fire on new indicators matching a saved query, so a first sighting in this area raises a notification rather than waiting to be noticed at the next review.
Feeds, data sources and the API
The collection layer runs a feed registry of free, machine-readable sources — bulk blocklists and trackers (Maltrail, IPsum, FireHOL, the full abuse.ch corpora, phishing databases, Emerging Threats, Spamhaus, DigitalSide, ThreatView), authoritative government feeds (CISA KEV, OFAC, UN and EU sanctions lists), and reference datasets (RIR allocations, ip-to-ASN and geolocation tables, MITRE ATT&CK, EPSS). collect.php pulls them server-side on a schedule; feeds.php and source-catalog.php show what is registered, what it covers and when it last ran.
Anything the platform holds is reachable programmatically. The REST API in api.php exposes 11 endpoints — status, stats, search, lookup, recent, export, bulk_check, top_threats, by_category, categories, check — and export.php streams 18 formats in bounded chunks, so a million-row export neither exhausts memory nor times out:
STIX 2.1, MISP, OpenIOC 1.1, CEF (ArcSight), LEEF 2.0 (QRadar), Zeek/Bro intel, Snort/Suricata rules, Palo Alto EDL, BIND RPZ, hosts blackhole, iptables, CSV, JSON, NDJSON/JSONL, XML.
That covers the CTI standards (STIX 2.1, MISP, OpenIOC), SIEM ingestion (CEF, LEEF, Zeek), detection engines (Snort/Suricata), and direct enforcement (Palo Alto EDL, BIND RPZ, hosts, iptables) — so intelligence developed here can be actioned in the tools you already run, without a manual reformatting step. A TAXII 2.1 server and a MISP/RSS feed are also served for pull-based sharing.
Use cases
Three ways this entry earns its keep in day-to-day work:
- Triage under time pressure. An artifact or report lands and you need a defensible read in minutes, not days. Establish behaviour first is the first move; the platform pre-computes the enrichment so the analyst spends the time on judgement rather than lookups.
- Building the picture. A single indicator is rarely the story. Resolve aliases turns one artifact into a network — shared infrastructure, repeated selectors, the same operator behind different names — via the correlation graph and the cross-entity link engine.
- Producing something actionable. Analysis that ends in a document nobody can use is wasted. Feed detection back feeds the case file, the detection rule, the block list or the referral — with sourcing attached so the recipient can verify it.
Case management (cases.php), watchlists, saved searches and scheduled reports mean the work persists between sessions and survives an analyst leaving the team.
How each sector uses Malware Family
The same entry is worked very differently depending on who you are, what authority you hold, and what you are ultimately producing. A military analyst is supporting a commander’s decision; a journalist is meeting a publication standard; an NGO caseworker is protecting a person. The underlying artifacts are shared — the constraints, outputs and thresholds are not.
🎖 Military and defence
Family assignment lets a defence cyber unit convert one detection into a set of expectations: known capabilities, typical delivery chains, expected persistence, likely command and control protocol and the techniques to hunt for next. That drives force protection decisions about isolating systems and prioritising sweeps across a mission network, and it feeds the threat sections of network defence orders and coalition indicator packages. The important constraint is that family is not actor. Ransomware-as-a-service codebases are operated by many affiliates and commodity loaders are used by everyone, so a family identification supports a defensive posture decision and must not be presented as an attribution to a state or a unit.
🕵 National intelligence
Families are the technical building blocks of actor tracking. Requirements-driven work asks whether tooling associated with a priority actor has appeared against a target set, whether a family's development shows continuing investment, and whether code overlap indicates shared developers or a shared supplier. Fusion combines reverse engineering results, sandbox behaviour, infrastructure patterns and human and signals reporting to move from family to campaign to actor, keeping those three layers explicitly separate in the assessment. Classification usually follows the collection: family analysis from public samples is releasable, whereas the observation that a specific target was hit may not be. Alias reconciliation should happen before dissemination.
👮 Law enforcement
In law enforcement, family identification structures a case. It predicts what artefacts to look for on victim systems, which supports search warrant scope and forensic tasking, and it links geographically separate incidents into a single investigation where the same tooling and configuration appear. For ransomware casework the family is what connects victim reports, leak site postings and cryptocurrency flows into one operation. Evidence must rest on the artefacts recovered from seized systems and lawfully obtained provider records, with the family assessment presented as expert analysis. Keep the distinction clear for the court between the software used and the person who used it.
🔍 Private investigation and corporate security
Corporate investigators use family identification to scope an incident and to answer the questions insurers, regulators and boards actually ask: what was this, what does it do, was data taken, and is it associated with a sanctioned entity. That last question matters because payment to certain ransomware operations creates sanctions exposure, so family and operator assessment carries direct legal consequence. Private actors must handle live samples under a documented policy with isolated infrastructure, must not distribute malware, and must not interact with actor infrastructure beyond passive observation. Where analysis exceeds internal capability, engage a specialist firm under contract rather than improvising.
📰 Journalism and OSINT media
Reporting on malware families requires care with naming and with attribution. Different vendors name the same code differently, so a story that treats two vendor names as two threats has doubled a single event. Verify the family assignment with at least two independent technical sources and, where possible, a named researcher who will explain the evidence. Never conflate the malware with a nation state: commodity families are available to anyone, and even bespoke tooling is sometimes shared or stolen. Publish the technical basis for any attribution claim, give named companies and researchers a right of reply, and avoid publishing capability detail that materially assists operators.
🌍 NGO, humanitarian and human rights
Civil society targets are hit by both commodity families and commercial surveillance tooling, and the two require different responses. Family identification tells a targeted organisation what data was likely accessed, which devices to rebuild and what to tell affected staff, which is the core of a victim-centred response. For accountability work, documenting the specific family used against journalists or human rights defenders supports reporting to national CERTs, platform vendors and human rights mechanisms. Handle device forensics with the individual's informed consent and clear explanation, avoid publishing details that identify the target without consent, and connect the person to appropriate psychosocial and legal support.
🎓 University and research
Family taxonomy is a genuine research problem: naming is inconsistent, ground truth is scarce, and published clustering results are frequently unreproducible because samples and thresholds are not shared. Good practice pins sample sets by hash, publishes feature extraction code, states the clustering algorithm and parameters, and evaluates against a curated reference such as Malpedia rather than against engine labels. Ethics approval applies where research involves live infrastructure interaction, victim data or sharing of executable samples. Publish hashes and features rather than binaries, route sample access through a vetted repository, and report alias mappings explicitly so results can be compared across studies.
Playbook: working Malware Family end to end
A repeatable sequence, from the moment the requirement lands to the moment a product is delivered and the case is closed out. Each phase states what you are trying to establish, not merely what to click — the point is a defensible chain of reasoning, not a checklist.
Phase 1 — Characterise behaviour before reading labels
Run static and dynamic analysis and write down what the sample actually does before you look at any vendor label, because a label read first anchors everything that follows. Capture persistence, injection, credential access, discovery, command and control protocol, encryption routines and any embedded configuration. A good output is a capability description written in technique terms rather than in product names. Stop and note the limitation if the sample refuses to execute in your environment, since evasion behaviour is itself a family characteristic.
Phase 2 — Collect candidate names as hypotheses
Gather engine detection names, YARA rule hits, community tags and any references from public reporting, treating each as a hypothesis rather than an answer. Record where sources agree and where they diverge, because divergence usually indicates either a genuinely new variant or a generic label masquerading as identification. A good output is a candidate list with the source of each name and its specificity. Discard purely generic labels immediately, since a name like Trojan.Generic carries no analytic content at all.
Phase 3 — Reconcile aliases
Map candidate names through a curated alias reference so you are not tracking one family under four names or merging two families that share one. Alias reconciliation is unglamorous and is the single largest source of avoidable error in threat reporting, particularly when a report is assembled from multiple vendor sources. A good output is a canonical family name for your organisation with the aliases recorded alongside. Publish the alias mapping with your product so recipients can reconcile against their own naming.
Phase 4 — Test the assignment against concrete overlap
Confirm or reject the family hypothesis using structural evidence: configuration format and encryption, command and control protocol and message structure, distinctive strings and mutex naming, code reuse in specific routines, and build artefacts such as rich headers. Assignment requires concrete overlap with reference samples, not a shared label. A good output states the specific overlaps found and the competing hypotheses rejected. Stop and report the sample as unclassified if no reference overlap exists, which is a useful finding in a targeted intrusion.
Phase 5 — Extract configuration
Recover the embedded configuration, which usually carries command and control addresses, campaign identifiers, mutex names, encryption keys, target filters and version strings. Configuration extraction is where a family assignment pays for itself, because published extractors exist for most established families and the extracted campaign identifier frequently ties incidents together. A good output is a structured configuration record stored alongside the sample hash. Note the extractor and version used, since configuration formats change between builds.
Phase 6 — Pull the family baseline and diff it
Retrieve the known techniques, delivery chains, infrastructure patterns and detection logic for the assigned family, then compare systematically against your incident. What is present confirms; what is absent is more interesting, because it may indicate a new variant, a partial deployment or a wrong assignment. A good output is a two-column comparison of expected and observed behaviour with the differences called out explicitly. This step is what converts a family label into an actionable hunting plan.
Phase 7 — Separate code identity from operator identity
Record family and suspected operator as distinct attributes with independent confidence levels, because shared tooling does not mean shared actor. Ransomware-as-a-service means one codebase and many affiliates with different tradecraft, initial access methods and targeting. Loaders and commodity stealers are sold to anyone. A good output is an assessment that states the family with high confidence and the operator with a separately reasoned confidence. Collapsing the two is the error that produces retracted attribution claims.
Phase 8 — Map the delivery chain
Reconstruct how the family arrived: initial access vector, loader, dropper, injection method and payload staging, since families increasingly appear as one link in a chain operated by different specialists. Access brokers, loader operators and payload operators may be entirely separate groups. A good output is a chain diagram with the observed evidence for each link and the gaps identified. This structure is what tells a defender where to intervene most cheaply, which is rarely at the payload.
Phase 9 — Assess victimology and campaign scope
Establish whether the deployment fits the family's typical targeting or diverges from it, using leak site postings, public reporting, sector telemetry and your own visibility. A commodity family deployed against a single high-value target is a different problem from the same family in an opportunistic spray. A good output is a short victimology note with the evidence and its limits. Be explicit that public leak site data reflects what operators chose to publish, not the true victim population.
Phase 10 — Check sanctions and legal exposure
For ransomware and extortion cases, screen the assessed operator, associated wallets and any negotiation infrastructure against sanctions designations, because payment to a designated entity creates strict liability exposure regardless of intent. This is a legal step with a hard deadline, not an analytic nicety, and it must be routed to counsel and compliance rather than resolved by the analyst. A good output is a documented screening result with the list version and date, delivered before any payment decision is discussed.
Phase 11 — Convert to durable detection
Write YARA rules against code constructs, decryption routines and configuration structures rather than against build-specific strings, and write behavioural rules against the execution chain. Test both against a benign corpus before deployment. Publish detection logic where doing so does not materially help the operator. A good output is a rule set with documented test results, an owner and a review date, plus a note of which techniques remain undetected so the gap is visible rather than assumed closed.
Phase 12 — Record the evidence and share the reasoning
Document why the family assignment was made, what evidence supported it, what alternatives were considered and how confident you are, then share in a structured format with the aliases mapped. Threat intelligence that shares conclusions without reasoning cannot be corrected by recipients who see contradicting evidence. A good output is a product that a peer could disagree with intelligently. Revisit and amend the assessment publicly when new evidence changes it, since silent revision destroys the value of the naming system.
The platform ships this as a step-checked workflow in playbooks.php, so progress is recorded against a case rather than held in someone’s head.
Source register: what to collect from, and how
Sources are listed with their access model so you can plan around cost and licensing before you build a dependency on them. Open means no account required; registration means a free account or API key; licensed means paid or institutional access. Always confirm current terms — licensing changes, and a source that was free for research may not be free for commercial or evidential use.
| Source | Access | What it gives you | How it is used here |
|---|---|---|---|
| Malpedia | Registration | Curated malware family library from Fraunhofer FKIE with alias reconciliation, YARA rules, references and reference samples. | The authoritative starting point for resolving aliases and testing a family hypothesis against curated references. |
| MITRE ATT&CK Software | Open | Family and tool entries mapped to techniques, associated groups and public references within the ATT&CK knowledge base. | Provides behaviour-level expectations for an assigned family and the detection coverage question that follows. |
| MalwareBazaar | Open | abuse.ch sample repository with family tags, YARA matches and downloadable recent builds submitted by the community. | Pulls recent samples attributed to a family for comparison against the specimen in your incident. |
| ThreatFox | Open | Community indicator feed linking command and control infrastructure and hashes to malware families with confidence levels. | Checks whether observed infrastructure is already associated with the candidate family by other reporters. |
| VirusTotal | Registration | Multi-engine labels, relationships, behavioural reports and community graphs across a very large sample corpus. | Generates candidate family names and surfaces related samples, always treated as hypotheses to be tested. |
| YARA rule repositories | Open | Public collections of family detection rules maintained by vendors, national CERTs and independent researchers. | Tests a sample against community family rules and provides a starting point for writing durable local rules. |
| MISP galaxies and taxonomies | Open | Structured community reference data mapping malware families, threat actors and their aliases with source references. | Machine-readable alias reconciliation that can be embedded directly in an intelligence platform. |
| Ransomware.live | Open | Aggregated ransomware leak site postings recording claimed victims, dates and the group behind each site. | Establishes campaign scope and victimology for ransomware families, with the caveat that postings are operator-selected. |
| CISA advisories | Open | Joint government advisories describing specific families with technical detail, indicators and mitigation guidance. | Authoritative baseline for widely deployed families, frequently including indicators from incident response engagements. |
| Vendor threat research publications | Open | Detailed reverse engineering write-ups from security vendors covering family internals, configuration formats and campaign analysis. | Supplies the structural detail needed to test a family assignment rather than accept a label. |
| Hybrid Analysis | Registration | Public sandbox reports with behavioural detail, extracted configuration and dropped artefacts for submitted samples. | Second independent behavioural perspective when comparing an unknown sample against family expectations. |
| Tria.ge | Registration | Automated sandbox with family-specific configuration extractors and signature-based family identification. | Rapid configuration extraction for established families, giving campaign identifiers and command and control addresses. |
| OFAC Sanctions List Search | Open | US designations including individuals, entities and cryptocurrency addresses associated with ransomware operations. | Mandatory screening step before any ransomware payment discussion, with the list version and date recorded. |
| Europol and national CERT reporting | Open | Law enforcement and national authority publications on disruption operations, family takedowns and decryption tooling. | Identifies whether free decryption exists and whether the operation has been disrupted, which changes response options. |
Prefer sources that publish a methodology and a revision history. A dataset that changes silently is a liability in any product that has to survive challenge.
Tooling
Tools commonly used against Malware Family. None of these replace judgement, and each carries its own failure modes — know what a tool infers versus what it observes.
- YARA — Rule engine for content and structural matching used to test family membership at scale. Limitation: rules keyed to build-specific strings break on recompilation.
- Configuration extractors — Family-specific parsers recovering command and control addresses, keys and campaign identifiers. Limitation: break silently when the family changes its configuration format.
- Automated sandboxes — Produce behavioural reports and often family identification with extracted configuration. Limitation: evasive samples detect the environment and behave benignly.
- Disassemblers and decompilers — Enable code-level comparison of routines that establishes genuine lineage. Limitation: labour intensive and requires skills that are scarce in most teams.
- BinDiff and similar binary comparison — Quantifies function-level similarity between a sample and reference binaries. Limitation: heavy obfuscation and different compilers produce misleading similarity scores.
- MISP with galaxies — Stores family assignments, aliases and supporting evidence in a shareable structured form. Limitation: alias data requires active curation to stay current.
- Fuzzy and structural hashing — Clusters candidate relatives via TLSH, imphash and section hashes before deep analysis. Limitation: clusters packers and toolchains rather than code lineage.
- Malpedia library — Curated references and rules for testing an assignment against ground truth. Limitation: coverage skews toward families that researchers have chosen to document.
AI skills and automation in detail
These are deterministic jobs with defined inputs and outputs, not open-ended prompting. Each is idempotent and cursor-based: interrupt one and it resumes where it stopped rather than duplicating work or losing progress.
- Enrichment Runner — Walks the indicator set through a chosen provider in time-boxed, cursor-based batches that resume rather than restart.
- Enrichment → Local — Materialises enrichment into the local store so dashboards render from your own database instead of a live third-party call.
- Correlate Infrastructure — Builds the cross-entity link graph: shared hosting, reused certificates, overlapping registrants, repeated selectors.
- Detection Rules — Generates YARA, Sigma and Snort/Suricata logic from the selected indicators, ready to deploy.
- Summarise (Copilot) — Produces a narrative summary beside the underlying records. It explains; it never creates indicators or assigns attribution.
- Generate Report — Assembles a sourced product from the current case or query, with provenance attached to each element.
A note on the boundary: the only skill that involves a language model is Summarise (Copilot), and it writes prose about records that already exist. Nothing else on this list involves generation of any kind. No indicator, relationship or attribution in the platform originates from a model. See the full skill list.
Tradecraft notes
The distinctions that separate a competent analyst from a fast one:
- Read behaviour before you read labels. An engine name seen first anchors the analysis, and the resulting report will find evidence for that family because the analyst was looking for it. Write the capability description first and date it, then compare.
- Family identity and operator identity are different attributes with different confidence levels. Ransomware-as-a-service means one codebase and dozens of affiliates, so a confident family assignment supports a defensive plan and supports no attribution claim whatsoever.
- Alias reconciliation is the highest-return unglamorous task in the discipline. Reports assembled from multiple vendor sources routinely double-count one family or merge two, and neither error is visible to the reader unless the alias mapping is published alongside.
- What the family baseline predicts and your incident does not show is more interesting than what matches. Absent behaviour indicates a new variant, a partial deployment, an interrupted intrusion or a wrong assignment, and each of those changes the response.
- Builders, packers and loaders get named as families even when they only wrap other payloads. Before treating a name as a family, establish whether it describes a codebase with lineage or a commodity wrapper used by unrelated operators.
- Configuration structure is far stronger evidence of lineage than strings or engine labels, because the format reflects design decisions that persist across builds. Two samples sharing a distinctive configuration encryption scheme and layout are related in a way string overlap never proves.
- Public leak site postings measure what operators chose to publish, not who they hit. Victims who paid, who were never listed, or who were listed and then removed are all invisible, so victimology derived from leak sites is a lower bound with a selection bias.
- Screen for sanctions exposure as a legal step with a deadline, not as an analytic footnote. Payment to a designated entity is strict liability in several jurisdictions, and the analyst's job is to deliver the screening result to counsel early enough to matter.
Measuring whether it is working
Capability claims should be falsifiable. These are the measures that show whether work on Malware Family is producing anything, and they are worth baselining before you change process or tooling.
- Proportion of family assignments supported by recorded structural evidence such as configuration format or code overlap, rather than by engine labels alone. This measures analytic rigour directly.
- Rate at which family assignments are later revised, tracked over time. A very low rate usually means assignments are not being revisited rather than that they are correct.
- Alias reconciliation coverage: percentage of families in the internal knowledge base with a maintained alias mapping to major vendor and community naming schemes.
- Median time from family assignment to deployed behavioural detection for the family's techniques, which measures whether analysis reaches the defensive stack.
- Proportion of ransomware engagements where sanctions screening was completed before any payment discussion, with the list version recorded. The target is one hundred per cent.
- Number of incidents where family baseline expectations produced a hunting lead that found additional compromise, measured as a direct outcome of the assignment.
- Percentage of published family assessments that state confidence and the competing hypotheses considered, which is what allows recipients to correct rather than inherit an error.
Beware of measuring volume alone. Indicator counts and report counts rise easily and say little; time-to-attribution, proportion of findings that survive review, and how often a product changed a decision say a great deal.
Common pitfalls
- Generic engine labels such as trojan or downloader carry no family information and are frequently promoted to attribution by mistake.
- Alias confusion causes double counting, where one campaign is reported as several because vendors used different names.
- Commodity tooling is shared across unrelated actors, so a family match is not attribution to a group by itself.
- Builders and cracked kits produce samples that look like one family while being operated by entirely unconnected criminals.
- Families fork and diverge; assuming last year's capability set still applies leads to missed behaviour in current incidents.
- Marketing-driven naming of a new family for an old codebase inflates the perceived novelty of a threat and distorts prioritisation.
Legal and ethical considerations
Family research is lawful defensive work, but the material involved needs care. Samples may contain victim data, stolen documents or credentials, so storage and sharing require access controls and, for customer-derived material, contractual authority. Acquisition, execution and distribution of live malware should be governed by an internal policy, isolated infrastructure and clear records. Where research touches actor-controlled infrastructure, interaction beyond passive observation can create legal exposure and should be authorised explicitly and documented.
Data integrity: no fabrication, no drift, no hallucination
Intelligence that cannot be traced back to a source is not intelligence, it is assertion. Everything in this entry — and everything in the platform behind it — is built on a small number of non-negotiable rules.
Provenance on every record
Every indicator carries the source that supplied it, a first-seen and last-seen timestamp, and a sighting count. Where several feeds report the same artifact, each contribution is recorded separately rather than collapsed, so you can see whether a finding rests on one source or twelve. Source attribution travels with the data into every export, so a recipient can audit a claim without asking you for the working.
Nothing is invented to fill a gap
If the platform has no data for Malware Family, it says so. Empty is displayed as empty — never padded with plausible-looking placeholder values, sample records or illustrative examples that a reader might mistake for observations. A dashboard with no rows is a true statement about collection coverage, and it is treated as a gap to close, not a blemish to hide.
Scoring is deterministic and reproducible
Threat scores, reputation grades and risk tiers are computed from stated inputs with fixed weights, not estimated. The same inputs always produce the same output, and the formula is visible rather than a black box. Aggregates are cached with an explicit time-to-live so a figure on screen is never silently stale — and when a heavy query exceeds its time budget the platform serves the last known-good value and labels it, rather than inventing a fresh number or hanging.
Where AI is used, and where it is not
Language models summarise and explain. They do not create indicators, assign attribution or manufacture relationships. No IP address, wallet, hash or identity in the platform originates from a model — every one is ingested from a named feed, resolved from a reference dataset, or entered by an analyst with a source recorded. Copilot output is presented as narrative alongside the underlying records, never in place of them, so a reader can always check the summary against the evidence.
Guarding against drift
Enrichment is additive and timestamped rather than overwriting. Reference data — sanctions lists, allocations, taxonomies — is re-synchronised from the authority on a schedule instead of being edited in place, so local copies cannot quietly diverge from the source of truth. Attribution is recorded with a confidence level and the reporting it rests on, and inferred relationships are labelled as inferred. When a source retracts or corrects, the correction propagates rather than leaving a stale assertion behind.
What this means for you
You can put a finding from this platform in front of a regulator, a court, a board or a partner agency and show where each element came from. That is the standard the tooling is built to — because in this work, being confidently wrong is more damaging than being usefully uncertain.
By the numbers
The taxonomy this entry belongs to is not a marketing list — it is the actual structure of the platform: 52 mission domains, 52 intelligence disciplines and 65 data points, each with a live dashboard behind it. Supporting that: 18 indicator types, 14 playbooks, 16 AI skills, 18 export formats and a 30-step automated pipeline.
This particular entry connects directly to 8 intelligence disciplines, 5 mission domains, 6 closely related entries — every one of them a tag you can follow, and a dashboard you can open.
Questions analysts actually ask
Why do vendors give the same malware different names?
Because naming happens independently at the point of discovery, and there is no central registry with authority to assign. A vendor that sees a sample first names it from its own clustering, and that name enters their products and reporting. Other vendors do the same, sometimes for partially overlapping sample sets, so aliases end up covering slightly different scopes rather than being pure synonyms. Curated references such as Malpedia and MISP galaxies exist specifically to reconcile this. Publish your alias mapping with any product, because the recipient's tooling will be using different names.
Does identifying the family tell me who attacked us?
No. It tells you what software was used, which is a different question. Commodity families are sold or leaked and used by unrelated criminals; ransomware-as-a-service codebases are operated by many affiliates with different tradecraft and targeting; and even bespoke tooling is occasionally shared, stolen or deliberately deployed to mislead. Family assignment supports your defensive response, predicts what to hunt for and connects incidents that share tooling. Actor assessment requires separate evidence such as infrastructure, tradecraft, targeting patterns and non-technical intelligence, and it carries its own separate confidence level.
How much overlap is enough to assign a family?
Enough that the overlap could not plausibly arise from common tooling. Shared configuration format and encryption scheme, matching command and control protocol structure including field ordering and error handling, and reuse of distinctive non-library code routines are strong. Shared packer, common compiler artefacts, similar generic strings and imphash matches on stub imports are weak, because they group by build environment rather than by codebase. State which category of evidence you found. Where only weak evidence exists, report the sample as related to but not confirmed as the family.
What do I do with a sample that matches nothing?
Treat it as a significant finding and raise the priority of the case. In a targeted intrusion, tooling unknown to every public repository suggests bespoke development, which implies investment and intent, whereas commodity malware often implies opportunism. Document the capability thoroughly, write detection on its distinctive constructs, and preserve the sample under controlled access. Consider sharing with a national CERT or a trusted sharing community, which may hold matching material that is not public. Do not upload it to a public repository if it may contain victim-identifying configuration.
Are engine detection names ever useful?
Yes, as hypothesis generators, with the specificity of the name doing all the work. A specific name that maps cleanly to a documented family in a curated reference is worth testing. A generic label such as a heuristic or packer detection carries no family information at all and should be discarded rather than recorded. Note also that engine labels update retroactively, so a sample can be relabelled months later. Record the label with the date you observed it, and never build a report where the only evidence for a family is that several engines used the name.
How should we handle live samples safely?
Under a written policy, on isolated infrastructure, with named responsibility. Analysis environments should have no route to production, no shared credentials and controlled egress, with any internet access explicitly authorised and logged. Store samples encrypted with access limited to named analysts, and never distribute executable malware outside the organisation without a legal basis and a recipient agreement. Record acquisition, storage location and every access. The most common real-world failure is not a lab escape but a sample sitting unencrypted on a shared drive, which becomes a serious incident when the estate is later audited.
Should we publish detection rules for a family?
Usually yes, with judgement. Published YARA and behavioural rules raise the cost for operators across the whole ecosystem and invite correction from peers with better samples. The judgement is about specificity: a rule that reveals a decryption key or an unpatched flaw the operator does not know you have found may cost more than it delivers. Avoid publishing detail that materially assists the operator in evading detection cheaply, prefer rules based on constructs that are expensive to change, and coordinate with law enforcement where an active disruption operation may be under way.
Standards, frameworks and further reading
Work that references a recognised framework is easier to defend, easier to hand over, and easier for a partner to consume:
- MITRE ATT&CK provides the technique taxonomy that turns family behaviour into detection and coverage statements.
- MITRE Malware Behavior Catalog offers a structured vocabulary for describing malware capability independent of vendor naming.
- STIX and TAXII define the structured representation and exchange of malware objects, relationships and confidence.
- MISP taxonomies and galaxies provide community-maintained alias reconciliation and classification vocabularies for families and actors.
- Traffic Light Protocol governs handling and onward sharing restrictions for family analysis distributed through trust communities.
- ISO/IEC 27035 sets out incident management process, within which family identification informs containment and eradication decisions.
- OFAC and equivalent sanctions regimes create strict liability exposure for payments to designated ransomware operators, making screening a legal control.
- Admiralty grading or an equivalent source and information reliability scheme keeps family assignment confidence separate from actor attribution confidence.
References
Primary sources and authoritative references for this entry. Publishers revise and retire material, so treat the retrieval date as part of the citation and re-check before relying on any of it in a formal product.
- Malpedia — Fraunhofer FKIE. Curated malware family library with alias reconciliation and reference samples.
- ATT&CK Software — MITRE. Family entries mapped to adversary techniques and associated groups.
- MalwareBazaar — abuse.ch. Open sample repository with community family tagging.
- ThreatFox — abuse.ch. Community feed linking infrastructure indicators to malware families.
- MISP galaxies — MISP Project. Machine-readable reference data for family and actor naming and aliases.
- Ransomware.live — Ransomware.live. Aggregated ransomware leak site postings used for campaign scope assessment.
- Joint cybersecurity advisories — Cybersecurity and Infrastructure Security Agency. Government technical advisories on specific malware families with indicators and mitigations.
- Sanctions List Search — US Department of the Treasury, Office of Foreign Assets Control. Designations relevant to ransomware payment exposure, including cryptocurrency addresses.
- No More Ransom — Europol and partners. Repository of free decryption tools published following law enforcement disruption operations.
Link integrity: every reference above was verified with a live request when this page was generated. Where a publisher had moved or withdrawn a document, the link was repointed at a preserved copy in the Internet Archive and marked as archived. Anything with no reachable copy anywhere had its link removed rather than left to rot — the source is still credited, it simply cannot be linked.
Put it into practice
The Quantus Intel threat intelligence platform operationalises this entry: family profiles with alias reconciliation, linked infrastructure, ATT&CK mapping and detection content per tracked codebase. Explore the platform, or browse the rest of the library by following any tag above.