Following one ransom, properly: a Qilin case, from the first host to the money

A note on this write-up.
This is the long version of a talk given at leHACK.
Identifiers are defanged: C2 IPs are masked, on-chain addresses and transaction IDs are redacted, exact amounts are rounded and block heights and timestamps withheld so the victim's transaction can't be trivially re-identified from a public explorer, GraphSense entity IDs are dropped, and the victim is referred to by sector only.
Exchange attributions are trace-derived, not ownership-grade, and the venue names are withheld in this public version (see Methodology & confidence). Negotiation economics from the engagement are withheld (TLP:AMBER+STRICT). Everything else is on-chain and public by nature.

TL;DR

A healthcare-sector victim was hit by Qilin (aka Agenda). The entire break-in
was one login: the built-in administrator opening an RDP session to the DC at 02:45 from a VPN-natted gateway IP, with a valid credential and no exploit. The attacker sat for 19 days, then launched encryption from the Veeam backup server, not the domain controller. The DC went silent at 22:22 and stayed dark for 30 days before anyone noticed.

Two things made this case worth writing up:

1. The infrastructure pivot. The attacker wiped their logs but left one WinSCP.ini. It stored the raw ed25519 host keys of 11 C2 servers, as point coordinates, not fingerprints. We reconstructed the fingerprints (RFC 8032), pivoted on internet-wide scan data, and went from a config file to live attacker tooling without sending a packet at the target.

2. The money. On stage we compressed the on-chain trace into "one payment → exchanges." That was a lie of brevity, and the room called it out. The real trail is a four-layer laundering machine with two segregated cash-out tracks, an intake-time 80/20 split, a coinjoin coordinator with €2.15B of total multi-party throughput in 73 hours (the operator is one depositor among hundreds, not the owner of that sum), and a destination wallet that had been flagged as criminal five months before the victim paid. And it was not a single payment: the same operator-hub address is shown, on the public chain alone, funding a second victim's ransom seventeen days later. This post gives that trace the room it deserves.

Timeline (one clock)

Who is Qilin

Thirty seconds on the adversary, because the structure matters for the money. Qilin (aka Agenda) is a Ransomware-as-a-Service operation, active since 2022. An operator runs the platform and the leak site, affiliates do the actual break-ins, and the two split the take. The negotiation and operational tradecraft is inherited from Conti,
which, as you'll see, runs all the way down to how the operator and the affiliate launder separately, on two tracks that never touch.

By volume it is the most active ransomware brand on earth right now. Victims named on its leak site went from 167 in 2024 to 958 in 2025, a +474% jump as LockBit and RansomHub collapsed, and 2026 is on pace to beat that again (1,911 leak-site posts all-time). The economics are the most affiliate-friendly in the market: affiliates keep up to 85% of each ransom, and the operator takes the rest for running the platform.
Demands come primarily in BTC, occasionally XMR. Hold that split in your head, because in the trace below you watch the 80/20 cut happen on-chain.

It is not abstract. Qilin's most infamous hit, the June 2024 Synnovis / NHS London attack, delayed 11,000+ patient appointments, forced a national blood appeal, and was cited as a contributing factor in a patient's death. And yet Ransomwhere, the public ransom-payment database you'd reach for to ask "how much is this group really making," has zero entries for Qilin; it skews toward 2018 to 2021 families. The busiest group on the planet is effectively invisible to the feed built to track ransom payments. No public feed tracks it is not the same as it isn't happening, which is exactly why one case, traced
properly, is worth the length that follows.

Figures: leak-site counts via Ransomlook and public reporting; Synnovis impact per NHS
England / BBC. Throughput and payment specifics below are from our own case work.

Pillar 1: One leftover file → their whole network

The DC was clean: no log-clearing, no audit tampering, no attacker tooling. The real evidence sat on the staging host the encryption ran from, in a folder named C:\ProgramData\update\ (boring on purpose; a folder of installers reads like patching). Among the tools (Atera RMM as C2, NetScan, PsExec, a recon .bat) was a portable WinSCP, and WinSCP keeps a diary.

