Follow the Payload · 15 — The Rented Payload: The Vendor Built It, the Affiliate Aimed It

Follow the Payload — Case 15. This register takes what an intruder leaves behind and reads it for the one thing it cannot hide: its purpose. Closing each case on the objective the payload serves: STEAL COMPUTE · STEAL BANDWIDTH · RECRUIT · STEAL DATA · EXTORT · PERSIST.

The register has kept two readings apart since its first case: intent (what the payload is for) and author (who deployed it). This case splits the second reading in half. A rented payload — one from the malware-as-a-service economy, where a vendor builds a capability and many affiliates license it — has two authors, not one, and they are different people. A vendor developed the ransomware, the stealer, the loader, and rents it out; an affiliate paid for access to it and aimed it at a victim. The code that ran on the host is the vendor's product; the choice to run it here, against this target, for this purpose, is the affiliate's decision. So "who is behind this payload" no longer has a single answer. It has two: the vendor who built it, and the deployer who wielded it — the one who made the gun and the one who aimed and fired it.

This split matters because the two parties carry different things, and confusing them corrupts both the attribution and the intent-reading. The vendor is what the payload identifies: a MaaS build carries the vendor's fingerprints — distinctive code, a branded ransom note, a family signature — so the payload points, sometimes strongly, at the supplier. But the intent of the attack belongs to the affiliate: the vendor supplied a general capability with no target, and the affiliate supplied the target and the objective, so the decision to extort this victim is the affiliate's, not the vendor's, even though the vendor's code did the extorting. And this yields the case's central rule: "same MaaS family" means "same vendor," never "same deployer" — because one vendor serves many affiliates, a shared family is a shared supplier, not a shared hand. This case works out the vendor/deployer split, the layered confidences it produces, and the way it ties the payload register back to the money economy and the broker seam the earlier registers mapped.

1. Two Authors, Joined by a Rental

Begin with the structure that produces two authors: the malware-as-a-service economy. In this model, a vendor does the development — he writes the ransomware, the stealer, the loader, the bot — and then, rather than deploying it himself, he rents it out: he sells licenses, or takes a percentage of the affiliates' proceeds, or operates a subscription, and many unrelated affiliates pay to use his tool. The affiliate does the deployment — he gains access to a victim (himself, or bought from a broker), runs the vendor's tool against it, and pursues his own attack. So a single MaaS payload on a host is the product of two hands: the vendor's, which built it, and the affiliate's, which deployed it, joined by nothing but a rental transaction.

These two hands are genuinely separate people, and that is the whole point. The vendor never touched this victim; quite possibly he does not know the victim exists, because he sells to hundreds of affiliates and does not track where each aims the tool. The affiliate did not write a line of the code; he rented a finished capability and pointed it. Their relationship is commercial, not collaborative — supplier and customer, not co-conspirators on a specific attack — and treating them as one actor erases a real division of labor that structures the entire modern criminal economy. The payload was built by one party and used by another, and "who is behind this attack" has to distinguish which "behind" you mean: behind the tool, or behind the targeting.

This deepens the intent-vs-author split the register has run on since the miner. There, "author" was a single (usually LOW) reading — who deployed the commodity payload. For a rented payload, "author" itself bifurcates: there is a vendor-author and a deployer-author, and they require separate confidences because they are separate parties with separate identifiability. The vendor may be a well-known RaaS brand, sharply characterized; the affiliate may be entirely anonymous — or, occasionally, the reverse. The single author-reading the register did before becomes, for a rented payload, two author-readings, and the case's first discipline is simply to run both and never merge them.

2. The Intent Belongs to the One Who Aimed

Of the two authors, which one holds the intent of the attack? The affiliate — the deployer — and this is the case's most important claim, because it is easy to get backwards. The vendor built the capability, so it is tempting to locate the intent with him. But the vendor's product is general: his ransomware can encrypt anyone, his stealer can grab any credentials, and he built it with no specific victim in mind, because he does not choose the victims — his affiliates do. The vendor's actual intent is commercial: he wants to sell the tool and collect his cut, and toward that end the tool is deliberately target-agnostic, a general weapon for sale to whoever pays. There is no "extort this hospital" in the vendor's intent, because the vendor never heard of the hospital.

