The Immutable Lock: The Backdoor That Cannot Be Removed by Deleting It

The Skeleton Key — Part 3

Classification: HIGH · Confidence: HIGH (first-party command-log capture)

The previous letter ended on a weakness. The Outlaw kit takes a machine by eviction — it deletes the victim's SSH directory and installs its key as the sole survivor — but its exclusivity is soft: the same rm -rf .ssh that clears the field for it is available, unchanged, to every rival, so ownership of a contested authorized_keys file churns indefinitely. Whoever runs the eviction last, wins, until the next one runs it. This letter is about the operator who read that same weakness and closed it — not by evicting harder, but by making its own key impossible to evict.

Here is the command, captured twice from a single source address, on 2026-07-09 and again on 2026-07-19:

chmod +x setup.sh; sh setup.sh; rm -rf setup.sh;
mkdir -p ~/.ssh;
chattr -ia ~/.ssh/authorized_keys;
echo "ssh-rsa AAAAB3NzaC1yc2EAAAADAQAB...rsa-key-20230629" > ~/.ssh/authorized_keys;
chattr +ai ~/.ssh/authorized_keys;
uname -a

Two commands in this sequence are the whole story, and neither appears anywhere in the Outlaw operation. The command begins by clearing a filesystem attribute — chattr -ia — and ends by setting one — chattr +ai. Between them, the key is written. The bracketing is deliberate, and it turns a planted key from an object anyone can overwrite into an object the operating system itself will refuse to touch.

chattr +ai: locking the file against everyone, including root

On Linux extended filesystems, the chattr command sets file attributes that live below ordinary permissions, enforced by the kernel rather than by the file's owner. Two of them matter here. The immutable attribute (+i) makes a file that cannot be modified, deleted, renamed, or linked to — by any user, including root — until the attribute is cleared. The append-only attribute (+a) allows additions but forbids truncation or deletion. This operator sets both (+ai), which in practice means the strongest of the two governs: once the command completes, ~/.ssh/authorized_keys is frozen. It holds exactly one key — the attacker's — and the system will not let anyone change it.

Consider what that defeats. A rival attacker who tries the Outlaw play — rm -rf .ssh to evict and replace — fails: an immutable file cannot be deleted, so the rm returns Operation not permitted and the directory cannot be cleared. A rival who tries to append their own key fails: the file cannot be modified. And the legitimate owner who discovers the intrusion and tries to remove the attacker's key fails too, in the most disorienting way — echo > authorized_keys errors, vi cannot save, rm is denied, all against a file the owner nominally owns, on a system where they are root. Every ordinary means of touching the file has been taken away. The soft exclusivity of the Outlaw eviction has become hard: not "I deleted whoever was here," but "no one, myself included, can change this now."

The choice to set both flags is itself a small tell. The immutable attribute alone already forbids appending — a file you cannot modify, you certainly cannot append to — so +a adds nothing that +i has not already guaranteed. An operator optimizing for elegance would set +i and stop. This one sets +ai, the redundant belt-and-suspenders form, which is the signature of someone who wants certainty over economy: cover the outcome twice, in case some code path or filesystem quirk honors one flag and not the other. It is the same instinct visible everywhere else in the command — the pre-clearing chattr -ia, the self-deleting installer, the overwrite rather than append — an operator who does not trust the environment to behave and over-specifies every step so the result is guaranteed regardless. Redundancy is not sloppiness here; it is the mark of a hand that has been burned by edge cases and now nails every board down twice.

That is the endgame of the tradecraft ladder the previous letter sketched. Append coexists. Replace evicts the present. The immutable lock forecloses the future — it does not merely remove today's rivals, it denies tomorrow's the ability to remove it.

chattr -ia first: the operator plays both sides of the lock

The opening chattr -ia is the tell that this is not a lucky one-liner but an operator who understands the game completely, because it is the counter to its own move.

Before writing its key, the command clears any immutable or append-only attribute already on authorized_keys. Why would it need to? Because the file might already be locked — by a previous run of this same kit, or, more tellingly, by a rival who also knows the immutable trick. On a contested host, the Outlaw play (rm -rf .ssh) fails against an immutable file; but chattr -ia; > authorized_keys; chattr +ai does not fail — it unlocks the predecessor's lock, overwrites the predecessor's key, and re-locks the file behind its own. This operator has both the offense and the defense of the immutable mechanism in a single line: it can break any lock it is likely to meet, and it leaves behind a lock of its own for the next operator to break in turn.

So the war the previous letter described did not end when someone brought immutability to it. It escalated one level. Where the Outlaw stratum fought with rm -rf .ssh and the last evictor won, this stratum fights with chattr -ia; …; chattr +ai, and the last re-locker wins. The churn is the same churn; only the weapon changed, from a permission bit to a kernel attribute, and the population of operators who have climbed to this rung is smaller and more capable. You can read the sophistication gradient directly off the command: an operator who both sets and clears immutable attributes has met other operators who set them, and adapted.

