Lesson 3.4 · Memory and operating systems· 2 min read
User mode, kernel components, and rootkit claims
Distinguish execution privilege, component type, and concealment behavior when examining kernel-related malware claims.
- Platform:
- Cross-platform
- Language:
- Concepts
- Difficulty:
- Intermediate
What you will learn
Distinguish execution privilege, component type, and concealment behavior when examining kernel-related malware claims.
Before you begin: Processes and memory; APIs and platform backends.
Execution level and behavior are separate properties
Kernel-related terminology can make a source study sound more conclusive than its evidence supports. Separate where a component executes, how it interacts with the system, and what behavior it implements. A component name such as driver does not answer all three questions.
Microsoft explains the distinction between user mode and kernel mode. Its driver overview also distinguishes user-mode and kernel-mode drivers. The word “driver” alone therefore does not establish kernel execution.
A component relationship map
User-mode component
prepares a request
receives a result
Boundary
validates the request in a particular context
Kernel component, if present and reached
performs the supported operation
reports its result
This diagram is a reasoning aid, not a driver interface or an implementation recipe. In an actual study, identify the component that owns each operation and the evidence that a request reaches it. Merely finding request-building code does not establish a loaded or reachable kernel component.
Why a rootkit is not just a privileged component
MITRE's Rootkit entry concerns mechanisms used to conceal software or activity by affecting what the system reveals. Treat a rootkit claim as a behavioral claim requiring evidence. Kernel execution and concealment are related possibilities, not synonyms. A privileged component can perform ordinary work, and a misleading view can have causes other than a rootkit.
For a source study, ask which observation is affected, which component supplies that observation, and whether an independent view confirms a discrepancy. Avoid concluding that a missing item was hidden if the collection mechanism simply failed, filtered it legitimately, or observed a different moment.
Lifecycle still matters
A compiled component, an installed component, a loaded component, and an invoked component are different states. Errors at one boundary can prevent later behavior. The earlier lifecycle lesson applies here: record the request and outcome separately, including partial initialization and failure paths.
Operating-system and architecture assumptions belong in the explanation. A source file written for one environment does not prove compatibility with another. Build settings and the inspected artifact determine which implementation is relevant.
Exercise
A repository contains a file named kernel_driver.c, while the only observed process prints that a request failed. Can you conclude that a rootkit is active? Name two missing relationships.
Check your understanding
No. You need evidence connecting the source to a relevant loaded component and evidence of the claimed concealment behavior. A filename and a failed user-mode request establish neither. Preserve the difference between intended capability and confirmed activity.