D3-SBV Service Binary Verification: What It Detects, Which ATT&CK Techniques It Counters and How to Verify It

Replacing the executable behind an existing service gives an attacker code that starts with the system, under the service's privileged account, without creating anything new for defenders to notice. MITRE D3FEND names the defence D3-SBV Service Binary Verification, a Detect tactic countermeasure under System File Analysis (D3-SFA), itself part of Operating System Monitoring. D3FEND defines it as analysing changes in service binary files by comparing to a source of truth. This card covers the artefact it verifies, the ATT&CK techniques D3FEND relates it to, the sources of truth available on Windows and Linux, and how to prove the verification catches a swapped binary. It is written for detection engineers, endpoint and server owners, and incident responders.

Key takeaways

• The artefact is the service application. D3FEND notes that services start from an entry point executable, a binary or a script, and that attackers sometimes modify these executables to launch their own code.
• Everything depends on the source of truth. D3FEND's considerations: binaries change for legitimate updates, and the source of truth must not be corrupted for the method to work.
• Three core ATT&CK relations. Through the Service Application artefact, D3FEND relates D3-SBV to Executable Installer File Permissions Weakness (T1574.005), Services File Permissions Weakness (T1574.010) and Service Stop (T1489).
• Join file changes to service starts. MITRE CAR-2014-02-001 looks for a file created or modified, then started by services.exe, excluding known installers.
• Signatures and package databases are practical sources of truth. Authenticode on Windows and package manager digests on Linux let you verify without building every baseline yourself.

D3-SBV at a glance

How it works

D3-SBV answers one question for every service: is the file this service runs the file it should be? That takes three inputs. The service inventory: each service's executable path and arguments (on Windows, the path the Service Control Manager runs; on Linux, the ExecStart= of each systemd service). The current file state: hash, signature, owner and permissions of that file. The source of truth: a known good hash list, a trusted signer, or the package manager's record of what it installed.

CAR-2014-02-001 adds the time dimension. Its logic finds files that were created or modified, then later process creations whose parent is services.exe and whose image path matches the modified file, filtering legitimate installers such as msiexec.exe in System32 and SysWOW64. The output is the service name and the approximate time of change on each host. CAR rates moderate coverage of Windows Service (T1543.003), Services File Permissions Weakness (T1574.010) and Service Execution (T1569.002), and notes that a well-tuned baseline is essential because legitimate software installs services often.

Sources of truth compared

The strongest designs keep the source of truth off the host being checked: a central hash store, a signer allowlist in policy, or package digests verified against the vendor repository. See the File Integrity Monitoring Guide and the Linux File Integrity Monitoring Guide for baseline tooling.

ATT&CK techniques D3FEND relates to D3-SBV

Relationship type: inferred, not a direct mapping. D3FEND marks these relations as inferred and experimental, based on shared digital artefacts. They show relevance, not guaranteed coverage. Each ID was checked against ATT&CK v20.

The core set comes from the Service Application artefact that D3-SBV verifies:

D3FEND's page also shows a wider inferred list that D3-SBV inherits because it analyses Operating System File, the artefact of its parent D3-SFA. These relate to system files in general rather than service binaries specifically:

For attacker behaviour and mitigations, see the T1574 Hijack Execution Flow Defensive Guide, MITRE ATT&CK T1489 Service Stop and the T1543 Create or Modify System Process Defensive Guide.

Where it is implemented

Microsoft's event 4697 documentation notes that changes to the service file path after installation are not logged in that event, which is why D3-SBV cannot rely on installation events alone: the swap of an existing binary only shows in file telemetry and verification. Microsoft also recommends flagging any ServiceFileName outside %windir%, Program Files or Program Files (x86). Product classes implementing D3-SBV include file integrity monitoring tools, endpoint detection and response agents, application control in audit mode, configuration management drift reports and vulnerability scanners with integrity checks.

Where identity fits

The account a service runs as decides what a swapped binary can do. Event 4697 records ServiceAccount, and Microsoft recommends reporting any value other than localSystem, localService or networkService, since that means a service runs under a user account. A replaced binary behind a service running as a domain account inherits that account's access and any stored credentials. Inventory service accounts alongside service binaries; see the Windows Services and Service Account Security Guide and How to find Windows services running as domain accounts.

