Does installing a rootkit give an adversary the privilege level it hides at?
answer
- read the name literally
- keeping root, not getting root
- every level has a precondition
- concealment is bought with privilege
- loading a driver already needs admin
basics
~20 sNo. A rootkit conceals activity at a level the adversary already controls. Loading a kernel driver or writing firmware needs administrative privilege first, so concealment is something an intrusion buys after it has won, never a route to winning.
solid answer
~40 sNo, and getting this backwards reorders the whole investigation. Every concealment level has a privilege precondition that must already be satisfied: hooking functions inside another process needs write access to that process, loading a kernel driver needs administrator rights plus a signature the operating system's code-integrity policy accepts, planting a boot component needs write access to the EFI System Partition, and touching firmware needs the flash to be writable. The rootkit does not grant any of that. So when a kernel implant turns up, the question is not `how did the rootkit get admin` but `what gave them admin, hours or weeks earlier`. Concealment is a purchase an operator makes with privilege they already hold, in exchange for staying resident.
go deeper
Be ready to say plainly that the name means keeping access, not getting it, and to name one precondition - loading a kernel driver needs administrator rights.
Explain the precondition for each level: writing into another process, registering a kernel-mode service with an accepted signature, writing the EFI System Partition, writing platform flash.
Show that the implant reframes the question rather than answering it: the entry route is still unknown, still open, and the implant is evidence of what the operator chose to spend privilege on.
Own the consequence for policy: if concealment is bought with privilege, the controls that matter most are the ones that make administrative rights hard to get and short-lived, not the ones aimed at the implant.
## What the word actually claims A rootkit is not a category of malicious capability like a keylogger or a downloader. It is a claim about **where** code sits and **who it can lie to**: an implant that changes what the layers above it are told, so that ordinary questions asked at those layers come back with doctored answers. The historical name is literal - a kit for keeping *root* once you have it. That etymology is the whole point, and it is the fact this question turns on. ## Every level has a privilege precondition Work up the stack and each rung costs more, and each cost is paid **before** the implant exists: - **User-mode hooking.** An operator rewrites the first bytes of an API function, or an import table entry, inside a target process so calls detour through their code. The precondition is the ability to write into that process - the same user account, or a privilege that allows opening another user's process. Cheap, and it only affects the one process. - **Kernel driver.** Code inside the operating system kernel, with no boundary between it and the rest of the machine. The precondition on Windows is administrative rights (registering and starting a kernel-mode service) *plus* a signature that the code-integrity policy will accept. On Linux it is the ability to load a module, which is root, and possibly a signature if module signing is enforced. - **Boot chain.** A component that runs before the kernel - a doctored boot manager or loader in the EFI System Partition - so the kernel it starts is already under the operator's control. The precondition is write access to that partition, which is administrative, and either Secure Boot switched off or a signed component the firmware will still accept. - **Firmware.** An implant in the platform's SPI flash, or in a peripheral's option ROM, running before the boot chain exists. The precondition is that the flash is writable: the platform's write-protection settings not applied, an abusable signed-update path, or physical access. None of these preconditions is *produced* by the implant. Each is *consumed* by it. ## Why crews pay for it anyway If concealment does not win privilege, why spend on it? Because privilege is perishable. A stolen password gets rotated, a session dies, a host gets patched, a laptop gets rebuilt. What a lower-level implant buys is **residence**: the ability to still be there after the thing that let you in has been closed, and to make the machine's own answers unreliable while you are. The cost is real - kernel code that is wrong does not throw an exception, it stops the machine, and a crashing fleet is the loudest thing an operator can do. That price is why plenty of intrusions never install one: if the operator can simply keep using valid administrator credentials, concealment is an expense with no return. ## The ordering error and what it costs The wrong answer - *the rootkit is how they got in* - has practical consequences. It makes people hunt for an exploit against the kernel when the actual entry was a valid credential and a scheduled task. It makes them treat the implant as the incident rather than as the last thing that happened. And it makes them assume that removing the implant undoes the intrusion, when the access route that made the implant possible is untouched. Read it the other way and the implant is evidence about the adversary, not about the machine. A kernel-level implant tells you the operator had administrative rights on that host and chose to spend them on staying. A firmware implant tells you they had administrative rights **and** the platform's flash was not write-protected **and** they judged the target worth an implant that survives the disk. That is a statement about their objective and their budget. ## The one nuance worth carrying There is a partial exception that is not really an exception: a *vulnerable* driver, legitimately signed by some vendor, can be loaded by an administrator and then abused to execute code in the kernel. That looks like privilege being gained rather than spent - but the administrator rights needed to install a driver in the first place were already held. The crossing it buys is from administrator to kernel, not from nobody to administrator.
- If concealment does not win privilege, why does an operator pay for a kernel implant at all?For residence. The access route that got them in is perishable - credentials rotate, sessions die, hosts get rebuilt. Kernel-level code survives those and can make the machine's own answers unreliable while it runs. The price is stability: kernel code that is wrong does not throw an exception, it stops the machine, which is the loudest thing an operator can do.
- A kernel-mode implant is found on a host. What does its presence let you conclude about the adversary?That they held administrative rights on that host before the implant existed, and chose to spend them on staying rather than on moving. It says nothing about how those rights were obtained, so the entry route is still unknown and still open. It also implies a signature the machine's code-integrity policy accepted, which is itself a scarce asset.
- Where does the vulnerable-driver case sit relative to this ordering rule?It is a crossing from administrator to kernel, not from nothing to administrator. Installing any kernel driver, including someone else's legitimately signed one, already requires administrative rights. So it still fits the rule: privilege is spent to reach a lower level, not conjured by reaching it.
A false wall in a building hides a room from anyone walking the corridor - but you had to already be inside, with the keys and the tools, to build it. It is what an intruder spends access on, not how they got past the door.
saying these in an interview costs you the question
- Calls a rootkit an entry technique or an exploit
- Says the rootkit escalated them to SYSTEM
- Treats finding the implant as having found the intrusion
- Assumes kernel implants are free and therefore always present
- Thinks a rootkit works without any prior privilege