Abnormal Security Messages

Abnormal Security Message Analysis

Overview

Abnormal Security provides deep message analysis capabilities beyond basic threat detection. This skill covers message retrieval, header inspection, attachment analysis, sender authentication results, and delivery context. Use it when performing forensic analysis of specific emails or investigating delivery patterns.

Anti-triggers

• Where a message went, or why it never arrived — Abnormal sees messages only as evidence attached to a detected threat. It has no delivery pipeline, no queue, and no bounce record, so "trace this email" questions belong to the gateway: use Mimecast Message Tracking.
• Removing the message from inboxes, or putting it back — that is the remediation surface; use Abnormal Security Threats.
• Inspecting a message a gateway is holding — everything Abnormal can show was already delivered. Pre-delivery holds are SpamTitan Quarantine or Proofpoint Quarantine.

Message Field Reference

These are response fields describing what Abnormal reports about a message. They are not tool parameters — the only parameters the message tools accept are threatId and messageId. Availability varies by message and by tenant configuration; treat any single field as best-effort.

Core Message Fields

Sender Analysis Fields

Authentication Fields

Attachment Fields

URL Fields

Delivery Context

MCP Tools

Two tools, and both are scoped to a single threat. There is no separate headers tool and no tenant-wide message search — you cannot ask "show me every message from this sender". Every message lookup starts from a threatId.

Headers arrive inline, not from a separate call

abnormal_messages_get returns the header set as part of its one response, alongside URLs, attachments and the AI analysis. Everything the Header Analysis Workflow below asks for comes out of that single call — there is no second, header-only fetch to make, and nothing to page through. The practical consequence is on the other side: one abnormal_messages_get pulls the entire substance of a customer's email into context, including recipient addresses and Authentication-Results, whether or not you needed the headers. Call it when you intend to do forensics on that message, not to browse.

ID vocabulary

threatId is a UUID string. messageId is the message identifier from the abnormal_messages_list response (URL-encoded when sent). Do not confuse either with caseId, which abnormal_cases_get takes as a number.

Tool Usage Examples

List messages associated with a threat:

{
  "tool": "abnormal_messages_list",
  "parameters": {
    "threatId": "184def76-3c28-4e1b-9ef0-a5abc123def4"
  }
}

Get one message in full (metadata, headers, URLs, attachments):

{
  "tool": "abnormal_messages_get",
  "parameters": {
    "threatId": "184def76-3c28-4e1b-9ef0-a5abc123def4",
    "messageId": "<CA+8mv1x@mail.example.com>"
  }
}

Message Analysis Workflows

Header Analysis Workflow

1. Retrieve the message - abnormal_messages_get returns the headers inline; there is no separate header call
2. Check authentication:
   • SPF: Does the sending IP match the domain's SPF record?
   • DKIM: Is the DKIM signature valid and aligned?
   • DMARC: Does the message pass DMARC policy?
3. Trace routing:
   • Follow Received headers from bottom to top
   • Identify mail servers and relay hops
   • Check for unusual routing or delays
4. Inspect key headers:
   • From vs Return-Path mismatch (potential spoofing)
   • Reply-To vs From mismatch (redirect replies)
   • X-Mailer or User-Agent (sending client)
   • Content-Type and encoding

Attachment Analysis Workflow

1. List attachments - Review filenames, types, and sizes
2. Check for suspicious patterns:
   • Double extensions (e.g., invoice.pdf.exe)
   • Macro-enabled Office files (.docm, .xlsm)
   • Archive files (.zip, .rar, .7z) containing executables
   • Unusual MIME types
3. Cross-reference with threat data:
   • Check if the attachment hash matches known malware
   • Review sandbox analysis results if available
4. Assess risk:
   • Was the attachment opened by the recipient?
   • How many users received the same attachment?

Sender Reputation Workflow

1. Check sender identity:
   • Is this a first-time sender to this recipient?
   • Does the display name match the email address?
   • Is the domain recently registered?
2. Verify authentication:
   • SPF, DKIM, DMARC all passing?
   • Are there any authentication failures?
3. Check sender IP:
   • Is the IP on any blocklists?
   • Does it match the expected mail server for the domain?
4. Review communication history:
   • Has this sender contacted the organization before?
   • Is the communication pattern normal?

Authentication Results Reference

SPF Results

DKIM Results

DMARC Results

Error Handling

Common API Errors

Best Practices

1. Always check authentication - SPF/DKIM/DMARC failures are strong spoofing indicators
2. Compare From and Return-Path - Mismatches often indicate spoofing or forwarding
3. Review Reply-To - Reply-To different from From is a common BEC indicator
4. Check attachment types carefully - Not all dangerous files have obvious extensions
5. Trace Received headers - Follow the email routing path for anomalies
6. Check if email was read - Read emails with credential phishing need password resets
7. Cross-reference with threats - Message context enriches threat investigations

Related Skills

• Abnormal Threats - Threat detection and analysis
• Abnormal Cases - Abuse mailbox case management
• Abnormal API Patterns - API authentication and usage