Why does a commodity infostealer run once and never install persistence?
answer
- think about the operator's unit of payment
- the value is realised in one pass
- staying costs, and buys nothing
- paid per install, not per victim
- no persistence means a different objective
basics
~20 sBecause the operator is paid per install, not per victim. One pass copies the browser profile and other saved material into an archive, uploads it and exits. Staying would add cost and exposure for material already taken.
solid answer
~50 sA commodity stealer is a subscription product: someone rents the build, spreads it as widely as they can through cracked software, game mods and fake installers, and is paid on volume. The whole value of a machine is realised in the first minute or two - the browser profile and other saved material are copied into one archive and uploaded - so there is nothing left for a second visit to fetch. Persistence would buy the operator no extra revenue while adding artefacts on disk, extra runtime and a longer window in which the run can be traced back to a particular build. Many builds delete themselves at the end for the same reason. The important consequence for classification is the opposite of the intuitive one: the absence of persistence is not evidence that the infection was minor or failed. It is evidence that the objective was a single-pass copy, and that copy has already left.
go deeper
Be ready to state the economics in one line: the operator is paid per install, so the whole take happens in a single pass and the host has no further value. Know that delivery is usually something the user chose to run.
Explain what the run actually does - copy per-user saved material into one archive, upload, often self-delete - and why persistence would add cost with no extra revenue for the operator.
Show that you grade severity by what the profile held, not by how long the code stayed. An interviewer wants to hear you reject the reading that a short non-persistent run is low impact.
Own the argument that this class is unaffected by patch discipline and endpoint hardening on machines you do not control, so the money belongs in limiting what a profile can hold that is still worth anything once copied.
## The product being sold A commodity infostealer is not a bespoke tool built for your company. It is a rented product. An operator writes and maintains the build and sells access to it on a subscription; the people who actually spread it are customers, and they are paid or profit on **volume**. Their unit of value is an install - one more machine emptied - not one particular machine. That single economic fact explains almost everything about how the malware behaves on a host. Delivery matches the economics. It arrives as something a person chooses to run: a cracked application or key generator, a game mod or cheat, a fake browser or codec update, a repackaged installer for a popular free tool. **No vulnerability is required**, which is why a fully patched fleet is not protected against this class - the user supplies the execution. ## What one pass looks like The run is short and shaped like an archiving job rather than an intrusion: - enumerate the browser profile directories for the logged-on user and copy what they hold; - pick up other saved material sitting in predictable per-user locations; - collect a small fingerprint of the machine - hostname, username, locale, approximate location, installed software, and crucially the **list of addresses the profile has saved or visited**; - pack all of it into one archive and upload it; - frequently, delete the executable and exit. What each individual store is worth, and how per-user encryption on those stores is defeated, is a separate subject in its own right; the point here is the **shape of the run** - one pass, one archive, done. ## Why persistence would be a cost Persistence exists to preserve *future* access. A stealer has no use for future access, because the thing it sells has already been taken. Weighed against zero extra revenue, staying resident costs the operator real things: - **Artefacts.** A run key, a service, a scheduled task or a startup entry is one more durable thing on the machine that ties the campaign to a build. - **Runtime.** Every extra minute of execution is time in which the process can be stopped mid-run - and a run stopped before upload is an install that does not pay. - **Reuse of the build.** A rented build is shared across many customers. The longer any single copy sits somewhere, the sooner the build stops working for everyone paying for it. Self-deletion after upload follows the same logic: once the archive is away, the binary has no remaining value to the operator and only carries risk. ## The wrong conclusion this invites The intuitive reading of a short, non-persistent, self-deleting infection is *nothing much happened*. A competent engineer will say something close to it: no persistence, no privilege escalation, no lateral movement, no second stage - a nuisance-grade event. That reading has the severity model backwards. For this class, **the damage is complete at the moment of upload**, which is typically minutes after execution, and everything a persistent intrusion would spend weeks doing is unnecessary because the objective was never the machine. The correct statement is: the presence of persistence would tell you the operator wanted *continued* access to that host. Its absence tells you the operator wanted a *copy*, got it, and left. The severity is set by what the profile held, not by how long the code stayed. ## What the copy becomes The archive is the operator's inventory item. Bundles are sorted and offered for sale, priced largely by what the fingerprint shows the machine could reach. That is why a mass, indiscriminate infection on an unmanaged personal laptop can become a specific company's problem later: the person who infected the machine and the person who eventually uses the contents are usually not the same person, and the second one arrives long after the first has moved on. ## How to answer it in a loop Say the economics first (paid per install, value realised in one pass), then the mechanics (archive and upload, frequently self-delete), then the corrective (absence of persistence is not low severity; it is a different objective). If you are asked whether patching helps, say plainly that delivery is user-executed and needs no vulnerability, so patch level is close to irrelevant against this class.
- Why do many of these builds delete themselves at the end of the run?Because the archive is already uploaded, so the binary has no further value to the operator, while every hour it remains on disk is another hour in which that particular build can be pulled apart and stop working for every customer renting it. Deleting costs the operator nothing and preserves the product.
- Our fleet is fully patched. Are we protected from this class?No. Commodity stealers are delivered as software the user chooses to run - cracked installers, game mods, fake updates - so no vulnerability is exploited and patch level is close to irrelevant. What reduces exposure is limiting what a browser profile is allowed to hold and what a copied artefact is still accepted for.
- How does this differ from malware that stays for weeks?It is selling a different thing. A loader or bot sells continued access to the host, so persistence is the product and the operator invests in surviving reboots. A stealer sells a one-time copy of what the user had saved, so the host has no residual value once the archive is uploaded.
It is a smash-and-grab rather than a burglary with a copied key. The crew is paid by the number of doors entered, so they empty the hall table and leave; coming back would cost them time they are not paid for.
saying these in an interview costs you the question
- No persistence, so the infection failed or did nothing
- It exited quickly, so nothing was taken
- A patched fleet is safe from this class
- Corporate material taken means a targeted attacker
- Removing the malware ends the incident