Deleting the malware file you found is the easy part; the hard part is finding every copy, keeping a sample for the investigation, and making sure the file is not quietly put back by a persistence mechanism you missed. MITRE D3FEND names this countermeasure File Eviction (D3-FEV) and defines it as "File eviction techniques delete files from system storage." It sits under the Evict tactic as a child of Object Eviction (D3-OE), and has one child of its own, Email Removal (D3-ER). This card covers what D3-FEV changes, the long list of ATT&CK techniques D3FEND relates to it, how endpoint tools implement it through quarantine, and how to prove a file is gone and stays gone. It is written for incident responders and endpoint engineers who already run an endpoint protection platform; the EDR Guide covers the tooling itself.
Key takeaways
- Quarantine first, delete second. D3FEND's own guidance is to let antivirus software quarantine a suspected file, verify it is not benign, and only then delete it permanently.
- Preserve before you evict. D3FEND notes the organisation may prefer to quarantine the file to a secure system so security staff can investigate. A sample, its hash and its path are the evidence for scoping every other host.
- Ordinary deletion is not eviction. D3FEND points out that deleting in File Explorer only moves a file to the Recycle Bin, and that data can persist on disk even after that is emptied.
- Remove the reason the file came back. Most files in D3FEND's mapping are persistence and hijacking artefacts; removing the payload while a Run key, service or scheduled job remains invites reinfection.
- Prove it with a sweep and a block. Search the whole estate for the hash and path afterwards, and add a block indicator so a returning copy is stopped and alerted on.
D3-FEV at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-FEV (d3f:FileEviction) |
| Tactic | Evict |
| Parent technique | Object Eviction (D3-OE), "the broadest class for object eviction" |
| Child technique | Email Removal (D3-ER) |
| Digital artefact | File (relation: deletes); the D3FEND page also shows may-access Mail Server, from its Email Removal child |
| D3FEND reference | Safety Detectives, "How Does Antivirus Quarantine Work?" (internet article) |
| What it changes | Removes malicious files and deceptive content files (such as phishing documents) from storage |
| Main limitation | Removes the file, not running processes, registry or service entries, or credentials the file already stole |
How it works
D3FEND describes the problem plainly: adversaries place files or programs on a host to perform malicious actions, and as part of eviction those files should be removed to prevent further compromise or reinfection. It names two kinds: malware that is directly harmful, and content files meant to deceive users, such as phishing documents.
The workflow D3FEND describes has three stages.
- Quarantine: the antivirus moves the file from its original location to a protected location and changes it so it cannot execute. D3FEND's cited article describes the same: the file is moved to a secure folder, altered so it cannot run, and then held until someone decides to delete, restore or submit it for analysis.
- Verify: an analyst confirms the file is malicious (hash reputation, sandbox detonation, scope across the estate) rather than a false positive.
- Delete or retain: the file is deleted permanently, or retained in a secure evidence store if the investigation needs it. D3FEND notes data can persist on disk after deletion and that data shredder tools may be needed to wipe a file completely; for whole media, NIST SP 800-88 Rev. 2 covers sanitisation.
The parent technique, Object Eviction (D3-OE), covers the wider eviction family, including process, registry and credential eviction; this page stays with files.
ATT&CK techniques D3FEND relates to D3-FEV
Relationship type: inferred only. D3FEND marks these mappings "inferred, experimental" and derives them from the File artefact, because each technique creates, modifies or uses a file (checked November 2026). The list is long, so it is grouped by the role the file plays. Each ID was checked against ATT&CK v20.
| File role | ATT&CK techniques (v20 IDs) | What eviction must also remove |
|---|---|---|
| Delivered payload or lure | T1204.002 Malicious File; T1566.001 Spearphishing Attachment, T1566.002 Spearphishing Link, T1566.003 Spearphishing via Service | Every downloaded and cached copy, plus the email (see D3-ER) |
| Autostart and logon persistence | T1547.001 Registry Run Keys / Startup Folder, T1547.006 Kernel Modules and Extensions, T1547.007 Re-opened Applications, T1547.008 LSASS Driver, T1547.009 Shortcut Modification; T1037.001, T1037.002, T1037.003, T1037.004 logon and RC scripts; T1543.001 Launch Agent, T1543.002 Systemd Service, T1543.004 Launch Daemon | The registry value, service unit, launch plist or script line that points at the file |
| Event-triggered execution | T1546.002, T1546.004, T1546.005, T1546.006, T1546.008, T1546.009, T1546.010, T1546.013, T1546.014, T1546.015 | The trigger configuration (screensaver setting, shell profile, trap, AppInit or AppCert entry, COM registration) |
| Hijacked execution flow | T1574.001 DLL, T1574.004 Dylib Hijacking, T1574.006 Dynamic Linker Hijacking, T1574.007, T1574.008, T1574.009 path interception, T1574.012 COR_PROFILER | The planted library and any environment variable or search path change |
| Server and application components | T1505.002 Transport Agent, T1505.003 Web Shell; T1137.001 Office Template Macros, T1137.003 Outlook Forms | Server registration of the component; for web shells, the vulnerability that allowed the upload |
| Authentication tampering | T1556.002 Password Filter DLL, T1556.003 Pluggable Authentication Modules | The registration of the module, then rotation of credentials that passed through it |
| Masquerading and hiding | T1036.001, T1036.003, T1036.005, T1036.006; T1564.002, T1564.003, T1564.006, T1564.007; T1027.001, T1027.002, T1027.004 | Look-alike copies in other paths; hidden users or virtual machines the files belong to |
| Injection and proxy execution | T1055.001, T1055.002, T1055.003, T1055.009, T1055.014; T1218.005 Mshta, T1218.011 Rundll32; T1127.001 MSBuild | The running process (process eviction) as well as the file on disk |
| Collection and staging | T1074.001 Local Data Staging; T1560.001, T1560.002, T1560.003 archives; T1114.001, T1114.002 email collection | Staged archives, after preserving them to scope what was taken |
| Credential files | T1552.001 Credentials In Files, T1552.003 Shell History, T1555.003 Credentials from Web Browsers, T1003.007 Proc Filesystem, T1003.008 /etc/passwd and /etc/shadow | Not the file itself in most cases: rotate the exposed credentials |
| Privilege abuse, tampering and impact | T1548.002 Bypass User Account Control, T1548.003 Sudo and Sudo Caching; T1070.004 File Deletion; T1565.001 Stored Data Manipulation, T1565.003 Runtime Data Manipulation | Restore altered files from known good copies |
| Command and control and exfiltration tooling | T1071.001 Web Protocols, T1573.002 Asymmetric Cryptography, T1048.002 Exfiltration Over Asymmetric Encrypted Non-C2 Protocol | Implant configuration files and keys; block the infrastructure |
D3FEND still lists five IDs that ATT&CK v20 has revoked or deprecated. Their current equivalents are: Plist Modification is now T1647 Plist File Modification; DLL Side-Loading is now part of T1574.001 DLL; Clear Linux or Mac System Logs is now T1685.006; Impair Command History Logging is now T1690 Prevent Command History Logging. Launchd under Scheduled Task/Job is deprecated in v20 with no successor and is omitted.
The useful reading of this table is the third column: for most rows the file is only half of the eviction. The technique pages go deeper, for example the T1547 Boot or Logon Autostart Execution Defensive Guide, the T1574 Hijack Execution Flow Defensive Guide and the T1036 Masquerading Defensive Guide.
Where it is implemented
| Implementation class | What it does | Fits when |
|---|---|---|
| Antivirus automatic quarantine | Detects on write or execution and quarantines without an analyst | Known malware; the baseline on every host |
| EDR response action | Analyst-initiated stop and quarantine across many hosts, with action tracking | A file confirmed during an investigation that is present on several devices |
| Block indicator by hash | Prevents the file being read, written or executed anywhere it reappears | After eviction, to stop reintroduction |
| Live response or remote shell | Manual collection and removal on one host | Files the agent does not classify, such as scripts and web shells |
| Configuration management | Enforces the absence of a file or the known-good state of a directory | Servers and fleets where drift detection is already in place |
| Reimage | Replaces the whole system from a known-good image | Deep compromise, kernel components or low confidence in scoping |
Example: Microsoft Defender for Endpoint
Microsoft documents one implementation of these classes in detail, used here as an example. The "Stop and Quarantine File" action stops running processes, quarantines the file and deletes persistent data such as registry keys. It applies to devices where the file was seen in the last 30 days, up to 1,000 devices per action, with a delivery timeout of 3 days for offline devices; Microsoft recommends a block indicator for larger scopes or long-offline devices. Results appear in the Action center as Success, Failed and Pending. "Download file" collects a password-protected archive of a quarantined file for analysis, and "Add indicator" blocks a portable executable by hash. On the device, Microsoft Defender Antivirus lists quarantined items with MpCmdRun.exe -Restore -ListAll and restores one with -Restore -Name. Availability: Microsoft states these response actions apply to Defender for Endpoint Plan 2, with some manual actions in Plan 1. For the product itself, see the Microsoft Defender Antivirus guide.
Implementation steps
- Collect before removing. Capture the file, its hash, full path, owner, timestamps and the process that wrote it. Keep a copy in an evidence store with restricted access.
- Scope by hash and path. Search every endpoint and server for the same hash, file name and directory pattern. Masquerading files often reuse legitimate names in unusual paths, so search by both.
- Find what launches it. For each host, list autostart entries, services, scheduled jobs, shell profiles and server components that reference the file.
- Contain, then evict together. Isolate the host if needed, stop the process, then remove the file and its launch mechanism in the same change window so neither restores the other.
- Quarantine, verify, delete. Use the platform's quarantine action, confirm the verdict, then delete permanently or move to the evidence store. Avoid plain user-level deletion, which may leave a recoverable copy.
- Block reintroduction. Add a hash block indicator and, where the file came in through a weakness (an upload form, a phishing attachment), close that path.
- Rotate exposed credentials. If the file held or harvested credentials, rotate them; deleting a stolen secret's copy does not make it secret again.
- Roll back a false positive. Restore from quarantine on each affected device, record the reason, and add a narrow allow entry rather than a broad exclusion.
Where identity fits
Many files that matter to attackers are credential stores for non-human identities: cloud credential files, kubeconfig files, private keys and environment files read under T1552.001. Evicting malware that read them closes one door but leaves the secrets in the attacker's hands. Treat any file eviction where credential files were in reach as a trigger to rotate those service account keys and tokens, as covered in the MITRE ATT&CK T1552 Unsecured Credentials Guide.
How to verify it works
- Estate-wide sweep: rerun the hash and path search after eviction; the expected result is zero hits outside quarantine and the evidence store.
- Action results: review failed and pending results for every device and follow up each one, especially devices that were offline.
- Persistence re-check: after a reboot, confirm no autostart entry, service or job references the old path and that the file has not reappeared.
- Block test: confirm the hash indicator is active by checking it appears in policy on a sample of devices, and watch for block alerts that show reintroduction attempts.
- Watch period: keep heightened monitoring on evicted hosts for a defined period, for example 30 days (an NHI Mgmt Group suggestion, not a standard).
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | Why it matters |
|---|---|---|
| Evictions with a preserved sample and hash | 100% | Scoping and later attribution depend on it |
| Hosts with the file after the eviction sweep | Zero | Direct proof the file is gone |
| Reinfections on evicted hosts within 30 days | Zero | Shows the launch mechanism was removed too |
| Time from confirmed verdict to estate-wide quarantine | Tracked per incident, falling over time | Speed of eviction once the decision is made |
| Restores due to false positives | Tracked monthly | Shows whether verification before deletion is working |
Limits, bypasses and failure patterns
- Deleting the only sample: eviction before collection leaves no hash to sweep for and no sample to analyse.
- Payload removed, launcher left: a Run key, service or web server component that downloads the file again restores it on the next boot or request.
- Fileless and in-memory stages: injected code and running processes survive file deletion. Pair file eviction with process eviction and a reboot or isolation.
- Look-alike copies: masquerading files with legitimate names in other paths are missed by path-only searches.
- Web shells without the root cause: removing a web shell while the upload flaw remains open invites a new one. See the Web Shell Response Playbook.
- Exclusions as a fix: a broad folder exclusion added to stop a false positive creates a place where real malware is never scanned.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-3 Malicious Code Protection | Detection, quarantine and removal of malicious code |
| NIST SP 800-53 Rev 5 | IR-4 Incident Handling | Eradication as part of incident handling |
| NIST SP 800-53 Rev 5 | MP-6 Media Sanitization | Where deleted data must not be recoverable from storage |
| NIST CSF 2.0 | RS.MI-01, RS.MI-02, RS.AN-03 | Containment, eradication, and analysis of what happened |
| NIST SP 800-61 Rev. 3 | Incident response as a CSF 2.0 Community Profile | Places eviction inside the response life cycle |
| MITRE ATT&CK mitigation | M1049 Antivirus/Antimalware | The mitigation that provides automatic quarantine |
| MITRE D3FEND | D3-OE, D3-FEV, D3-ER | Hierarchy from object eviction to file and email removal |
Related countermeasures
- Email Removal (D3-ER): the child technique for mail stores. See D3-ER Email Removal.
- Registry Key Deletion (D3-RKD): removes the registry persistence that often launches an evicted file. See D3-RKD Registry Key Deletion.
- Process Termination (D3-PT): stops the running instance before the file is removed.
- Restore File (D3-RF): brings back known-good copies of files the attacker altered or deleted.
- File Hash Reputation Analysis (D3-FHRA): supplies the verdict before deletion. See D3-FHRA File Hash Reputation Analysis.
Practitioner checklist
- Collect the file, hash, path and writing process before any removal.
- Sweep the estate by hash and by name and path pattern.
- List and remove every launch mechanism that references the file.
- Quarantine, verify the verdict, then delete or move to the evidence store.
- Follow every failed and pending action result, including offline devices.
- Add a hash block indicator and close the entry path.
- Rotate credentials that were stored in or reachable by the file.
- Re-check persistence after reboot and monitor evicted hosts for a set period.
- Restore false positives with narrow allow entries, never broad exclusions.
Standards and references
- MITRE D3FEND: File Eviction (D3-FEV)
- Safety Detectives: How Does Antivirus Quarantine Work?
- NIST: SP 800-61 Rev. 3 Incident Response Recommendations and Considerations for Cybersecurity Risk Management
- NIST: SP 800-88 Rev. 2 Guidelines for Media Sanitization
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- Microsoft Learn: Take response actions on a file
- Microsoft Learn: Restore quarantined files in Microsoft Defender Antivirus
Related NHI Mgmt Group resources: Incident Response Guide · EDR Guide · M1049 Antivirus/Antimalware · T1070 Indicator Removal Defensive Guide · MITRE D3FEND Guide