Follow the Payload · 5 — The Harvester: When the Loot Is a Key

Follow the Payload — Case 5. 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 three objectives each settled the payload into the host for a continuing use — the miner mined day after day, the proxy relayed indefinitely, the bot waited for orders. This case is briefer and, in a specific way, more dangerous. The harvester does not settle in. It reads the host's secrets and leaves. Its purpose is theft of data — but not any data: credentials, the access-bearing secrets that live on almost every real machine, the SSH keys and cloud credentials and API tokens and stored passwords that a working host accumulates as it does its job. The harvester sweeps the places those secrets live, exfiltrates what it finds, and often departs without leaving a trace, its whole objective captured in a single pass. The host was never the prize. The keys on it were.

And this is what makes the credential harvester categorically different from every objective before it: the loot is itself a key. Stolen compute is spent and gone; stolen bandwidth is relayed and gone; a recruited host waits for orders that consume it in the moment. But a stolen credential is not consumed by the theft — it is generative, because a credential's whole nature is to unlock something, and a stolen credential unlocks it for the thief. One harvested SSH key logs into the next server. One cloud credential opens an entire account. One token reaches a whole tenant of a shared service. So the harvester's output is not a terminal gain sitting in a wallet; it is a seed, the raw material of the next intrusion, and the next intrusion may drop another harvester, which seeds the one after that. The credential harvester is the objective that most directly manufactures more intrusions, because its product is precisely the thing an intrusion needs to begin — and this case reads that generativity, and the doubled harm it creates, and the seam where this register's what becomes the access register's how.

1. The Sweep

Begin with what the harvester does, because its behavior is its whole objective compressed into a few seconds. A working host is full of secrets, because working requires them: to reach other servers it holds SSH keys, to use cloud services it holds API credentials, to run applications it holds passwords in config files and tokens in environment variables, and the browser and the OS keychain hold still more. These secrets are scattered across a small number of well-known locations — the conventions are near-universal, so an SSH key is almost always in ~/.ssh, an AWS credential almost always in ~/.aws/credentials, tokens almost always in the environment or a .env file. The harvester knows these locations, because everyone does, and it visits them in a sweep: open, read, collect, move to the next, and when the known stores are exhausted, send the collected material out to a collection endpoint.

That is the entire payload — a systematic read of the host's secret stores followed by an exfiltration — and it is over quickly, because there is nothing to sustain. The miner had to keep mining to keep earning; the harvester's earning is complete the instant the secrets are read and sent. A credential does not yield more by being read twice, so there is no reason to read it twice; and staying on the host after the secrets are captured gains nothing while adding the risk of discovery. So the harvester's rational behavior is to grab and go: land, sweep, exfiltrate, leave, frequently without installing any persistence at all. The payload that steals the most consequential thing on the host is often the one that spends the least time there.

This brevity is worth dwelling on because it inverts an intuition. One might expect the most damaging payloads to be the most elaborate and the most entrenched, and some are; but the harvester's damage is out of all proportion to its footprint. A few seconds of reads and one outbound transfer can capture the keys to a dozen other systems, and then be gone — no persistent process to find, no ongoing resource abuse to notice, nothing left running to alert on. The harvester's smallness is not a sign of low ambition; it is a sign that its ambition was already fully realized in the sweep. What it took, it has, and what it took can open doors for years.

2. The Loot Is a Key

Here is the property that defines STEAL DATA and separates it from every prior objective: the loot is a key, and a key is generative. Consider the difference precisely. When the miner steals compute, the stolen compute is consumed — turned into a hash, submitted, gone; the theft produces a one-time gain and the resource is spent. When the harvester steals a credential, the credential is not consumed by the theft; it is copied, and the copy is a working key, as valid in the thief's hand as in the owner's. The owner still has his key (he may not even know it was copied), and now the thief has it too, and the thief can use it — to log in, to access, to reach whatever the key was made to reach. The theft does not deplete; it duplicates a capability.

