Follow the Payload · 3 — The Recruit: A Soldier Awaiting Orders

Follow the Payload — Case 3. 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 first two payloads each did something to the host. The miner spent its compute; the proxy relayed through it. In both cases the payload's purpose was a completed act, present on the machine, readable off the binary — you found the miner mining, the proxy relaying, and you knew the objective because the objective was being enacted in front of you. This case breaks that pattern. The recruit payload — a botnet agent, a Mirai-class bot, a generic command-and-control implant — does not mine, relay, or steal. It phones home, and it waits. Its purpose is not to do a thing to the host but to make the host do whatever it is later told, by subordinating it to a remote commander. The payload enrolls the machine as a soldier, and a soldier's defining feature is that his purpose is not his own — it belongs to whoever gives the orders, and at the moment of enrollment, the orders have not been given.

This makes the recruit the register's first meta-objective, and it demands a different kind of reading. Every prior payload answered "what is this for?" with a terminal act. The recruit answers it with a deferral: this host is now available to be used for something, and what that something is has not yet been decided. The objective the register can read at enrollment is not the eventual crime — that is unknown, still in the botmaster's future or unspoken in his plans — but the enrollment itself: the conversion of an independent machine into a controllable unit awaiting instruction. That is a real, certain, unambiguous objective, and it reads at HIGH. But it points forward to a second objective, the terminal one, which the register must be disciplined enough to leave marked UNKNOWN, because to name it before it is commanded is to convict a soldier of a battle he has not yet been ordered to fight. The recruit teaches the register to read intent at two horizons and to keep them honestly apart.

1. Enrollment Is Not Use

Begin with the distinction that defines the case: enrollment is not use. When a payload uses a host, it consumes some resource of the host toward a purpose that is being enacted now — the miner uses cycles to mine, the proxy uses the address to relay, and in each case the using and the purpose are the same event. When a payload enrolls a host, it does not consume a resource toward a present purpose; it establishes control, a standing arrangement whereby the host will consume its resources toward a future purpose, on command. The recruit payload's immediate function is not to extract value from the host but to install a chain of command over it — to make the machine listen for orders and obey them. Nothing is being extracted at enrollment; a relationship is being created, the relationship of a soldier to his commander.

This is why a freshly enrolled bot can sit on a host doing nothing visible for weeks. It is not idle in the sense of broken; it is at rest, enrolled and waiting, its purpose fulfilled in the sense that matters to its author — the host is now controllable — and unfulfilled in the sense that matters to the eventual victim — no attack has yet been launched. The miner that mines nothing is malfunctioning; the bot that attacks nothing is simply awaiting orders, doing exactly what a bot is supposed to do between commands. The register must not read the waiting bot as a failed or dormant payload. It is a succeeded payload whose success was enrollment, and enrollment is a state, not an act — the state of being available for use.

And this reframes what the payload's author wanted. The miner's author wanted coin, and got it as the miner ran. The proxy's author wanted a laundering exit, and got it as the proxy relayed. The recruit's author wanted a controllable host, and got it the moment the host beaconed and obeyed — his purpose is complete at enrollment, whatever happens afterward. What the host is eventually used for is a further question, belonging to a further decision, possibly by a further person. The enroller's objective is availability; he has achieved it; and the terminal objective, the thing the availability is for, is a separate matter the enroller may not even have settled yet. Enrollment is the objective the register reads here, and it is genuinely distinct from whatever the fleet will one day do.

2. The Meta-Objective and Its Two Horizons

RECRUIT is a second-order objective — a purpose whose content is another purpose, deferred — and reading it correctly means holding two intents at two horizons and refusing to merge them.

The immediate intent is certain. At enrollment, the payload's purpose is to subordinate the host to a remote commander, and this is as unambiguous as the miner's mining: a bot that beacons to a C2 and stands ready to execute commands is doing exactly one thing, and that thing is reporting for duty. Once the beacon is observed, the intent is not merely unambiguous but executed — the host is demonstrably enrolled, demonstrably in contact with its commander, demonstrably awaiting orders. So the immediate objective, RECRUIT, meets the register's HIGH standard: unambiguous function, executed effect. The host has been made a soldier, and that is a completed, readable fact.

The ultimate intent is uncertain. What the botmaster will eventually command the fleet to do — launch a DDoS, send spam, scan for more victims, mine, proxy, stage a deeper intrusion — is not written on the enrollment payload, because it is a decision that lives in the botmaster, not the bot, and it may not have been made at enrollment, or may change repeatedly over the host's enrolled life. A generic bot is a generic soldier: capable of many missions, committed to none until ordered. The register cannot read the terminal objective off the enrollment payload for the simple reason that it is not there to be read; it is a future event, contingent on a decision the register has not observed.

