Follow the Access · 17 — The Planted Key: Cutting a Copy Before the Lock Is Changed

Follow the Access — Case 17. This register follows the intruder from the login prompt to the foothold's fate, and closes each case on what the access becomes: RANSOMED · MINED · PROXIED · HARVESTED · WIPED · RESOLD.

Getting in is the fragile part. The password the attacker guessed can be changed. The flaw he exploited can be patched. The machine can reboot and drop his session. A foothold obtained through any of the earlier cases is, at the moment of entry, a temporary thing — a door that the owner might close at any time, often without even knowing the attacker used it. So the professional intruder's very first act, before he mines a single coin or steals a single file, is to make his access permanent: to establish a second, independent way back in that does not depend on the original hole staying open. He cuts himself a copy of the key, so that when the owner finally changes the lock, the attacker still walks in through a door the owner does not know exists.

This is persistence, and it is one of the most important and least appreciated moves in the whole intrusion. The register can describe it with unusual precision, because the honeypot beneath these words has watched it happen thousands of times. Its entity graph holds 3,240 relationship edges of a single type — shared_authorized_key — each one a record of an attacker writing his own SSH public key into a compromised account's authorized-keys file, so that afterward he can log in with his private key, no password required, forever, regardless of what the owner does to the password. And its key analysis flags 284 keys as actor-reuse: the same attacker key planted across many different machines, one master credential unlocking a whole population of victims. These are not descriptions from a report. They are the sensor's direct record of intruders cutting copies of the key, at scale.

So the disposition is RESOLD, because persistence is precisely what turns a fleeting compromise into a durable, sellable asset. A momentary foothold is worth little; a standing backdoor that survives the owner's remediation is worth a great deal, because a buyer can rely on it. Persistence is the manufacturing step that productizes access — the move that converts a one-time break-in into inventory with a shelf life. This is the case about the copy of the key the attacker cut before the lock was changed, and about how that copy becomes a commodity worth more than the break-in that produced it.

1. Making the Fragile Foothold Permanent

Begin with why persistence is the professional's first priority, because the ordering tells you how experienced attackers think. An amateur, having gained access, rushes to do the thing he came for — steal the data, install the miner, deploy the ransomware. A professional does something else first: he secures his ability to come back. He does this because he understands that his initial access is the most fragile thing he has, and that everything he plans to do depends on retaining it. If he starts his real work and the owner happens to change the password, or patch the flaw, or reboot the box mid-operation, he is locked out with the job unfinished and no way back. So he spends his first minutes buying insurance against exactly that: an independent foothold that will survive whatever the owner does to the door he came through.

The logic is the logic of a burglar who, having picked a lock, immediately makes a wax impression and cuts himself a copy of the key before doing anything else in the house. The picked lock got him in once, but it is unreliable — the owner might change it. The copied key is reliable, because it does not depend on the lock staying pickable; it opens the door directly, and it will keep opening the door until the owner discovers it exists and specifically revokes it, which owners rarely think to do. The intruder's copied key is his real access; the original break-in was just the means of getting close enough to cut it. This is why persistence comes first: it transforms the access from something that might vanish at any moment into something the attacker controls and can rely on, and only once he has that reliability does he begin the work that reliability was for.

The consequence is a decoupling that defines the case. After persistence is established, the attacker's continued access no longer has anything to do with how he originally got in. The weak password, the unpatched flaw, the phished credential — whatever the entry was — becomes irrelevant, because the attacker now returns through the key he planted, not the hole he came through. This decoupling is the source of everything dangerous about persistence, and it is the reason, as later sections will show, that fixing the entry does not evict the attacker. He is no longer using the entry. He is using the copy of the key, and the copy is a different door entirely.

2. What the Honeypot Watched: The Planted Key

