Detecting T1014 Rootkit

How T1014 Rootkit hides attacker activity from defenders

When a host behaves oddly but shows nothing unusual in process lists, service views or file browsers, the problem may be a component designed to stay out of sight. Under the Stealth tactic (TA0005), T1014 Rootkit describes an adversary hiding its presence and activity by modifying how the operating system reports processes, files, network connections or loaded code, so that standard listings omit the attacker's artifacts. The technique is one of the ways an intrusion keeps its footholds and avoids the defender's first look. This page targets MITRE ATT&CK Enterprise version 20.0, and the detection guidance below names that version so mappings can be checked against it later.

The concealment works differently by platform. On Linux, hidden components commonly sit in kernel modules or in user-space hooks that alter what system calls return to tools such as ps or directory listings. On macOS, the equivalent concern is kernel extensions, system extensions and altered launch items. On Windows, the focus is on drivers, injected code and tampered query results. In each case the attacker's goal is the same: the defender's view of the system is filtered before it reaches the analyst. This means that a clean-looking process table is not proof of a clean host, and the team should confirm which telemetry sources sit below the level where a rootkit could interfere, such as boot logs, kernel module load records, or events collected by a separate agent.

Before building detections, the reader should decide three things: which platforms in the estate are in scope for T1014, which telemetry can be trusted when in-host views may be compromised, and who owns the response when a hidden component is suspected. Confirm with your vendor and your own environment whether your endpoint agents record module loads and driver loads, and whether those records are forwarded off the host. Plan for the case where the host itself cannot be trusted to report on its own state, and treat memory or offline disk evidence as the next step rather than a conclusion.

Telemetry that reveals T1014 Rootkit on each platform

This table maps each telemetry source to the signal that suggests a rootkit is hiding activity, the platform where it applies, and an open-source collector that can gather it. Read it as a starting point for detection engineering, then confirm the current T1014 detection strategies and data component mappings in the enterprise-attack 20.0 STIX bundle before you build rules. A rootkit usually shows up as a gap between what the kernel or operating system reports and what an independent view of the host shows, so the strongest coverage comes from comparing sources.

Telemetry	Signal to look for	Open-source collector
Module Load (DC0016), Linux	Kernel modules loaded outside the approved baseline, or modules without a matching package or signature	Wazuh file and system inventory, Velociraptor artifacts
Module Load (DC0016), Windows	Unsigned or unexpected drivers loaded, or driver load events that do not match the expected driver inventory	Sysmon-equivalent agent with driver load events, Wazuh, Velociraptor
Module Load (DC0016), macOS	Kernel extensions or system extensions that are new, unsigned or outside the approved list	Velociraptor artifacts, Wazuh log collection
Process Creation (DC0032), all platforms	Processes visible to a live memory or kernel-level listing but absent from the normal process listing, or the reverse	Wazuh, Velociraptor, Sysmon-equivalent agent
File Creation (DC0039), all platforms	New files in system directories, boot paths or driver folders that appear without a matching change ticket or package event	Wazuh file integrity monitoring, Velociraptor
Process Access (DC0035), Windows	Access to kernel-level or protected process handles by unexpected tools, which can indicate tampering with security software	Sysmon-equivalent agent, Velociraptor
Command Execution (DC0064), all platforms	Shell or administrative commands that load modules, change boot configuration or alter kernel parameters	Wazuh command monitoring, Velociraptor, Security Onion host logs

Why kernel-level hiding breaks host-only views

A rootkit that hides at the kernel level can make user-space tools report a clean host, so a detection that relies only on what the operating system's own commands and APIs return can be fooled by the same layer it is trying to inspect. For T1014 Rootkit, the defensive answer is to compare several independent views of the same host and treat any disagreement between them as a finding. Each view should be collected through a different path, so that a single compromised reporting layer cannot quietly align all of them.