And the capability it duplicates is access, which is the one capability that begets more of itself. A stolen credential opens a system, and that system is a host too — with its own secrets, its own credential stores, its own keys to still other systems. So the harvester's product feeds directly into a compounding loop: harvest host A, use A's keys to reach host B, harvest B, use B's keys to reach C, and so on, each harvest funding the next intrusion with exactly the access it needs. This is why credential theft is the engine of so many large breaches — not because any single theft is catastrophic, but because each theft manufactures the means of the next, and the chain compounds. The harvester is the objective whose output is the input of the whole intrusion process; it is theft that pays for more theft.

This generativity is what makes STEAL DATA, in its credential form, arguably the most strategically significant objective in the register, however modest any single instance looks. The miner takes value out of the ecosystem (compute converted to coin); the harvester takes value that re-enters the ecosystem as new attack capability. A stolen credential is not an endpoint of harm but a beginning — the seed from which the next intrusion grows — and reading the harvester's intent means understanding that its purpose points not at what it did to this host but at what its loot will do to the next. The loot is a key, the key opens a door, and behind the door is another host with more keys. That recursion is the harvester's true objective, and it is why a small, brief, trace-less payload can be the most consequential thing that ever touches a machine.

3. The Seam With the Access Register

The harvester is the exact point where this register touches Follow the Access, and naming the seam precisely clarifies both registers. Follow the Access read how intruders get in — and among the primary vectors it documented, stolen valid credentials rank at the top, because a valid credential is the cleanest way in: no exploit, no vulnerability, just a login that works. This register reads a payload whose objective is to produce exactly those stolen valid credentials. So the harvester's output — a batch of working keys — is precisely the access register's input, and the two registers close a loop: the what of one intrusion (STEAL DATA) becomes the how of the next (valid-credential access). The payload objective and the access vector are two ends of the same rope.

This loop is why reading the harvester's intent requires reading forward, off the host and into the future. The proxy already taught the register to read an objective that points off the host, but the harvester's forward-pointing is of a sharper kind. The proxy pointed to passive downstream victims — parties the host's relayed traffic reached, who suffered the traffic but were not themselves further compromised. The harvester points to active future intrusions — the systems its stolen keys will open, which will themselves be breached, harvested, and used to reach further. The proxy's downstream was a set of targets; the harvester's downstream is a continuation of the attack, the next link in a chain the harvest forges. So the harvester's objective is consummated not on this host, and not merely on some passive victim, but on the next intrusion the harvest enables — a purpose that reaches into the access register's territory because it manufactures the access register's raw material.

This has a practical consequence the register will lean on repeatedly: to read a harvester is to know that somewhere else is now compromised, or soon will be. The harvested keys are, at the moment of exfiltration, valid access to real systems, and they are in a thief's hands, and thieves use what they steal. So a detected harvest is not a self-contained event to be cleaned; it is an announcement that the reach of this host has been captured and will be exercised. The seam with the access register is not academic — it is the reason a harvest on one host is a warning to every system that host could touch.

4. Reading the Objective, and the Executed/Staged Line

STEAL DATA reads at HIGH when the harvesting behavior is observed and executed, and its executed form is one of the most unambiguous signatures in the whole register: a systematic sweep of known credential locations, followed by outbound transfer. A process that opens ~/.ssh/id_rsa, then ~/.aws/credentials, then reads the environment, then reaches into browser credential stores, in a rapid successive sweep, and then sends the collected material to an external endpoint, is doing exactly one thing, and there is no benign account of it. Legitimate software does not sweep every secret store on the host in sequence and ship the contents to an unknown server. The sweep-plus-exfil is unambiguous (the function is unmistakably credential theft) and executed (the reads happened and the transfer happened, both observed), which is the register's gold standard, and it closes STEAL DATA at HIGH.

