Attribution failed does not prove the attacker was anonymous
A case with no named offender shows what the evidence could establish, not that anonymity worked. Separate guidance, adoption and attribution failure.
A case that ends without a named offender tends to get described as anonymous, and that word does a lot of quiet work. It converts a statement about evidence into a statement about the world. The two are not the same, and for older incidents the difference is often the only thing the surviving record can support. An unattributed incident tells you what could be established, not what was possible.
Five checks keep those two apart.
Check 1: separate the guidance from its adoption
RFC 1281, published in November 1991, recommended keeping and auditing security-relevant records, supporting connection tracing, and naming a security contact for incident handling. It also asked operators to publish what they collected and who could use it. That is a dated record of what was recommended, which is a different claim from what any particular network did.
A recommendation is evidence that the concern existed. It is not evidence of implementation, and it is certainly not evidence that a specific investigation succeeded.
Check 2: name which link in attribution broke
Attribution is a chain, and each link fails in its own way: a network observation, the account associated with it, control of that account at the time, and the evidence connecting that control to a person. An intermediary address is not a location. A username is not proof of who typed at the keyboard. A logged session is not proof that the account owner was present.
Write down which link is missing before writing down a conclusion.
| Evidence | What it actually establishes |
|---|---|
| Source address in a log | An address at that moment, not a person |
| Account name | A credential was used, not who held it |
| Session window | When activity happened, not intent |
| Cross-network correlation | A path, not an identity |
Check 3: date the evidence you are citing
Old reports compress time badly. Records never kept, records expired under a retention policy, records that existed but were never correlated between organizations, and investigations simply not pursued all leave the same trace in a modern summary: nothing. Only the first is a statement about technical capability.
Prefer primary documents with dates over remembered summaries, and quote the sentence you are relying on.
Check 4: resist turning history into a technique catalogue
The historical question is what was observable and what could be established from it. A list of exposed services and default credentials answers a different question, and it is the wrong kind of answer for a reader trying to understand attribution. It is also unnecessary, because the argument survives without operational detail.
If an example needs a recipe to be interesting, the example is doing the wrong job.
Check 5: state the narrower finding you can defend
A defensible finding reads like this: the surviving record shows that guidance existed, that some operators collected authentication logs, and that the specific case produced no evidence sufficient to identify a person. That is narrower than nobody was watching, and it is more useful because it can be checked. Note what would have changed the outcome as well, since missing correlation is a different failure from missing data. Then stop.
Broad claims about an entire decade need records from that decade, not a plausible story about how things used to be.