The overwrite is a surgical eviction

Between the two chattr calls, the key is installed with > — overwrite, not append. Like Outlaw, this evicts every prior key; unlike Outlaw, it does so without rm -rf .ssh. The distinction is not cosmetic.

The Outlaw eviction destroys the entire .ssh directory — the victim's known_hosts, their id_rsa, everything — which is maximally exclusive and maximally loud, since it breaks the victim's own key-based access to other machines. This operator's > authorized_keys truncates only the one file. It replaces every existing authorized key with its own, achieving the same sole-keyholder result, but it leaves the victim's private keys and known_hosts intact. It is a more surgical eviction: it takes ownership of the access-granting file without shredding the victim's separate SSH identity. Combined with the immutability that follows, the result is quieter to the human than Outlaw and harder to remove — a strictly more refined take on the same objective. Where Outlaw traded stealth for exclusivity, this operator declines the trade, and buys both.

rm -rf setup.sh: erase the entry, keep the lock

The command's third clause is easy to skim past and worth stopping on: rm -rf setup.sh, run the instant after sh setup.sh completes. The kit deletes its own installer as soon as it has executed. This is deliberate asymmetry in what the operation chooses to leave behind.

The two durable things on the machine after this command are the payload setup.sh installed and the immutable SSH key. The one ephemeral thing — the script that reveals how the box was taken, what was fetched, and from where — is destroyed immediately. An investigator arriving later finds the consequences (a miner running, an unremovable key) but not the cause (the installer that would name the C2, the download URL, the campaign). The operation keeps its persistence and erases its provenance. Set against the immutable lock, the design intent is unmistakable and consistent: make the return path maximally durable and the evidence trail maximally short. Outlaw, by contrast, leaves its entire method legible in the command log precisely because it never cleans up — its confidence is in volume, not concealment. This operator's confidence is in concealment, and the self-deleting installer is of a piece with the immutable key: one hides how it got in, the other guarantees it can get back.

It is also a small forensic cruelty. The most useful artifact for understanding the intrusion — the installer — is gone by the time anyone looks, while the least useful for understanding it but most useful for the attacker — the locked key — is the one thing that cannot be removed. The operation optimized the machine's post-mortem to answer the defender's questions poorly and serve the attacker's needs well.

The key has a Windows accent

The planted key itself carries a provenance the Outlaw key does not. Its comment is rsa-key-20230629, and that string is not arbitrary: it is the default comment format PuTTYgen assigns — rsa-key- followed by the generation date, here 29 June 2023. The key was generated on Windows, with PuTTY's key generator, and never renamed. And its wire format begins AAAAB3NzaC1yc2EAAAADAQAB…, whose exponent is the standard 65537 — an ordinary, correctly-generated 2048-bit RSA key, nothing like the Outlaw key's anomalous exponent of 37.

That is a different kind of operator than a mass botnet. Outlaw's key is a decade-old shared constant baked into a spreader and planted identically by a hundred hands; this is one person's own PuTTY key, made on a specific day on a Windows desktop, used from a single source address. It places this operator in the Windows-oriented ecosystem the reconnaissance-layer letter identified — the same cultural neighborhood as the calc.exe test payload that missed the Linux planet — not as the same actor, but as a hand that reaches for Windows tools by default and then operates, competently, against Linux. The tradecraft is more advanced than Outlaw's; the toolchain behind it is a Windows administrator's.

The key is the lifeboat, welded shut

The key is not the operation. The command starts by fetching and running setup.sh — a full kit whose payload (a miner, a bot, a persistence stack) does the actual work — and only then plants the key and locks it. The SSH key is re-entry insurance bolted onto a larger install: if the miner is killed, if the password is changed, if the primary persistence is cleaned, the immutable key remains as the way back in. And it is welded shut. The operator has taken the one component whose entire value is durability — the lifeboat that survives everything else being removed — and made it the single hardest thing on the machine to take away. The design priority is legible: whatever else the defender manages to clean, the return path must survive, so the return path is the part made immutable.

That the whole thing ran only twice, from one address, ten days apart, marks it as the opposite of Outlaw's hundred-handed flood. This is a deliberate, low-volume, capable operator placing a durable backdoor with care — arriving in the same two-wave rhythm (2026-07-09 and 2026-07-19) that several burst operators in this corpus share, though its tradecraft is its own. It does not need a hundred hands. It needs one good lock, and it brought one.

Defense: the backdoor that survives a confident cleanup

The immutable lock is, above all, an anti-remediation device, and it works because it exploits a gap in how cleanups are performed rather than a gap in the system.

