Why is 'the payload was memory-only, so the reboot cleared it' usually the wrong conclusion?

## Why the claim is attractive It sounds rigorous. Memory is volatile; a reboot clears memory; the payload was in memory; therefore the payload is gone. Every step is individually true, and the conclusion is still usually wrong, because the premise smuggles in a second claim that was never checked: that memory was the payload's **only** residence. ## Error one: residence is not the same as execution `Fileless` and `memory-only` are assertions about the executable - no program image on disk, nothing to hash, nothing for an executable allowlist to refuse. They are not assertions about storage. In most real chains, the body persists as **data**: an encoded blob in a job record, a value in the application's own configuration store, a long string in an environment or profile fragment. A durable trigger reads that data and hands it to a runtime that was already installed. On such a host, a reboot is not a cleanup step. It is the trigger's *cue*. The chain is designed so that a restart is the thing that brings it back. Telling an owner the reboot cleared the host, when the reboot is what re-ran the payload, is the specific mistake this question exists to prevent. ## Error two: the disposable case is real, and it still does not mean cleared There is a genuine variant with nothing durable at all. Consider the position that produces it: a commodity criminal running a mass campaign against one flaw in an internet-facing application, code executing as the application's unprivileged service account, no domain, no user profile, a long uptime. For that operator, persistence is a bad trade. Building a trigger costs work, requires writing somewhere that has an owner, and creates the one durable thing anybody could stumble over. Re-exploiting the same unpatched flaw costs a single request. The rational design is a payload that lives in the process and dies with it. So `nothing was planted` is frequently correct - and it means the operator **chose** not to persist, not that they failed to. The reboot then really did end that process. It did not close the flaw, it did not change the operator's cost of returning, and it did not remove them from a target list they are re-scanning anyway. `Cleared` is a statement about one process; the owner heard a statement about their service. ## Error three: what was taken does not reboot away The process ran as the application's service account for as long as it ran. Everything that account could read - configuration values, keys held in the application's own settings, connection strings, the data the application serves - was readable to it. A reboot restores none of that. Any conclusion phrased as `we are back to normal` has to survive the question *what did that account have access to*, and on a public-facing application server the honest answer is usually `more than the owner assumed`. ## What the defensible claim looks like Say two things, not one: 1. **Nothing durable on this host invokes anything the operator put there.** That is a claim about job records, unit-style startup definitions, profile fragments and the application's own configuration store - the places a body can sit as data and be handed to a runtime. 2. **The way in is closed.** The flaw that let them execute is fixed, or the path to it is removed. With both, `the reboot ended their code` is a sound statement. With only the first, you have removed residence and left an open door for a crew whose entire model is walking back through it. With only the second, you may have closed the door on someone who is already inside on the next boot. ## How to say it to an owner who will act on it Owners act on classifications, so give them a classification that maps to an action. `Memory-only, nothing planted, flaw still open` means *patch now, expect a return*. `Memory-only executable, body stored as data with a trigger` means *the reboot re-ran it; the host is not in the state you think*. `Memory-only, nothing planted, flaw closed` is the only version where the reboot is genuinely the end of it - and even then it is the end of the code, not of what the account exposed while it ran. The wider lesson is that a single adjective is not a verdict. `Fileless`, `persistent` and `privileged` are three independent properties, and a claim about one of them answers nothing about the other two.