Now the evidence, because persistence is a case the honeypot can prove rather than describe, and the proof is in its own graph. The most common persistence technique on Linux — the operating system of the servers and devices the honeypot emulates — is the planted SSH key, and the mechanism is worth stating precisely. SSH, the standard remote-login protocol, supports logging in with a cryptographic key pair instead of a password: a user places a public key in a file called authorized_keys in their account, and anyone holding the matching private key can then log in as that user, without a password. It is a legitimate, widely-used feature. The attacker abuses it by writing his own public key into the authorized_keys file of an account he has compromised. From that moment, he can log in as that user any time, using his private key, and — this is the crucial part — changing the account's password does nothing, because key-based login does not use the password at all. He has cut a copy of the key that the owner cannot revoke by changing the password, because it is not the password.

The honeypot's entity graph holds 3,240 shared_authorized_key relationship edges, and each is a fingerprint of exactly this act. When the sensor observes an attacker planting a key, and later observes the same key on another machine, it records the relationship — and 3,240 such edges means the honeypot has watched attackers plant and reuse their persistence keys thousands of times, tying compromised machines together by the copies of the key left on them. This is the register's most direct evidence for any persistence claim: not an inference that attackers do this, but a count of the times the sensor caught them doing it. The planted key is not a theoretical technique in a framework; it is the single most-observed persistence mechanism in the honeypot's entire dataset, captured over and over, the concrete reality of intruders securing their return.

And the 284 actor-reuse keys add the operational dimension. A key classified as actor-reuse is one the honeypot has seen planted across multiple compromised machines — the same attacker public key, in the authorized_keys files of many different victims. This reveals that persistence is not a bespoke, per-target craft but a standardized practice: an intruder generates a key pair and uses that one key as his backdoor across his entire population of victims, so that a single private key unlocks his whole inventory of compromised machines. It is the master key to his kingdom of stolen boxes, and its reuse is what makes his persistence efficient — he does not manage hundreds of separate credentials; he manages one key that opens hundreds of doors. The honeypot's 284 actor-reuse keys are 284 such master keys, each unlocking some cluster of victims, and each captured by the sensor as the attacker planted it, machine after machine.

3. The Many Doors Beyond the Key

Broaden the picture, because the planted SSH key is the honeypot's most-captured technique but only one of many, and the full repertoire of persistence is what makes the tactic so hard to fully evict. The MITRE ATT&CK framework catalogues persistence as an entire tactic with dozens of techniques, because attackers have found an enormous number of ways to arrange a return, and a thorough intruder plants several at once — layering backdoors so that even if the defender finds and removes one, the others remain.

The alternatives to the planted key are diverse. The attacker can create a new user account — a backdoor account with a legitimate-looking name, blending in among the real users, so that his login appears to be just another authorized person. He can install a scheduled task or cron job that runs on a timer, periodically re-establishing his access or calling out to his infrastructure, so that even if his session is killed, the task brings him back at the next interval. He can add a startup service or modify a startup script, so that his access re-establishes itself every time the machine boots. He can plant a web shell (Case 06), a backdoor disguised as part of a website. He can install a full implant or remote-access tool. Each of these is a different door, and each shares the defining property: it survives the closing of the original entry, and it is designed to blend in with legitimate configuration so the defender does not notice it. The backdoor account looks like a user; the scheduled task looks like maintenance; the planted key looks like a normal authorized_keys entry. Persistence hides in plain sight, camouflaged as the ordinary furniture of a working system.

This diversity is why persistence is the tactic that most demands thoroughness from the defender, and most punishes incompleteness. Finding one planted backdoor is not enough if the attacker planted three; removing the key does not help if he also created an account and a scheduled task. A professional intruder, understanding that persistence is his lifeline, does not rely on a single mechanism — he establishes redundancy, so that evicting him requires finding every door he cut, and missing even one means he is still inside. The register's earlier cases often had a single point of fix; persistence, by design, has many, scattered and disguised across the system, each an independent way back that the defender must find and close individually. It is the tactic built specifically to make eviction hard, and it succeeds, because the attacker gets to choose how many doors to cut and where to hide them, while the defender must find all of them to be sure.

4. Why the Fix Does Not Evict

Now the property that makes persistence so consequential, and so commonly underestimated: fixing the entry does not evict the attacker, because the attacker is no longer using the entry. This is the single most important operational lesson of the case, and it is where organizations most often fail after a breach.