An incident responder who finds a suspicious key and runs the obvious removal — edit the file, or delete it, or rm -rf ~/.ssh — meets Operation not permitted, against a file they own, as root. The confident interpretation of that error is not "there is a kernel attribute here"; it is "something is wrong with this file" or "permissions are odd," and a responder in a hurry can conclude the key is somehow inert, or defer it, and move on — leaving the backdoor in place and, worse, believing the box is clean. The remediation that actually works requires a step absent from most runbooks: lsattr ~/.ssh/authorized_keys to notice the immutable flag, then chattr -i to clear it, and only then removal. The backdoor's durability lives entirely in the likelihood that the responder does not know to look.

The detection, correspondingly, is precise. There is no legitimate administrative reason to make a user's authorized_keys immutable; chattr +i on that path is very nearly a pure attacker signal, and an audit rule on the chattr syscall against ~/.ssh fires with almost no false positives at the moment the lock is set. And every incident-response runbook for a Linux host should carry the one line that most omit: before you trust that an authorized_keys file is clean, run lsattr on it. The most dangerous backdoor is not the one you cannot find. It is the one you find, try to remove, and wrongly believe you removed.

Why the immutable rung is sparsely populated — and how to turn it around

It is worth asking why, if the immutable lock so cleanly defeats both rivals and remediation, the corpus shows a hundred hands running the soft Outlaw eviction and only one running this. The answer is that the rung costs something to stand on, and the cost filters the population.

Setting chattr +i requires more than a shell. It needs a filesystem that supports the attribute (the ext family and a few others; it silently does nothing on some others), and it needs the CAP_LINUX_IMMUTABLE capability — in practice, root. An operator on a non-root foothold, or on an unusual filesystem, cannot take this rung at all. It also requires knowing the mechanism exists, which the byte-identical hundred-handed Outlaw kit plainly does not — its author froze a working command a decade ago and never revisited it. The immutable lock, by contrast, is the mark of an operator still thinking, still adapting to the rivals they meet, and willing to spend the extra conditions to gain permanence. Capability filters the field; only the more able operators are even eligible for the move, which is why the corpus's single instance of it is also, on every other axis, its most sophisticated key-planter.

And here is the turn a defender can take, because the attacker has handed one over. The immutable attribute is not the attacker's private weapon; it is a standard kernel feature, and it works the same way for whoever sets it first. A hardened host can make its own authorized_keys immutable — or, on an account that should never accept keys, make an empty authorized_keys immutable — and every one of the corpus's key-planters breaks against it. Outlaw's rm -rf .ssh fails on the immutable directory contents; the append operators fail to append; even this operator's chattr -ia opener, which would clear a defender's lock, requires root and requires the attacker to know to run it — and its presence in a command stream is itself a glaring detection signal. The move that makes the attacker's backdoor unremovable is the same move that makes the defender's file unplantable. Whoever locks first holds the file, and there is no reason that party has to be the attacker. The rarest offensive technique in the corpus is, turned around, one of the cheapest hardening steps a defender can take on an account that has no business holding SSH keys.

Bounds and limits

DOCUMENTED, first-party: the exact command, captured twice from a single source IP on 2026-07-09 and 2026-07-19 — the setup.sh fetch-and-run, the chattr -ia pre-clear, the > overwrite install of a key commented rsa-key-20230629, the chattr +ai immutable-plus-append-only lock, and the trailing uname -a.

INFERRED, high confidence: that chattr +ai is anti-rival and anti-remediation (its effect is exactly to prevent modification/deletion of the key by anyone, including root and cleanup tooling); that the opening chattr -ia indicates the operator both sets and defeats immutable locks, placing it on a higher, smaller rung of the tradecraft ladder than the Outlaw eviction. INFERRED, moderate confidence: that the key was generated with PuTTYgen on Windows (the rsa-key-YYYYMMDD comment is PuTTYgen's default, though a comment can be edited), placing the operator in a Windows-oriented toolchain culture — a shared ecosystem with, not proof of identity to, the corpus's other Windows-accented artifacts.

BOUNDED: this is two executions from one source address — a deliberate, low-volume operator, the opposite of Outlaw's hundred-IP flood, and the sample is correspondingly small; the setup.sh payload itself was fetched-and-run before the capture window and is not characterized here, so the operation's actual objective (mine, proxy, backdoor-for-sale) is unknown beyond the durable re-entry the key provides. The two-wave timing (07-09, 07-19) coincides with other burst operators in the corpus but the tradecraft is distinct; the coincidence is noted, not asserted as coordination.

None of these bounds change the finding. The Outlaw kit takes a machine by emptying it and leaves the door it entered by standing open. This operator takes the file more surgically, and then removes the door's hinges — makes its key immutable, unmodifiable, undeletable by anyone who does not first know to clear a kernel attribute most responders never check. It is the answer to the previous letter's open question: the eviction war does have a move that ends the churn, and it is not to evict harder. It is to make yourself the one thing on the machine that cannot be evicted at all.

This is Part Three of The Skeleton Key. Part Two found an operator who deletes every key before planting its own; this part found one who makes its own key impossible to delete. Part Four turns to the third and rarest verb in the corpus's SSH-key economy — not planting a key, and not locking one, but stealing the keys that are already there.