D3-SDM System Daemon Monitoring: Catching Stopped and Tampered Security Services

An intruder who can stop the antivirus service, turn off the firewall or kill the logging daemon can then work unseen, so the state of critical system services is itself a detection signal. MITRE D3FEND calls this countermeasure System Daemon Monitoring (D3-SDM) and defines it as "Tracking changes to the state or configuration of critical system level processes." It is a Detect technique under Operating System Monitoring, and its digital artefact is the Operating System Process. This card covers what to watch, which ATT&CK techniques D3FEND relates it to, the native and product signals on Windows, Linux and macOS, how to prove the alerts fire, and how attackers get around them. It is for SOC analysts, detection engineers and endpoint owners; the wider parent topic is covered in D3-OSM Operating System Monitoring.

Key takeaways

• Watch the watchers. D3FEND's article names firewall and antivirus services as popular targets and notes that disabling system logs lets an attacker's actions go unnoticed.
• Two approaches. D3FEND suggests monitoring hardened system services, and monitoring registry updates for changes to security settings.
• The ATT&CK link is defence impairment. D3FEND relates D3-SDM to Disable or Modify Tools (T1685 in ATT&CK v20) and, through the Scheduled Job sub-artefact, to Scheduled Task (T1053.005).
• Silence is the hardest signal. A stopped agent cannot report that it stopped, so the most reliable control is a heartbeat or missing-telemetry check from a system the attacker does not control.
• Prevention beats detection here. Tamper protection, protected processes and service recovery settings stop many attempts; D3-SDM catches what gets through and the attempts themselves.

D3-SDM at a glance

How it works

D3FEND's article explains that attackers may manipulate system settings or services to disable logging or the monitoring of security tools, and that analysis of logs, registries and process monitoring helps defenders find signs of tampering. In practice a D3-SDM programme watches three kinds of change.

• State changes: a protected service moves to stopped, is set to disabled, or its process exits unexpectedly.
• Configuration changes: a security product's policy, exclusions or real-time protection settings change, through the registry, a configuration file or a management command.
• Health gaps: an agent or log forwarder that used to report stops reporting, which is often the only trace of a successful kill.

The MITRE CAR analytic referenced by D3FEND is the simplest example: in the Windows System log, event 7036 where the service name is Windows Defender or Windows Firewall and the new state is "stopped". CAR rates its own ATT&CK coverage as low, which is a fair reminder that one event rule is a start, not a programme.

ATT&CK techniques D3FEND relates to D3-SDM

Relationship type: inferred only. D3FEND lists these relations as "inferred and experimental", derived through the Operating System Process artefact (D3FEND 1.6.0, checked November 2026). D3FEND still shows Disable or Modify Tools under its pre-v20 ID as a sub-technique of Impair Defenses; ATT&CK v20 revoked that ID and its successor is T1685, used below. Each ID was checked against ATT&CK v20.

Two neighbours are worth watching with the same rules, though D3FEND does not relate them to D3-SDM: Service Stop (T1489), used before ransomware encryption, and Create or Modify System Process (T1543), where the attacker installs a service rather than stopping one. See the T1685 Disable or Modify Tools Defensive Guide, the T1053 Scheduled Task/Job Defensive Guide and MITRE ATT&CK T1489 Service Stop.

Signals to collect

Platforms are listed alphabetically; order is not a ranking. Event numbers are documented by the source named in each row.

Deeper collection guidance is in the Sysmon Guide, the Windows Event Log Guide and the Linux Logging and auditd for Defenders Guide.

Where identity fits

Stopping a protected service normally needs local administrator or root rights, and in many incidents those rights come from a management or deployment account, not a person. Alert enrichment should record which account changed the service and whether that account is a known automation identity. Patch, backup and software deployment service accounts that legitimately restart security agents should be scoped to that action and listed in the allow-list by name, so a stolen one used outside its window stands out.

Implementation steps

