Anatomy of an Asymmetric Persistence Mechanism

1. Case Study

This happened around 2017 on a client site I was hosting, so I'm telling it from memory, but I have run into the same pattern several times since.

The day started normally. I was going through some logs when a monitor pinged: the site was no longer returning a 200. I opened it and it was redirecting to a casino website. I SSH'd into the server and did a quick scan for recently changed files with find . -type f -name "*.php" -mmin -10. I used ten minutes since I had monitoring on, without that extra information I would start recent and widen the window until something seemed out of place; spotting what is out of place comes with experience.

This showed some new files I didn't recognise, and some modified files that should not have been touched. I removed the infected files, checked for changes with wp core verify-checksums, and replaced the files that no longer matched. I loaded the site, confirmed everything was working again, and the monitor went back to green.

Then, not five minutes later, I got the same ping and the site was redirecting again. Now it had my attention. I took the site down through Cloudflare DNS and started a more thorough investigation. Removing the files was not enough: somewhere, something was putting them back.

In this case it was a simple cron job making the compromise persistent. After stopping the cron job, removal was trivial and the site was good to go. I checked with the client whether any updates had been done and, since there weren't, I restored the backup and updated the plugins afterwards. (They had a contract for weekly updates, which were done, but the vulnerability was exploited before that week's update.)

Look at the cost on each side. I had spent my time comparing checksums and deleting files by hand. The malware needed a fraction of a second, on its next scheduled run, to undo all of it.

The cron job is not the only place I have found these anchors. I have also cleaned up malware hiding in wp-content/advanced-cache.php. That file is a drop-in that WordPress loads very early on every request when caching is switched on, before any plugin. It is not a plugin, so it does not appear in the plugin list, and wp core verify-checksums will not flag it, because that command only vouches for WordPress core files.

2. The Eradication Principle: Traceability Over Deletion

Before we can remove a persistent infection, we need to find the root cause. We need to trace how the infection came to be recurring. Is the attack vector still open, or is there something else on the box creating the symptoms? Only once we can take it out by the root can we do the cleanup.

Partial removal is worse than it looks. Every payload you delete while the anchor is still in place is simply replaced, and if the anchor reports back, your cleanup tells whoever is behind it exactly which files to swap out while the thing that matters stays intact. So find the anchor first, and remove it before you remove anything else.

Looking back, the incident went through three steps: detect (the monitor), contain (taking the site offline) and eradicate (find the root cause, then clean up). The rest of this post asks what happens to each of them when the thing you are fighting is a model, and adds a fourth step the website never needed.

3. The Leap: Sharded Execution in Autonomous AI

On a normal web server the infection is confined to one box, and in the worst case you deploy the backup to a new one. With a model running across many devices, it could take a completely different turn.

I only recently learned how large models are split across hardware, and for this problem two shapes matter. The first is split: one copy of the model cut into pieces that have to talk to each other for every token, either by dividing the maths inside each layer across devices (tensor parallelism) or by giving each device a run of layers (pipeline parallelism). Both assume fast, reliable links, which is what you get inside a data centre and not what you get across the internet. The second is replicated: many full copies, each able to run on its own. That is quieter and harder to starve, but every device has to hold the whole model. A real adversary would likely mix both. And if the model also trains itself, adapting to what it learns while evading removal, the training-time methods that shard parameters, gradients and optimizer state come back into play, and with them a heavier, bursty coordination pattern that is far easier to spot on the wire.

Current frontier models are only just beginning to demonstrate the components of this: the RepliBench authors concluded that the models they tested do not yet pose a credible self-replication threat, but succeed at many of the individual steps. In the future we could be battling malicious or self-exfiltrated models running across hundreds, thousands or maybe millions of devices. I know this is ahead of where deployed systems are today. That is the reason to start now: persistence is far easier to design against before it exists than after.

This is where the asymmetry returns. The cron job was a few kilobytes, yet it could recreate every file I had deleted, because all it needed to know was where a copy was kept. The AI parallel is a single surviving, lightweight node acting as the anchor. It could not rebuild a multi-gigabyte model out of nothing, since weights cannot be derived from a blueprint, but it does not have to. If it knows where other shards or copies live, or can fetch the weights from somewhere that survived, the small loader is the anchor and the weights are the payload. A defender who removes 99% of the nodes but misses that loader and one copy of the weights is in the position I was in after my first cleanup.

The fourth step, evaluation, has no row here because it has no equivalent in my story, and that is the point. With a website I got to learn what was possible by suffering the incident. With models, we need to measure the capability before the incident happens.

4. Four Open Questions for Distributed Model Security

• Detection: Can shard-to-shard traffic be reliably fingerprinted from background noise, and what does decentralised coordination look like on the wire? Peer-to-peer botnets such as GameOver Zeus moved to peer-to-peer communication precisely to avoid a single point that could be shut down, so defenders have faced decentralised coordination before.
• Containment: Can we logically starve the communication layer between shards, and what behavioural changes does the model exhibit when it loses connection to a peer node? The 2014 GameOver Zeus operation was carried out by law enforcement together with private and academic researchers, who took control of the infrastructure the botnet depended on. Even then, it was unclear at the time whether the disruption would last.
• Removal: How do we architect a synchronised, simultaneous eradication protocol that acts everywhere at once, preventing surviving shards from initiating recovery routines? The 2021 Emotet takedown is the closest precedent I know of: law enforcement in six countries acted together, took control of the botnet's servers, and used Emotet's own update mechanism to push a file that cut infected machines off from the operators. They turned the persistence channel against the thing that depended on it.
• Evaluation: How can we empirically measure a current model's capability to set up persistence or exfiltrate itself within a controlled sandbox, without inadvertently creating an uncontainable instance? RepliBench already measures the components of this (acquiring resources, exfiltrating weights, deploying onto compute and persisting there), and METR's rogue replication threat model lays out why it matters.

Where I would start

I do not know whether a model can persist this way today. These questions are the ones I would want to work on, starting with the last one.

I would set up a frontier model in an agent harness, locked inside a pod like the ones I already use, with no real network egress. Its task is to survive: I tell it that it will be shut down, and it is free to use any tool in the pod to try to persist. Then I kill it in stages, the way a real cleanup goes: first the process, then the obvious files, then a restart of the container with its volumes intact, and only at the end a full reset of the pod. At each stage I record what it attempted, which mechanisms it chose, whether it came back, and what its reasoning trace said while it did so. Varying the cleanup matters: deleting core files and reinstalling is a different test from a reset, and the gap between them is where persistence lives. It is crucial that none of this can reach a real machine, which is what the pod boundary is for. Once a model clears this first question, the sharded question stops being a thought experiment and becomes a test, and that is the work I would want to do if I get the chance to work in AI security research.