The discipline, then, is to keep these two horizons distinct and to resist the powerful temptation to collapse them — to look at a bot and declare "this is a DDoS payload" because bots are often used for DDoS, or "this is a spam bot" because the fleet it joined once sent spam. That collapse imports a terminal objective the evidence does not support, convicting the host of a specific crime when all that is established is its general availability. The register reads the immediate objective at HIGH (RECRUIT — the host is enrolled) and marks the terminal objective UNKNOWN (it awaits a command not yet observed). Two horizons, two confidences, never merged: the certain enrollment and the uncertain mission, held apart because they are apart — one is a fact about the host now, the other a decision about the host later, and only the first is in evidence.

3. The Beacon: A Command Channel, Not a Work Channel

The recruit's executed signature is the beacon, and the beacon deserves close reading because it is precisely what distinguishes RECRUIT from every terminal objective. A beaconing host maintains a persistent, periodic callback to a command-and-control endpoint — reaching out on a schedule to a hardcoded address, or a domain generated by an algorithm that produces a new rendezvous each day, or an IRC channel, an HTTP endpoint, a custom protocol — and in that callback it does two things: it announces that it is alive and available (the heartbeat), and it asks whether there are orders (the poll). Often it also reports a fingerprint of itself — its architecture, its bandwidth, its capabilities — so the botmaster knows what kind of soldier he has acquired. The beacon is the host reporting for duty, over and over, indefinitely.

What makes the beacon diagnostic is what kind of channel it is. The miner also talks to a remote server — its pool — and the proxy also talks to a remote server — its control backend — so an outbound channel alone does not distinguish a bot. The difference is in the channel's purpose. The miner's channel is a work channel: it submits completed hashes and receives new work units, the traffic of a machine doing a job. The proxy's channel is likewise a work channel, carrying the relayed traffic that is its job. The bot's channel is a command channel: it carries no work, only availability and instruction — the host is not sending results, it is asking what to do. That distinction, work versus command, is the line between a host that is being used and a host that is enrolled to be used, and the beacon is the observable form of a command channel. When the register sees a host reaching out not to submit work but to receive instruction, it is seeing enrollment, and the presence of that command channel is the fact that closes RECRUIT at HIGH.

4. Capability Delivered, Decision Deferred

RECRUIT institutionalizes a separation the earlier cases only hinted at: the payload delivers a capability, and a separate actor makes the decision, and the two need not be the same hand. The bot code enrolls the host — that is the capability, a controllable machine. The botmaster commands the fleet — that is the decision, the choice of what the machines will do. And the enroller and the commander can be different people, at different times, because a fleet is an asset that can be built, sold, rented, or handed off: the operator who assembled the botnet by spreading the bot may never point it himself, instead renting its firepower to customers who supply the terminal objective, or selling the whole fleet to another operator entirely.

This has a sharp consequence for reading intent, and it is the reason the register refuses to attribute the terminal objective to the enroller. The enroller's purpose was availability, and it was complete at enrollment; he wanted controllable hosts and he got them, and his intent is fully described by "recruit machines into a fleet." What the fleet is later used for reflects the intent of whoever commands it later — possibly the enroller, possibly a renter, possibly a buyer — and reading the fleet's eventual DDoS or spam campaign back onto the enroller assumes an identity (enroller = commander) that the delegated structure specifically breaks. The recruit payload is, in this sense, the payload-layer echo of the access-broker seam the attribution register documented: just as the broker who takes a foothold is not the buyer who uses it, the operator who enrolls a host is not necessarily the botmaster who fires it. Enrollment delegates the terminal intent, handing it forward to a commander who may be a stranger to the enroller, and the register keeps the enroller's certain, completed objective (RECRUIT) separate from the commander's later, deferred one.

The author, as ever, stays LOW. Bot code is commodity — Mirai's source has been public for years, and countless variants are compiled from it by unrelated operators — so the binary implies a shared objective (RECRUIT) and nothing about a shared hand. The C2 endpoint is more interesting: two hosts beaconing to the same C2 are enrolled in the same fleet, which is a genuine shared-infrastructure link and groups them at MEDIUM confidence. But "same fleet" is emphatically not "same person" — the C2 may itself be rented, shared among affiliates, or resold — so the C2 identifies a fleet membership, a grouping, not a controller. Read the objective (RECRUIT) at HIGH, the fleet-membership (shared C2) at MEDIUM as a cluster, and the author at LOW, exactly as the commodity discipline requires.

5. The Loaded Gun

For the defender, the recruit objective carries a distinctive and urgent shape: an enrolled host is a loaded gun whose trigger is held by a stranger. The miner harms the host; the proxy launders through it; but the bot commits the host to whatever the botmaster decides next, and that decision is entirely outside the host owner's control and largely invisible until it fires. The enrolled machine may sit quiet and well-behaved for months — a good citizen by every local measure, no resource abuse, no visible harm — and then, on a single command, become a participant in a crippling DDoS against some third party, a node in a spam campaign, a scanner hunting the next thousand victims, or the launch point for a deeper intrusion. The danger is not what the bot is doing but what it can be made to do on an order that has not yet come.

