Why can an operator with a domain admin credential run code on another host over the ADMIN$ share or WMI with no exploit?
answer
- no exploit needed
- sanctioned remote-admin features
- credential plus admin on target
- patching does not close it
basics
~20 sThe administrative share and WMI are built-in remote-administration channels. They authenticate with the credential and run if the account has admin rights on the target, so no vulnerability is needed — the credential itself is the key.
solid answer
~40 sChannels like the ADMIN$ share, remote service creation, WMI and a WS-Man shell exist so operations teams can manage hosts remotely. They are sanctioned features, not bugs. Each one authenticates the presented credential and executes if that account holds administrative rights on the destination. So an intruder who already holds a working admin credential does not need to exploit anything — the same feature the desktop team uses to push a fix lets the intruder run code. The precondition is administrative authority on the target plus reachability, and nothing else. This is why a fully patched estate is not, on its own, safe from movement on a valid credential.
go deeper
Be ready to say that built-in remote-admin channels run on a credential plus admin rights on the target, with no exploit needed.
Explain that these are sanctioned features, so the precondition is administrative authority on the destination, not a vulnerability.
Show why patching does not close this path and why the real limit is who holds admin where, and from which source hosts.
Frame the tension: operations needs remote-admin channels to function, so the control is scoping and origin rather than removal, and it lives with the defence-in-depth decision, not with patching.
## The channels are features, not flaws Windows and Active Directory estates ship with several ways to run code on a remote host so a central team can administer many machines: the built-in **administrative shares** (for example `ADMIN$`, mapping to the Windows directory), **remote service creation**, **WMI**, a **WS-Man remote shell**, and **RDP**. Every one of these is a designed, supported capability. None is a vulnerability. ## What each channel actually checks When an operator uses one of these channels against a target, two things must be true: - **A credential is presented and accepted.** The channel authenticates the account. - **That account has administrative authority on the destination host.** Without admin rights on the target, the admin share, service-create and WMI all refuse. When both hold, the code runs. No memory-corruption bug, no malformed packet, no unpatched service is involved. This is the most important idea on this leaf: **credentialled movement is authorised, not exploited.** ## Why this trips people up The common wrong answer is that lateral movement requires an exploit or malware. It does not. An intruder who has obtained a valid admin credential — by any means — can move exactly the way the IT team moves. That is what makes it hard to distinguish from legitimate administration and why it is the backbone of real intrusions. ## The consequence for defence Because these channels are features, **patching does not close them.** You cannot patch away a sanctioned capability. What limits the path is *who holds administrative rights on which hosts, and from where they may use them* — a scoping and origin problem, not a vulnerability-management one. The technical answer to 'we are fully patched, are we safe from this?' is: not from this. Patching removes exploits; it does not remove an operator's granted access. ## Precondition, restated Strip everything else away and the shared precondition of the admin share, service-create and WMI is the same: an accepted credential that carries administrative authority on the destination. That is the thing all of these channels turn on, and it is why the credential — not the exploit — is the asset an intruder is really after.
- Does removing vulnerabilities from a host stop this kind of movement?No. These channels are sanctioned features, not bugs, so they run whenever the credential carries admin rights on the target. Patching removes exploits, not granted access. What limits the path is who may hold admin rights on which hosts and from where they connect.
- What single precondition do the admin share, service-create and WMI all share?Administrative authority on the destination host, presented by an accepted credential. Without admin rights on the target, all three refuse; with it, none of them needs an exploit. The credential is the key, which is why it is the thing an intruder works to obtain.
saying these in an interview costs you the question
- Thinks lateral movement always requires an exploit or malware
- Assumes a fully patched estate is safe from credentialled movement
- Believes the ADMIN$ share is anonymously accessible