But the harvester's grab-and-go nature creates a specific evidentiary gap that the register must handle honestly, and it is worth working through because it recurs. Because the harvester is fast and often leaves no persistence, the honeypot may capture the reads — the systematic sweep of credential locations — but miss the exfil, if the payload exfiltrated through a channel or at a moment the sensor did not catch, or departed before the transfer was logged. What is the register's reading then? The temptation is to call it HIGH anyway, because a sweep of every credential store is obviously theft. The discipline is to resist that and grade it honestly: reads-with-observed-exfil is HIGH (unambiguous and executed); reads-without-observed-exfil is MEDIUM — the sweep is strong evidence of intent to steal, but the theft's completion is not confirmed, and "the secrets were read and staged" is a real and different claim from "the secrets were exfiltrated." This is the same executed-versus-staged distinction the register draws everywhere — the miner that ran versus the payload that only arrived — applied here at the credential layer. The sweep proves the intent to harvest; only the observed exfil proves the harvest completed. The register marks the gap rather than papering over it, reading HIGH on the full signature and MEDIUM on the sweep alone. The author, as ever, stays LOW: commodity stealers and grab scripts are public and universal, so the payload names the objective loudly and the hand not at all.

5. The Keyring Blast Radius

The harvester doubles the victim, and it does so at a scope that the register must name precisely, because it dictates the entire response. The proxy's split sent harm to strangers the host's traffic reached; the harvester's doubling reaches everyone the host held keys to. A compromised host is almost never an island — it holds an SSH key to a partner's server, an API token for a customer's cloud account, a database password for a system shared across an organization, a session for a third-party SaaS the company uses. Harvesting the host steals access to all of them at once. So the theft's reach is the host's entire keyring: every system the host could reach, every party whose secret it stored, is now reachable by the thief, and each of those parties is exposed through no action, fault, or often even knowledge of their own.

This is why a single harvested host can seed intrusions across many unrelated organizations, and why the harvester's blast radius is so much larger than its footprint. The host that was breached may be minor — a developer's laptop, a small server, a build machine — but its keyring may reach a partner network, a production cloud, a customer database, and a dozen SaaS tenants, and all of those are now within the thief's grasp because their keys sat on the one host he took. The compromise of one modest machine becomes the exposure of everything that machine could touch, and the things it could touch belong to many parties who never knew their key was there. The harvester converts a narrow intrusion into a broad exposure, and the breadth is measured not by the host's importance but by its reach.

For the defender, this dictates a response far broader than cleaning the payload — which, since the harvester is often already gone, may not even be possible or relevant. Removing the harvester does nothing about the secrets already exfiltrated, and those secrets are now valid keys in a thief's hand. So the imperative is rotation at keyring scope: every credential the host held must be treated as compromised and rotated — not just the local passwords, but every SSH key, cloud credential, API token, and shared secret the host could reach, across every third party, invalidated before it can be used. And because the theft is generative, the response must also watch the reachable systems for downstream use: the stolen keys will be tried against the systems they open, so those systems should be monitored for logins using the now-stolen credentials, so that a use of a not-yet-rotated key is caught. Clean the host if you can, but the real remediation is invalidating the keyring, everywhere it reaches, before the keys are exercised.

The honest close is the fairness the doubled victim demands. The third parties whose credentials were harvested from a compromised host are exposed, not implicated. A partner whose API key happened to sit on the breached machine has done nothing wrong; his exposure is a consequence of the host's compromise, not his own, and if his stolen key is later used to breach his systems, that intrusion is the thief's act, wearing the partner's key exactly as the proxy's abuse wore the host's address. The register names the objective — credential theft — and records the keyring as a scope of exposure to be remediated, explicitly not as a scope of culpability. The parties whose keys were stolen are victims once removed, not participants in the theft that will be committed with their keys. The vectors do not lie: this payload swept the secret stores and shipped them out, so its objective is credential theft, and its loot is a set of keys to systems it never touched. We name the objective, we map the keyring so it can be rotated, we watch for the keys' downstream use, and we do not implicate the parties whose keys were taken. We read the payload, we name the purpose it executes, and we let people judge.

6. The counter-narrative, steelmanned

The strongest objection to this case attacks the HIGH reading directly, using the harvester's own defining trait against it: because the harvester is grab-and-go and often leaves no persistence, the honeypot frequently sees only the reads — the sweep of credential locations — and not the exfiltration, because the payload shipped the data through an unseen channel or left before the transfer was logged. So in practice, the objection says, STEAL DATA is often asserted at HIGH on the strength of the sweep alone, without the "executed" half of the register's own standard ever being observed — which means the register is quietly relaxing its unambiguous-and-executed rule for its most consequential objective, reading a completed theft into what is really only an observed attempt to read secrets.