WinSCP stores the host keys, as raw points

WinSCP.ini has a [SshHostKeys] section recording the SSH host key of every server it ever connected to. For ed25519 it stores the key in PuTTY's legacy format: the affine (x, y) coordinates of the Edwards point, not the fingerprint that Shodan and Censys index on.

[SshHostKeys]
ssh-ed25519@22:45.135.xxx.xxx = 0x89272fd8…f32199,0x2cebc698…92ebdc
ssh-ed25519@22:176.120.xxx.xxx = 0x89272fd8…f32199,0x2cebc698…92ebdc   ; <- identical key
ssh-ed25519@22:179.43.xxx.xxx = 0x…
…11 distinct C2 servers logged in total

Two IPs carrying the identical (x, y) is the first finding: they are one server identity behind two addresses, the same operator-controlled host, or a clone of its image.

Reconstructing the fingerprint (RFC 8032 §5.1.2)

To pivot, we need the SSH fingerprint, which means turning (x, y) back into the 32-byte wire-format public key, then hashing it. Point compression is the whole trick: encode y little-endian, and fold the low bit of x into the top bit.

# WinSCP stores the ed25519 host key as the affine (x, y) of the Edwards point.
x = int(parts[0], 16)
y = int(parts[1], 16)

# RFC 8032 §5.1.2: compress to the 32-byte SSH pubkey.
pub = bytearray(y.to_bytes(32, "little"))   # y, little-endian
pub[31] |= (x & 1) << 7                      # fold bit-0 of x into the top bit

blob = ssh_string(b"ssh-ed25519") + ssh_string(bytes(pub))

# Hash the wire blob: each scanner indexes a different encoding of it.
md5    = hashlib.md5(blob).digest()
sha256 = hashlib.sha256(blob).digest()
shodan_fp  = ":".join(f"{b:02x}" for b in md5)                       # Shodan  ssh.fingerprint   (colon-MD5)
censys_fp  = sha256.hex()                                            # Censys  fingerprint_sha256 (hex)
openssh_fp = "SHA256:" + base64.b64encode(sha256).decode().rstrip("=")  # ssh-keygen -lf (base64)

The reconstructed value is byte-for-byte what ssh-keygen -lf prints for the same key. We verified it against freshly generated keys before trusting it on the case data: reconstruct (x, y) → fingerprint, compare to ssh-keygen, identical.
That's nine lines of point math, no magic, and it's the entire basis for the pivot.

Pivot on the key, not the address

The C2 IPs from the config are cold today: query them on Censys/Shodan and you get no results; even where a host answers, the host key is No Data. The operator rotated away months ago. The IP rotates before any blocklist publishes it. The fingerprint does not.

So you search the fingerprint across the internet's existing scan data, with no active scanning at the target:

# Shodan
ssh.fingerprint:"51:f9:bc:a6:…:ee:29:04"

# Censys
services.ssh.server_host_key.fingerprint_sha256="9a51cbb8…719a82cd"

Each query returns every host presenting that key, including addresses never written in the config, and it catches IP rotation the moment the operator moves; the key travels with the server. Clustering the results by identity, not address surfaces the wider fleet.

From the whole internet to nine hosts

Knowing the affiliate's tooling, we turned their habits into Censys filters and
intersected two ordinary signals into one rare combination:

http Server header = "CerberusFTPServer/2024"     # 300 hosts run it
  AND labels.value = "RMM"                        # the affiliate also ran Atera
→ 9 candidate hosts