The affiliate is the one who supplied the target and the specific objective. He chose this victim, obtained access to this host, and aimed the vendor's general capability at it for his purpose. The intent "extort this hospital, steal these credentials, ransom this company" is entirely his — the vendor supplied the means, the affiliate supplied the ends and the target, and the attack is the affiliate's act performed with the vendor's instrument. The gun analogy is exact and worth stating: the vendor manufactured the gun; the affiliate bought it, chose whom to point it at, and pulled the trigger. The shooting is the shooter's act, not the manufacturer's, even though the manufacturer's product fired the bullet.

So the register reads the objective from the payload's function, exactly as always — this RaaS encrypts, so the objective is EXTORT — but it attributes that intent to the affiliate's decision, not the vendor's product. The objective is what the payload does (a fact about the vendor's capability); the intent to do it to this victim is the affiliate's (a fact about the deployer's choice). The register keeps these joined in the reading — the intent is the objective, aimed — but attributes them correctly: the objective belongs to the family, the aiming belongs to the affiliate, and the attack is the affiliate's act. This is the intent-belongs-to-the-deployer principle, and it is why identifying the vendor, however precisely, does not tell you whose intent drove this particular attack.

3. The Payload Identifies the Vendor, Not the Deployer

What a rented payload actually identifies is the vendor — and this is a real, useful grouping that the register should not undervalue even as it keeps it in its place. A MaaS payload carries the vendor's fingerprints: distinctive code the vendor wrote, a branded ransom note that names or styles the RaaS operation, a characteristic C2 protocol, a family signature the whole security community has catalogued. These identify the family — this is a particular RaaS, this is a specific stealer brand — at MEDIUM-to-HIGH confidence, because the vendor's product is distinctive, sometimes as distinctive as a bespoke artifact, since a RaaS build genuinely is bespoke to the vendor who wrote it. So the payload points, often strongly, at the supplier.

But it does not identify the affiliate who deployed it, and the reason is structural: the same vendor product is deployed by many affiliates, so the family fingerprint is shared across all of them. Every affiliate of a given RaaS drops the same branded, distinctive payload, so the payload's distinctiveness distinguishes the vendor (one supplier) and precisely fails to distinguish the deployer (any of hundreds of customers). The family fingerprint is a strong signal about who built this and a null signal about who aimed this, because building is one hand and aiming is many. Identifying the family tells you the supplier with confidence and the customer not at all.

This is where the case's central error lives, and it is a subtle one because the family feels like a strong attribution. Reading "same MaaS family" as "same operator" is the error: it takes a signal that genuinely does identify the vendor strongly and misreads it as identifying the deployer strongly, attributing two attacks to one actor because they used the same RaaS. This is like attributing two robberies to one robber because both used the same brand of crowbar bought at the same hardware store — the shared tool is real evidence of a shared supplier and no evidence of a shared hand. It is the commodity error of Case 4 refined one crucial level: there, an obviously-commodity tool (a public miner) was easy to recognize as non-attributing; here, a distinctive, near-bespoke-looking family tempts attribution because it seems too specific to be shared — but it is shared, across all the vendor's affiliates, because the distinctiveness belongs to the vendor's product, not to any deployer. So the register groups rented payloads by vendor (a supply-chain link, real and groupable) and refuses to group them by deployer on the family alone, holding firm against the pull of a distinctive family that looks like a fingerprint of one hand and is really the fingerprint of one supplier.

4. The Same Structure the Earlier Registers Found

The rented payload ties the payload register to two prior registers, and seeing the connections locates the MaaS split in the larger map the whole lineage has been drawing. First, to Follow the Money: the MaaS economy is a monetization structure, exactly the kind the money register mapped. The vendor monetizes by building and renting — he profits from the tool without ever attacking a victim; the affiliate monetizes by deploying and extorting — he profits from the victim using the rented tool. The payload is the product traded in that economy, and reading a rented payload is reading one transaction in a market the money register charted: a division of labor where the profit is split between the supplier of the capability and the user of it, each taking a cut of the harm.