The objection is precise and it lands on a genuine tension. The register's whole confidence framework rests on the executed condition — the miner that ran, the proxy that relayed, the effect observed — and the harvester is exactly the payload most likely to deny the register that observation, because its speed and trace-lessness are designed to be over before anyone watches. If the register habitually called a bare sweep "HIGH — credential theft," it would be doing precisely what it forbids elsewhere: inferring a completed act from a staged capability, importing the "executed" it did not witness because the intent seems obvious. And the intent does seem obvious — a sweep of every secret store is plainly theft-shaped — which is exactly the condition under which the register is most tempted to overclaim, and exactly where its discipline is supposed to hold hardest.

The register answers by conceding the standard and applying it, not relaxing it: reads-with-observed-exfil is HIGH, reads-without-observed-exfil is MEDIUM, and the register marks which it has. This is the same executed-versus-staged line the register draws for every objective, and the harvester gets no exemption from it — precisely because it is consequential, not despite it. When the honeypot observes the full signature (the systematic sweep and the outbound transfer), STEAL DATA is HIGH, unambiguous-and-executed, as section 4 states. When the honeypot observes only the sweep, the register reads MEDIUM: the sweep is strong evidence of intent to harvest — a process reading every credential store in sequence is not doing so innocently — but "the secrets were read and staged" is a genuinely weaker claim than "the secrets were exfiltrated," and the register states the weaker claim when only the weaker evidence exists. The gap is real: a sweep that was interrupted, sandboxed, or failed to exfiltrate did not complete the theft, and the difference between a staged harvest and a completed one matters both for accuracy (was anything actually taken?) and for response (a confirmed exfil demands immediate keyring rotation; a staged-but-unconfirmed one demands rotation too, but the register should not assert a completion it cannot show). So the objection correctly identifies the temptation and incorrectly assumes the register yields to it: the register reads the sweep-alone at MEDIUM because the executed half is missing, exactly as its standard requires, and reserves HIGH for the cases where the exfil is observed. Crucially, MEDIUM here is not weak — a MEDIUM "intent to harvest, exfil unconfirmed" still triggers the full defensive response, because a keyring that was read must be rotated whether or not the read was confirmed to have shipped; the register does not need HIGH to sound the alarm. What it needs, and keeps, is the honesty to say HIGH only when it saw the theft complete and MEDIUM when it saw only the reach for the keys — which is not a relaxed standard but the standard, held under exactly the pressure the harvester was built to apply.

7. Objective Signal — STEAL DATA

Case 5 read the register's fourth objective in its credential-harvesting form. Where the miner, proxy, and bot each put the host to a continuing use, the harvester reads the host's credential stores — SSH keys, cloud credentials, environment tokens, config secrets, browser passwords — and exfiltrates them; the host was never the prize, the secrets on it were. THE DEFINING FEATURE: the loot is itself a KEY, so the theft is GENERATIVE. Stolen compute is spent and gone; stolen bandwidth relayed and gone; but a stolen credential UNLOCKS OTHER SYSTEMS — one harvested key logs into the next host, one cloud credential opens an account, one token reaches a tenant — so the harvest's output is a SEED, the raw material of the next intrusion, in a compounding chain. The harvester is the objective that most directly manufactures future intrusions, because its product is exactly what an intrusion needs to begin: valid access to somewhere new.