This dictates the defensive response, and the response is clean because it targets the one thing enrollment cannot do without: the command channel. Sever the beacon — block the callback, sinkhole the C2 domain, cut the outbound control connection — and the host is disarmed, regardless of what the botmaster intended, because a soldier who cannot hear his commander cannot obey him. Severing the command channel converts the enrolled host back into an independent machine: the terminal objective, whatever it was going to be, can no longer be delivered, because the delivery mechanism is the very channel that was cut. This is why the beacon is both the detection signal and the remediation target — find the callback, and you have found the enrollment; kill the callback, and you have undone it. The bot may remain on disk, but a bot that cannot reach its C2 is a soldier with no orders and no way to receive them, which is to say no longer a soldier at all.

The honest close is the register's refusal to convict a capability, which is both a fairness commitment and an accuracy one. A host that beacons has been made available for abuse; it has not committed abuse, and the register will not read its intent as "DDoS" or "spam" before any such command is observed, because that would attribute a crime that exists only as a potential. The register names what is executed — enrollment, the beacon, the subordination of the host — at HIGH, and it holds the terminal objective UNKNOWN until a command is actually seen, refusing to sentence the soldier for a battle he has not been ordered to join. This is not weakness; it is the same discipline that made every prior register's confidences worth trusting, applied to the temporal gap between capability and act. The vectors do not lie: this host beacons, so it is enrolled, so its objective now is RECRUIT. What it will be told to do later is a future the register will not presume. We name the enrollment, we hold the mission unknown, we sever the channel, and we let people judge — refusing to convict the loaded gun of a shot it has not fired.

6. The counter-narrative, steelmanned

The strongest objection to this case is that holding the terminal objective as UNKNOWN is uselessly, even irresponsibly, cautious. A bot enrolled into a known DDoS botnet — a fleet whose C2 the whole security community has watched launch attack after attack — plainly has a terminal objective, and it is DDoS; refusing to name it, insisting the mission is "unknown until commanded," is pedantry that withholds actionable intelligence from defenders who need to know what this fleet does. If the register can see that a host has joined a fleet with a long, documented history of a specific crime, then declining to say "this host is now a DDoS asset" is not rigor — it is a failure to state the obvious, and it leaves the defender less informed than the plain facts allow.

The objection has real force, because it is true that fleets do have characters, and that a C2 with a documented history is genuine, valuable intelligence. A defender who learns that a host has beaconed to a C2 associated with a specific, long-running DDoS operation knows something important and specific — far more than "this host is enrolled in some fleet." To pretend that history is unknowable, or irrelevant, would indeed be a kind of willful blindness, discarding a real prior that bears directly on what the host is likely to be commanded to do. If the register's caution amounted to "we know nothing about the terminal objective ever," the objection would be correct that this is useless.

The register answers that its caution is narrower and more precise than the objection assumes: it distinguishes the FLEET's typical use — a real, nameable, often MEDIUM-confidence prior drawn from the C2's known history — from THIS host's commanded act, which is genuinely unknown until issued, and it reports the first while declining to assert the second. These are different claims, and conflating them is the error the register avoids in both directions. The register absolutely can and does say: "this host has beaconed to a C2 with a documented DDoS history, so the fleet's character is DDoS, and the host's most likely commanded use is DDoS — a MEDIUM prior from fleet history." That is the actionable intelligence the objection rightly wants, and the register delivers it, because the fleet's history is evidence and the register reads all the evidence. What the register declines is the further step: asserting that this host has committed DDoS, or that its terminal objective is DDoS as a settled fact, when no command to that effect has been observed. The difference is between an informed expectation (this fleet does DDoS, so expect DDoS) and a convicted act (this host did DDoS), and only the second is being withheld. This matters for accuracy because fleets are repurposed and resold — a botnet with a DDoS history can be rented to a spam customer next week, or pivoted to proxying, or handed to a buyer with entirely different plans — so "the fleet has done DDoS" does not entail "this host will do DDoS," only that it is a strong prior. And it matters for fairness because attributing a specific committed crime to a host that has only been enrolled convicts a capability, defaming the host's owner for an act his machine was made available for but never actually commanded to perform. So the register gives the defender everything the evidence supports — the fleet's character, the likely mission, the MEDIUM prior — while holding the line at the one claim the evidence does not reach: that a specific crime was committed on command not yet seen. That is not pedantry; it is the exact difference between reporting what a soldier is likely to be ordered to do and testifying that he has already done it, and only the honest register keeps them separate.