By itself, Cerberus FTP is on ~300 hosts; an RMM label is common too. Asked for both at once, the internet collapses to 9 hosts that look like this operator, one of which served a live Cerberus Web Client login page (the affiliate's browser-based tool for moving stolen victim files).

From the whole internet to nine servers: 300 hosts run the affiliate's Cerberus FTP build; intersect that with an RMM label and the internet collapses to nine candidate hosts.
Honest framing. Those nine are a shortlist of candidates to investigate,
not confirmed attribution; but a shortlist of nine, built from one victim's
leftover file, with zero packets sent at the target.

Pillar 2: Following the money, properly

This is the section we owe the room. On stage it became "the victim paid, and the money went to exchanges." Here is what actually happened.

First, the methodological point that makes the rest legible: we do not trace addresses, we trace entities. A blockchain address is a leaf. Using the common-input-ownership heuristic (co-spend clustering, the engine inside tools like GraphSense), addresses that are spent together are inferred to be controlled by one actor and collapsed into an entity. The "one transaction → exchange" story skips every entity, every intermediate relay, and the split that happens before anything reaches a cash-out. Put those back and the picture changes completely.

The payment, and the move before it

• Ransom: ~2.5 BTC (≈ €150k), early April 2026, into an operator-controlled intake address. (Exact amount, block, timestamp and tx hash are withheld here. Together they'd pull the unredacted victim transaction from any explorer in seconds.)
• 3.5 hours earlier: a 0.0001 BTC dust transaction, victim wallet → ransom address. This is a victim test-send (confirming the address works before wiring six figures), not an operator action. That is precisely why it's a dependable signal rather than fragile tradecraft: it's the victim's own caution, so the operator can't suppress it without instructing victims to stop verifying the address. As an on-chain tell, a tiny inbound to a ransom address routinely precedes the full transfer, so spotting it buys a few hours' notice that a payment is imminent.

A 0.0001 BTC test ping fires 3.5 hours before the full ~2.5 BTC payment, from the same wallet to the same address: the very first on-chain move, almost invisible, and a live warning that a payment is coming.

The funding anomaly

Before the payment, where did the victim's BTC come from? Tracing the victim wallet backwards, its ~2.5 BTC arrived via a single-use relay funded by the operator hub (~12 BTC → relay → ~2.5 BTC → victim), and the funding transaction sits in the same block as the ransom payment. The victim held the coins for less than one block. Victim and operator infrastructure demonstrably touch before the ransom is paid. That much is confirmed on-chain.

The interpretation needs care, and our earlier instinct ("the operator seeded the victim's wallet") is probably the weaker reading. The more likely one: the victim bought BTC through a gray-zone OTC desk that the operator also launders through. The hub behaves like a high-volume OTC (four-year history, hundreds of counterparties, ~€388M throughput), and ransomware crews are known to steer victims toward "no-questions" desks they themselves use. On that reading the shared infrastructure needs no victim complicity and no bespoke pre-funding; operator-seeding becomes a secondary hypothesis, not the default. Either way the on-chain fact stands, and, as a later section shows, the same just-in-time
funding shape recurs in a second incident, which fits a shared OTC far better than per-victim seeding.

One caveat that colours everything downstream: we call it "the operator hub" as shorthand, but whether the hub is operator-owned infrastructure or a third-party gray-market desk the operator merely uses is unresolved on-chain. The distinction is not academic. If it is a shared desk, its ~€388M lifetime throughput is the desk's volume, not Qilin's revenue, and the downstream "relays" are ordinary hot-wallet change rather than bespoke laundering hops. We keep the "hub" label for readability and flag the ambiguity rather than smooth it over.

The split happens at the intake, not at an exchange

The ransom address is an operator-controlled intake. Funds do not flow from it to an exchange. They split, within hours:

• 80% (≈2.0 BTC) → the affiliate pool
• 20% (≈0.5 BTC) → the operator's mixer pool

This is the inherited RaaS revenue model expressed on-chain, and it's the first thing the compressed version erased.

Two segregated tracks that never meet

From the split, the money runs down two independent laundering tracks. A 3-hop forward trace from one never reaches the other; they are deliberately kept apart. (Operationally: two cash-outs, two subpoenas.)

The affiliate track (the gang's cut).
The 80% lands in an affiliate pool, a cluster with ~€194M lifetime
throughput across ~2,196 counterparties, drained to zero. The pool then exits in a single batch of 1,604.15 BTC ≈ €113.6M (>99.95% of its balance) to an off-ramp cluster carrying multiple exchange tagpacks, consistent with an OTC / institutional desk (working hypothesis). Co-resident in that off-ramp cluster is a Phobos payment address from 2021 (suggestive only; a CIOH cluster-merge artifact cannot be ruled out from a single address).

The operator track (the brand's cut).

The 20% enters the operator's mixer pool, a WabiSabi-style coinjoin
coordinator (P2TR) that processed 35,621 BTC ≈ €2.15B in the same 73 hour window (~€700M/day). That €2.15B is the coordinator's total multi-party throughput, not the operator's money; the operator is one depositor among hundreds, which is precisely the point of using it. From there:

• a direct hop to one exchange (10.97 BTC);
• the rest through a CFLW-tagged abuse corridor (21,541 BTC across ~25k addresses) that fans out to four more exchange clusters (22.62 / 8.13 / 6.88 / 5.20 BTC);
• and a leg back into a public Wasabi CoinJoin (~22.5M addresses), the end of trace.

Crucially, a portion of the mixed output (≈77%) re-merges toward the affiliate pool; the two tracks brush on-chain but the cash-outs stay segregated.

The warning nobody used

The affiliate pool, the wallet the victim's money actually landed in, was tagged abuse / financial_crime by a commercial dark-web feed on 2025-11-06, five months before the payment. The ransom-note address itself was fresh and screened clean; the destination did not. Screening only the address you're given shows nothing. Screen the cluster it belongs to, and re-screen the moment funds move.

The detailed trail (defanged)

The full map: the victim pays one ransom into an operator-controlled intake, which splits 80/20. The 80% gang's cut runs down the affiliate track (affiliate pool → single-batch off-ramp); the 20% brand's cut runs down the operator track (coinjoin mixer pool → CFLW abuse corridor → five trace-tagged exchange clusters). The operator hub also funded the victim's wallet before payment. Wallet addresses and entity IDs removed; amounts aggregate; exchange names withheld and are trace tags, not ownership.

Scale, in context

This was not a boutique operation. The operator hub has cycled ~9,006 BTC
(≈€388M) over four years across 115 addresses and is still active; our victim's
payment is ~0.03% of its lifetime throughput. The hub is fed by abuse-tagged
clusters (a dark-web mixing_service contributing ~3,049 BTC over 74 tx, an
account_hack/market source, a money_laundering source), and it pushes out to a
public Wasabi CoinJoin and even to a 2022 ransomware-tagged address:
multi-affiliate, multi-incident laundering. The affiliate side shows ~2,196
inbound counterparties at ~1.26 BTC each (≈€71k at each deposit's block time,
the size of a typical affiliate cut, not €194M ÷ 2,196), many other victims,
historically.

Discipline note. This multi-victim claim is aggregate and historical (hub throughput + counterparty count). There is exactly one victim intake inthis dataset, the GraphSense export. An earlier pass that read operator-internal laundering denominations within that dataset as "other victim streams" was retracted, and we don't reintroduce it. Enumerating other victims is a separate query. That is exactly what the next section does, on the public chain, and it turns up a concrete second one.

It wasn't a single payment: a second victim, on the public chain

After the talk, we ran the open-source version of that query: no commercial clustering, no entity database, just the public Bitcoin ledger read through a free explorer. One result is worth stating plainly.

The same operator-hub address that funded our victim is shown funding a different victim seventeen days later: the hub's primary address sends ~11 BTC to a single-use relay, the relay passes ~10 BTC to a funder wallet, the funder sends the exact ransom amount to a fresh victim wallet, and in the same block that victim forwards it to a new ransom intake, preceded by a 0.0001 BTC test-ping fifteen minutes earlier.

About seventeen days after our case, the same recurring operator-side
recipient surfaces again. On the free public chain we can follow it
address-to-address, no clustering required: a funder wallet sends the exact ransom amount to a fresh victim wallet, and ~2 hours later that victim forwards it into a new ransom intake that splits to that same recurring operator-side address, the third such split we found inside an 11-day April window. The just-in-time funding shape repeats: a funder pre-loads the precise amount, the victim holds it only briefly before paying.

What clustering would be needed for, and what we therefore don't assert, isthat this recurring recipient is the same entity as the hub that funded our healthcare victim. Confirming that needs the commercial clustering tier we deliberately did without here; on free public data the two are a candidate match, not proof. So this is a concrete, publicly traceable second ransom split that shares one operator-side recipient with our case. Strong as a pattern, but "the same hub paid twice" stays a working hypothesis until a commercial tier resolves the cluster.

The operator's housekeeping is visible too. Within the same April window, that operator-side recipient moved a cut through three transactions packed into a single block, each one spending the previous transaction's unconfirmed output:

Three transactions in a single Bitcoin block, where TX2 spends an output of TX1 and TX3 spends an output of TX2, all before any of them had a confirmation. That ordering is only possible if one wallet controls all the addresses, making it a proof of common key control that needs no clustering. A recurring collector address skims a small peel from both TX2 and TX3.

That ordering is only possible if the spender holds the private key to each freshly created output: you cannot spend an unconfirmed output unless you own it. Chained this tightly inside a single block, it is strong evidence of one wallet moving on autopilot. It is not a magic wand: exchange batching and CoinJoin coordinators chain unconfirmed outputs too, so we read it as strong corroboration of single-wallet control rather than an absolute trump card, strongest when paired with the co-spend clustering. A recurring collector address skims a small peel from each hop, and the same collector recurs across the chain: operator bookkeeping, in the open.

But it's worth being exact about what the public chain can and can't carry, because the difference between "verified" and "attributed" is the whole game:

A two-column scorecard. Verified on public data, reproducible by anyone: same-block atomic chaining, the hub funding a second victim, the repeating just-in-time funding plus dust test-ping, and a recurring operator-side collector. Needs commercial tooling, not asserted here: the full 115-address cluster and the €388M total, the exchange names at cash-out, the dark-web abuse tag flagged five months early, and the Qilin family attribution itself.

What public data proves: the same-block common control, the second publicly traced ransom split, the repeating just-in-time funding shape, the recurring collector.
What it cannot, and we therefore don't claim: that the second split's
operator-side recipient is the same hub that funded our victim rather than a lookalike address (that's a cluster question, not a ledger one), the full 115-address cluster and the ~€388M total (multi-hop clustering at scale isn't reproducible from a public explorer), the exchange names at cash-out (no public source attributes them), the
dark-web "flagged five months early" tag (proprietary by nature, which is why it has value), and the "this is Qilin" label itself (that rests on the incident-response side, not the chain).

One emerging behaviour is worth flagging without over-reading it: in a sibling incident, change funds transit cross-chain through NEAR Intents, moving in chunks up to ~0.30 BTC to a deposit address that immediately forwards to NEAR Intents' Bitcoin treasury (which we identified from a public block-explorer tag for that treasury address, a third-party label, not NEAR's own published list). The appeal is structural: an intent-based cross-chain swap moves BTC into another chain (or straight into a stablecoin) programmatically, with no deposit account at a KYC-bound exchange. The deterministic on-chain
link breaks at that non-custodial boundary, which is harder to subpoena than an exchange; that said, a cross-chain tracker can often re-acquire the trail from the treasury's downstream side and tight timing correlation, so it is a speed bump, not a wall. We flag this as a single sibling-incident observation, not a trend we can prove from this dataset, and we are deliberately not using it to characterise our healthcare victim, whose funds we did not trace there.

Pillar 3: Why it stayed quiet

The attacker's tradecraft was modest. The detection environment did the hiding.

Every loud alert was a false positive. Over the 16 days of DC logs that survived, there were 940,969 failed-logon "brute force" events, all self-inflicted: a misconfigured Barracuda DCAgent hammering the DC
from localhost (~59k/day), normal Fortigate VPN LDAP binds that look exactly like a password spray, and nightly Veeam VSS ntds.dit snapshots tripping an "Ntdsutil Abuse" rule. 17 Sigma rules fired, all noise. The one real indicator, the 02:45 built-in-admin login, was the quietest event in the log.

The evidence almost didn't survive. The DC kept only 16 days of security logs, shorter than the 19-day dwell, so its own record of the break-in was already overwritten by the time anyone looked. We reconstructed the initial access from the Fortigate VPN logs, which retained the account, the three connections (Feb 20/23/24), the 02:45 login, and the source. The way in was a valid VPN credential (reused, weak, or broker-sourced; acquisition unknown), not an exploit. The same gap means the 19-day dwell is partly a blank: with the DC's log
window already rolled over, the stretch between access and encryption
can't be reconstructed from host logs. The tooling (Atera, NetScan, WinSCP, PsExec) was recovered from the Veeam staging host after the fact; it tells us what they ran, not the day each piece landed.

The launch point was the backup server. Encryption ran from the Veeam host (10.160.0.26), not the DC. The DC was only the identity target. The estate was Windows-only: NetScan mapped VMware ports, but the scanned ESXi hosts were never locked.

The C2 was a signed, whitelisted IT product. Atera RMM, dropped as
AteraAgent.exe / setup_Unassigned.msi in \ProgramData\update\. "Code signed and legitimate" is now an attacker advantage, not a safety guarantee.

Methodology & confidence

Every claim above carries a tier. We never dress a trace tag up as ownership.

How we read it, shape over labels: the mixer carried no provider tag, so we identified it by structure (≈€2.15B over 73h, hundreds of no-reuse counterparties, uniform P2TR outputs, zero tagpacks). Each claim is filed under a confidence tier from confirmed down to gated

Three principles do most of the work:

• Multi-input only. Our clusters rest on the common-input-ownership heuristic: addresses co-spent as inputs to one transaction must share a signer. We lean on that and deliberately not on change-address heuristics, which infer ownership from suspected change outputs and are a classic source of false merges (GraphSense's entity clustering is built the same way). Where we needed court-grade certainty, the operator's outflow, we went past heuristics entirely to same-block chaining, which proves common key control outright.
• Shape over labels. The mixer carried no tag from any provider. We identified it by its structure: ~€2.15B throughput in 73h, hundreds of distinct counterparties with no reuse, uniform P2TR outputs, zero tagpacks. A coordinator wears no label; throughput and fan-in/out are the signature.
• Trace tags ≠ ownership. The exchange names come from Chainlabs Trace TagPacks: strong leads, not court-grade. Confirm via a commercial ownership tier before any filing. Say it out loud whenever the names appear.

On the euro figures. Every EUR amount here is GraphSense's valuation of a transaction at its own block time, not a single spot price. BTC's price moved between the events described, so dividing one euro figure by another (or by a counterparty count) gives slightly different implied BTC prices: the affiliate off-ramp, for instance, cleared at a higher BTC price (~€71k) than the April ransom (~€60k). The BTC quantities are the invariant; read the euros as point-in-time conversions.

ATT&CK

The whole chain mapped to catalogued ATT&CK techniques across Initial Access, Execution/C2, Discovery, Lateral Movement, Exfiltration and Impact: every ID visible in standard Windows Security and network logs.

Appendix: defanged IOCs & reproducible bits

Host / endpoint

• C2 staging path: C:\ProgramData\update\
• C2 agent: AteraAgent.exe / setup_Unassigned.msi (Atera RMM)
• Recon: Netscan64.exe (SoftPerfect), scan.bat, PsExec
• Exfil: WinSCP.exe 6.3.5 portable (over SFTP)