1. List the critical daemons. For each platform, name the services whose loss blinds you: antivirus and EDR agents, host firewall, event log and audit daemons, log forwarders, Sysmon, backup agents. This list is the scope of D3-SDM.
2. Turn on prevention first. Enable tamper protection where the product offers it (for example, "Prevent agent tampering" in an Elastic Defend agent policy, or "Tamper protection (device)" in a Microsoft Intune Antivirus policy for Microsoft Defender for Endpoint) and set service recovery or systemd Restart= for critical units.
3. Write state and configuration rules. Alert on stop, disable and uninstall events for the listed services, and on writes to their registry keys or configuration files. Key Linux audit rules so results are searchable by name.
4. Add the missing-telemetry rule. In the SIEM, alert when an asset that reported in the last day has sent no agent or log data for a set window. An example window is 30 to 60 minutes for servers; this is an NHI Mgmt Group suggestion, not a standard.
5. Build the maintenance allow-list. Record approved patch windows, deployment tools and their service accounts. Suppress only matching events, never a whole host.
6. Pilot and tune. Run in alert-only mode on one server group for two weeks, fix benign triggers at the source, then extend.
7. Define the response. A security service stopped outside a change window is treated as possible hands-on-keyboard activity: isolate through the network or the EDR console if it still responds, restore the service and collect logs from a central copy, not the host. The EDR Tampering and BYOVD Response Playbook covers the full response.

How to verify it works

• Replay the CAR unit test in a lab: stop the firewall and antivirus services from an administrative console on a test host and confirm the alert arrives with the host and account. With tamper protection on, the stop should be blocked and the attempt should still be reported.
• Check prevention status: on Windows, Get-MpComputerStatus | Select-Object IsTamperProtected, RealTimeProtectionEnabled shows whether tamper protection and real-time protection are on.
• Test the silence rule: disconnect a test host's network and confirm the missing-telemetry alert fires within the window.
• Test the Linux rules: modify a watched configuration file on a test host and search the audit log for the rule key.

Limits, bypasses and failure patterns

• Killed before it can speak: an agent removed through a vulnerable driver or from kernel level may send nothing. The Bring Your Own Vulnerable Driver and EDR Killers Guide covers this; the missing-telemetry rule is the backstop.
• Logs cleared or stopped first: if the event log or audit daemon is the first thing stopped, the later service changes are never recorded locally. Forward events off-host as they happen.
• Changes that look like administration: exclusions added through the management console with a stolen administrator account do not stop any service. Monitor configuration changes in the management plane as well as on hosts.
• Allow-lists that are too wide: suppressing all service events during a weekly patch window gives an attacker a weekly window too.
• Assuming every platform blocks: tamper protection modes differ by operating system and product, and some modes report rather than block. Check each product's documented mode per platform and plan audit rules and off-host forwarding for the report-only cases. Vendor documentation also notes that a local administrator can still change operating system settings, so limit who holds those rights.
• Monitoring only Windows Defender and Firewall: the CAR example names two services. Real scope includes third-party agents, log forwarders and backup agents.

Framework mapping

For the audit mitigation itself, see M1047 Audit.

Related countermeasures

• System File Analysis: watches the files and configuration that daemons depend on. See D3-SFA System File Analysis.
• Scheduled Job Analysis: examines the scheduled tasks D3FEND links to this technique. See D3-SJA Scheduled Job Analysis.
• System Init Config Analysis: watches the boot and init configuration that starts services. See D3-SICA System Init Config Analysis.

Practitioner checklist

• Keep a named list of critical security and logging daemons per platform.
• Enable tamper protection on every managed endpoint and confirm it with a status query.
• Alert on stop, disable and uninstall of each listed daemon, including Sysmon events 4 and 16.
• Watch registry keys and configuration files that control security product settings.
• Run a missing-telemetry rule from the SIEM for every agent and log source.
• Scope the maintenance allow-list to named tools, service accounts and time windows.
• Forward logs off-host in real time so local log clearing does not erase the trail.
• Test each rule monthly in a lab and record the result.

Standards and references

• MITRE D3FEND: System Daemon Monitoring (D3-SDM)
• MITRE CAR: CAR-2016-04-003 User Activity from Stopping Windows Defensive Services
• Elastic Docs: Prevent Elastic Agent uninstallation (agent tamper protection)
• Microsoft Learn: Protect security settings with tamper protection
• Microsoft Learn: Configure tamper protection on Windows devices
• Microsoft Learn: Sysmon
• Linux man-pages: audit.rules(7)
• systemd: systemd.service, Restart= and WatchdogSec=
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls

Related NHI Mgmt Group resources: T1685 Disable or Modify Tools Defensive Guide · EDR Tampering and BYOVD Response Playbook · Sysmon Guide · MITRE D3FEND Guide