D3-OSM Operating System Monitoring: Coverage and Tests

Attackers who gain a foothold on a host change the operating system itself, through new services, boot scripts, drivers, scheduled jobs and cleared logs, and those changes are only caught if something is watching the operating system as a whole. MITRE D3FEND names this countermeasure Operating System Monitoring (D3-OSM). Its definition scopes the operating system as the kernel and its process management functions, hardware drivers, initialisation or boot logic, and key system daemons and their configuration, and calls the monitoring or analysis of these components for unauthorised activity Operating System Monitoring. D3-OSM sits under the Detect tactic as a child of Platform Monitoring (D3-PM). It is a grouping technique: most of its practical content lives in nine child techniques. This card explains what the umbrella covers, how D3FEND relates it to ATT&CK, where it is implemented on Windows, Linux and macOS, and how to prove the telemetry is actually arriving. It is written for detection engineers and endpoint security owners.

Key takeaways

It is an umbrella, not a single sensor. D3FEND groups nine children under D3-OSM, from Scheduled Job Analysis to Memory Boundary Tracking; a programme for D3-OSM is a programme for those nine.
The ATT&CK list is inherited. D3-OSM has no artefact relation of its own in the D3FEND ontology; the ATT&CK techniques on its page roll up from its children and D3FEND labels them inferred and experimental.
Native OS telemetry does most of the work. D3FEND notes that implementations range from built-in kernel modules and privileged third-party daemons to standard administration tools shipped with the operating system.
Log tampering is the first thing to watch. One of D3FEND's two references is MITRE CAR-2016-04-002, which alerts when Windows Security event 1100, 1102 or 1104 or System event 104 appears.
Silence is not proof. A monitored host that stops sending events looks clean, so verification of the sensor and its pipeline is part of the control.

D3-OSM at a glance

Attribute	Value
D3FEND ID	D3-OSM (d3f:OperatingSystemMonitoring)
Tactic	Detect
Parent technique	Platform Monitoring (D3-PM), "Monitoring platform components such as operating systems software, hardware devices, or firmware."
Scope in the definition	Kernel and process management, hardware drivers, initialisation and boot logic, key system daemons and their configuration
Digital artefacts	None directly on D3-OSM; its children cover Input Device, Process Code Segment, Operating System File, System Init Configuration, User Init Configuration File, Operating System Process, Network Node, Service Application and Job Schedule
D3FEND references	Sophos patent US20110023115A1 (host intrusion prevention using software and user behaviour analysis); MITRE CAR-2016-04-002 (User Activity from Clearing Event Logs)
D3FEND version checked	1.6.0, November 2026

What it covers: the nine child techniques

The D3FEND page for D3-OSM lists the following children. Each has its own card on this site; use them for deployment detail rather than treating D3-OSM as one control.

Child technique	What it watches	Card
Endpoint Health Beacon (D3-EHB)	Regular health reports from an endpoint agent	D3-EHB Endpoint Health Beacon
Input Device Analysis (D3-IDA)	Input devices and their activity	D3-IDA Input Device Analysis
Memory Boundary Tracking (D3-MBT)	Process code segments and memory boundaries	D3-MBT Memory Boundary Tracking
Scheduled Job Analysis (D3-SJA)	Job schedules such as Task Scheduler and cron	D3-SJA Scheduled Job Analysis
Service Binary Verification (D3-SBV)	Binaries behind registered services	D3-SBV Service Binary Verification
System Daemon Monitoring (D3-SDM)	Operating system processes and daemons	D3-SDM System Daemon Monitoring
System File Analysis (D3-SFA)	Operating system files	D3-SFA System File Analysis
System Init Config Analysis (D3-SICA)	Boot and system initialisation configuration	D3-SICA System Init Config Analysis
User Session Init Config Analysis (D3-USICA)	User logon and shell initialisation files	D3-USICA User Session Init Config Analysis

The "what it watches" column is a short summary in our words, based on the artefacts D3FEND lists for the family. D3-OSM also sits beside its sibling Platform Monitoring techniques such as Operating Mode Monitoring (see D3-OMM Operating Mode Monitoring), Platform Uptime Monitoring (D3-PUM Platform Uptime Monitoring) and Firmware Verification.

ATT&CK techniques D3FEND relates to D3-OSM

Relationship type: inferred only, inherited from child techniques. In the D3FEND ontology D3-OSM carries no "monitors" or "analyzes" relation of its own. The D3FEND site rolls up the inferred relations of its children and labels them inferred and experimental (D3FEND 1.6.0, checked November 2026). The table groups them by tactic as the D3FEND page does and lists the IDs it shows. D3FEND still lists some IDs that ATT&CK v20 has revoked; the table shows the v20 technique of the same name, with a note. Every ID was checked against ATT&CK v20.