Second, to Follow the Operator's broker seam: the vendor/affiliate split is the capability-versus-decision seam, one layer up from where the attribution register found it. There, the access-broker sold access — a foothold — and the register drew the seam between the broker who took the access and the buyer who used it, because the seller was not the user. Here the MaaS vendor sells capability — a tool — and the seam is identical: the vendor who built the tool is not the affiliate who used it, seller is not user. The chain is now three links: VENDOR (builds capability) → AFFILIATE (rents capability, supplies access, and aims) → VICTIM. And note the affiliate often stands at the junction of both seams — he buys capability from the vendor and buys access from the broker, assembling a complete attack from two purchased components neither of whose suppliers he coordinates with. The payload register has met this delegated-actor structure before — at the recruit (enroller vs commander), at the backdoor (installer vs buyer) — and the rented payload is the same structure at the tool-supply layer: the hand that made the payload is not the hand that deployed it, and the intent is the deployer's.

Seeing these connections is not decorative; it tells the register how to read the rented payload consistently with everything else. The vendor/affiliate split is not a special MaaS quirk but one more instance of the pervasive division of labor the whole lineage documents — access split from use, enrollment split from command, capability split from decision — and the reading discipline is the same in every instance: identify each party at its own confidence, attribute the intent to the party who made the targeting decision (the affiliate, the commander, the buyer), and refuse to collapse a supply relationship into a shared hand. The rented payload is the payload-layer face of a structure the register has been reading, one seam at a time, across three registers.

5. Layered Confidence, and Two Distinct Crimes

The rented payload's confidences are layered, and stating them precisely is the case's practical output. The vendor/family reads at MEDIUM-to-HIGH: the code and branding are distinctive, so identifying the family — and through it the vendor's operation — is a real grouping, sometimes as strong as a bespoke artifact, because a RaaS build is the vendor's bespoke product. The deployer/affiliate reads at LOW: the payload does not distinguish which of the vendor's many affiliates deployed it, so absent a deployer-specific second signal — a bespoke wallet, a reused affiliate handle, a distinctive access method — the affiliate is anonymous, one of many. The objective reads at the payload's function (HIGH for a known family — this RaaS encrypts) but is attributed to the affiliate's intent, not the vendor's product. Three separate readings — vendor MEDIUM-HIGH, deployer LOW, objective HIGH-to-the-affiliate — that the register never collapses into a single "who and what."

