The morning everything stopped

At 4:47 a.m. on a Tuesday, every workstation and file server at a mid-size contract manufacturer called Hargrove Precision went dark. By the time the first employees arrived at six, the ransom note had already been sitting on every screen for over an hour: a generic template demanding payment in cryptocurrency, a TOR-hosted negotiation portal, and a countdown clock. The production floor, the ERP system, the shared drives - all encrypted. Hargrove's IT team declared a disaster and called in incident response before the coffee was made.

Daniel joined the engagement as a cyber threat intelligence analyst embedded with the IR team. While the responders worked to contain the damage, recover backups, and understand the attacker's path through the network, Daniel's job was different. He was there to answer a question that would matter long after the systems came back online: who did this? Not in the sense of catching someone before the end of the week, but in the structured, documented, probabilistic sense that turns scattered artifacts into an attribution lead - something an organization and its law enforcement contacts can actually use.

Starting with what the attackers left behind

Ransomware operators and their affiliates rarely announce themselves. The ransom note was, as Daniel expected, boilerplate - a template that told him nothing useful about the specific actor. The negotiation portal was a TOR hidden service with no identifying characteristics. What actors consistently underestimate, though, is how much they leave in the open long before the attack: in the infrastructure they built, the personas they constructed, and the habits they developed across years of activity. The attack itself is the last event. The trail was laid down much earlier.

Daniel began with the artifacts the IR team had recovered from the compromised environment: a bitcoin wallet address from the ransom demand, a staging domain used to host the dropper payload, a TLS certificate fingerprint from that domain, and - recovered from endpoint telemetry - an operator alias embedded in a dropper script that had not been scrubbed. The alias was a short handle: vx_marshal. It was a small thread, and Daniel pulled it.

The alias that traveled too far

The first search Daniel ran in Expose was for the handle vx_marshal. The results came back layered. The same handle - sometimes with minor variations like vxmarshal or vx.marshal - had appeared across several years of activity on underground forums indexed in public breach data and archived forum crawls. The persona had posted on at least two forums discussing exploit development, had appeared in a paste archive with a PGP public key attached, and had been referenced in a leak-site post from a ransomware-as-a-service operation that Hargrove's IR team recognized from prior industry reporting.

That last connection was significant. The leak site in question was run by an RaaS operation - a ransomware-as-a-service group that recruits independent affiliates to deploy its malware in exchange for a percentage of ransom receipts. The leak site post mentioning vx_marshal was not a post by the affiliate - it was a comment thread, partially archived, in which the handle appeared alongside a complaint about a negotiation process. It placed the alias in the orbit of that specific RaaS brand without definitively establishing the relationship. Daniel noted it as a moderate-confidence link and moved to corroborate it.

Pivoting through infrastructure

The staging domain recovered from the incident - a registration using a privacy proxy, aged roughly eleven months - gave Daniel his next pivot point. He ran the domain through Expose against certificate transparency logs, passive DNS records, and hosting overlap data aggregated from public sources. The TLS certificate it had used had been issued to a small cluster of domains registered in a similar pattern: same registrar, overlapping registration dates, similar naming conventions mixing short pseudo-random strings with generic terms.

Two of those related domains appeared in prior public reporting - not from this incident, but from an unrelated compromise at a logistics company eight months earlier, documented in a threat intelligence sharing community whose disclosures are publicly accessible. The infrastructure overlap was not coincidental. Actors building their own staging environments reuse hosting accounts, certificate issuers, and registrar habits across campaigns because it is cheap and operationally convenient. Each reuse is a quiet link between incidents that were otherwise unconnected.

Daniel used Expose to pull those prior domains into a timeline alongside the current staging domain, mapping the hosting overlap visually. The picture that emerged was of a single operator - or a small, consistent team - who had been running campaigns from related infrastructure for the better part of a year:

• the Hargrove staging domain, registered eleven months before the incident and hosted on a VPS provider in Eastern Europe;
• two predecessor domains from the logistics company incident, sharing the same certificate issuer and a two-day registration window with the Hargrove domain;
• a fourth domain, surfaced by Expose from a paste-site dump, that had hosted a file with vx_marshal's PGP key as a contact reference;
• hosting ASN overlap across all four, pointing to the same upstream provider account.

Following the money - and its limits

The bitcoin wallet address from the ransom note was Daniel's third thread. Cryptocurrency addresses are pseudonymous, not anonymous, and the public ledger that records every transaction on the bitcoin blockchain is openly searchable. Daniel ran the wallet through Expose against aggregated blockchain explorer data and known wallet clustering information from public sources and prior disclosures.

The wallet itself was fresh - created for this campaign, a common practice among more operationally aware actors. But wallets don't exist in isolation. Funds from fresh campaign wallets are typically moved to mixing services or consolidated through intermediary wallets before reaching the operator's longer-term holdings. Two hops from the Hargrove demand wallet, Expose surfaced an intermediary address that had received funds from three other addresses flagged in publicly available ransomware payment tracking data maintained by researchers and shared openly. One of those flagged addresses had been cited in connection with the same RaaS operation whose leak site had mentioned vx_marshal.

