Monitor & Respond - Email Quarantine Queue

Role Requirements

Procedure Scope: Administrators

Required Group Membership: Admin.Security

Handbook Reference

Package: Email Security

Domain: Email

Modifies: Quarantine Queue

When to Perform this Operation

Twice a day: Key times such as 8am and 2pm.

Analyst Description and Importance

The Defender for Email Quarantine Queue serves as a dedicated space where emails that pose as potential security threats or are deemed unwanted are held. This empowers analysts with the capability to inspect, release, delete, or take no action on emails in the queue. Analysts can use the message data to determine the right course of action for each of these emails to make sure emails with malicious intent are not incorrectly released. The twice daily review of the quarantine queue is crucial to minimize the disruption that could be caused by a legitimate email being incorrectly held in the queue, ensuring the emails in the queue are held appropriately and those which are not are reliably released to recipients.

Security Importance:  

Monitoring and responding to the quarantine queue ensures potentially dangerous or unwanted messages are not released to users, helping to mitigate the security risk of high confidence phishing and malware.

Business Importance: 

Monitoring and responding to the quarantine queue ensures legitimate business email is not held up in the queue, helping to mitigate the business risk of critical email being held by an inaccurate scanning verdict.

Covered in this Operation

In the context of managing the email quarantine queue, training goes beyond simply knowing how to release emails. Analysts need the ability to identify significant emails, understand the security information tied to each entry, and comprehend the detection methods in use.

This knowledge enables analysts to process large volumes of data efficiently while maintaining accuracy and quality in decision-making. Effective training here isn’t about overanalyzing each item—it’s about building the judgment needed to handle emails confidently, based on context and security insights, ensuring the queue is managed smoothly and inboxes remain secure.

Identifying Notable Emails

The rules below work as the schema to identify a notable email which could be either incorrectly held which would need release, or malicious emails which may be notable for the organization.

Subject Lines

• If the subject explicitly references common business operations (e.g., "Invoice," "Meeting Recap," "Project Update").
• If the subject contains urgent or pressuring language.
• If an email's subject line matches common themes of recent cyber threats identified in industry alerts (e.g., security updates).

Sender's Addresses

• If the sender's domain is recognized as a legitimate and reputable business domain.

• If the sender’s domain closely resembles a known business but with slight anomalies (e.g., misspellings, additional characters).
• If the sender’s domain closely resembles or matches the organizations name.
• If the sender’s email address format follows a typical business pattern (e.g., [firstname].[lastname]@[company].com) as opposed to a random or generic format.

Policy Categorizations

• If the email is identified as containing malicious files.
• If the email is identified as anti-phishing.
• If the email is identified as spam but the subject is relevant to typical business or industry activities.
• If the email is tagged under a category but contradicts the typical characteristics of that category (e.g., a 'spam' tag but with a clear, professional subject line).

Understanding Email Security Information

When an email is clicked into, useful information becomes available. This can be used for the analysis of primary indicators.

Quarantine details section:

• Received: The date/time when the message was received.
• Expires: The date/time when the message is automatically and permanently deleted from quarantine.
• Subject: The subject of the email.
• Quarantine reason: Shows if a message has been identified as Spam, Bulk, Phish, matched a mail flow rule (Transport rule), or was identified as containing Malware.
• Policy type: The threat policy category that the email failed compliance for.
• Policy name: The name of the policy that has been triggered.
• Recipient count: The number of recipients that the mail has been sent to.
• Recipients: The specific addresses associated with the recipient. If the message contains multiple recipients, you might need to use Preview message or View message header to see the complete list of recipients.
• Released to: All email addresses (if any) to which the message has been released.

Delivery details section:

• Threats: General detection of email threats using technologies such as phishing, spam, or malware.
• Delivery Action: System actions based on detection, including Delivered, Junked, and Blocked.
• Original Location: Initial delivery or detection location, such as Inbox folder, Junk Email folder, Quarantine, or External.
• Latest Delivery Location: Post-action location of the message, updated after actions like ZAP or admin interventions; includes Inbox, Quarantine, Deleted Items, etc.
• Detection Technologies: Technologies used to identify threats, including Advanced filter, Campaign, File detonation, Impersonation user, and URL detonation.
• Primary Override: Actions due to policy or user/admin override, with options like Allowed by organization policy, Blocked by user policy, and sources including Antispam policy settings and Tenant Allow/Block List.