Consider the natural, reasonable response to a discovered compromise. An organization learns it was breached through a weak password, so it changes the password. Or it learns it was breached through an unpatched vulnerability, so it applies the patch. Having done so, it reasonably concludes that the hole is closed and the attacker is locked out — the way in has been fixed, so surely the intruder can no longer get in. This conclusion is wrong, and it is wrong because of the decoupling from Section 1: the attacker, having established persistence, no longer returns through the original hole. He returns through the planted key, the backdoor account, the scheduled task — none of which depend on the password or the patched flaw. So the organization changes the password the attacker no longer needs, and applies the patch to the flaw the attacker no longer uses, and the attacker, entirely unaffected, logs back in through the door he cut for himself, into a network that believes it has evicted him. The fix closed the front door while the burglar comes and goes through the copied key to the side door the owner never knew he made.

This is why incident response, done properly, is not remediation of the entry but a hunt for persistence. Evicting an attacker means finding and removing every backdoor he established while he was inside — every planted key, every rogue account, every malicious scheduled task, every implant — which is far harder than fixing the one hole he came through, because the backdoors are multiple, disguised, and scattered, and because the defender often does not know how many there are. An organization that fixes the entry and declares victory has, in the common case, done the easy half of the job and skipped the hard half, leaving the attacker with exactly the standing access his persistence was designed to preserve. The recurring, painful pattern in real breaches is the re-compromise: an organization "remediates," believes it is clean, and is breached again days or weeks later by the same attacker through the same persistence it never found. The fix was real; the eviction was imaginary; the copy of the key was still in the lock the whole time.

5. RESOLD — Access With a Shelf Life

Now the disposition, and persistence earns RESOLD because it is the step that converts access from a perishable moment into a durable, tradeable commodity. To see why, return to the access-broker economy of Case 10, and ask what a broker actually wants to sell — because the answer reveals persistence as the productizing step.

A broker's product is access, and access is only valuable to a buyer if the buyer can rely on it. A fleeting foothold — a session that might drop, a password that might change, a flaw that might be patched before the buyer can use it — is nearly worthless as inventory, because the buyer cannot depend on it still working when they go to use it. What a broker needs to sell, and what a buyer will pay for, is durable access: a standing, verifiable, re-enterable door that will still be open tomorrow and next week, that survives the victim's ordinary maintenance, that the buyer can develop at their own pace into a ransom or a theft. Persistence is exactly what manufactures that durability. The planted key, the backdoor account — these are what make a foothold into a reliable, lasting asset, one the broker can verify still works and the buyer can trust will keep working. Without persistence, access is a moment; with persistence, access is a product.

So the disposition is RESOLD because persistence is the productization of access — the manufacturing step that turns a one-time compromise into inventory with a shelf life. This is why the professional intruder establishes persistence before doing anything else even when he does not personally intend to ransom or mine the box: the persistent access is itself the valuable thing, whether he uses it or sells it, and the market prices it far above a fleeting foothold precisely because it is durable. The register marks the disposition RESOLD not because every persistent foothold is literally sold, but because persistence is the property that makes access sellable — the transformation that gives a break-in a market value beyond the moment. A one-time entry is an event; a persistent backdoor is an asset; and the difference between them, the thing that makes the second worth trading, is the copy of the key the attacker cut before the lock was changed. Persistence is where access stops being something that happened and becomes something that can be owned, held, and sold.

6. The Key That Betrays Its Maker

Before the defense, a forensic irony worth pausing on, because it is how the honeypot turns the attacker's own persistence into the map of his infrastructure, and it explains a thread that has run through the whole register. The intruder plants a reused key for his own convenience: one key to unlock all his boxes, so he does not have to manage hundreds of separate credentials. But that same convenience is a catastrophe for his anonymity, because the reused key is a durable, unique identifier that ties every machine he backdoored into a single, provable cluster.

