What are the signs that malware families are related through shared development rather than just similar tooling?

What counts as shared development signal versus tool similarity?

Shared development is suggested when the overlap is deeper than a common compiler, library, or framework footprint. Look for repeated implementation choices that recur across unrelated functions, especially where the same error handling, state handling, API usage, or ordering logic appears in multiple places. A single shared library can explain a lot; a cluster of unusual choices across modules is harder to dismiss as coincidence.

Tool similarity usually shows up in the “surface area” of the sample: the same packer, the same open-source crypto library, the same HTTP stack, or the same logging helper. Those can make two samples look alike without implying shared authorship. Shared development becomes more plausible when the overlap reaches into how code is structured, not just which dependencies were used. That distinction is central to avoiding false lineage claims.

One useful way to think about it is whether the matching behaviour is portable. If the same function could have been copied into a very different program with little effort, that is stronger evidence than a generic routine that any builder would likely write. The more specific the overlap becomes to internal logic, module boundaries, and coding decisions, the less likely it is to be explained by off-the-shelf tooling alone.

Which code characteristics most strongly suggest common lineage?

The most persuasive signals are repeated uncommon patterns in networking routines, file handling, command execution, and embedded constants. Analysts should pay close attention to modules that behave in the same way under the same conditions, such as identical sequencing of checks, the same parsing edge cases, or the same custom encoding and decoding routines. Those kinds of overlaps often survive even when the outer packaging changes.

Shared modules are especially significant when they perform core malware functions rather than utility work. If two samples implement the same persistence logic, the same exfiltration flow, or the same fallback behaviour with matching quirks, that points to reused source or a shared codebase. Identical logic in error paths can be even more telling, because defensive or failure handling is often where developers unconsciously reveal a stable style.

Embedded constants are another strong indicator when they are specific enough to be unlikely by chance. Hard-coded names, unique thresholds, custom command strings, or repeated derivation values can connect samples even when symbols are stripped. In practice, analysts should compare these features across multiple samples, because a one-off match is weak, but a repeating pattern across a family strengthens the lineage hypothesis.

How should analysts separate lineage from shared tooling?

The cleanest separation comes from comparing what is generic with what is idiosyncratic. Open-source libraries, standard network clients, common packing methods, and routine file operations should be treated as background noise unless they are used in a distinctive way. The real question is whether the same implementation choices recur in places where the tooling would not force them to recur.

A practical approach is to cluster similarities by function and then ask whether each cluster has an alternative explanation. If the same HTTP library appears in two samples, that is expected. If both samples also implement the same retry pattern, the same header ordering, and the same response parsing quirk, the combined pattern is much harder to explain by tooling alone. The value is in the constellation of matches, not any single point.

Analysts should also compare samples against the broader malware ecosystem. If a pattern is common across many unrelated families, it may simply reflect a popular framework or commodity builder. If the pattern is rare, appears in multiple samples, and is embedded in core behaviour, it becomes a more credible lineage marker. That is why manual review still matters after automated similarity scoring, because common dependencies can inflate resemblance without adding evidentiary weight.

Risk and Threat Considerations

Misreading shared tooling as shared development can distort attribution, clustering, and response priorities. The risk is not only analytical error, but also overconfidence in family relationships that may actually be explained by the same public library, builder kit, or commodity framework.

Failure mechanism: Teams over-weight visible overlaps such as imports, packers, or common helper code, while under-weighting deeper structural comparisons and rare implementation details. That can produce false family merges, missed distinctions between campaigns, and weak conclusions about who is reusing whom.

Impact: Incorrect lineage can mislead hunting, reporting, and containment decisions, especially when defenders use family relationships to predict future behaviour, assess reuse, or prioritize clusters for deeper investigation. It can also hide the fact that multiple actors are independently using the same tooling, which changes both threat assessment and response strategy.

Practitioner Guidance

What to verify: Test whether the overlap survives after you remove generic libraries, compiler artefacts, and framework defaults. If the similarity disappears once commodity code is discounted, treat the lineage claim as weak.

What practitioners underestimate: The strongest evidence is often negative space, what is repeated in places that do not need to match. Unusual ordering, custom control flow, and repeated failure handling are often more reliable than obvious signature-like strings.

Practitioner takeaway: Treat shared tooling as a filter, not a conclusion, and only call shared development when the same uncommon implementation choices recur across multiple independent functions.

Related resources from NHI Mgmt Group

• What are the signs that persistent access is being maintained through identity systems rather than malware alone?
• What are the signs that two ransomware families may share source code rather than just similar behavior?
• What makes Shai Hulud 2.0 different from a normal npm malware event?
• What breaks when malware is delivered through shared AI chatbot pages?