Email details section:

• Sender display name: Display name associated with the sender, portion of the from section that does not include the [@] domain portion.
• Sender address: Address associated with the sender, if the display name and the address do not match or follow a similar formatting this can be an indicator of something suspicious.
• SMTP Mail From address: Indicates the address used by the mail client or application.
• Sent on behalf of: Indicates that the mail was sent from another user, this will bring awareness to who initiated the message send.
• Return path: Used to verify the identity of where the email originated from, if this address differs from the SMTP Mail from Address, this could be an indicator of something suspicious.
• Sender IP: The IP address associated with sender.
• Location: The location based on the associated IP address.
• Recipients: The address associated with the recipient.
• Time received: Provides the Date and Time the message was received.
• Directionality: Specifies if the mail is inbound or outbound.
• Network message ID: A network message id is a unique identifier for a digital message, most commonly an email. It is generated by the sending mail server or host and has a specific format that is a subset of an email address. The message id can contain the name and location of the server that generated it and can be used to trace the message hops in the internet header.
• Internet message ID: A unique identifier that refers to a particular version of a particular message.
• Campaign ID: A unique number used to calculate the success and allows for reporting on groups of campaigns.
• DMARC: Domain-based Message Authentication Reporting and Conformance (DMARC) tells a receiving email server what to do given the results after checking SPF and DKIM. A domain's DMARC policy can be set in a variety of ways — it can instruct mail servers to quarantine emails that fail SPF or DKIM (or both), to reject such emails, or to deliver them. A success or fail will be applied to this section based on the result of the DMARC check.
• DKIM: DomainKeys Identified Mail (DKIM) enables domain owners to automatically "sign" emails from their domain. DKIM uses public key cryptography; a DKIM record stores the domain's public key, and mail servers receiving emails from the domain can check this record to obtain the public key, the private key is kept secret by the sender, who signs the email's header with this key, Mail servers receiving the email can verify that the sender's private key was used by applying the public key. A success or fail will be applied to this section based on the result of the DKIM check.
• SPF: Sender Policy Framework (SPF) is a way for a domain to list all the servers they send emails from. SPF records list all the IP addresses of all the servers that are allowed to send emails from the domain, mail servers that receive an email message can check it against the SPF record before passing it on to the recipient's inbox. A success or fail will be applied to this section based on the result of the SPF check.
• Composite authentication: Helps identify spoofed senders and phishing emails when senders do not use SPF, DKIM, and DMARC authentication.

URLs section:

• URL: Provides a list of all URLs that were housed within the email.
• Threat: Indicates if any of the housed URLs show signs of being malicious or compromised.

Attachments section:

• Attachment name: Provides the name of the attachment.
• Threat: Indicates if any of the provided attachments are malicious.
• Detection tech/Malware family: Provides additional information on the type of malware that might be present within the attachment.

Understanding Email Detection Technologies

Understanding “Spam”, “Phish”, or “Malware” is only the general determination. The delivery details section specifies the status of the emails, but since this is the quarantine queue, we only need to focus on the detection technologies line item. Use this section to determine the exact reason for the hold and align the email security information and context activities to investigate this determination. For Microsoft’s verbatim definitions of these, view the knowledge article here.

Analyzing Email Security Context

For each analysis, the primary indicators should be analyzed to determine the technical legitimacy and any alignment with common email threats. Informed by the detection technology, investigation of these items will contribute to the overall legitimacy of the hold and any determination of false positives. Validation of these indicators against contextual data from headers and message content can be performed in the subsequent step with the aim to validate results found from this primary indicator analysis.

Subject Line:

• Urgency or fear-inducing language ("Immediate action required", "Alert", "Notice").
• Grammatical errors, odd phrasing, or unusual formatting.
• Relevance and consistency with expected communication themes.

Recipient Tag:

• If tagged as a "Priority account," extra scrutiny is needed since such accounts are often targets of focused attacks.

Sender Information:

• Compare the sender's display name and email address for mismatches or suspicious similarities to known brands (e.g., "Micros0ft" instead of "Microsoft").
• Check if the return path or sender email match the receiving organizations domain, indicating a phishing attempt or 3^rd party mailer utilizing the domain space.
• Check the return path and sender email address for discrepancies that could indicate masking or redirection.

