Kernel Modules and Extensions (T1547.006)

Plain-language orientation

Kernel Modules and Extensions is represented in Enterprise ATT&CK as T1547.006, a sub-technique associated with Persistence, Privilege Escalation. It refines the parent technique Boot or Logon Autostart Execution (T1547) into a more specific behavior. Bare Metal Cyber treats the identifier as a disciplined label for observable behavior, not as a verdict about actor identity, intent, severity, or the success of an intrusion.

The educational purpose of this profile is to help a learner move from a framework label to defensible analysis. A useful mapping explains what happened, which evidence supports the conclusion, which legitimate activities could appear similar, and how the behavior changed an adversary’s access, knowledge, capability, concealment, control, collection, transfer, or effect.

Within the ATT&CK model, the associated tactical context is: Persistence: maintain access across interruptions, restarts, credential changes, or defensive actions; Privilege Escalation: gain permissions or security context beyond the adversary’s current level. One observation may support more than one tactic, and the same technique can occur repeatedly or in a different order than a diagram suggests. Investigators should therefore reconstruct the actual sequence rather than forcing events into a presumed linear attack chain.

Why defenders track this behavior

Defenders track Kernel Modules and Extensions because the behavior can reveal a meaningful decision point in an attack path. The most useful question is not simply whether a named tool, command, service, or artifact exists. It is whether the observed activity matches the behavior described by T1547.006 in the affected environment and whether it enabled a measurable next step.

Attempted and failed activity matters. A blocked instance of Kernel Modules and Extensions may expose targeting, assumptions, infrastructure, identity use, or intended follow-on actions even when the preventive control worked. Recording both successful and unsuccessful observations improves threat hunting, control validation, and later incident reconstruction.

• Identify the precondition that made Kernel Modules and Extensions possible or attractive.
• Identify the affected identity, asset, workload, application, service, or external resource.
• Separate the behavior from the product or utility that happened to perform it.
• Record whether the action was attempted, partially successful, successful, or prevented.
• Connect the observation to immediately preceding and following events.
• State confidence, evidence limitations, and plausible benign explanations.

Observable evidence

Evidence for Kernel Modules and Extensions should be described as an observable sequence rather than a single keyword. Start with the initiating identity, process, service, application, or external source; identify the affected object and state change; then correlate the event with independent context. The exact sources will vary by platform and architecture, so the official ATT&CK record should be consulted for current platform-specific examples.

Before asserting coverage, validate parser behavior, field meaning, timestamps, retention, sensor health, and the scope of collection. Telemetry generated only on a potentially compromised host may be incomplete or altered. High-consequence conclusions benefit from centralized or cross-domain evidence that the adversary could not easily control.

• Configuration, registry, policy, boot, service, and scheduled-object changes
• Before-and-after state from configuration management or integrity monitoring
• Actor, process, management channel, and privilege context
• Startup, login, persistence, and system initialization events
• Code-signing, package, driver, firmware, and trust-validation evidence
• Independent records from centralized administration and endpoint telemetry

Detection engineering workflow

A detection for T1547.006 should document the observable pattern, required fields, analytic logic, suppression conditions, expected benign activity, triage action, and known coverage boundary. Merely assigning the ATT&CK ID to a vendor alert does not prove that the organization can reliably detect Kernel Modules and Extensions.

Begin with a behavior hypothesis, test it with authorized and harmless activity, and confirm that the resulting evidence survives ingestion into the systems analysts actually use. Measure false positives, false negatives, source outages, and the effect of environment changes. Detection content should be versioned and reviewed when the relevant platform, identity architecture, or ATT&CK definition changes.

• Describe the minimum evidence that distinguishes Kernel Modules and Extensions from routine activity.
• Identify required fields and the systems responsible for producing them.
• Baseline legitimate administrative, automated, and user-driven behavior.
• Correlate sequence, identity, asset, privilege, destination, and outcome.
• Define a triage path that can confirm or reject the behavior quickly.
• Record unmonitored platforms, tenants, networks, or workflows as explicit gaps.

Defensive design and mitigation

Defending against Kernel Modules and Extensions requires controls at the decision points that make the behavior possible. A framework relationship is a starting hypothesis: it must be translated into specific identities, systems, applications, trust boundaries, configurations, and recovery requirements. No single preventive feature should be treated as complete coverage.

