Volexity's UTA0560 shellcode match with APT31 activity tests attribution confidence

The finding

Volexity has reported that UTA0560, a threat cluster it tracks, uses the same shellcode as activity attributed to APT31 and tracked elsewhere under the designation TA412. As a dev.to analysis of the research explains, the observation itself is narrow — one binary artefact appearing in two bodies of activity — but it lands on a question at the centre of threat intelligence work: how much a shared tool actually proves about who is behind an operation.

What the shared artefact is

Shellcode is small, position-independent machine code that executes once an exploit or loader has taken control of execution on a target. According to the dev.to write-up, such code is typically built once, embedded in a loader and kept in service while it stays useful, which makes reuse across campaigns routine practice rather than a mistake.

That cuts both ways. A shellcode blob is a specific file with particular bytes rather than a generic technique, so the same bytes turning up in two campaigns is genuine evidence that the deployments are connected. What it cannot establish on its own is the nature of that connection.

Four explanations, four different conclusions

The dev.to analysis sets out four ways to read the overlap. The first is shared ownership: one team operating under two tracking names, reusing its tooling across target sets. This is the reading usually implied when two clusters get linked.

The second is reuse by a second party, in which a loader, builder or tool leaked, was sold, or was captured and repurposed. Because tool sharing between crime groups and state-aligned operators is common, a shared component under this reading points to a common supply chain rather than a common command structure.

The third is deliberate planting, where a well-resourced actor seeds a rival's artefacts to misdirect investigators. The analysis calls this uncommon and costly, yet notes it looms larger in attribution debates than its frequency justifies, largely because it is the most dramatic scenario.

The fourth is a false association: identical shellcode can come from a shared third-party builder, a public proof of concept, or a common framework, in which case the artefact identifies a tool, not a team.

Why the difference is operational

For intelligence consumers, the practical difference between one group running both campaigns and two groups drawing on the same supplier is not philosophical. If a single adversary is behind both sets of activity, defenders in each target population should assume the attacker can do to them what it has already done to the other. If the tooling circulates through supply, that capability may arrive anywhere without the other population's targeting being relevant. If the shellcode came from a builder in wide use, defenders should expect it to keep surfacing.

The immediate actions overlap — patch the vulnerability being exploited, hunt the loader, block the infrastructure — but, as the analysis notes, the prioritisation and the expected persistence of the threat differ sharply between scenarios.

What a match gives defenders

Directly, very little, the dev.to piece argues: detection keyed to exact bytes goes stale quickly because the author can simply change the code. The durable signals sit around the shellcode — which process spawns the loader, how code is injected, how persistence is established, and where the traffic goes.

The wider recommendations include reading attribution reports for their evidence types rather than only their conclusions, since a shared binary, a shared infrastructure range and a shared targeting pattern carry different weight; keeping apart what an artefact proves, what infrastructure suggests and what analysts assess; and refusing to defer action while attribution is unresolved, because the exploited path is actionable whichever name sits on the campaign.

The analysis also urges organisations to capture and store their own incident artefacts so public reporting can be checked against internal evidence, and it predicts that as tooling circulates among more capable actors, shared components will say less about who an actor is and more about what they can do.

Why it matters

Attribution reaches decision-makers as a finished product, and finished products are expected to give a firm answer. A finding that two named clusters share a component injects ambiguity into conclusions previously stated with more confidence. The dev.to analysis frames the professional response not as abandoning attribution but as being explicit about what supports it: the shared shellcode proves only that the shellcode is shared, and the overlap justifies reviewing the complete evidence base rather than folding two investigations into one.