Look again at the honeypot's 284 actor-reuse keys through the defender's eyes. Each reused key is, from the attacker's side, a master credential — but from the sensor's side, it is a signature. When the honeypot sees the same public key planted in the authorized_keys files of many machines, it does not just observe persistence; it observes that all those machines belong to the same operator, because only one operator holds the private key that matches. The reused key is simultaneously the thing that keeps the attacker in and the thing that proves the machines are his. His persistence mechanism is his attribution thread. The 3,240 shared_authorized_key edges in the entity graph are, in aggregate, a map of which victims were backdoored by which actors, drawn using the attackers' own planted keys as the ink — and that map is a large part of how the honeypot's 212,000-edge entity graph reconstructs the criminal economy this register has followed throughout.

The lesson generalizes beyond keys, and it is a quietly hopeful one. Persistence is meant to be the attacker's hidden advantage, but persistence requires leaving something behind — a key, an account, a task — and anything left behind is evidence. The attacker who wants to come back must plant a marker to come back through, and the marker, especially when reused across victims for efficiency, becomes the durable identifier that links his operations and unravels his infrastructure. His need to persist is in tension with his need to hide: the more reliably he arranges his return, the more he leaves behind for the defender to find and correlate. The honeypot exploits exactly this tension, harvesting the attackers' persistence keys as attribution data, turning the copies of the key they cut into the ledger of who they are. Persistence, meant to hide the intruder, in aggregate exposes him — which is the register's recurring consolation: the vectors do not lie, and the marks the attacker leaves to help himself are the same marks that give him away.

7. Disposition — RESOLD

Case 17 followed persistence — the professional intruder's first act after entry, the cutting of a copy of the key before the lock is changed. Because a foothold is fragile, he immediately establishes an independent way back in that does not depend on the original hole: most commonly, as the honeypot's 3,240 shared_authorized_key edges directly record, by planting his own SSH public key in a compromised account's authorized_keys file, so that changing the password does nothing; and often across many victims with one reused key, as the 284 actor-reuse keys show. He layers other doors too — backdoor accounts, scheduled tasks, startup services, web shells — each disguised as ordinary configuration, each surviving the closing of the entry.

The disposition — the foothold's fate — is RESOLD, because persistence is the step that turns access into a durable, tradeable commodity. A fleeting foothold is nearly worthless inventory; a standing backdoor that survives remediation is what a buyer will pay for, because it can be relied upon — so persistence is the manufacturing step that productizes access, converting a one-time compromise into an asset with a shelf life. It is why the intruder secures his return before doing anything else: the persistent access is itself the valuable thing, whether he uses it or sells it into the broker economy of Case 10.

The defense follows from the case's hardest truth: remediation is not eviction. Fixing the entry — changing the password, applying the patch — closes the door the attacker no longer uses, while the door he cut for himself stays open; so eviction means hunting persistence, auditing authorized_keys for keys you did not add, reviewing accounts, inspecting scheduled tasks and startup services, hunting the web root, and continuously monitoring these locations, because a new key or account or task is a high-fidelity signal. And the case's consolation is the key that betrays its maker: the reused persistence key that keeps the attacker in is the same key that ties his victims together and unravels his infrastructure in the honeypot's graph. The vectors do not lie: the intruder picked the lock once, cut a copy of the key, and walked back in through a door the owner fixed everything but — his convenience his exposure, his return his signature, his persistence both his asset and his ledger. We do not judge. We record. We let people judge — and then, if they are wise, hunt for every copy of the key, because eviction is finding them all.

Follow the Access continues. Case 17 disposition: RESOLD. Confidence: HIGH — the planted-SSH-key persistence technique and its key-reuse practice are captured directly in the honeypot's entity graph (3,240 shared_authorized_key edges, 284 actor_reuse keys); the broader persistence repertoire is catalogued in MITRE ATT&CK's Persistence tactic (TA0003); the RESOLD disposition follows the durable-access requirement of the access-broker economy (Case 10); and the reused-key-as-attribution observation is drawn from the honeypot's own entity-graph methodology. The remediation-is-not-eviction lesson and the persistence-hunting defense follow standard incident-response practice. The web-shell persistence form connects to Case 06. Classification: TLP:WHITE. Include everything — the vectors do not lie, and they do not judge. The reader judges the copied key, the door the fix never closed, and the mark the attacker left to find his own way back.