Daniel was careful about what this established. Wallet clustering from public blockchain data is probabilistic, and two hops through intermediary addresses is a plausible link, not a proven one. He logged the connection as a supporting indicator - meaningful in context, but not sufficient on its own. Crypto trails corroborate; they rarely convict.

"Attribution is an argument, not a finding," Daniel said later. "You're assembling evidence that a specific actor probably did something, and you have to be honest - in writing - about what 'probably' means and where the uncertainty lives. A link that's two hops through a blockchain intermediary is not the same as a direct match. It matters. It's not proof."

Separating the affiliate from the brand

One of the most important analytical distinctions Daniel documented was the difference between the RaaS operator and the affiliate who had actually conducted the Hargrove intrusion. Ransomware-as-a-service works like a franchise: the operator group develops and maintains the malware platform, runs the leak site, handles some of the negotiation infrastructure, and collects a cut of every ransom paid. The affiliates are independent contractors who do the actual intrusion work - gaining access, moving laterally, deploying the payload - and keep the majority of the proceeds.

This distinction mattered enormously for attribution. The evidence Daniel had assembled pointed to vx_marshal as an affiliate - a contractor operating under the RaaS brand, not someone who controlled the brand itself. The infrastructure, the forum persona, the wallet trail: all of it was consistent with an independent operator running campaigns on their own, using a licensed malware platform. Attributing the attack to the RaaS brand as a whole would have been an overreach. The attack at Hargrove appeared to be the work of one specific contractor, and that distinction shaped how Daniel framed everything that followed.

Building the attribution case

After three hours of pivoting through Expose and cross-referencing against public threat intelligence disclosures, Daniel had enough to structure a formal attribution assessment. He was rigorous about confidence levels, which varied by link:

• High confidence: the handle vx_marshal was embedded in dropper artifacts recovered from the Hargrove environment, and the same handle appeared across multiple independent public sources spanning at least two years - forum posts, a PGP key paste, and infrastructure references.
• High confidence: the staging infrastructure used in the Hargrove attack overlapped with infrastructure used in a prior campaign, confirmed through certificate transparency logs and passive DNS data available from public aggregators.
• Moderate confidence: the vx_marshal persona operated within the affiliate ecosystem of a specific RaaS brand, based on the leak-site reference and the wallet chain proximity to flagged addresses. Multiple links, but each individually indirect.
• Low-to-moderate confidence: the vx_marshal persona corresponded to a single individual rather than a small team sharing the handle. Single-actor assumption was the most parsimonious reading of the evidence but not confirmed.
• Not established: real-world identity behind the handle. The public record had produced a documented threat actor persona and a consistent infrastructure fingerprint. It had not produced a name, a location, or a verified identity.

Every pivot Daniel had made - from handle to infrastructure, infrastructure to prior campaign, wallet to intermediary address - was documented with the source, the date accessed, and the confidence level assigned to that specific link. The assessment was a structured argument, not a summary. Someone reviewing it should be able to follow every step and challenge any link they found unconvincing.

What OSINT builds - and what it doesn't

Daniel delivered the attribution package to Hargrove's legal team and, through them, to the relevant law enforcement contacts the IR firm maintained. He was explicit in the cover document about what the assessment was and wasn't. Open-source intelligence attribution surfaces a probable lead - it does not establish guilt, and Daniel had done nothing that required access to any system or data he wasn't entitled to view. Every source was public: blockchain explorers, certificate transparency logs, archived forum data, threat intelligence community disclosures, paste site archives. No hacking back, no covert access, no offensive action of any kind.

What the package gave investigators was a documented starting point: a consistent threat actor persona with a multi-year history in public-indexed sources, an infrastructure fingerprint that tied the Hargrove attack to prior campaigns, and a crypto trail that corroborated a connection to a known RaaS ecosystem. That is the appropriate use of OSINT in threat attribution - building a structured, defensible lead that law enforcement can pursue using the legal tools and investigative authorities that analysts don't have.

For Hargrove, the attribution work also had immediate operational value. Understanding that the intrusion bore the marks of a specific affiliate's campaign - rather than, say, a nation-state actor or an insider - shaped the IR team's recovery priorities, the insurer's incident classification, and the security improvements Hargrove chose to prioritize. Knowing roughly who came through the door is not irrelevant just because you can't prove it in court.

The discipline that makes attribution useful

The easy version of threat attribution is the one that declares a confident conclusion and stops there. It feels satisfying, and it is almost always wrong in some dimension. The version that holds up - in law enforcement briefings, in legal proceedings, in insurance claims, in board-level reporting - is the one that documents every step, assigns honest confidence levels, distinguishes between what the evidence shows and what it suggests, and is explicit about what remains unknown.

Daniel's work did not put vx_marshal in a courtroom. It was never meant to. It gave Hargrove and its law enforcement contacts a structured, sourced, reproducible lead that named a probable actor, documented the operational fingerprint that connected this attack to prior campaigns, and gave investigators something real to pursue. That is what good OSINT attribution delivers: not a verdict, but a well-built argument that the people with legal authority to act can actually use.

The attackers thought generic ransom notes and fresh wallets made them invisible. What they hadn't accounted for was the record they'd been building in the open for years - the reused handle, the consistent infrastructure habits, the archived forum posts. Those threads didn't disappear when the encryption ran. They were still there, waiting for someone patient enough to pull them.