Monitor & Respond - Email Action Center 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 Action Center Queue serves as a critical tool for ensuring the correct security remediation actions are taken on emails if they are delivered to users’ inboxes. This feature provides a direct way for analysts to eliminate potentially malicious emails from a users inbox, and ensure these remediations are appropriate. The daily review of the action center queue is important to ensure these potential threats to both security and business are addressed quickly, and do not exist in a state of awaiting approval for extended periods of time.

 Security Importance:

Monitoring and responding to the submission queue ensures potentially harmful emails in user inboxes are remediated, helping to mitigate the security risk of advanced threat actors changing security determinations after an email has been delivered to an email inbox.

 Business Importance:

Monitoring and responding to the submission queue ensures legitimate business email is not mistakenly remediated from inboxes, helping to mitigate the business risk of an errant remediation recommendation removing an email with legitimate business need from a user inbox.

Covered in this Operation

In the context of managing the email user submission queue, training goes beyond marking an email as what users have submitted it as. Analysts need the ability to accurately respond as a subject matter expert, which in some cases, may not align with their original reason for reporting. Understanding the security information tied to each entry, comprehending the detection methods in use, and identifying instances where users can be misled are core skills needed for this.

This skillset enables analysts to process the entries efficiently while maintaining accuracy and quality in decision-making. Effective training here isn’t always about agreeing with users — it’s having the judgment needed to provide feedback on users suspicious around emails they receive, confidently ensuring the queue is managed effectively and users receive accurate feedback for their involvement in contributing to a secure email security culture.

Understanding Investigation Security Information

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

Investigation Graph

• Started: The specific time and date of occurrence on the alert which instated the event. Allows for an analyst to track when an event initially occurred.
• Duration: The amount of time that elapsed from the start of the investigation to an action being taken. Can be used to track metrics around Mean Time to Remediation (MTTR) for potential threats.
• Status: The current status of the investigation for the alert, such as “Queued”, “No Threats Found”, “Pending Action”, or “Remediated“. This state provides visibility into which investigations have already been addressed or need further attention.
• Alert Severity: The impact level of the alert, such as “Informational”, “Low”, “Medium”, or “High”. This rating helps analysts prioritize their responses based on the potential risk to the organization. Higher severity alerts generally require immediate investigation.
• Category: The type of threat associated with the alert, such as “Threat Management”. The category allows analysts to filter and organize alerts by threat type, making it easier to manage specific email threats more efficiently.
• Detection Source: Identifies the Microsoft Defender component that generated the alert, typically listed as Defender for Office 365 (MDO) for email alerts and Microsoft Defender for Endpoint for endpoint alerts. This field helps analysts understand where the alert originated, guiding them to the right tools and resources for investigation.

Alerts section:

• Alert Name: The title of the alert that summarizes the nature of the security event, such as "Email Sending Limit Exceeded" or "Phishing Attempt Detected." Provides a quick overview of the identified issue.
• Tags: Custom labels added to alerts for easy categorization, filtering, or prioritization. Common tags might include “High Priority,” “Phishing,” or specific departmental labels. These tags help organize alerts, making it simpler to sort and focus on relevant alerts.
• Severity: The impact level of the alert, such as “Informational”, “Low”, “Medium”, or “High”. This rating helps analysts prioritize their responses based on the potential risk to the organization. Higher severity alerts generally require immediate investigation.
• Investigation State: The current status of the investigation for the alert, such as “Queued”, “No Threats Found”, “Pending Action”, or “Remediated“. This state provides visibility into which alerts have already been addressed or need further attention.
• Status: The current condition of the alert, such as “New”, “In Progress”, or “Resolved”. The status shows the life cycle of the alert, helping analysts identify unresolved alerts that may still pose a threat.
• Category: The type of threat associated with the alert, such as “Threat Management”. The category allows analysts to filter and organize alerts by threat type, making it easier to manage specific email threats more efficiently.
• Detection Source: Identifies the Microsoft Defender component that generated the alert, typically listed as Defender for Office 365 (MDO) for email alerts and Microsoft Defender for Endpoint for endpoint alerts. This field helps analysts understand where the alert originated, guiding them to the right tools and resources for investigation.

Mailboxes section:

• Verdict: The determination of the investigation, such as “No threats” or “Malicious”. This rating helps analysts determine if the activity being investigation has been identified as malicious or not.
• Display Name: Identifies the display name of the user associated with the investigation, such as those who received phishing emails or clicked a malicious link. Identifies impacted users for targeted remediation efforts.
• Primary Email Address: Identified the primary email address of the user associated with the investigation, such as those who received phishing emails or clicked a malicious link. Identifies impacted users for targeted remediation efforts.
• UPN: Identifies the UPN of the user associated with the investigation, such as those who received phishing emails or clicked a malicious link. Identifies impacted users for targeted remediation efforts.
• Object ID: Identifies the object ID of the user associated with the investigation, such as those who received phishing emails or clicked a malicious link. Identifies impacted users for targeted remediation efforts.
• Risk Level: Determines the level of risk introduced by the action taken, such as “low”, “medium”, or “high”. Adds general context for analysts to work from in further identifying the severity.
• Risk: Describes the type of risk observed, such as “malicious URL click”. Adds the exact action perform that was identified as risky to add context for analysts.
• Risky Activities: A count of the amount of defined risky activities that were identified. Using this information can determine the extent of activity around the risky activity for analysts.

Evidence section:

• Emails (May Appear): Lists emails that are evidence in the investigation, including malicious messages, phishing attempts, or emails with suspicious attachments or links. Outlines individual emails and if they are in scope for remediation actions, should they be approved.
• Email Clusters (May Appear): Groups of related emails identified as part of the same threat campaign. Outlines the email clusters with their status and if they are in scope for remediation actions, should they be approved.
• IP Addresses (May Appear): IP addresses involved in the incident, either as sources of malicious activity or as targets. Outlines IP addresses with their status and if they are in scope for remediation actions, should they be approved.
• Files (May Appear): Files pertinent to the investigation, such as malware samples, infected documents, or unauthorized downloads. Outlines files with their status and if they are in scope for remediation actions, should they be approved.
• Processes (May Appear): Processes running on devices associated with the incident, which may indicate malware execution or unauthorized activities. Outlines processes with their status and if they are in scope for remediation actions, should they be approved.
• URL’s (May Appear): Web addresses involved in the incident, such as phishing sites, command-and-control servers, or sites hosting malware. Outlines URL’s with their status and if they are in scope for remediation actions, should they be approved.

Entities section:

• Emails (May Appear): Emails that are not always malicious or part of the remediation plan but were evaluated during the investigation. Could be used to determine related emails.
• Email Clusters (May Appear): Email clusters that are not always malicious or part of the remediation plan but were evaluated during the investigation. Could be used to determine related emails clusters.
• IP Addresses (May Appear): IP addresses that are not always malicious or part of the remediation plan but were evaluated during the investigation. Could be used to determine related IP addresses.
• Files (May Appear): Files that are not always malicious or part of the remediation plan but were evaluated during the investigation. Could be used to determine related files.
• Processes (May Appear): Processes that are not always malicious or part of the remediation plan but were evaluated during the investigation. Could be used to determine related processes.
• URL’s (May Appear): URL’s that are not always malicious or part of the remediation plan but were evaluated during the investigation. Could be used to determine related URL’s.

Log section:

• Status: Current status of the described activity, such as “Completed”, “Running”, or “Pending Approval”. Checking the status on various actions can ensure remediation actions complete successfully.
• Create: Details when the activity was initialized. Can be used to ensure response SLA is maintained.
• Execution Start: Details when the activity began execution. Can be used to ensure response SLA is maintained.
• Duration: The time between running to completed. Can be used to determine the runtime of a particular execution as it pertains to the task it was accomplishing, not including the automation trigger time.
• Description: Brief description about the task which was executed. Can be included in post-event writeups to provide context around specific actions taken in response to a threat.

Pending Actions section:

• First Seen: The time when the described entity was first detected to have malicious traits. Often used by analysts to compare against other timestamps such as time of delivery to pinpoint verdict changes.
• Details: Information about the entity itself, such as URL’s or to/from details. Used to quickly get an overview of the entity in question and inform whether response approval is appropriate.

Understanding Email Detection Technologies

Understanding “Spam”, “Phish”, or “Malware” is only the general determination. The delivery details section specifies the status of the emails. Use this section to determine the how the determination has changed since being initially allowed 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 action approvals and help make a final determination. 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 Reject a Remediation

When it comes to rejecting a remediation, it’s important to make this determination before choosing to approve one. This initial step is critical because it is where the analyst should validate Microsoft’s claim to perform remediation actions on an email, as there are instances where these recommendations can be incorrect and cause impact to legitimate organization email. Overriding these should only be performed when the analyst can be exceptionally confident that the email is indeed clean, and the request for remediation is Microsoft’s error. The situations where analysts may see this in play are as such:

• Internal Communications: Daily operations, meetings, or internal announcements from colleagues or departments. It is not uncommon for a user to occasionally report an email as phishing, despite it being from an internal sender.
• Business Deals: Details about negotiations, contracts, or agreements. These can be trickier to interpret, however, an understanding of the business and its common business partners can help in identification.

Recognize when to Approve a Remediation

After a remediation has been confirmed to not require an outright reject, confirming the approval of the remediation actions can be performed. Many of the automation items surrounding an investigation have already concluded at this point in the process, and a confirmation of the verdict and determination by Microsoft is recommended. The situations where analysts will most likely see an action requesting remediation are for emails such as:

• 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.
• Education and Training: Professional development opportunities, training sessions, or educational materials.
• Sales or Marketing: Cold emails advertising a product or service that do not have pertinent to business operations.

In managing the Defender email action center queue, monitoring focuses on identifying remediation actions that require an approval, and if the recommended response is appropriate.

By evaluating relevant security data alongside any available contextual information, analysts can accurately decide on these remediation approvals. This approach ensures remediations requiring swift identification are found within a timeframe that does not allow threats to linger in mailboxes, along with releasing misidentified emails.

Review the Defender for Email Action Center Queue

Identifying remediations requiring approval which have not yet reviewed by an analyst is the primary goal of monitoring.

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

This fact is due to the nature of the email action center management system, wherein, an item in the queue indicates the system is awaiting response and approval/rejection. Although the core scope of this operation is focused the approval or rejection of these entries, analysts can opt to take additional steps when following the rejection path to ensure these emails are released back into user inboxes.

Respond with Email Action Center Rejection Action

This action applies to email action center entries which have been confirmed by an analyst as not containing threats and will be rejected for execution to mitigate potential business impact.

Optional steps that can be taken in addition to the rejection of this action, as remediation requests are outputs of the detection of malicious activity. Depending on the type of remediation requested, and the level of automation currently configured, these optional actions can vary:

• Malicious URL Detected: Follow the Defender for Email URL Submit and Allow Action article to further re-allow URL that has been misclassified as malicious, as well as the Defender for Email Release article to release the email back to the users’ inbox, as it is likely quarantined if ZAP automation is configured.
• Malicious Body/Subject Detected: Follow the Defender for Email Quarantine Release Action article to release the email back to the users’ inbox, as it is likely quarantined if ZAP automation is configured.

Respond with Email Action Center Approval Action

This action applies to email action center entries which have been confirmed by an analyst as containing threats and will be approved for execution to mitigate potential security impact.

Need Assistance?