tl;dr consider not using other org's malware family names when it isn't obvious, and provide good IOCs and/or Yara sigs when you create/use your own names

-----

It seems like CTI analysts are collectively getting better about not using other vendor's names for threat groups/clusters (e.g., not-Mandiant calling something APT42, not-Proofpoint calling something TA453) (maybe just because of the resident APT35 reply guy, @chicagocyber).

However, a far less talked about but similar scenario is malware family naming. This has a lot of the same pitfalls, and can often cause analytical confusion, especially when people use malware family names synonymously with threat groups (Carbanak, Winnti).

Let me start with a not-so-uncommon scenario:

* Vendor A tracks a new malware family has TRASHFIRE. They publish a blog on the family, and release some hashes.
* Some time passes, and Vendor B has identified malware that has similar functionality to TRASHFIRE. Instead of using their own name, they call it TRASHFIRE, and publish a blog on the activity.
* Simultaneously, Vendor A has internally been tracking the activity Vendor B just reported on, but they use a different name for the malware.

This leads to confusion in the public space about what TRASHFIRE is, and could lead to bad analysis, pivots, and attribution by future analysts (a la the APT35/APT42/Charming Kitten confusion).

However, unlike threat groups, analysts far more commonly observe malware that names itself, with artifacts leftover in the samples that analysts can recover, and use to derive the intended name. While it's often convenient to use these names, they come with their own set of pitfalls sometimes:

* Bad guys lie. If someone write an implant and call it PlugX, but it doesn't have any technical relation to PlugX, should an analyst track it as PlugX? I don't think so. (caveat: tracking that it calls itself PlugX can be meaningful, and is distinct from what I'm discussing in this post)
* Distinct malware families often have overlapping names, often without being intended. If the presented name of a malware family is taken at face value, and another analyst down the road observes a sample with the same name, this can create wrong assessments on the sample if not properly validated. Using a different name can eliminate this from happening.
* Threat actors often rename malware to disguise its origin, even when the code itself is the same as something with a different name (hello ransomware "developers"). This is similar to the first example, and tracking what the malware calls itself is often relevant, but if you are focused on understanding the code itself and how it fits into the broader ecosystem, taking the RaaS name associated with the ransom note and codifying that as the family of the sample limits the usefulness of your names.

At it's core, assigning a name to a piece of malware is a similar task to attributing a set of activity to a threat group/cluster. You have a set of data (bytes instead of commands/domains/IPs/etc) to investigate and determine its meaning and relevance in the bigger picture, and determine how it fits into the rest of your data. The analytic rigor you dedicate to this task varies depending on your overall tasking, and this influences the precision of your assessment: is it benign/malicious? is it a backdoor, infostealer, proxy, etc.? what specific malware family is it? how does it compare/how has it evolved from previous versions? All of these factors influence how a specific entity derives a name for a family, and are very similar to the factors affecting threat activity attribution.

All of that being said, the two problems are not 1:1, and in fact there are often strong cases for why a consistent public name should be used. I can immediately think of two, and I'm sure there are other cases as well:

* Commercial products such as Cobalt Strike, Core Impact, and Brute Ratel
* Malware families that the community at large has a solid consensus on (big banking trojans come to mind here, e.g. Qakbot/Icedid)

An obvious downside to this, and one that is talked about a lot in the "why shouldn't X use Y's name" debate, is that it can create additional confusion for an analyst to understand what all of these different names are and how they overlap. Similar to how it can be mitigated for the threat group naming debate, I see three obvious mitigations:

* Public reporting on a family should provide common AKAs for the family, and enough IOCs (with context!) that an analyst can easily consume it and assess overlaps in their own dataset
* The CTI community should continue sharing high quality Yara rules for specific families, which can be used in an automated fashion to assess overlap between families (assuming the rule doesn't FP and the anchor for the rule was correct, some very large assumptions)
* Analysts should favor platforms that make the identification of overlaps easier to surface, and limit the overhead it takes to determine how these overlap. @vertexproject makes this trivial, and I would guess that MISP and OpenCTI have options for this as well.

I think the argument for a malware family name rosetta stone is a lot stronger than that for threat groups, since access to samples (i.e. the raw data needed to make an assessment) is far more ubiquitous than access to high quality intrusion data (which I can count on two hands the number of private orgs with). Folks like the @mitreattack team and Arkbird_SOLG have done great work to make overlaps between threat groups publicly accessible, and a malware-centric version of that would be even more useful.

(for additional info on this from the threat group naming perspective, check out this @CuratedIntel blog: https://www.curatedintel.org/2022/05/threat-group-naming-schemes-in-cyber.html)

I am sure that many individuals in the CTI/infosec space have thoughts both for and against this proposition, but I think that this is a conversation worth having, and would be curious to hear them. It's certainly not as clear cut as the threat group naming debate (at least for me).

(also this ended up being way longer than I thought, maybe I should convert it to a blog post? idk how mastodon works)

The definition of “supply chain attack” feels like it’s getting stretched pretty thin if you’re extending it to trojanized installers of legitimate software distributed via torrent sites.

By that definition, all the malware ever downloaded off LimeWire constitutes a “supply chain attack”.

Now if you’ll excuse me…

I can’t get over Kaspersky laying out exactly how much of a dog on a leash they are. This is the equivalent of putting on a big puppy dog face and going “Please Daddy Vladdy, don’t put the hurt on me! I’m just a lil’ guy and I promise I’ll be a good collection enabler and never speak ill of you!”

(link for those who want to see the shame: https://securelist.com/reassessing-cyberwarfare-lessons-learned-in-2022/108328/#_ftn2)