A change board asks: can we just block mshta, rundll32 and regsvr32 on the admin jump host?

## Why the question is asked this way The board has heard that intrusions run through trusted operating-system binaries and has drawn the obvious conclusion: remove the binaries. It is a reasonable instinct and it is partly right, which is what makes a flat yes or a flat no both wrong. The useful answer separates the list into parts, states what each part costs, and names the class of control the board should actually be commissioning. ## Part one: the binaries are not equivalent **Some are genuinely removable.** An HTML application host is a good example: it exists to run a legacy application format, and in many modern estates nothing supported depends on it. Removing or blocking it is a small, reversible-if-wrong change with a real reduction in reachable execution paths. That is a win worth taking, and taking it makes the rest of the conversation credible. **Some are load-bearing.** A library-export runner is how the platform itself reaches configuration entry points; a component registration utility is how software is registered during install, repair and update. These are not conveniences engineers happen to like - they are on the path of supported operations that the estate performs every week. Blocking them does not inconvenience administration, it breaks it. A candidate who says *block all three* has not distinguished these two cases, and that distinction is the entire answer. ## Part two: the environment makes breakage worse, not better A managed-service provider's administration jump host has two properties that change the calculation: - **Concentration.** One host reaches many client tenants through delegated rights. A break is not one team's bad afternoon; it is a multi-tenant failure of the provider's ability to administer at all, during whatever incident happens to be running. - **A locked software inventory.** Nobody may add software, including the engineers. The lock is a good control, but it means the engineers have no alternative tooling. Their workflows depend on the built-ins *because* they cannot install anything else. Remove the built-ins and there is no workaround - just a stopped change and an emergency reversal. This is why blanket blocks on hosts like this have a short life. They are reverted at the first broken installer, and the reversal costs the security team credibility for the next proposal. ## Part three: the block does not remove the class Even a perfectly executed block of three images narrows one path rather than closing a class. The property being exploited is *trust the estate extends to binaries it already ships*, and the estate ships many binaries that will accept a path, an identifier or a URL. The operator holds a delegated administrator's session; they are not constrained to the three names on the board's slide. So the honest sentence for the board is: this is a per-item control against a class-shaped exposure. Per-item controls are not worthless - each one removes a cheap path and raises the cost of the first hop - but they must be presented as attrition, not as a fix, or the board will believe the problem is solved. ## Part four: what to commission instead The durable control acts on **what a permitted interpreter is handed, and by whom**, rather than on which images exist: - Constrain the *input*: what content a permitted interpreter may accept, and from where. The operator's chain depends on handing a trusted binary content it fetches from somewhere the estate does not control. - Constrain the *invoker*: which identities may drive administration binaries, from which host, inside which change window. On a jump host where every legitimate action is a planned change under a delegated identity, this is a far tighter fit than on a general-purpose desktop. - Constrain the *reach*: if the first hop cannot retrieve remote content, the chain loses its retrieval step and has to stage some other way. How such rules are expressed, and what a path, publisher or hash rule can and cannot say about a permitted interpreter, is its own subject with its own hard limits - but the board does not need that detail to make its decision. It needs to know the shape of the thing being asked for. ## The answer to give Remove what is genuinely unused, starting with the application host, as a change with a stated rollback. Do not block the load-bearing binaries outright on this host; propose the constraint on what they may be handed and who may invoke them, with a named owner. And say plainly that neither action removes the class, because the estate's trust in its own shipped software is the thing being borrowed, and that trust is not something you can delete three files to withdraw.