Use independent layers where consequence is high. Prevention should be paired with protected evidence, bounded privileges, exception governance, containment options, and tested recovery. Document where a control applies, where it does not, and how operators will recognize a failure or bypass.

• Manage secure baselines as versioned code or controlled configuration
• Restrict who and what can change startup, service, policy, and boot settings
• Monitor drift and preserve before-and-after state
• Protect signing keys, update channels, firmware, and administrative tooling
• Require approval and independent evidence for high-risk changes
• Test rollback and recovery from unauthorized configuration changes

Investigation and response

When Kernel Modules and Extensions is suspected, begin with the most direct observation and work backward to enabling access and forward to consequences. Avoid assuming that the first detected event was the initial compromise. The behavior may be one visible step in a longer chain or may reflect legitimate administration performed through an unusual path.

Containment should preserve evidence while reducing the adversary’s ability to continue. Depending on the affected environment, that may require isolating assets, revoking sessions, rotating credentials, disabling access paths, protecting recovery systems, or moving investigation to an independent management plane. Recovery is complete only when the enabling condition and downstream changes are understood.

• What observation most directly supports T1547.006 Kernel Modules and Extensions?
• Which identity, process, service, application, or infrastructure initiated it?
• Was the activity expected for that actor, asset, location, privilege, and time?
• What precondition, access path, or control failure enabled it?
• What new information, access, capability, concealment, transfer, or impact followed?
• Which evidence sources may be missing, impaired, delayed, or controlled by the adversary?
• What must be revoked, contained, restored, or monitored before normal operations resume?

Safe practitioner exercise

Study Kernel Modules and Extensions in a disposable lab, sanitized dataset, or tabletop exercise. Do not deploy malware, target systems you do not own, bypass controls on production assets, collect real credentials, or attempt unapproved access. The objective is to understand evidence and control behavior, not to reproduce harmful tradecraft.

Document the starting state, expected event sequence, timestamps, test identities, rollback method, and success criteria. After the exercise, remove test artifacts, restore the environment, verify the baseline, and retain only sanitized evidence needed for learning or detection validation.

• Write a one-sentence hypothesis describing how Kernel Modules and Extensions would appear in authorized telemetry.
• Select a harmless administrative action or prepared dataset that produces comparable evidence.
• Confirm the event reaches the endpoint, identity, network, application, or cloud records analysts use.
• Draft a detection query or triage checklist without attempting concealment or control bypass.
• Record one false-positive condition, one missing field, and one coverage limitation.
• Restore the lab and confirm the test did not leave active accounts, jobs, services, files, or network exposure.

Common mapping mistakes

ATT&CK mappings become less useful when analysts select an ID because a product, command, or keyword is familiar rather than because the evidence supports the defined behavior. Use the narrowest current technique or sub-technique justified by the facts, and retain a broader mapping when the evidence cannot support the narrower conclusion.

• Treating the presence of a tool as proof that Kernel Modules and Extensions occurred.
• Assuming the ATT&CK tactic is a chronological phase rather than an adversary objective.
• Using a sub-technique when evidence supports only the parent technique.
• Claiming organization-wide detection because one vendor rule carries the ID.
• Ignoring failed attempts, benign administrative look-alikes, or telemetry gaps.
• Using a retired identifier as current without documenting the catalog version and successor behavior.

Version, attribution, and source scope

This profile was reviewed against Enterprise ATT&CK v19.2. ATT&CK evolves, and names, relationships, platforms, detection guidance, and status can change. The official record for T1547.006 remains the controlling source for current framework metadata; Bare Metal Cyber adds original educational explanation and defensive context.

© 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation.

MITRE ATT&CK® and ATT&CK® are registered trademarks of The MITRE Corporation. Bare Metal Cyber is not affiliated with or endorsed by MITRE.

Certification relevance

This subject appears in or supports the following certification bodies of knowledge:

Authoritative sources

• MITRE ATT&CK® — T1547.006: Kernel Modules and Extensions
• MITRE ATT&CK® Enterprise Techniques
• MITRE ATT&CK® Data & Tools
• MITRE ATT&CK® Terms of Use