Tactic (as grouped by D3FEND)	ATT&CK v20 techniques	Child technique most relevant (our reading)
Execution and stealth (hijack execution flow)	T1574.005 Executable Installer File Permissions Weakness, T1574.010 Services File Permissions Weakness, T1574.011 Services Registry Permissions Weakness, T1574.006 Dynamic Linker Hijacking	D3-SBV, D3-SFA, D3-SICA
Execution and persistence (jobs)	T1053.005 Scheduled Task	D3-SJA
Persistence and privilege escalation	T1543.002 Systemd Service, T1547.001 Registry Run Keys / Startup Folder, T1037.004 RC Scripts, T1037.005 Startup Items, T1546.004 Unix Shell Configuration Modification, T1548.003 Sudo and Sudo Caching	D3-SDM, D3-SICA, D3-USICA
Privilege escalation (process injection)	T1055.009 Proc Memory, T1055.012 Process Hollowing	D3-MBT
Stealth	T1036.003 Rename Legitimate Utilities, T1036.004 Masquerade Task or Service, T1564.006 Run Virtual Instance, T1564.002 Hidden Users	D3-SDM, D3-SJA, D3-SFA
Defence impairment (D3FEND lists these four under IDs that ATT&CK v20 has revoked; their ATT&CK v20.1 revoked-by successors are shown)	T1685.006 Clear Linux or Mac System Logs, T1685 Disable or Modify Tools, T1688 Safe Mode Boot, T1686.002 Network Device Firewall	D3-SFA, D3-EHB, D3-SICA
Defence impairment and persistence	T1556.003 Pluggable Authentication Modules, T1578.002 Create Cloud Instance, T1578.003 Delete Cloud Instance, T1578.004 Revert Cloud Instance	D3-SFA, D3-EHB
Persistence (server components)	T1505.003 Web Shell, T1505.002 Transport Agent	D3-SFA, D3-SBV
Credential access and collection	T1003.007 Proc Filesystem, T1056.001 Keylogging, T1056.003 Web Portal Capture, T1056.004 Credential API Hooking, T1114.002 Remote Email Collection	D3-IDA, D3-MBT

The D3FEND page also names techniques without IDs (Software Deployment Tools, Exploitation for Client Execution, Exploitation for Privilege Escalation, Video Capture, Audio Capture, Service Stop, Remote System Discovery); they are omitted here. The right-hand column is NHI Mgmt Group's reading of which child carries each relation, not D3FEND data. Treat the table as a coverage map for planning, not a claim that any one product detects each technique. For two of the most common persistence paths, see T1546 Event Triggered Execution Defensive Guide and T1685 Disable or Modify Tools Defensive Guide.

Where it is implemented

D3FEND's own knowledge base article says Operating System Monitoring has varied implementations, including built-in kernel modules, third-party privileged system daemons, and standard systems administration tools included with an operating system. Operating systems are listed alphabetically.

Platform	Native telemetry	Examples of OS components it can watch
Linux	Linux Audit subsystem configured with auditctl rules; syscall rules (`-a always,exit -S ...`) with `-k` keys for search, and `-e 2` to lock the rule set until reboot	Changes to /etc/shadow, sudoers, systemd unit files, cron tables, PAM configuration
macOS	Endpoint Security framework, a C API for system extensions that receive notifications of events that already occurred or authorise pending events, including process executions, file system mounts, process forks and signals	Process execution, mounts, launch item changes; the client needs the Endpoint Security entitlement
Windows	Windows event logs plus Sysmon; Sysmon event 6 (Driver loaded) with hash and signature, event 25 (ProcessTampering), events 12 to 14 (registry), events 19 to 21 (WMI), and events 4 and 16 that record Sysmon's own service state and configuration changes	Driver loads, Run keys, services, WMI subscriptions, log clearing (Security 1102)

Commercial endpoint detection and response agents, host intrusion prevention systems and open source agents package the same sources. The Sophos patent D3FEND cites describes one design: baseline profiles of user and code behaviour, then action when code copies itself to a system folder or sets a registry run key to itself. For collection and retention design, see the Linux Logging and auditd for Defenders Guide, the Sysmon Guide and the Windows Event Log Guide.

Where identity fits

Many of the OS changes in the table are made under service and system accounts: a new systemd unit runs as a dedicated service user, a scheduled task runs as SYSTEM, a modified PAM module touches every login. Record which account made each change and which account the new item runs as; a new service running under a privileged service account is a higher priority than one under a constrained user. The D3-LAM Local Account Monitoring card covers the account side.

