D3FEND Object Eviction (D3-OE) Implementation Guide

Responders often delete the file they found, declare the host clean, and watch the attacker return through a registry key, a mailbox rule or a cached DNS answer they never touched. MITRE D3FEND groups the removal of attacker artefacts under Object Eviction (D3-OE), a technique in the Evict tactic that it defines as terminating or removing an object from a host machine, and calls the broadest class for object eviction. This guide treats D3-OE as a family: what each of its eight child techniques removes, how to choose and sequence them during eradication, how to prove an eviction held, and where the approach breaks down. It is written for incident responders, SOC leads and platform owners. Each child technique has its own page on this site with the operational detail; this page explains how they fit together. For D3FEND itself see the MITRE D3FEND Guide.

Key takeaways

Object Eviction is about artefacts, not access. It removes files, emails, registry keys, DNS records, domain registrations and disk contents. Revoking credentials and killing processes sit in sibling Evict families (Credential Eviction and Process Eviction).
The family has eight children in two levels. File Eviction contains Email Removal, and Disk Formatting contains Disk Erasure and Disk Partitioning; the rest sit directly under D3-OE.
Order matters more than any single deletion. Evict persistence and its credentials in the same window, after evidence is preserved, or the attacker rebuilds what you removed.
Every eviction needs a verification step. A scan, a re-query or a fresh resolver lookup that shows the object is gone, plus monitoring for its return.
D3FEND's ATT&CK links are inferred. The site labels them inferred and experimental, so use them to plan what to look for, not as proof that eviction defeats a technique.

What D3FEND means by Object Eviction

In the D3FEND ontology D3-OE sits directly under Defensive Technique and enables the Evict tactic. Its definition is short: terminate or remove an object from a host machine. The children widen "host" in practice: two of them act outside your own estate (a domain registrar for Domain Registration Takedown) or on shared services (a mail server for Email Removal). D3FEND relates each child to a digital artefact through a verb, and those verbs are a useful way to think about the family:

deletes: File, Email, Windows Registry Key, DNS Record and Domain Registration.
modifies or erases: Secondary Storage (Disk Formatting modifies it, Disk Erasure erases it).
creates: Partition Table (Disk Partitioning).
may-access: Mail Server (Email Removal).

The defensive value is that eviction is the only point in an incident where attacker footholds actually leave the environment. Detection and isolation buy time; eviction ends the intrusion if it is complete. NIST CSF 2.0 captures this outcome as RS.MI-02, incidents are eradicated, and NIST SP 800-61 Rev. 3 (final, April 2025) places incident response inside CSF 2.0 risk management. See the Incident Response Guide.

The child techniques

Every child technique in the D3FEND ontology under D3-OE, as of November 2026. Indented names are children of the row above.

D3FEND technique	Artefact relation	One-line purpose
D3-FEV File Eviction	deletes File	Delete malicious files and programs from system storage, usually through quarantine then removal
D3-ER Email Removal	deletes Email; may-access Mail Server	Purge malicious messages from mailboxes before users open them (synonym: Email Deletion)
D3-RKD Registry Key Deletion	deletes Windows Registry Key	Remove registry keys and values that hold persistence or attacker configuration
D3-DNSCE DNS Cache Eviction	deletes DNS Record	Flush cached DNS answers so poisoned or attacker records stop resolving (synonym: Flush DNS Cache)
D3-DRT Domain Registration Takedown	deletes Domain Registration	Have the attacker's domain suspended or removed at the registrar or registry
D3-DKF Disk Formatting	modifies Secondary Storage	Prepare a storage device with an empty file system, removing everything previously on it from normal view
D3-DKE Disk Erasure	erases Secondary Storage	Securely delete all data so it cannot be recovered
D3-DKP Disk Partitioning	creates Partition Table	Divide a disk into separate partitions, used in rebuilds to segregate data and systems

Two practical groupings follow from the table. Surgical eviction (FEV, ER, RKD, DNSCE) removes named objects from a running system. Wholesale eviction (DKF, DKE, DKP) removes everything on a device, which is what you choose when you cannot trust a surgical clean. Domain Registration Takedown stands apart: it acts on infrastructure you do not own and depends on a third party. ICANN's 2013 Registrar Accreditation Agreement (Section 3.18) requires accredited registrars to publish an abuse contact and take prompt, reasonable steps to investigate and respond to abuse reports, so a well-evidenced report to the sponsoring registrar is the usual starting point.

Choosing between surgical and wholesale eviction

