A quarantine is only as safe as its release process: most quarantine failures are files released by the wrong person, too fast, without a second look. MITRE D3FEND defines Content Quarantine (D3-CQ) as "Transfer content that does not comply with policy to a quarantine zone." It sits under the Isolate tactic as a child of Content Filtering (D3-CF), alongside Content Modification and Content Validation, and D3FEND says it quarantines two artefacts: File and Database Record. This card covers what D3FEND says, the ATT&CK techniques it relates, how quarantine works in mail, endpoint and application pipelines, how to design release and retention, and how to prove the quarantine holds. Platforms are listed alphabetically where named; the product notes describe customer-side settings.
Key takeaways
- Quarantine buys time for analysis. D3FEND describes it as a protective measure that isolates potentially harmful files or elements until they can be safely analysed or processed. It is the holding step between detection and a decision.
- Release rights are the control. Who can release which category of content, with what review, matters more than where the quarantine lives.
- Retention is a deadline. Mail platforms delete quarantined items after a fixed period; investigations and false positive reviews must finish inside it, or a copy must be preserved.
- Data, not only files. D3FEND includes Database Record: records that fail policy in an ingestion pipeline belong in a quarantine table or queue, not in production tables or the bin.
- The quarantine store is sensitive. It holds live malware and often confidential mail. Access, encryption and audit apply as for any evidence store.
D3-CQ at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-CQ (d3f:ContentQuarantine) |
| Definition | "Transfer content that does not comply with policy to a quarantine zone." |
| Tactic | Isolate (through the parent Content Filtering) |
| Parent technique | Content Filtering (D3-CF) |
| Digital artefacts | Quarantines File; quarantines Database Record; filters File and enforces Content Policy (inherited) |
| D3FEND reference | OPSWAT patent application US20190268352A1, "Method For Content Disarm and Reconstruction" |
| Siblings | Content Modification (D3-CM), Content Validation (D3-CV) |
| Related eviction technique | File Eviction (D3-FEV), which removes a file rather than holding it |
How it works
A detection or policy check decides that content does not comply. Instead of delivering it or deleting it, the system moves it to a store the user cannot reach, records why, and waits for a decision: release, delete, or keep as evidence. Quarantine differs from D3-FEV File Eviction in that the content is preserved and reversible; it differs from D3-CM Content Modification in that nothing reaches the user until a decision is made.
Quarantine across channels
| Channel | What is quarantined | Examples from documentation |
|---|---|---|
| Messages and attachments failing malware, phishing, spam or content rules | Google Workspace email quarantine (Moderation Tool); Microsoft Defender for Office 365 quarantine | |
| Endpoint and file servers | Files detected by anti-malware scanning, held in a protected folder | ClamAV --move and --copy; Microsoft Defender Antivirus quarantine |
| Collaboration storage | Files in shared libraries detected as malicious, blocked from opening | Mail platform protections extended to shared storage, where licensed |
| Upload and transfer services | Uploads awaiting scanning or failing validation, held in a separate bucket or path | Application design; the OWASP File Upload Cheat Sheet recommends scanning uploads with antivirus or a sandbox before use |
| Data pipelines | Records failing schema or content checks, held in a quarantine table or dead-letter queue | Pipeline design; D3FEND's Database Record artefact |
Platform notes (alphabetical)
ClamAV. The ClamAV scanning documentation describes --move=DIRECTORY and --copy=DIRECTORY to place infected files in a quarantine directory, and warns that --remove is generally a bad idea except on monitored upload or download directories. With a running daemon, the move or copy action is performed by clamdscan, not clamd. The documentation suggests pairing quarantine with the clamd VirusEvent feature so detections notify someone. On-access scanning through ClamOnAcc defaults to notify-only; prevention mode blocks access and the documentation warns of performance impact on busy directories.
Google Workspace. Email quarantine is part of the Moderation Tool and is set up by super administrators. Every account has a default quarantine and admins can create custom quarantines, restrict them to groups and enable periodic admin notifications. Admin console settings decide which messages are quarantined, for example incoming messages with suspicious attachments or outgoing messages with confidential information. Admins can release a message or block it, optionally notifying the sender. Google states that quarantined messages are kept up to 30 days and then permanently deleted, with copies possibly remaining in Google Vault under its own retention. See the Google Workspace Security Guide.
Microsoft. In Defender for Office 365, malware and high-confidence phishing are always quarantined. Quarantine policies define what users can do and whether they are notified; users cannot release their own messages quarantined as malware or as high-confidence phishing, and can at most request release. Microsoft documents a 30-day retention for malware and Safe Attachments detections, and a default of 15 days for anti-spam detections in default and custom policies (adjustable from 1 to 30 days), after which messages are permanently deleted. All admin and user actions on quarantined messages are audited. For endpoints, Microsoft Defender Antivirus quarantined items can be listed with MpCmdRun.exe -Restore -ListAll and restored by name or through Protection history in Windows Security. See the Microsoft Defender Antivirus guide.
ATT&CK techniques D3FEND relates to D3-CQ
Relationship type: inferred only. D3FEND derives these rows from the File artefact that D3-CQ quarantines and its parent filters. It labels them "inferred, experimental" (D3FEND 1.6.0, checked November 2026); the same list appears for the other Content Filtering techniques. Each ID was checked against ATT&CK v20.
| ATT&CK tactic (v20) | Techniques D3FEND relates through the File artefact |
|---|---|
| Initial Access | T1566.001 Spearphishing Attachment, T1566.002 Spearphishing Link, T1566.003 Spearphishing via Service |
| Execution | T1204.002 Malicious File, T1072 Software Deployment Tools, T1127.001 MSBuild |
| Persistence and Privilege Escalation | T1037.001 to T1037.004 logon, network logon and RC scripts and Login Hook; T1546.002, .004, .005, .006, .008, .009, .010, .013, .014, .015 event triggered execution; T1547.001, .006, .007, .008, .009 autostart execution; T1543.001, .002, .004 Launch Agent, Systemd Service, Launch Daemon; T1137.001 Office Template Macros, T1137.003 Outlook Forms; T1505.003 Web Shell; T1548.002 Bypass User Account Control, T1548.003 Sudo and Sudo Caching |
| Stealth | T1055.001, .002, .003, .009, .014 process injection; T1218.005 Mshta, T1218.011 Rundll32; T1574.001, .004, .006, .007, .008, .009, .012 hijack execution flow; T1036.001 Invalid Code Signature, T1036.003 Rename Legitimate Utilities, T1036.005 Match Legitimate Resource Name or Location, T1036.006 Space after Filename; T1027.001 Binary Padding, T1027.002 Software Packing, T1027.004 Compile After Delivery; T1564.002, .003, .006, .007 hide artefacts; T1070.004 File Deletion |
| Defense Impairment | T1556.002 Password Filter DLL, T1556.003 Pluggable Authentication Modules; T1647 Plist File Modification; T1685.006 Clear Linux or Mac System Logs; T1690 Prevent Command History Logging |
| Credential Access | T1555.003 Credentials from Web Browsers, T1003.007 Proc Filesystem, T1003.008 /etc/passwd and /etc/shadow, T1552.001 Credentials In Files, T1552.003 Shell History |
| Discovery and Collection | T1083 File and Directory Discovery, T1005 Data from Local System, T1119 Automated Collection, T1074.001 Local Data Staging, T1114.001 Local Email Collection, T1560.001 to T1560.003 Archive Collected Data |
| Command and Control, Exfiltration | T1071.001 Web Protocols, T1573.002 Asymmetric Cryptography, T1048.002 Exfiltration Over Asymmetric Encrypted Non-C2 Protocol |
| Impact | T1565.001 Stored Data Manipulation, T1565.003 Runtime Data Manipulation |
D3FEND still lists some IDs that ATT&CK v20 has revoked; the table shows the successors: Plist Modification is now T1647 Plist File Modification, DLL Side-Loading is folded into T1574.001 DLL, Clear Linux or Mac System Logs is now T1685.006, and Impair Command History Logging is now T1690 Prevent Command History Logging. D3FEND also lists Launchd, which ATT&CK v20 marks deprecated with no successor, so it is left out.
Where quarantine genuinely helps (NHI Mgmt Group view): delivery and staging. Attachments behind T1566.001 and malicious files behind T1204.002 never reach the user, and web shells (T1505.003) or staged archives (T1074.001, T1560.001) found by a scan are preserved for analysis instead of deleted. That preservation is the main reason to quarantine rather than evict. See MITRE ATT&CK T1566 Phishing.
Designing release and retention
| Category | Who may release (example policy, not a standard) | Evidence before release |
|---|---|---|
| Confirmed malware | Nobody; keep as evidence or delete after the incident closes | Not applicable |
| Phishing, high confidence | Security team only, after analysis | Header and URL analysis, sender verification |
| Encrypted or unscannable attachments | Security team, or user-supplied password triggering a rescan where the platform supports it | Rescan result |
| Spam and bulk | User self-release | None beyond the platform's checks |
| Data loss prevention matches (outbound) | Data owner or compliance reviewer | Business justification recorded |
| Failed records in pipelines | Data owner after correction | Fixed record re-validated before re-ingestion |
- Preserve before expiry: when an item is part of an incident, export it (hash, headers, the file in a password-protected archive) to your evidence store; platform deletion after the retention period is permanent.
- Protect the store: restrict quarantine access to named roles, record every view, download and release, and keep quarantine paths on endpoints and servers outside user write access.
- Notify the right people: admins on new high-severity items, users on items they may act on, never senders of confirmed malicious content.
Rolling it out
- Map every detection to an action. For each control (mail filtering, endpoint scanning, upload scanning, DLP), state whether it blocks, modifies, quarantines or evicts.
- Write the release matrix. Use a table like the one above, approved by security and the business.
- Configure platform policies to match. Release rights, notifications and retention where adjustable.
- Connect to the SOC. Forward quarantine and release events to the SIEM so a release of a later-confirmed malicious item can be traced.
- Pilot user self-release for low-risk categories with one group and track requests.
- Roll back a misfiring rule by releasing its items in bulk after review, then fixing the rule; never by turning quarantine off.
How to verify it works
- Test file: send the EICAR anti-malware test file, or a safe file built to match a test rule, through each channel and confirm it lands in quarantine, is logged and raises the expected alert.
- Release rights: as a standard user, try to release a test item in a malware category and confirm the platform allows only a request.
- Endpoint path: confirm quarantined files cannot be executed or read by the user, and that restore requires administrative rights.
- Pipeline path: inject a malformed record and confirm it reaches the quarantine table, not production, and appears in monitoring.
- Retention drill: check that an incident item can be exported before the platform deletes it.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | Why it matters |
|---|---|---|
| Released items later confirmed malicious | Zero; each one reviewed | Direct measure of release quality |
| Median time to decision on items held for review | Within one working day | Long holds push users to work around the control |
| Quarantine events reaching the SIEM | 100% of channels | Unlogged quarantines cannot be investigated |
| Items expiring while linked to an open incident | Zero | Lost evidence |
| False positive rate per rule | Tracked; noisy rules tuned | Keeps release volumes manageable |
Limits, bypasses and failure patterns
- Self-release of dangerous categories: allowing users to release phishing or unscannable attachments turns quarantine into a speed bump.
- Silent deletion of evidence: retention runs out during a slow investigation. Export first.
- Scope gaps: some messages cannot be quarantined at all; Google notes messages sent to Groups and messages to or from suspended accounts, and Microsoft notes that forwarded messages to unprotected recipients are delivered without Safe Attachments scanning. Know your exceptions.
- Delete instead of quarantine: using remove actions on endpoints destroys what an investigator needs and makes false positives unrecoverable.
- Quarantine store exposure: a world-readable quarantine directory or a shared admin account for releases turns the store into a malware library and hides who released what.
- Detection quality: quarantine holds only what a detection catches. It depends on scanning and analysis such as D3-FCOA File Content Analysis.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-3 Malicious Code Protection | Quarantining malicious code as a response action |
| NIST SP 800-53 Rev 5 | IR-4 Incident Handling | Preserving quarantined items as evidence |
| NIST SP 800-53 Rev 5 | SI-4 System Monitoring | Quarantine and release events as monitored events |
| NIST CSF 2.0 | DE.CM-09, DE.AE-02 | Monitoring content and analysing adverse events |
| MITRE ATT&CK mitigation | M1049 Antivirus/Antimalware | Closest mitigation (NHI Mgmt Group view); see M1049 Antivirus/Antimalware |
| MITRE D3FEND | D3-CF, D3-CQ | Parent and technique |
Practitioner checklist
- Decide per detection whether to block, modify, quarantine or evict.
- Approve a release matrix by category and enforce it in every platform.
- Prevent user self-release of malware, high-confidence phishing and unscannable items.
- Forward quarantine and release events to the SIEM.
- Export incident-linked items before platform retention expires.
- Restrict and audit access to quarantine stores and paths.
- Use quarantine tables or dead-letter queues for failed data records.
- Test each channel monthly with a safe test file.
Standards and references
- MITRE D3FEND: Content Quarantine (D3-CQ)
- OPSWAT: Method For Content Disarm and Reconstruction (US20190268352A1)
- NIST: SP 800-53 Rev 5, Security and Privacy Controls
- ClamAV: Scanning
- Google Workspace: Set up email quarantine
- Microsoft: Quarantined email messages in EOP and Defender for Office 365
- Microsoft: Restore quarantined files in Microsoft Defender Antivirus
- OWASP: File Upload Cheat Sheet
Related NHI Mgmt Group resources: D3-CM Content Modification, D3-CV Content Validation, D3-FEV File Eviction, Email Security Guide.