This is the SEAM where the payload register touches Follow the Access: the harvester's OUTPUT is the next intrusion's INPUT (the access register read stolen credentials as a primary vector; this payload's OBJECTIVE is to produce them), closing a loop where a payload-objective on one host supplies the access-vector for the next — so reading the harvester means reading FORWARD into the access register, the objective consummated not on this host but on the next intrusion the harvest enables (the second off-host objective after the proxy, but pointing to an ACTIVE future intrusion, not a passive downstream victim). The harvester's TEMPORAL SIGNATURE is GRAB-AND-GO, not persistence: value captured in a SINGLE SWEEP (read once, hold), often no persistent presence, briefer and harder to catch in the act. Its tell reads at HIGH: SYSTEMATIC reads of KNOWN CREDENTIAL LOCATIONS followed by OUTBOUND TRANSFER — unambiguous (no benign account of sweeping every secret store then exfiltrating) and executed (reads and transfer observed). The register grades honestly the harvester's characteristic gap: the full sweep-plus-exfil is HIGH, but the SWEEP ALONE (exfil unobserved) is MEDIUM — the same executed-versus-staged line the register draws everywhere, applied at the credential layer.

THE VICTIM IS DOUBLED at the scope of the host's entire KEYRING: every party the host held keys to (a partner's server, a customer's cloud, a shared database, a third-party SaaS) is now reachable by the thief, exposed through no fault of their own — which is why a single harvested host can seed intrusions across many unrelated organizations. Defensively the response is ROTATION at keyring scope (every credential the host could reach, across every third party, considered compromised and rotated — not just local passwords) plus watching the reachable systems for DOWNSTREAM USE of the stolen keys, because the theft is generative and the keys will be tried; the real remediation is invalidating the keyring before the keys are exercised. The exposed third parties are EXPOSED, not implicated: a partner whose key sat on the breached host did nothing wrong, and any later intrusion with his stolen key is the thief's act. Author stays LOW (commodity stealers). The steelmanned objection — that the grab-and-go harvester lets the register assert HIGH on the sweep alone, quietly relaxing its executed standard — is answered by the register conceding and applying the standard: HIGH only with observed exfil, MEDIUM on the sweep alone (a real staged-versus-completed gap), with MEDIUM still triggering the full keyring rotation because a keyring that was read must be rotated whether or not the exfil was confirmed. No individual named — objective named, commodity author declined, third parties recorded as exposed. Classification: TLP:WHITE. We read the payload, we name the purpose it executes, we map the keyring to be rotated, and we let people judge.

Follow the Payload — Case 5. Objective signal: STEAL DATA (credential harvesting). Confidence: HIGH for the objective when executed and observed (a SYSTEMATIC sweep of KNOWN CREDENTIAL LOCATIONS — ~/.ssh, ~/.aws, env, config secrets, browser stores — followed by OUTBOUND TRANSFER: unambiguous, no benign account, effect observed); MEDIUM on the sweep ALONE (credential-location reads without observed exfil — strong intent-to-harvest but the theft's completion unconfirmed, the register's executed-vs-staged line at the credential layer); LOW for the author (commodity stealers and grab scripts). THE DEFINING FEATURE: the loot is itself a KEY, so the theft is GENERATIVE — unlike spent compute or relayed bandwidth, a stolen credential UNLOCKS OTHER SYSTEMS, so the harvest's output is a SEED for the next intrusion, in a compounding chain; the harvester most directly manufactures future intrusions. It is the SEAM with Follow the Access (harvest OUTPUT = next intrusion INPUT), so reading it means reading FORWARD into the access register — the objective consummated on the next intrusion the harvest enables (an ACTIVE future intrusion, not a passive downstream victim). TEMPORAL signature: GRAB-AND-GO (single sweep, often no persistence, hard to catch in the act). THE VICTIM IS DOUBLED at KEYRING scope: every party the host held keys to is now reachable by the thief, EXPOSED not implicated (a single host can seed intrusions across many organizations). Defensively: ROTATE the whole keyring (every credential the host could reach, across every third party) and watch reachable systems for DOWNSTREAM USE; MEDIUM still triggers full rotation. Steelmanned objection (grab-and-go lets HIGH be asserted on the sweep alone, relaxing the executed standard) answered by grading honestly — HIGH only with observed exfil, MEDIUM on the sweep alone, standard held not relaxed. No individual named. Classification: TLP:WHITE. Include everything — the payload swept the secret stores and its loot is keys to systems it never touched; we name the objective, map the keyring, and decline the commodity author.