Situation	Lean towards	Why
Commodity malware, single host, known indicators, no privilege escalation seen	Surgical: FEV, RKD, DNSCE	Scope is bounded and verifiable with a rescan
Phishing wave reaching many mailboxes	Surgical: ER, then FEV on any host that opened an attachment	Purging at the mail server reaches every copy at once
Kernel-level or boot-level persistence, rootkit suspected, or SYSTEM-level compromise of a server	Wholesale: reimage, using DKE or DKF on the old disk	Surgical removal cannot be proven complete when the attacker controlled the operating system
Device leaving service or reassigned after compromise	Wholesale: DKE, matched to media type	Sanitisation must make data recovery infeasible, not only hidden
Phishing or command and control domain still live	DRT alongside internal blocking	Takedown is slow and outside your control, so block first and pursue removal in parallel

This decision table is an NHI Mgmt Group view, not part of D3FEND. Where a disk is being reused or disposed of, follow NIST SP 800-88 Rev. 2 (final, September 2025), which defines sanitisation as making access to target data infeasible for a given level of effort and helps organisations build a media sanitisation programme. Plain formatting does not meet that bar on its own. See the Media Sanitisation Guide.

Sequencing an eviction

Eviction usually fails because it is done piecemeal while the attacker still has a way back in. A workable order, which is our recommendation rather than a D3FEND requirement:

Preserve evidence first. Capture memory, disk images or at least the objects themselves (file hashes and copies, exported registry keys, message headers and IDs, resolver cache contents) before deleting anything. Deletion is irreversible and removes the record you need for scoping and for any notification decision. See the Forensic Readiness Guide.
Scope the full object set. Use the indicators from the first host to search every other host and mailbox. Build one eviction list covering files, autostart registry locations, scheduled tasks, services, mailbox rules, hosts file entries and domains.
Contain, then evict in one window. Isolate affected hosts, then remove all listed objects together. Pair this with Credential Eviction (revoking the accounts, keys and tokens the attacker used) and Process Eviction (ending the running implants) in the same change window, so persistence and access disappear at the same time.
Purge shared caches and external infrastructure. Flush resolver caches after attacker DNS records are corrected, purge malicious mail, and file takedown requests for attacker domains.
Verify and monitor. Rescan, re-query and re-resolve, then watch for each removed object or indicator to reappear for an agreed period.

Rollback and safety

Registry: export each key before deletion. Microsoft documents reg delete with a /f switch that deletes without asking for confirmation, and remote use is limited to the HKLM and HKU root keys, so scripted eviction across many hosts needs a tested key list and a reviewed export.
Files: quarantine before delete where your endpoint tool supports it, so a false positive can be restored.
Email: where the mail platform offers both a recoverable delete and a hard purge, run the recoverable action first, require a second approver for large purges, and keep the action log as evidence.
Disks: wholesale eviction has no rollback. Confirm evidence capture and backups are complete and clean before you erase.

ATT&CK techniques D3FEND relates to Object Eviction

D3FEND links D3-OE to offensive techniques through the artefacts its children delete or erase, and states that these mappings are "inferred, experimental, and will improve as the knowledge graph grows". The full list is long; the table summarises it by tactic using ATT&CK v20 IDs. Read it as a list of objects eviction must find, not as coverage.

Tactic	Examples D3FEND lists (ATT&CK v20)	Child most involved
Persistence and Privilege Escalation	T1547.001 Registry Run Keys / Startup Folder, T1546.015 Component Object Model Hijacking, T1543.002 Systemd Service, T1505.003 Web Shell, T1137.003 Outlook Forms, T1037.001 Logon Script (Windows)	RKD, FEV
Stealth	T1574.001 DLL, T1036.005 Match Legitimate Resource Name or Location, T1564.002 Hidden Users, T1070.004 File Deletion	FEV, RKD
Credential Access	T1552.001 Credentials In Files, T1552.003 Shell History, T1555.003 Credentials from Web Browsers, T1556.002 Password Filter DLL	FEV, RKD
Collection	T1114.001 Local Email Collection, T1074.001 Local Data Staging, T1560.001 Archive via Utility	FEV, ER
Initial Access and Execution	T1566.001 Spearphishing Attachment, T1566.002 Spearphishing Link, T1204.002 Malicious File	ER, FEV
Command and Control	T1071.001 Web Protocols, T1573.002 Asymmetric Cryptography	DNSCE, DRT
Impact	T1561.001 Disk Content Wipe, T1561.002 Disk Structure Wipe, T1565.001 Stored Data Manipulation	DKF, DKE, DKP (rebuild after impact)

D3FEND's page still lists some techniques that ATT&CK v20 has revoked: Impair Command History Logging is now T1690 Prevent Command History Logging, and DLL Side-Loading is listed here under its v20 successor T1574.001 DLL. The child-to-technique column is our reading of which artefact each technique leaves behind. For the persistence techniques in depth see T1547 Boot or Logon Autostart Execution Defensive Guide and T1505 Server Software Component Defensive Guide.