Implementation steps

1. Build the service inventory. For each host class, list every service, its executable path with arguments, and its run-as account. Resolve script entry points to the script file, since D3FEND counts scripts as service entry points.
2. Choose a source of truth per binary. Signer allowlist for vendor-signed binaries, package verification for packaged Linux binaries, and a central hash baseline for unsigned and in-house services.
3. Check permissions as well as content. A binary or folder writable by non-administrators is the precondition for T1574.010. Report it as a finding even when the hash still matches; see M1022 Restrict File and Directory Permissions.
4. Add the CAR-style correlation. Join file creation or modification on a service path to a later process start by services.exe (or systemd) from that path, excluding approved installers and change windows.
5. Schedule full verification. Run signature and hash verification of all service binaries daily or weekly and ship results centrally, so a change missed by real-time telemetry still surfaces.
6. Integrate patching. Feed approved update hashes or package versions into the baseline before deployment, so updates do not generate alerts.
7. Pilot and roll back. Run alert-only for two weeks on one host group, classify every hit, then widen. D3-SBV only reads files, so rollback is disabling a rule; restoring a tampered binary belongs in the incident process after evidence is preserved.

How to verify it works

• Swap test: on a test host, install a harmless test service, then replace its binary with a different harmless, unsigned binary and restart the service. Both the correlation analytic and the next scheduled verification should flag it.
• Permission test: grant write access on a test service folder to a standard user group and confirm the permission check reports it.
• Package test: on a Linux test host, modify a non-critical packaged binary and confirm rpm -V or your integrity tool reports a digest change (the 5 flag in rpm output).
• Update test: apply a normal vendor update and confirm no alert fires, which proves the source of truth is maintained.

These metrics are examples to adapt, not a standard.

Limits, bypasses and failure patterns

• Source of truth on the same host: an attacker with administrative rights can alter local baselines or package databases. Keep baselines central and verify against the vendor where possible.
• Trusting any valid signature: a legitimately signed but vulnerable or abused binary passes signature checks. Pin expected signers per service and use fleet prevalence.
• Checking the binary, not what it loads: a service binary can stay intact while a DLL or shared library it loads is replaced, which is the Dynamic Linker Hijacking pattern in the wider list. Extend verification to service directories.
• Installation events only: event 4697 does not record later changes to the file path, and nothing records a same-path swap except file telemetry.
• Script entry points ignored: services that start a script are verified by checking the interpreter only, leaving the script open to change.
• Patch noise: without a link to patching, every update becomes an alert and analysts stop reviewing.

Framework mapping

The NIST mapping and M1022 are NHI Mgmt Group's view; the M1045 relation is D3FEND's. See M1045 Code Signing.

Related countermeasures

D3-SBV is the only child of D3-SFA System File Analysis. Under the same Operating System Monitoring branch sit D3-SICA System Init Config Analysis (service configuration and startup entries) and D3-SJA Scheduled Job Analysis. Hash-based checks overlap with D3-FH File Hashing and D3-FHRA File Hash Reputation Analysis.

Practitioner checklist

• Inventory every service with its executable path, arguments and run-as account.
• Assign a source of truth to each service binary: signer, package database or central hash.
• Keep baselines and signer allowlists off the hosts they verify.
• Report service binaries and folders writable by non-administrators.
• Correlate service path file changes with later service process starts.
• Run full verification at least weekly and ship results centrally.
• Feed approved patches into the baseline before they deploy.
• Run a binary swap test after each tooling change and track the result.

Standards and references

• MITRE D3FEND: Service Binary Verification (D3-SBV)
• MITRE CAR: CAR-2014-02-001 Service Binary Modifications
• MITRE ATT&CK: T1574.010 Services File Permissions Weakness
• Microsoft Learn: 4697 A service was installed in the system
• Microsoft Learn: Sigcheck
• Microsoft Learn: Sysmon
• Linux man-pages: rpm(8)
• Debian manpages: debsums(1)

Related NHI Mgmt Group resources: MITRE D3FEND Guide · T1574 Hijack Execution Flow Defensive Guide · File Integrity Monitoring Guide · Windows Services and Service Account Security Guide