The three views most teams can build are the loaded module list, the process list and the file records. Module load telemetry from an endpoint agent shows what the kernel reported as loaded at the time of collection, which is useful for spotting unsigned or unexpected modules, but it is still the host's own report. Process and file records collected by an agent have the same limitation. Offline evidence, such as a memory image or a disk image taken from a host that is powered down or isolated, gives a second path that does not depend on the running kernel's answers. Its limit is timing: it shows the host at one moment, and acquiring it may alter the state you want to examine. Confirm with your forensic team how acquisition is sequenced and which images your agent or hypervisor can produce.

Plan the comparison before an incident. Decide which agent telemetry you will retain for module loads, process creation and file creation, how long offline images are kept, and who is authorized to compare the two. Document the expected differences, such as short-lived processes that exit before a snapshot, so analysts can separate noise from a hidden object. Confirm with your platform and security vendors which of these views they actually expose, and where an agent's data comes from, rather than assuming parity across Linux, macOS and Windows.

Detection ideas for T1014 Rootkit that SOC teams can build

T1014 Rootkit hides adversary activity by altering what the operating system reports. The ideas below pair a telemetry source with a comparison or baseline, so that a deviation from normal stands out even when the adversary has tampered with one view. Each one needs tuning against your own fleet before it pages anyone.

Unexpected module loads into privileged processes

Alert when a module or library loads into a privileged or security-sensitive process that has no history of loading it. The logic compares Module Load events against a per-host baseline of approved drivers, kernel modules and DLLs for each process name and signing identity. Tune the threshold on first-seen module, filtered by unsigned or unexpected publisher, and review hits in a short window after each host build. Likely false positives include endpoint security agents, EDR sensor updates, hypervisor tools and vendor drivers loaded at boot. Maintain an allowlist keyed on signer and hash, not file name alone.

File creation in boot and system module paths

Flag new or modified files in boot loader directories, kernel module directories, and driver store locations, especially when the creating process is not a package manager or known installer. The logic joins File Creation events on those paths with the parent process and the update window. Start with a zero-tolerance rule for unsigned binaries written to boot paths outside maintenance periods, then add a rate threshold for bursts across many hosts. Expected false positives come from kernel updates, initramfs regeneration, Windows cumulative updates and driver installs. Check the installer lineage before escalating.

Process listing mismatches across collectors

Compare the process list returned by a kernel-level collector with the list returned by user-space tooling on the same host at the same moment. A process visible to one source and missing from another is a candidate for hidden activity. Set a small tolerance for short-lived processes and require the mismatch to persist across two or more collection cycles before alerting. Expected false positives include processes that exit between snapshots, sampling skew, containers with separate namespaces, and collectors that run with different privileges. Document which collector is authoritative for each platform in your runbook.

New kernel or driver artifacts outside change windows

Alert on new kernel modules, drivers or service registrations that appear outside approved change windows and are not tied to a change ticket. The logic correlates driver or kernel module load events, service creation records and configuration management data with the change calendar. Tune by setting a window tolerance and requiring the artifact to be unsigned, newly seen, or loaded by an unexpected parent. Common false positives include security tooling deployments, hardware enablement, virtualization guest tools and scheduled patching that runs outside the nominal window. Confirm with your change management system which events are expected before enabling paging.

How to validate that the T1014 Rootkit detection fires

This sequence proves that the T1014 Rootkit detections fire on the telemetry you actually collect, with a known and recorded latency, before you rely on them in production. It produces a validation record that links each detection to the ATT&CK version it targets.