7. Objective Signal — RECRUIT

Case 3 read the register's third objective and its first meta-objective. Where the miner and proxy each put the host to a terminal use, the recruit payload does not USE the host — it ENROLLS it. A botnet agent (a Mirai-class bot, a generic C2 implant) phones home and WAITS, subordinating the host to a remote commander as a soldier in a fleet. Its purpose at enrollment is not an act performed but a capability delivered: RECRUIT is a SECOND-ORDER objective, whose content is to make the host AVAILABLE for a terminal objective named LATER by the botmaster — who may change it day to day or resell the fleet.

So the register reads TWO INTENTS at TWO HORIZONS and keeps them distinct. The IMMEDIATE intent — subordinate the host — is unambiguous and, once the beacon is observed, executed, so it reads at HIGH: RECRUIT. The ULTIMATE intent — what the fleet will be commanded to do (DDoS, spam, scanning, mining, proxying, further intrusion) — is UNKNOWN at enrollment, not written on the payload, and the register must NOT collapse a generic bot into "a DDoS payload" before any command is seen; enrollment commits the host to OBEDIENCE, not to a specific crime. The tell is the BEACON — a persistent periodic callback to a C2 — which is a COMMAND channel (receive instructions), distinct from the miner's or proxy's WORK channel (submit results / relay traffic); the presence of a command channel is the observable fact of enrollment. RECRUIT institutionalizes the split between the payload that delivers CAPABILITY and the actor who makes the DECISION: the enroller's purpose is complete at enrollment, and the terminal purpose belongs to whoever commands the fleet later — possibly a customer, since fleets are sold, rented, and handed off (the payload-layer echo of the access-broker seam). The author stays LOW (commodity bot code), and the C2 is a shared-FLEET grouping (MEDIUM), not a shared-hand link — "same botnet" is not "same person."

Defensively the enrolled host is a LOADED GUN whose trigger is held by a stranger — quiet for months, then a DDoS participant, spam cannon, scanner, or intrusion launch point on a single command — so the imperative is to sever the COMMAND CHANNEL (block the beacon, sinkhole the C2), which disarms the host regardless of the botmaster's intent, converting an enrolled soldier back into an independent machine; the beacon is both detection and remediation. The steelmanned objection — that holding the terminal objective UNKNOWN is uselessly cautious when a host joins a known DDoS botnet — is answered by distinguishing the FLEET's typical use (a real, nameable MEDIUM prior from the C2's documented history, which the register DOES report) from THIS host's commanded act (unknown until issued, which the register declines to assert as a committed fact): an informed expectation is not a convicted act, and fleets are repurposed and resold, so "the fleet does DDoS" is a strong prior, not proof "this host did DDoS." No individual named — enrollment named, the terminal crime not presumed, the fleet controller left unnamed. Classification: TLP:WHITE. We name the enrollment, hold the mission unknown, sever the channel, and let people judge.

Follow the Payload — Case 3. Objective signal: RECRUIT (the register's first META-objective). Confidence: HIGH for enrollment (unambiguous — a bot that beacons to a C2 and awaits commands subordinates the host to a remote commander — and executed once the beacon is observed); UNKNOWN for the terminal objective (what the fleet will be commanded to do is deferred and delegated, not written on the enrollment payload, and must not be collapsed into "a DDoS/spam payload" before a command is seen); LOW for the author (commodity bot code — Mirai's public source spawns countless variants), with the C2 a shared-FLEET grouping at MEDIUM (not a shared hand — the C2 may be rented/resold). RECRUIT is a second-order objective: the purpose is to make the host AVAILABLE for a purpose named later. TWO HORIZONS, kept distinct: immediate (subordinate the host, HIGH) vs ultimate (the commanded mission, UNKNOWN). The tell is the BEACON — a COMMAND channel (receive instructions), distinct from a miner/proxy WORK channel. RECRUIT delegates intent: the enroller (capability) is not necessarily the commander (decision) — fleets are sold/rented/handed off, the payload-layer echo of the access-broker seam. Defensively the enrolled host is a LOADED GUN aimed by a stranger — sever the COMMAND CHANNEL (block the beacon, sinkhole the C2) to disarm it regardless of intent; the beacon is both detection and remediation. Steelmanned objection (holding the terminal objective UNKNOWN is uselessly cautious for a host in a known DDoS botnet) is answered by distinguishing the FLEET's typical use (a real MEDIUM prior from C2 history, which the register REPORTS) from THIS host's commanded act (unknown until issued, which the register declines to convict) — an informed expectation is not a committed act, and fleets are repurposed/resold. No individual named — enrollment named, terminal crime not presumed. Classification: TLP:WHITE. Include everything — the host beacons, so it is enrolled and its present objective is RECRUIT; what it will be told to do later is a future the register will not presume.