After removing local administrator rights from all users, which standing privileges still let an intruder move?

## Why the claim feels sufficient and is not "We removed local admin from our users" is the answer a competent senior engineer gives, because it is a genuinely good change that took real organisational effort. It is also an answer to a different question. It governs one thing: whether an ordinary user, on the machine he is logged on to, can raise himself to administrator. The privileges that let an intruder *move* are a different set, and they survive that change intact. Decompose the phrase before answering. Standing administrative rights are three preconditions: **1. Reach - a reusable secret many hosts accept.** The built-in local administrator account with one fleet-wide password is the classic case, but it is not the only one. A service-desk group nested into every machine's local Administrators group has identical reach with a different name. So does a management service account that is administrator on all servers. Each of these is a credential that, once obtained on one host, is accepted by hundreds. **2. Direction - a high-trust credential used on a low-trust host.** When a credential is used to create a session on a machine, that machine has to be able to act for the account, and whoever administers the machine is inside the boundary of that logon. A tier-0 or tier-1 credential typed into a laptop the intruder already controls therefore becomes his. The control is not a stronger password; it is a rule about which direction logons are allowed to flow. **3. Permanence - privilege held around the clock.** An account permanently in a privileged group is privileged at every moment, including the moment it is compromised. Time-bound, approval-gated elevation converts that into privilege that exists only during an approved window. ## Mapping the change to the preconditions | Change | Removes | |---|---| | End users are no longer local administrators | A user can elevate himself on his own machine | | Per-host unique rotated administrator secrets | Reach of the local administrator secret | | Tier separation on logons | Direction: high-trust credentials on low-trust hosts | | Time-bound approval-gated elevation | Permanence of privileged membership | Read down the right-hand column: the first row is not a prefix of the others. It sits on its own axis. ## The scenario that makes this concrete Code is already running with local administrator rights on one managed laptop, driven by a ransomware affiliate paid a share of the eventual proceeds - his constraint is tempo, so every next step is judged by whether it costs an hour or a fortnight. How did he get administrator on a laptop where users are not administrators? Usually one of three ways, none of them exotic: the machine's built-in administrator account, an application that was granted local administrator to make it work, or an exception granted to that user because he is a developer and never revisited. From there, ask what each remaining precondition is worth to him. Reach means hop two is a logon. Direction means he does not have to hop at all - he can wait for, or induce, a support session and let a privileged credential arrive at the machine he owns. Permanence means when he does obtain a privileged account, it is privileged immediately and indefinitely, with no approval step and nothing that expires. ## What good sounds like in an interview Refuse the single-sentence answer, and refuse the opposite mistake of listing every hardening measure you know. The expected move is: restate the claim, say which precondition it removes, and then name the ones it does not, with a reason for each. If asked which to fix first, the honest ordering is reach before permanence, because reach is the cheapest thing for the intruder to use and, for the estate, the least visible to the people doing daily support work. One more distinction worth having ready: removing user-level administrator rights is a **preventive** control aimed at what a user does; the three above are preventive controls aimed at what an intruder who *already holds* administrator on one host can do next. They belong to different points in the intrusion and it is not a contradiction to have done one and not the others - it is only a mistake to report the first as though it covered the rest.