Agree the emulation plan and approvals
The detection owner, the SOC lead and the range owner agree in writing which T1014 behaviors will be emulated, on which Linux, macOS and Windows hosts, and during which window. The plan names the systems in scope, the people who may stop the exercise, and the rollback steps for the range. Sign-off is complete when the plan is approved and stored with the range records, and the lab hosts are confirmed as isolated from production networks.
Prepare a benign, labelled test artifact
Use a harmless, clearly labelled test artifact that produces the same telemetry shape a rootkit-style change would produce, such as a non-malicious kernel module or a marked file change that the team created for the exercise. Do not use live malware or real credentials. The artifact is documented with its name, hash, purpose and owner, so that analysts can distinguish it from genuine activity. The step closes when the artifact is registered in the range inventory and the analysts who will triage it are told only that an exercise is running.
Confirm telemetry reaches the SIEM
Before any emulation, check that the data components that underpin the T1014 detections, including Module Load, Process Creation and File Creation, arrive from each lab host into the SIEM with the expected fields and timestamps. Confirm the agent versions and log sources on Linux, macOS and Windows, and note any gaps in a coverage table. The step is complete when every source shows recent events in the SIEM and the gaps are either fixed or accepted in writing by the detection owner.
Run the emulation and capture timestamps
The range operator runs the agreed test artifact on each in-scope host according to the plan, and records the start and end time of every action in the exercise log. The operator does not improvise beyond the plan. The step closes when the exercise log, the host-side timestamps and the SIEM event times are all saved to the range record, so that later latency figures can be traced to source events.
Record which detections fire and latency
The detection owner compares the exercise log with the alerts raised in the SIEM and the EDR or Wazuh console, noting for each detection whether it fired, whether it fired on the right host and the time between the action and the alert. Detections that did not fire are logged with the likely reason, such as missing telemetry, a threshold that was too high or a rule that was disabled. The step is complete when a result row exists for every planned behavior.
Log tuning changes against the ATT&CK version
Any change to a rule, threshold or exclusion made in response to the results is recorded in a change log with the reason, the author, the date and the ATT&CK version the rule targets. ATT&CK v18 replaced detections with detection strategies and analytics, so a mapping recorded without a version can become unreliable after a later release. The step closes when the change log is reviewed by a second person and linked from the validation record.
Clean up and retain the validation record
The test artifact is removed from every lab host, the host state is checked against the pre-exercise baseline, and the range is returned to its standard configuration. The validation record, containing the plan, approvals, telemetry check, results and change log, is stored where auditors and the next detection review can find it. The step is complete when the cleanup check is signed off and the record is filed with the ATT&CK version it covers.

Preventive controls that reduce T1014 Rootkit exposure

These six ATT&CK mitigations reduce the chance that a rootkit loads or survives on a host, and they limit how far an attacker can go once privileged access is gained. Each one is preventive, so pair it with the detections for Process Creation, Module Load and File Creation. Confirm which mitigation IDs map to T1014 in the v20.0 bundle before you rely on them.

Audit (M1047)

Audit is the mitigation that makes T1014 visible at all. Turn on logging for kernel module loads, driver installation, boot configuration changes and writes to system directories, then forward those events to the SIEM. Check that the Linux, macOS and Windows audit sources are enabled on every host class, not only on servers. Confirm the retention window with your compliance owner, because a rootkit often hides its own load event and you need the earlier baseline to compare against.

Behavior Prevention on Endpoint (M1040)

Behavior prevention blocks suspicious kernel-level actions before they complete. On endpoints, this means rules that stop unexpected driver installation, direct kernel memory writes and tampering with security agents. Test each rule on a cyber range host first, because aggressive rules can break legitimate drivers such as backup or virtualization tools. Ask your EDR or endpoint vendor which behaviors their product blocks by default and which require configuration, and record the answer in your control matrix.

Execution Prevention (M1038)

Execution prevention stops unsigned or untrusted code from loading at the privilege level where rootkits operate. Enforce driver signing on Windows and module signing on Linux, and use application control on macOS where it fits your fleet. Keep an approved list of kernel modules and drivers for each image, and review exceptions on a fixed schedule. Confirm the enforcement mode on each host build, since audit-only modes will log a rootkit load without stopping it.

Restrict file and directory permissions (M1022)

Limit who can write to the locations where rootkit components are usually placed, such as /lib/modules, /boot and the Windows driver store. Set these paths to be writable only by the build pipeline and the administrators who maintain them. Pair the permission model with File Creation monitoring in the same paths, so an attempted write from an unexpected process is both blocked and logged. Verify permissions after each patch cycle, because package updates can reset them.

User account management (M1018)

Control which accounts can load modules, install drivers or change boot settings. Remove dormant accounts, separate build, operations and security roles, and review membership of the groups that grant kernel-level rights. A rootkit needs an account that can act at that level, so fewer such accounts mean fewer ways to reach it. Review the list quarterly and after every staff change, and keep the review record as evidence for your assessor.

