What capability does an operator give up by driving rundll32 or mshta instead of their own tool?
answer
- you rent behaviour, you do not write it
- documented entry points only
- arguments are the entire interface
- no lifetime of its own
- execution technique, not persistence
basics
~20 sOnly the binary's designed behaviour is available. There is no arbitrary system call, the argument surface is capped and awkward, error handling is nearly absent, the process ends when the utility's job ends, and nothing in the chain provides persistence.
solid answer
~50 sA dropped tool is code the operator wrote; a shipped utility is code somebody else wrote for a different purpose, and the operator gets only what its documented entry points expose. In practice that means no arbitrary system calls and no control over how the process starts or what it maps beyond the designed hand-off; an argument surface that is capped and fiddly to escape; almost no error handling, so a wrong export name returns silently and a failed fetch may throw a dialog at whoever is at the console; and no lifetime of its own, because these utilities exit as soon as their designed job completes. Persistence is not included either - re-triggering the chain is a separate act with its own cost. The trade is deliberate: real capability is paid for the estate's existing trust.
go deeper
Remember these binaries were written for a legitimate purpose, so an operator gets only the behaviour that purpose exposes - not a general-purpose tool.
Be able to name concrete losses: entry-point-only behaviour, capped arguments, silent or noisy failure, no process lifetime of its own, and no persistence.
Present the trade as economic - trust bought with capability - and explain why the technique concentrates in the earliest hops rather than running throughout an operation.
Own the implication for where effort is spent: the technique is a bridge under constraint, so narrowing the bridge changes what the first hour can accomplish even if later phases are unaffected.
## Framing the trade Living off the land is usually taught as a pure win, which is why the cost side is a good interview question: it separates people who have read about the technique from people who have thought about why operators stop using it. The trade is simple to state. **Borrowed trust is paid for with lost capability.** A program the operator wrote does whatever they coded. A shipped utility does what its author intended, and the operator's entire influence is a string of arguments. ## What is actually lost **Entry-point-only behaviour.** A custom tool can call any system interface, allocate and protect memory how it likes, and control what it loads. A utility exposes a fixed door: call this export, register this component, render this application. Anything outside the door is unavailable unless the operator can get their own interpreted code running through that door first - which is why the chain exists in the first place. **A capped and awkward argument surface.** Arguments are the only channel. Beyond the hard length ceilings, quoting, escaping and the utility's own parsing of its parameters all constrain what can be expressed. Complex behaviour must therefore be moved into fetched content, which means another hop and another dependency. **Error handling.** This is the loss people forget and it is operationally the largest. A custom tool can retry, back off, fall back to a second channel and fail quietly. A shipped utility handed a bad argument typically does one of two unhelpful things: it returns with no effect, leaving the operator unable to tell whether the hop ran, or it surfaces a message intended for a human administrator. On a shared administration host, the second is a failure that happens in front of the person whose session is being used. **Process lifetime.** These utilities exit when their designed job finishes. A library-export runner returns when the export returns. A document or application host closes when its content is done. An operator who needs code alive across minutes or hours cannot get that from the utility itself; they need a different execution strategy, and arranging one is a separate technique with its own cost. **Persistence.** An execution chain is not a persistence primitive, and conflating the two is a common error. Nothing about pointing a trusted binary at content causes it to be pointed there again after a reboot. Re-triggering requires arranging for something the estate already runs - an autostart entry, a scheduled job, a logon script - which is a separate action, with a separate footprint, that the trusted-binary trick does not make free. **Operational comforts.** No built-in transport encryption of the operator's choosing, no timing control, no modular loading, no clean way to carry state between hops. Anything wanted must be written into the interpreted content, which costs size, which costs hops. ## Why operators accept the trade anyway Because of *when* they accept it. The technique is most valuable at the point where the operator has the least: one identity, no install rights, nothing staged, no second host. Trust is exactly the currency they lack, and capability is the currency they can most afford to spend, because at that moment they do not need much capability - they need one successful hop. As the operation progresses the calculation flips. Once there is a way to run code with a lifetime, an error path and real interfaces, the capability cost stops being worth paying. This is why intrusions that begin entirely inside trusted binaries frequently do not stay there, and why treating the technique as a whole-operation description rather than a phase description misreads it. ## The framing that lands in an interview Say the trade out loud - trust bought with capability - then give two or three concrete losses rather than a list of ten. Lifetime and persistence are the strongest pair, because they are the ones that force the operator's next move, and because getting them right demonstrates that you distinguish an *execution* technique from a *persistence* technique. Then note where the technique concentrates: early, under constraint, when there is no alternative. That last point is what a senior answer adds and a recited one omits.
- Why do crews often confine this technique to the earliest hops?Because trust is most valuable exactly where they have the least of everything else: no install rights, one identity, nothing staged. At that moment they need one successful hop, not rich capability. Once they can run code with a lifetime and an error path, the capability cost stops being worth paying, and they stop paying it.
- If the chain gives no persistence, how does anything survive a reboot?Only by a separate act - arranging for something the estate already runs on a schedule or an event to re-trigger the chain. That is an additional action with its own footprint and its own risk. Borrowing a trusted binary is an execution technique; treating it as a persistence mechanism is one of the most common errors on this subject.
- What does the missing error path actually cost an operator?Reliability and quiet. A written tool can retry, fall back and stay silent. A shipped utility given a bad argument may return with no effect, leaving the operator unsure whether the hop executed at all, or may surface a message meant for a human administrator. On a shared administration host that failure happens in front of the engineer whose session is being worn.
It is renting a delivery van rather than building one. It moves the load today, but you cannot change the doors, the fuel tank, or how long you keep it.
saying these in an interview costs you the question
- Claims the technique is strictly better than a written tool
- Treats an execution chain as a persistence mechanism
- Assumes arbitrary system calls are reachable through the utility
- Ignores that the utility exits when its designed job ends
- Describes the technique as an entire operation rather than a phase