Keeping these distinct prevents the specific over-readings each conflation would produce. Merging vendor and deployer and calling the whole thing "one actor" either inflates the affiliate to the vendor's identifiability (claiming to know the anonymous deployer because you know the family) or deflates the vendor to the affiliate's anonymity (throwing away a real family identification because the deployer is unknown) — both wrong. Attributing the objective's intent to the vendor over-reads (the vendor never chose this victim). Attributing the vendor's whole family of attacks to one affiliate over-reads the other way (that affiliate deployed only some of the family's attacks; the rest were other affiliates). The layered confidences are the antidote to all of these: each party read at exactly its warranted confidence, the intent placed with the party who aimed, and no reading allowed to borrow certainty from another.

The honest close is a fairness point the split makes sharp: the vendor's crime and the affiliate's crime are different crimes by different parties, and neither should be attributed to the other. The vendor's crime is building and selling the capability — a real crime, and a distinct one; the affiliate's crime is deploying it against a victim — also real, also distinct. They are not the same crime seen twice; they are two crimes in a supply relationship, and the register names each to its correct party: the vendor as the family's builder (a supply grouping, MEDIUM-HIGH), the affiliate as this attack's deployer (anonymous, LOW), the objective to the affiliate's intent. The vectors do not lie: this payload carries the vendor's fingerprints and executed the affiliate's attack. Who built it is the vendor; who aimed it is the affiliate; and the two are kept distinct, each named to its own act, neither inflated into the other. We identify the vendor, we mark the affiliate anonymous, we place the intent with the one who aimed, and we let people judge — refusing to make a shared supplier into a shared hand.

6. The counter-narrative, steelmanned

The strongest objection to this case is that the vendor/deployer split lets everyone off the hook. The vendor, the objection says, can shrug and claim "I only sold a tool — what my customers did with it is not my doing," disclaiming responsibility for every attack his RaaS ever committed; and the affiliate, being anonymous (LOW), is never actually identified, so he escapes too. The register's careful distinction, on this view, serves impunity: by splitting one accountable "attacker" into a vendor-who-only-built-it and an affiliate-who-can't-be-named, it dissolves responsibility into two parties who each point at the other, and the net effect of all this precision is that no one is held to account for an attack that plainly harmed a real victim. A register whose sophistication ends in "well, it's complicated, blame is distributed" has, the objection concludes, refined its way into excusing everyone.

The objection lands on a real danger, because responsibility-diffusion is a genuine feature of the MaaS economy — it is, in part, why the model exists: the vendor gains deniability by not choosing victims, the affiliate gains deniability by not building tools, and the split really does make prosecution harder than a single-actor attack. If the register's distinction encouraged the shrug — if it said "the vendor merely supplied, so he bears no responsibility" or "the affiliate is unknown, so nothing can be done" — it would indeed be serving impunity, and the objection would be right that sophistication had curdled into excuse.

The register answers that its distinction is about the accuracy of attribution, not the allocation of blame — and that accurate attribution is the opposite of impunity, because it names each crime to its correct party and thereby makes each actionable. Start with what the register actually asserts: it attributes the building to the vendor as a real, sometimes-HIGH identification of the supplier, and it attributes the deployment to the affiliate as an act that is culpable whether or not the affiliate is currently named. Neither of these excuses anyone. The vendor's "I only sold a tool" is not accepted by the register; it is contradicted by it — the register identifies the vendor as the builder of a capability whose entire purpose is criminal, which is precisely the identification that enables action against the MaaS operation at its source, the highest-leverage intervention there is (take down the vendor and you disable all his affiliates at once). Far from excusing the vendor, the register's family-identification is the thing that makes the vendor pursuable as a vendor — a specific, culpable party who built the weapon — rather than an invisible background condition. And the affiliate's anonymity is not the register excusing him; it is the register honestly reporting the current state of the evidence, which is that this attack's deployer has not yet been distinguished from the vendor's other customers — a gap to be closed (by finding a deployer-specific signal), not a verdict of innocence. The register says "the affiliate is one of many, not yet distinguished," which is an invitation to keep hunting, not a dismissal. So both parties remain fully culpable for their respective acts; the split does not diminish either crime, it names each crime to its correct party, and naming correctly is what makes pursuit possible. The alternative — a muddled single "attacker" that fuses builder and deployer — is worse for accountability, not better: it pursues a phantom that matches neither real party, lets the vendor hide behind "that wasn't me, that was an affiliate" (true, and the muddle cannot rebut it) and lets the affiliate hide behind "I didn't build that" (also true), because a conflated attribution can be defeated by the very split it ignored. The register's precision forecloses both dodges by attributing each act to its actual author: the building to the vendor (who cannot then disclaim it) and the deployment to the affiliate (whose anonymity is a hunt-target, not an acquittal). Accurate attribution is not the road to impunity; it is the only road away from it, because you cannot hold accountable a party you have mis-attributed, and the muddle the objection prefers mis-attributes both.

7. Objective Signal — NONE (The Vendor/Deployer Split)

Case 15 read the economy case — malware-as-a-service and the affiliate model, where a payload is RENTED, so the author who BUILT it and the operator who DEPLOYED it are different people. A MaaS VENDOR develops and rents a capability (ransomware/stealer/loader/botnet-as-a-service) that many unrelated AFFILIATES license and deploy for their own ends, so the payload on a host is the vendor's product wielded by the affiliate's hand — the vendor wrote the code and never touched the victim, the affiliate rented the code and chose the victim. This DEEPENS the intent-vs-author split: the AUTHOR-confidence itself splits into two different hands — the VENDOR (built the capability, identifiable from code/branding/family) and the DEPLOYER/AFFILIATE (rented it and aimed it, one of many) — requiring separate confidences, and conflating them is the central error.

The INTENT belongs to the DEPLOYER, not the vendor: the vendor supplied a GENERAL capability with no target (his intent is commercial — sell the tool); the affiliate supplied the TARGET and the specific objective (extort THIS victim), so the intent-of-this-attack is the affiliate's even though the vendor's code executed it — the vendor made the gun, the affiliate aimed and fired. But what the payload IDENTIFIES is the VENDOR — the family fingerprint (distinctive code, branded note, characteristic protocol) points at the SUPPLIER at MEDIUM-to-HIGH, not the customer, because the same product is deployed by many affiliates. So 'same MaaS family' means 'same VENDOR' (a supply-chain link) and NEVER 'same DEPLOYER' (an attack link) — one MaaS serves many affiliates, so attributing two attacks to one actor on the family is like blaming two robberies on one robber because both used the same brand of crowbar from the same store. This is the Case 4 commodity error refined: even a DISTINCTIVE, near-bespoke family does not link deployers, because the distinctiveness belongs to the vendor's product. The register groups rented payloads by VENDOR (supply chain), never by deployer on the family alone.

The linkage signal is NONE — methodology/economy. The rented payload ties the register to Follow the MONEY (the MaaS economy is a monetization structure — vendor builds-and-rents, affiliate deploys-and-extorts) and to Follow the OPERATOR's broker seam (capability-vs-decision one layer up — broker sells ACCESS, vendor sells CAPABILITY, seller ≠ user; the chain is VENDOR → AFFILIATE → VICTIM, the affiliate often buying capability from the vendor AND access from the broker). Confidence is layered: VENDOR/family MEDIUM-to-HIGH, DEPLOYER/affiliate LOW (absent a deployer-specific signal — a bespoke wallet, a reused affiliate handle), OBJECTIVE at the function but attributed to the affiliate's intent. The vendor's crime (building/selling) and the affiliate's crime (deploying) are DIFFERENT crimes by DIFFERENT parties; neither is attributed to the other. The steelmanned objection — that the split lets everyone off the hook (vendor: 'I only sold a tool'; affiliate: anonymous), serving impunity — is answered by the distinction being about ACCURACY not blame-allocation, and accurate attribution being the OPPOSITE of impunity: identifying the vendor as the builder is exactly what enables action against the MaaS at its source (the highest-leverage intervention), and marking the affiliate anonymous is an honest hunt-target not an acquittal — both remain culpable for their acts, and the muddled single-'attacker' alternative is worse, because it can be defeated by the very split it ignored (vendor disclaims deployment, affiliate disclaims building). No individual named — vendor a family/supply grouping, affiliate anonymous, neither crime attributed to the other. Classification: TLP:WHITE. We identify the vendor, mark the affiliate anonymous, place the intent with the one who aimed, and let people judge.

Follow the Payload — Case 15. Objective signal: NONE (methodology/economy — the rented payload splits author into vendor and deployer). A RENTED (malware-as-a-service) payload is BUILT by a VENDOR and DEPLOYED by an unrelated AFFILIATE, so the author-confidence itself SPLITS into two different hands: VENDOR (built the capability — identifiable from code/branding/family, MEDIUM-to-HIGH, a supply-chain link) and DEPLOYER/AFFILIATE (rented + aimed it, LOW, one of many; an attack link the family does not support). The INTENT belongs to the DEPLOYER, not the vendor (the vendor supplied a general capability with no target — commercial intent; the affiliate supplied the target and objective — the vendor made the gun, the affiliate aimed and fired), though the payload IDENTIFIES the vendor. CENTRAL ERROR: 'same MaaS family' = 'same VENDOR', NEVER 'same DEPLOYER' (one MaaS serves many affiliates — like blaming two robberies on one robber for a shared crowbar brand); the Case 4 commodity error refined (even a distinctive, near-bespoke family does not link deployers — the distinctiveness is the vendor's product). Ties to Follow the MONEY (MaaS = a monetization structure) and Follow the OPERATOR's broker seam (capability-vs-decision one layer up: broker sells access, vendor sells capability, seller ≠ user; VENDOR → AFFILIATE → VICTIM). Layered confidence: vendor MED-HIGH, deployer LOW, objective at the function but attributed to the affiliate's intent. Fairness: vendor's crime (building/selling) ≠ affiliate's crime (deploying); neither attributed to the other. Steelmanned objection (the split lets everyone off — vendor 'only sold a tool', affiliate anonymous — serving impunity) answered by the distinction being about ACCURACY not blame: identifying the vendor enables action against the MaaS at its source (highest leverage), marking the affiliate anonymous is a hunt-target not an acquittal, both stay culpable, and the muddled single-'attacker' alternative is worse (defeated by the split it ignored). No individual named — pure methodology. Classification: TLP:WHITE. Include everything — the payload carries the vendor's fingerprints and executed the affiliate's attack; who built it is the vendor, who aimed it is the affiliate, kept distinct, neither inflated into the other.