Privileged account management (M1026)

Installing a rootkit almost always requires root, administrator or SYSTEM rights, so the way those rights are granted matters most. Use just-in-time elevation where your platform supports it, store break-glass credentials in a vault, and record sessions that run with elevated rights. Alert when a privileged session loads a kernel module or changes boot configuration outside a change window. Ask your identity and PAM vendor to confirm which of these features are included in the product you deploy.

What to do in the first hour after a T1014 Rootkit alert

The first hour after a T1014 Rootkit alert is about proving the alert is real before anyone changes the host. Rootkits hide their own processes, modules and files from the operating system's normal views, so the triage analyst should confirm the signal against a second, independent view: for example, a Module Load event from the Wazuh or Sysmon agent compared with a kernel module listing or a memory-derived process list collected by Velociraptor, or a File Creation event checked against a file hash taken from a mounted disk image. If the independent view disagrees with the host's own tools, treat the alert as a probable compromise and escalate. Record the time, the analyst, the telemetry source and the result of each check in the incident ticket, because those notes are what the incident commander and any later auditor will rely on.

Before anyone reboots, isolates or reimages the host, preserve evidence in order of volatility. Volatile memory and live network connections are lost on power-off, so capture them first, then disk and logs. Isolation should cut the host from the network through the endpoint or network controls already in place rather than by shutting it down, so that running state remains available for analysis. Assess scope across the fleet by searching the same Process Creation, Module Load and File Creation telemetry for the indicators confirmed on the first host, and note every host where the search returns a result. The roles involved are the on-call SOC analyst, the forensic lead, the system owner, the platform engineering lead and, where personal or regulated data may be affected, the data protection or compliance lead.

The decision that needs documented sign-off is whether to remediate in place or rebuild from a known-good image. Remediation in place is rarely appropriate for a kernel-level rootkit, because the tools that would confirm a clean state run on the same compromised kernel, so the default should be a rebuild unless the forensic lead records a specific reason otherwise. The CISO or delegated risk owner should approve the isolation, the rebuild and any service interruption, and the sign-off should name the evidence retained, the hosts in scope and the criteria used to close the incident. Confirm with your own forensic and legal advisers how long evidence must be held and which regulator notifications apply, because those timelines depend on your sector and jurisdiction and are not set by this page.

How to rehearse T1014 Rootkit detection in a private cyber range

A Linux range should include at least one host running a current kernel build the team actually operates, with a separate monitoring host that receives forwarded logs and endpoint telemetry. Keep the topology small so the facilitator can trace every event from the endpoint agent to the case queue. Kernel module load events and file creation events in system directories are the core signals for this tab, so confirm that the agent records module loads with the module name, signer and load time.

Topology: one victim host, one collector or SIEM node (for example, a Wazuh manager with its indexer), and one analyst workstation with Security Onion or a similar console.
Telemetry to confirm: kernel module load records, process creation with parent lineage, and file creation in boot and module paths. Verify that the Wazuh agent or auditd rules forward these fields with timestamps.
Injects to plan: an illustrative benign kernel module loaded by the facilitator, followed by a file placed in a system path with no matching package record.
Good detection: an alert fires within the agreed window, names the module or file, and links it to the host and the user session that loaded it.
Good response: the analyst isolates the host, preserves memory and disk evidence, compares loaded modules with a known-good baseline, and records the decision in the case.

Check that the range record names the kernel version under test, because module signing behavior and telemetry fields change between builds.

Questions SOC leads and detection engineers ask about T1014 Rootkit

How do I tell a rootkit from a legitimate security driver or endpoint agent?

Start from the signed, documented behavior of the component, not from its footprint. A legitimate security driver or endpoint agent comes from a known publisher, loads through the vendor's expected install path, appears in your asset inventory and change records, and its hooks or kernel modules match the vendor's published component list. Treat anything that hides from your own inventory, fails signature or hash checks, loads from an unusual location, or changes after a reboot as suspicious until it is explained. Build an allowlist of approved drivers and modules per platform and review it after each agent upgrade. Confirm the expected module and driver list with each vendor, because it differs by product and version.