How to verify an eviction held

Files: a full rescan with current signatures and a hash search across the estate for every evicted file hash returns nothing.
Registry: autostart locations are re-enumerated on each host and compared with a known-good baseline; any recreated value raises an alert.
Email: a re-run of the original message search returns zero items in remediable locations, and the platform's remediation log shows the action completed for each message.
DNS: after correcting the authoritative or local record, ipconfig /displaydns on Windows (or the equivalent resolver query) shows the attacker answer is gone. Microsoft notes that ipconfig /flushdns discards dynamically added entries; entries preloaded from the local Hosts file come back from the file, so check and clean the Hosts file as a file eviction task.
Domains: WHOIS or RDAP shows the domain suspended or deleted, and resolution fails from outside your network.
Disks: sanitisation is verified and recorded per device, as NIST SP 800-88 expects for a sanitisation programme.

Where identity fits

Many evicted objects carry or point to credentials: a configuration file holding an API key, a registry value with a service account password, a mailbox rule forwarding mail to an attacker. Deleting the object does not invalidate the secret. Treat every credential found inside an evicted object as compromised and rotate or revoke it as part of the same window. Attackers also persist through machine identities, for example a scheduled task running as a service account; remove the task and review that account's permissions and keys. See the T1552 Unsecured Credentials guide.

Detection and measurement

Alert on the reappearance of any evicted object or indicator, on new autostart entries on previously evicted hosts, on mail from the same sender infrastructure after a purge, and on resolution of a taken-down domain. Metrics we suggest at NHI Mgmt Group:

Re-infection rate: percentage of evicted hosts where an evicted object or related indicator returns within 30 days.
Evidence-before-eviction rate: percentage of evictions with preserved copies or hashes of every removed object.
Eviction completeness: objects removed against objects on the scoped eviction list.
Time to purge: time from first malicious message detected to purge completed across all mailboxes.
Credential follow-through: percentage of secrets found in evicted objects that were rotated in the same window.
Sanitisation records: percentage of decommissioned compromised devices with a recorded, verified sanitisation.

Framework mapping

Framework	Reference	Link to D3-OE
NIST CSF 2.0	RS.MI-01, RS.MI-02	Containment, then eradication of attacker objects
NIST CSF 2.0	PR.PS-03	Hardware removed commensurate with risk (disk children)
NIST SP 800-53 Rev. 5	IR-4 Incident Handling, SI-3 Malicious Code Protection, SI-8 Spam Protection	File, registry and email eviction
NIST SP 800-53 Rev. 5	MP-6 Media Sanitization, SC-20 Secure Name/Address Resolution Service (Authoritative Source)	Disk children and DNS record correction
ISO/IEC 27001:2022 Annex A	5.26 Response to information security incidents, 7.14 Secure disposal or re-use of equipment, 8.10 Information deletion	Eradication and disposal
MITRE D3FEND	Evict tactic siblings: Credential Eviction, Process Eviction	Run in the same window as object eviction

Common failure patterns

Deleting before preserving. The only copy of a dropper or a mailbox rule is gone before anyone records its hash, path or content, so scoping stops at the first host.
Partial eviction. The payload is removed but the Run key, scheduled task or web shell that reinstalls it remains. Web shells in particular need a full search of web roots; see the Web Shell Response Playbook.
Evicting objects while credentials stay valid. The attacker logs back in with the same keys and re-plants everything.
Flushing the cache before fixing the source. A resolver cache flushed while the poisoned upstream record or Hosts file entry remains simply caches the bad answer again.
Formatting and calling it sanitised. A quick format leaves data recoverable; disposal or reuse needs a sanitisation method matched to the media.
Waiting on takedown. Treating a registrar request as the control leaves users exposed for days; block the domain internally first. See the Typosquatting and Lookalike Domains Guide.

Practitioner checklist

Map each of the eight D3-OE children to a tool, an owner and a documented procedure.
Preserve copies or hashes of every object before eviction.
Build a single scoped eviction list across hosts, mailboxes, registry, DNS and domains.
Run object, credential and process eviction in the same change window.
Export registry keys and quarantine files before deletion so false positives can be restored.
Reimage rather than clean when the attacker held kernel or SYSTEM-level control.
Sanitise reused or disposed devices to NIST SP 800-88 and record the result.
Verify each eviction and monitor for reappearance for at least 30 days.

MITRE D3FEND Object Eviction Implementation Guide: Choosing, Sequencing and Verifying Eviction Actions