What must be true for malware to spread host to host with no user action?
answer
- a conjunction, not one property
- nothing in the chain may wait on a person
- the code must complete the conversation unaided
- failures subtract from a shared pool
- operator hours versus propagation rate
basics
~20 sFour things at once: the next host exposes a service the spreading code can satisfy on its own, no step waits on a person, attempts succeed often enough to keep finding new hosts, and the code can name candidates to try.
solid answer
~50 sSelf-spread is a conjunction, not a property of one flaw. First, the next host must expose a service the code can satisfy unaided - unauthenticated, or with a credential the code already carries. Second, nothing in the chain may wait on a person: no file to open, no prompt to accept, no session for someone to log into. Third, each attempt must succeed often enough that the code recruits hosts faster than it burns them. Fourth, the code needs a way to name its next candidates - a sweep of the local subnet, entries in the device's own neighbour tables, or generated addresses. Miss any one and you are back to hands-on mass compromise, where an operator drives every host and cost scales with the number of machines instead of with wall-clock time. That is the split interviewers are testing: operator hours versus propagation rate.
go deeper
Be ready to list the preconditions in one breath and say that all of them must hold together. Interviewers accept a short answer here, but they will not accept 'it is a very severe vulnerability' as a definition of wormable.
Explain each precondition mechanically: what 'satisfy the service unaided' means for an unauthenticated flaw versus a carried credential, and what specifically counts as a human step. Show that removing one condition ends spread entirely.
Show you can apply the conjunction to a real estate rather than recite it - take a flaw you are handed, walk the four conditions, and reach a verdict that may contradict its severity rating in either direction.
Own the framing that self-spread and hands-on mass compromise are different cost models, not different skill levels, and be able to say what each predicts about breadth, selectivity and how fast the situation changes.
## What "wormable" actually claims Calling something wormable is a claim about **self-propagation**: once the code is running on one host, it reaches and executes on the next host with nobody driving it. It is not a claim about how damaging the code is, how clever the flaw is, or how a published scheme rates the severity. It is a claim that a specific set of preconditions all hold at the same time - and because it is a conjunction, removing any single one of them ends self-spread completely. ## The four preconditions **1. A reachable service the code can satisfy alone.** The next host has to be listening for something, and the spreading code has to be able to complete that conversation by itself. Two very different situations satisfy this. In one, the listening service has a flaw that grants execution before any authentication happens - the code sends bytes and gets to run. In the other, the service is working exactly as designed and the code simply authenticates, because it carries a credential that the next host accepts: a local administrator password that is identical on every device an installer touched, a default account left on a batch of cameras, a private key copied onto a shop-floor terminal. The second case involves no exploit at all and is every bit as wormable as the first. **2. No step that waits on a person.** This is the precondition that most often fails. If the chain contains "the user opens the attachment", "someone accepts the prompt", or "an administrator logs in and the code steals what appears", the code moves at the speed of human behaviour and only where humans go. Rating the underlying flaw as critical changes nothing about this. Conversely, a component that performs the human's step automatically - something that renders, indexes or previews content without being asked - can remove the human from a chain that used to need one. **3. Enough per-attempt reliability.** A hands-on operator can afford a technique that works four times in five: they retry, they move on, they pick another route. Self-spreading code has nobody to retry for it, and on many services a failed attempt does not just fail, it kills the listener - so the failure permanently subtracts a host from the pool that every infected node is drawing from. Reliability is therefore a first-class precondition of spread, not polish on top of a working technique. **4. A way to name the next host.** Code cannot attack an address it never generates. In practice this comes from what the infected device already knows - its own interface prefix and netmask, the neighbours it has recently talked to - or from generating addresses. How well generation works depends entirely on how densely the address range is populated. ## Self-spread versus hands-on mass compromise The alternative to self-spread is a crew that compromises many hosts by hand or by driving their own tooling from a foothold: authenticate, run, move, repeat. The two look similar in outcome and are completely different in economics. | | Self-spread | Hands-on mass compromise | |---|---|---| | Cost driver | one-off engineering | operator hours per host | | Time to breadth | minutes to hours, unattended | scales with headcount | | Choice of victims | whatever the addressing reaches | chosen, one at a time | | Stopping it | the operator usually cannot | the operator simply stops | That last row is why capable crews often deliberately do **not** build self-spread. A worm goes where the addressing takes it, including into estates the operator never meant to touch, and it spends the same technique against everything reachable at once. An operator working host by host keeps the choice of scope, timing and target worth, and can abandon a route that is not working. Cheap, unskilled use of a public exploit against everything that answers is the opposite trade: no selectivity, no control, but no wage bill either. ## How the question is usually pushed Expect the interviewer to hand you a flaw and ask whether it is wormable. The disciplined answer walks the conjunction rather than reaching for the severity rating: can the code complete the service conversation unaided, does anything wait on a person, does the attempt work nearly every time, and can the code enumerate somewhere to go next. Answer those four and the verdict falls out - and you will correctly call an unexploited, credential-reusing spreader wormable while refusing that label to a critical-rated flaw that needs someone to double-click.
- Does self-spread require a memory-corruption exploit?No. A spreader that authenticates to a service with a valid credential it already carries - a reused local administrator password, a default vendor account, a copied private key - satisfies every precondition and uses no exploit at all. The service behaves exactly as designed. This is why patch state alone never settles the wormability question.
- Why would a capable crew choose hands-on mass compromise over building a worm?Control. Self-spread goes wherever the addressing reaches, cannot be recalled, and spends the same technique against every reachable host at once. Working host by host keeps the choice of which estates to touch, when, and in what order, and lets the operator abandon a route that is not working. The cost is operator hours, which a funded crew can pay.
- What kind of component can remove the human step from a chain that needs one?Anything that processes content without being asked: a service that renders or indexes files as they arrive, a client that fetches and parses a resource automatically, an agent that unpacks whatever is placed in a watched directory. The flaw is unchanged; the precondition set is not, and the same defect flips from not-wormable to wormable.
Self-spread is a chain letter that addresses and posts itself; hands-on mass compromise is a courier who has to knock on every door in turn.
saying these in an interview costs you the question
- Calls anything with a critical severity rating wormable
- Assumes self-spread always requires an unauthenticated code-execution flaw
- Confuses an operator scripting logins across hosts with self-spread
- Ignores reliability, treating any working technique as sufficient
- Forgets the code must be able to generate its next target