One shellcode, two names: what Volexity's UTA0560 finding says about attribution confidence

Opening

Volexity reported that UTA0560, a cluster it tracks, uses the same shellcode as activity attributed to APT31 and tracked elsewhere as TA412. The technical observation is narrow. The implication is not.
When two tracks of activity share an identical binary artefact, the immediate question is whether they are one group, whether one copied the other, or whether the shared component came from somewhere else. Each answer changes what a defender should conclude from an attribution claim, and the tools usually available to a defender cannot distinguish between them.

Technical context

What was shared

Shellcode is the position-independent machine code that an exploit or loader runs after it has achieved execution. It is usually generated once, embedded in a loader, and reused while it works. Sharing it across campaigns is ordinary tradecraft rather than an accident, and it means the artefact is a durable identifier only for as long as the author keeps using it.
The value of the finding is that the shared component is specific. A shellcode blob is not a generic technique; it is a file with particular bytes. Finding the same bytes in two places is evidence of a relationship between those two deployments. The ambiguity is in what kind of relationship.

The four explanations

The first is shared ownership. One team operating under two tracking names, with tooling reused across target sets. This is the explanation most commonly implied.
The second is reuse by a second party. A tool, loader or builder leaked, was sold, or was captured and repurposed. Tool sharing among criminal and state-adjacent actors is common, and a shared component then means shared supply, not shared command.
The third is deliberate planting. A well-resourced actor can plant another group's artefacts to misdirect. This is rare and expensive, and it is over-weighted in discussions of attribution because it is the most dramatic possibility.
The fourth is a false association. The same shellcode can be produced by a shared third-party builder, a public proof of concept, or a common framework, in which case it identifies a tool rather than a team.

What the public record allows

A report that documents a shared artefact is reporting an observation. Attribution reporting generally stops short of asserting identity between two clusters unless the evidence extends beyond the artefact, and it usually does: infrastructure patterns, targeting, operational timing, and language artefacts.
The finding's value is in what it tells the reader to do with the assertion. A shared component is a reason to look at the whole evidence set. It is not a reason to merge two investigations.

Explanation and walkthrough

Why attribution confidence is an operational variable

For an intelligence consumer, the practical difference between "these are the same group" and "these two groups share supply" is not philosophical. It determines the response.
If a single group is conducting both sets of activity, the defenders in both target sets should assume the adversary has capability proven against the other. If the tooling is shared through supply, the defenders should assume they may face it without the other population's targeting being relevant. If the shellcode came from a builder in wide use, the defenders should assume they are one of many and the tooling will keep appearing.
The defensive actions overlap: patch the exploited path, hunt the loader, block the infrastructure. The prioritisation and the expected persistence of the threat do not.

What defenders can actually do with a shellcode match

Not much, directly. A shellcode match is not a signature that produces durable detection, because the author can change it and detection dependent on exact bytes has a short half-life. The durable output is the loader behaviour that surrounds it: the parent process, the injection method, the persistence mechanism, the network destination pattern.
Public attribution reporting is most useful here, and most often misread here. The report contributes context about an actor. The defender's job is to convert that context into a hypothesis about what would happen on their own endpoints, then check whether it is already happening.

The discomfort the finding creates

Attribution is delivered to decision-makers as a product, and products are expected to be conclusive. A finding that two named clusters share a component introduces ambiguity into a conclusion that was previously stated with more confidence. The professional response is not to abandon attribution but to state its basis.
The useful discipline is to separate three claims in any attribution assessment: what the artefact proves, what the infrastructure suggests, and what analysts assess. Reports often do this and readers often collapse it. A shared shellcode proves the artefact is shared. Anything more requires the rest of the case.

Defensive implications

• Read attribution reports for their evidence types, not only their conclusions. A shared binary, a shared infrastructure range and a shared targeting pattern carry different weight.
• Hunt behaviour, not bytes. Shellcode hashes change; loader behaviour and network patterns persist longer.
• Track which findings affect prioritisation. A shared-tooling finding may not change what you patch this week, but it changes how long you expect the threat to persist.
• Do not treat attribution ambiguity as a reason to defer. The exploited path in the report is a specific technical finding. That part is actionable regardless of which name is on the campaign.
• Record your own artefacts. An organisation that captures and stores its own incident artefacts can compare them against public reporting. Without that record, external attribution is a one-way channel.
• Expect supply-sharing to increase. As tooling circulates among more capable actors, shared components become a weaker basis for identity claims and a stronger basis for capability claims.

References

• Volexity research on UTA0560
• Public reporting on APT31 and the TA412 tracking designation
• MITRE ATT&CK entries referenced in the UTA0560 reporting