Deployment steps

Map the children to your estate. For each of the nine children decide which sensor provides it on Windows, Linux and macOS, and record gaps. This is the D3-OSM coverage map.
Turn on log tampering detection first. Alert on Security events 1100, 1102 and 1104 and System event 104, as CAR-2016-04-002 describes, and on the Linux and macOS equivalents your sensor provides. Forward logs off the host so clearing them locally does not remove the evidence.
Add high-value OS change rules. Services, drivers, boot and init configuration, scheduled jobs, PAM and sudoers. Start in alert-only mode on a pilot group of hosts.
Protect the sensor. On Linux, finish audit.rules with -e 2 once the rule set is stable, since auditctl documents that the configuration then changes only after a reboot. On Windows, alert on Sysmon events 4 and 16, which record the Sysmon service state and configuration changes.
Tune, then widen. Patch cycles, configuration management runs and software deployment generate legitimate OS changes. Correlate with change tickets or deployment tool identities rather than excluding whole paths.
Roll back safely. Keep the previous rule set versioned. Removing an immutable Linux audit configuration needs a planned reboot, so schedule rule changes with maintenance windows.

How to verify it works

Synthetic changes: on a test host in each OS build, create and delete a benign service, scheduled job and startup item, and confirm each produces an alert with host, account and timestamp. Use authorised emulation tooling where your change process allows it.
Log clearing test: clear a non-production event log on a test host and confirm the 1102 or 104 alert arrives centrally.
Sensor heartbeat: compare the list of hosts sending OS telemetry in the last 24 hours with the asset inventory. Missing hosts are blind spots; see D3-EHB Endpoint Health Beacon.
Rule integrity: confirm the deployed auditctl rules and Sysmon configuration match the approved version on a sample of hosts.

Metric	Example target (NHI Mgmt Group suggestion, not a standard)
Hosts with OS telemetry received in the last 24 hours, as a share of inventory	Above 98%
Child techniques with a sensor per OS family	9 of 9 recorded, gaps with an owner
Synthetic OS change tests passing each month	100%
OS change alerts matched to a change ticket or deployment identity	Rising quarter on quarter
Time from log clearing to central alert	Under 15 minutes

Limits, bypasses and failure patterns

Kernel-level attackers: a rootkit or malicious driver running at the same privilege as the monitor can hide from or tamper with it. Firmware and boot integrity checks cover what OS monitoring cannot; see the Firmware and Boot Security Guide.
Local-only logs: if events stay on the host, clearing them (T1685.005 on Windows, T1685.006 on Linux and macOS) removes the evidence. CAR-2016-04-002 notes that central collection makes it much harder for attackers to cover their tracks.
Disabled or modified sensors: stopping the agent or rewriting its configuration (T1685) is quieter than any later step, so sensor health has to be monitored separately.
Noise from management tools: configuration management and patching tools change OS components constantly; broad path exclusions to silence them also silence the attacker using the same paths.
Performance limits: auditctl documents that path watches using the -w form are deprecated due to poor system performance; use syscall rules with a path filter instead.
Treating the umbrella as done: a single "EDR deployed" tick does not show which of the nine children are actually covered on each OS.

Framework mapping

Framework	Reference	Relevance
NIST SP 800-53 Rev 5	SI-4 System Monitoring	Monitoring the system to detect attacks and unauthorised activity
NIST SP 800-53 Rev 5	SI-7 Software, Firmware, and Information Integrity	Detecting unauthorised changes to OS software and configuration
NIST SP 800-53 Rev 5	AU-12 Audit Record Generation, AU-6 Audit Record Review, Analysis, and Reporting	Generating and reviewing the OS events
NIST CSF 2.0	DE.CM-09, DE.AE-02, PR.PS-04	Monitoring computing hardware and software; analysing events; log records available for monitoring
MITRE D3FEND	D3-PM, D3-OSM and its nine children	Parent, technique and children

Practitioner checklist

Record which sensor provides each of the nine child techniques on each OS family.
Alert on Security 1100, 1102, 1104 and System 104, and on Linux and macOS log clearing.
Forward OS telemetry off the host to a central store.
Monitor services, drivers, init configuration, scheduled jobs, PAM and sudoers changes.
Lock Linux audit rules with -e 2 and alert on Sysmon events 4 and 16.
Reconcile hosts sending telemetry against the asset inventory daily.
Correlate OS changes with change tickets and deployment identities, not path exclusions.
Run monthly synthetic OS change tests per OS build.

D3-OSM Operating System Monitoring: Scope, Child Techniques, ATT&CK Coverage and Verification