From IOC to Adversary: Attribution Basics for Blue Teams

The question every incident ends with

Sooner or later during an incident, someone in a leadership call asks it: "Who is doing this to us?" It is a fair question. It is also the question blue teams are least equipped to answer, and the one where overconfidence does the most damage.

This article is a practical, deliberately skeptical introduction to attribution: how analysts move from a single IOC to a named adversary, what evidence carries weight, where the process fails, and why "how they operate" is worth more to a defender than "who they are".

Attribution is clustering, not naming

Real attribution happens in two distinct steps, and conflating them is the most common mistake.

Step one: activity clustering. You group observed intrusions into a cluster based on shared, distinctive characteristics: the same loader, the same C2 infrastructure patterns, the same working hours, the same victimology. The output is a statement like "these six intrusions were performed by the same hands". This is technical work, and blue teams can do it with their own data.

Step two: attribution to an organization or state. Linking that cluster to a real-world entity (a military unit, a contractor, a criminal crew) requires evidence defenders almost never have: signals intelligence, human sources, financial records, legal process. This is why the strongest attribution claims come from governments and indictments, not from SIEM queries.

Most vendor "attribution" is step one wearing the clothes of step two. A name like APT28 or Lazarus Group is a cluster label, not a passport. Keep that distinction in your head and half the confusion in CTI reporting disappears.

The evidence that actually clusters activity

Infrastructure overlap

Infrastructure is the classic pivot. Two intrusions that share a C2 server are related; the interesting work is in the weaker links. Useful pivots include:

• Shared hosting patterns: same niche VPS provider, same ASN, same registrar habits
• Certificate reuse: the same self-signed TLS certificate or certificate field quirks across servers
• Passive DNS history: a domain from intrusion A previously resolved to an IP from intrusion B
• Registration artifacts: recurring name server choices, registration timing, naming conventions in domains

Pivoting an indicator through mlab.sh enrichment (passive DNS, certificates, ASN context) is exactly this workflow: one IOC in, a map of adjacent infrastructure out. Each individual link is weak. Clusters are built from many weak links pointing the same way.

Beware the shared-infrastructure trap: bulletproof hosters and residential proxy networks serve many unrelated actors. An IP overlap on a provider that hosts half the crimeware ecosystem clusters nothing.

Malware lineage

Code is expensive to write and cheap to reuse, which makes it a strong clustering signal:

• Code reuse: shared functions, identical string obfuscation routines, the same custom crypto implementation
• Fuzzy hashing: ssdeep and TLSH group variants that exact hashes miss
• Build artifacts: PDB paths, compiler settings, compilation timestamps clustered in one timezone's working day
• Configuration structure: the same config block format across families

The caveat is leaked and commodity tooling. After the Cobalt Strike leaks, Beacon proves nothing about identity. Shared malware clusters activity only when the code is private to one operator.

Tradecraft and victimology

The highest-value signals sit at the top of the pyramid of pain: how the actor moves laterally, which LOLBins they prefer, how they name their scheduled tasks, what they steal and from whom. Victimology (consistent targeting of one sector or region) supports a cluster but never carries it alone; everyone attacks the same popular sectors.

False flags: the reason for humility

Actors know analysts pivot on these artifacts, and some actively plant misleading ones.

Olympic Destroyer (2018) is the canonical case: the malware contained deliberately implanted artifacts imitating Lazarus Group tooling, convincing enough that several teams initially pointed at North Korea before deeper analysis and later government statements pointed at Russian military intelligence.

Turla went further: the group hijacked infrastructure and implants belonging to an Iranian actor and ran operations through them, so victims saw Iranian tools attacking them while a Russian group did the driving. That operation was documented publicly by the NSA and UK NCSC in 2019.

The lesson is not "attribution is impossible". It is that single-source attribution is fragile. Cheap-to-fake artifacts (strings, language settings, compile timestamps, reused public tools) deserve less weight than expensive-to-fake ones (private code lineage, long-term infrastructure habits, operational tempo).

Say it with confidence levels

Analytic discipline means separating what you observed from what you assess. Borrow the structured language intelligence agencies use:

Write assessments the way you would want to read them: "We assess with moderate confidence that this activity is consistent with the cluster tracked as FIN7, based on loader code reuse and overlapping C2 patterns." Every claim carries its evidence and its uncertainty. If a report you are reading never states confidence, that is itself a signal about its quality.

Why "how" beats "who"

Here is the uncomfortable truth for defenders: even a perfect attribution rarely changes what you do next. You will not sanction anyone. You will not indict anyone. The name mostly feeds the executive briefing.

What changes your defense is the how:

• The cluster exploits internet-facing VPN appliances first: that reprioritizes your patch queue.
• The cluster lives off the land with WMI and scheduled tasks: that tells you which detections to build and test.
• The cluster exfiltrates via cloud storage APIs: that tells you where your egress monitoring is blind.

This is where a cluster label earns its keep: as an index into documented behavior. Look the group up on actors.mlab.sh, where 500+ actor profiles map aliases across vendors and link each group to its known TTPs and exploited CVEs. You are not looking up the name to know who to blame; you are looking it up to steal their playbook and test your defenses against it.

A sane attribution workflow for a blue team

1. Cluster your own incidents first. Shared infrastructure, tooling, and tradecraft across your cases is evidence you fully control and trust.
2. Enrich and pivot IOCs to expand the infrastructure picture, weighting each link by how expensive it would be to fake or coincide.
3. Compare against public clusters (ATT&CK groups, vendor reporting, actor databases) and note where your observations match and where they do not.
4. State confidence explicitly and record the evidence behind every alias or actor association.
5. Convert the actor profile into action: detections, patch priorities, hunt hypotheses. This step is the point; the rest is scaffolding.

Attribution is a hypothesis with a confidence interval, not a verdict. Cluster rigorously, name cautiously, and defend against the behavior, because the behavior is the only part that will visit you again.