Directionality:

• Identify is the directionality of Inbound, Intra-org, or Outbound align with the claims made by the sender and recipient, specifically to differentiate inbound phishing attempts from intra-org communications.

Campaign ID:

• Identify if the email is part of a larger campaigned, denoted by a campaign identifier.

Authentication Results:

• Verify DMARC, DKIM, and SPF results. Any failures here are significant red flags for domain spoofing or misuse.

URL Examination:

• Check for shortened URLs that might mask malicious sites.
• Look for URLs that misspell well-known domain names.
• Optional: Perform a URL analysis via a 3^rd party to assess any links flagged as suspicious to confirm if they are known for hosting malware or phishing schemes.

Attachment Review:

• Identify file types; be wary of executable files (.exe, .scr) or documents with macros (.docm, .xlsm).
• Check the detection technology or malware family associated with any attachments flagged as suspicious to understand the specific threat they might pose.

Recognize when to Release and Allow for 30 Days

These are emails that are essential to business operations and allowing similar messages for 30 days helps prevent disruptions due to repeated false positives. Additionally, performing this action will submit to Microsoft and nearly always results in similar emails being allowed in the future, even past 30 days, as they update their scanning engine.

• Business Deals: Details about negotiations, contracts, or agreements.
• Internal Communications: Daily operations, meetings, or internal announcements from colleagues or departments.
• Client Communications: Project updates, feedback, or requests from clients or stakeholders.

Recognize when to Release and Allow

These are emails that are essential to business operations and allowing similar messages for 30 days helps prevent disruptions due to repeated false positives. Additionally, performing this action will submit to Microsoft and nearly always results in similar emails being allowed in the future, even past 30 days, as they update their scanning engine.

• Business Deals: Details about negotiations, contracts, or agreements.
• Internal Communications: Daily operations, meetings, or internal announcements from colleagues or departments.
• Client Communications: Project updates, feedback, or requests from clients or stakeholders.
• Technical and IT Alerts: Notifications related to IT maintenance, system outages, or security alerts.
• HR Communications: Updates on policy changes, employee benefits, or payroll information.
• Legal Notices: Compliance requirements, litigation issues, or regulatory communications.

Recognize when to Release Only

These emails could be important but may not need future allowances for 30 days unless consistently flagged as false positives.

• Transactional Emails: Order confirmations, shipping notifications, or transaction receipts.
• Education and Training: Professional development opportunities, training sessions, or educational materials.

Recognize when to Take No Action

These emails have already been held, and do not require any action to prevent their delivery.

• Phishing, Suspicious, or Malicious Emails: Emails that attempt to have users perform tasks through deceptive requests, encourage users to click or download contents, respond back with sensitive information, or masquerade as other companies or people. Often contain urgent, threatening, or suspicious language. May include mismatched/malicious links and malicious attachments. Typically combined with failed primary identifiers.

In the context of email quarantine management, monitoring includes more than one step, as contextual verification during the process is crucial for accurate determinations.

This fact is due to the nature of the email quarantine management system, wherein, looking at the email details themselves rarely give a complete picture for whether it is malicious or not. Both the email security data and the context of email message contents should be evaluated before deciding.

Review the Defender for Email Quarantine Queue

Finding emails which could be notable for investigation is first, as it drives any analysis.

Perform a Preview Message Action

Looking into the context and body of the email can provide a better sense of whether the email is legitimate or not, even if technical indicators may suggest otherwise.

In the context of email quarantine management, a response action is not always warranted.

This fact is due to the nature of the email quarantine management system, wherein, the default behavior for unwanted email is to stay within the queue. However, cases where special action to allow delivery for expected emails may be warranted as outlined below when a need has been identified.

Respond with Email Release and Allow

These are emails that are essential to business operations and allowing similar messages for 30 days helps prevent disruptions due to repeated false positives. Additionally, performing this action will submit to Microsoft and nearly always results in similar emails being allowed in the future, even past 30 days, as they update their scanning engine.

Respond with Email Release

These emails could be important but may not need future allowances for 30 days unless consistently flagged as false positives.

Need Assistance?