How often should I compare kernel and process views for rootkit indicators?

Compare views on a schedule that matches your risk and your telemetry budget, and add event-driven comparisons after high-risk changes such as kernel updates, driver installs or privileged logons. A scheduled comparison catches drift that event rules miss, while event-driven checks shorten the window after a suspected compromise. Scheduling is an operational decision, so set the interval in your own change and incident procedures and test how much load the comparison adds on your busiest hosts before rolling it out widely.

How do I handle ATT&CK version changes for T1014 detections?

Pin every detection to the ATT&CK version it was written against, and record that version in the rule metadata. MITRE publishes ATT&CK content in STIX 2.1 bundles, and releases can rename, deprecate or revoke techniques, so a mapping that was correct in one version may need review in the next. Recent releases include v18, v19 and v20, and v19 split the Enterprise Defense Evasion tactic into Stealth (TA0005) and Defense Impairment (TA0112). When you upgrade, diff the technique and data component references for T1014 against the new bundle, then re-validate affected rules in your range before deploying them.

Which telemetry gaps should I check first for rootkit detection?

Check the data sources the detection depends on before you check the rules. For T1014 the core inputs are Process Creation, Module Load and File Creation, and each has blind spots. Confirm that kernel module or driver load events reach your SIEM on Linux, macOS and Windows, that file creation events cover the boot and system directories, and that process records include parent and hash fields. Also confirm clock sync, log forwarding health and retention, because a rootkit that acts during a gap leaves no event. Run a gap review by generating known benign loads and checking that each one appears in the platform index within your target latency.

How do I measure the quality of rootkit detections?

Measure detection quality with the results from your cyber range, not with rule counts. Track how many of the planted, approved test events your detections alerted on, how many benign events raised alerts, and how long each alert took to reach an analyst. Record the ATT&CK version and telemetry source for every rule, so you can explain changes over time. Review false positives with the owners of approved drivers and agents, and retire rules that never fire against your own test cases. Ask your team to set the targets they will report against before the exercise begins.

Can my own team run rootkit detection exercises without outside help?

Yes, a capable internal team can run these exercises if it has the telemetry, a non-production lab and written rules of engagement. The work includes building a range that mirrors your platforms, agreeing what test activity is permitted, validating that events reach your SIEM, and documenting results against your ATT&CK version. Outside help is most useful for scoping the range, reviewing coverage, and running fixed-scope exercises that produce evidence for auditors. DeployOpen implements and operates self-hosted open-source platforms, runs security testing and private cyber ranges, and prepares evidence for compliance assessments, but it does not issue audit reports or certifications.

How DeployOpen builds T1014 Rootkit detections and range exercises

DeployOpen approaches T1014 Rootkit as a written, fixed-scope engagement inside the client's own infrastructure. The work covers detection content on Linux, macOS and Windows, validated in a private cyber range and handed over with documentation the client's own team can run.

How we scope

Confirm which operating systems, kernels and endpoint fleets are in the T1014 Rootkit detection scope.
Record which telemetry sources exist for Process Creation, Module Load and File Creation, and where gaps sit.
Agree the ATT&CK version the detections target, since releases can rename or deprecate techniques.

How we build

Map candidate detections to the ATT&CK detection strategies for T1014 Rootkit and its data components.
Write Sigma rules and Wazuh or Security Onion detection content, tuned to the client's log sources.
Test detections against benign kernel module loads and driver updates to reduce false positives before go-live.

How we hand over

Deliver a written detection record listing logic, data sources, known blind spots and owners for each rule.
Provide cyber range exercise runbooks so the client's analysts can rehearse T1014 Rootkit detection and response.
Document the mitigations in scope, including Audit and Behavior Prevention on Endpoint, with configuration evidence.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Retainers can cover re-validation of T1014 Rootkit detections when the ATT&CK version or endpoint stack changes.
Confirm response times, reporting cadence and support hours in the written scope before work starts.

T1014 Rootkit