Aggregation and attribution
Attack tools are not usually developed for a single taget. As mentioned earlier on, attackers like to reuse existing components to save time and money. When looking at targeted attacks, however, we need to broaden our view to include how the methods of the attackers have developed over time. If you factor in a timeline it becomes immediately clear that attack groups do not appear out of nowhere. They have developed and refined their tools and techniques. This evolution sometimes makes it difficult to attribute a current event to an existing group.
Establishing connections between different threat actors is not a trivial matter. Following an old tradition in the security industry, whoever detects a threat first also has the right to name it. Oftentimes there are references made to components within the malware itself, such as prominent strings, debugging messages or similar items (see "0zapftis").
When diving deeper it often turns out that, while the name might be a different one, the attack group is the same. The difference is that time has not been factored in. Should an attack group have learned from a mistake they have made in the past and remediated it, in many cases their malware gets a different name assigned. The same happens if a new function is added to the attack group's toolset. This results in attributions to groups such as "EnergeticBear", "DragonFly" or CrouchingYeti" - all those groups, however, are identical and also go by the name of "Havex".
Why is naming a group so important, one might rightfully ask. The answer is surprisingly simple: when looking at all the attacks of the different (yet identical) groups and then establishing a timeline, you get a very precise picture of how the group's has developed their target approach over time. Additional criteria can be used for this. At this stage we would like to point to part #2 of this article series again.
When going back to data from past campaigns of a threat actor and compare this data to current events, differences surface which would otherwise gone unnoticed. When a threat group develops their toolset, it is almost never rebuilt from scratch. Chances are high that old code or old files are reuse to save time and money. Therefore, if a file or parts of the source code from a current event are identical to a past event then this can be viewed as conclusive evidence about the creator of the file. This piece of information is relevant when examining attacks which are imminent or even currently in progress: does the threat group attributes with the attack prefer certain types of target? Are their actions limited to a geographical region or does it act globally? This is absolutely vital information for reviewing APT scenarios as it can yield clues to possible mitigation strategies.