Abnormal Security Threats

Abnormal Security Threat Detection & Analysis

Overview

Abnormal Security uses behavioral AI to detect email threats that bypass traditional secure email gateways (SEGs). Unlike signature or rule-based detection, Abnormal profiles normal communication patterns and detects deviations indicative of attacks. This skill covers threat types, attack vectors, severity assessment, remediation, and investigation workflows.

Anti-triggers

• An email a user reported to the abuse mailbox — those arrive as cases carrying their own AI judgment and action set; use Abnormal Security Cases.
• A mailbox behaving strangely rather than an email arriving — impossible travel, new inbox rules, and lateral sending are account compromise, and this server exposes no account-takeover surface at all. Investigate identity in the M365 tenant instead; use cipp-users.
• Header, SPF/DKIM/DMARC, or attachment forensics on one message — use Abnormal Security Messages.
• Releasing something from a quarantine queue — Abnormal has no gateway queue. It inspects mail post-delivery through the M365 API and pulls it back out of inboxes. Anything sitting in a hold queue belongs to the gateway holding it: SpamTitan Quarantine, Mimecast Message Tracking, or Proofpoint Quarantine.
• A threat the gateway already stopped — mail blocked before delivery never reaches the mailbox, so Abnormal never sees it. Search the gateway's own logs.
• The same mail flagged by Check Point Harmony Email — Avanan is the other API-based, post-delivery platform on this stack and produces its own threat records; use avanan-threats.

Threat Types

Detection Approach

Threat Field Reference

Core Fields

Sender Fields

Recipient Fields

Remediation Fields

MCP Tools

Two tools cover the threat domain. There is no threat-level action tool — nothing here changes a threat's state, and abnormal_threats_get is a read.

There is no date-range parameter. Narrow by time through the OData filter string: receivedTime gt 2026-03-20T00:00:00Z.

ID vocabulary

threatId is a UUID string. The neighbouring caseId used by abnormal_cases_get is a number. The two identifiers read alike in prose ("pull case 12345", "pull the case for that threat") and are not interchangeable — passing a threat UUID to abnormal_cases_get is a type error, not a lookup miss.

Tool Usage Examples

List recent threats:

{
  "tool": "abnormal_threats_list",
  "parameters": {
    "filter": "receivedTime gt 2026-03-20T00:00:00Z",
    "pageSize": 25
  }
}

Get threat details:

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

Threat Investigation Workflows

BEC Investigation Workflow

1. Review threat details - Check attackType, attackStrategy, summaryInsights
2. Analyze impersonation:
   • Who is being impersonated (impersonatedParty)
   • Display name vs actual email address mismatch
   • Reply-to vs from address mismatch
   • First-time sender or unusual communication pattern
3. Check financial indicators:
   • Wire transfer, ACH, or gift card requests
   • Invoice or payment redirection
   • Urgency language ("urgent", "today", "confidential")
4. Assess scope:
   • Re-run abnormal_threats_list over the window and correlate on sender in the results — there is no tenant-wide message search, so scope is assembled from threat records, not from a sender query
   • Check whether other threats in the window share the sender or domain
5. Remediate - abnormal_messages_list, then abnormal_remediation_manage per message (see Remediation is per-message). Alert targeted recipients directly. Sender-domain blocking is not an Abnormal action — do it at the gateway or in M365.
6. Document - Record findings and IOCs

Credential Phishing Investigation Workflow

1. Get threat details - Focus on attackVector and embedded URLs
2. Analyze URLs:
   • Check for brand impersonation (Microsoft, Google, Dropbox)
   • Look for redirect chains and URL shorteners
   • Identify credential harvesting pages
3. Check sender authentication:
   • SPF, DKIM, DMARC results
   • Domain age and reputation
4. Assess user interaction:
   • Was the email read (isRead)?
   • Was it post-remediated (delivered then removed)?
5. Remediate - loop abnormal_remediation_manage over every message in the threat. Password resets and domain blocks are outside this server entirely: run them through cipp-users or the M365 tenant.

Malware Investigation Workflow

1. Get attachment details - File name, type, size
2. Review AI insights - Check summaryInsights for behavioral indicators
3. Assess delivery:
   • Was the attachment opened?
   • How many users received the same attachment?
4. Remediate - loop abnormal_remediation_manage over every message in the threat. Hash blocking and endpoint isolation are EDR actions, not Abnormal ones.

Severity Assessment Matrix

Remediation is per-message, not per-threat

Remediation does not live in this domain. The only mutating tool on the server is abnormal_remediation_manage, and it requires both threatId and messageId:

There is no "remediate this campaign" call. To act on a threat you must:

1. abnormal_threats_get — confirm the threat is what you think it is.
2. abnormal_messages_list — enumerate the messages inside it.
3. abnormal_remediation_manage — once per message, in a loop.

Why the loop is the hazard

The shape of the risk is not "one big blast radius decision". It is an N-call loop that can stop halfway.

• Partial failure leaves a campaign half-remediated. Rate limiting (60 req/min) or a single 4xx mid-loop means some recipients had the message pulled and others still have it in the inbox. Nothing in the API reports "the campaign is done" — only per-message results. Track which messageIds succeeded; do not infer completion from the first few.
• The message list is a point-in-time snapshot. A live campaign can land in more mailboxes while you are looping. Re-run abnormal_messages_list after the loop rather than trusting the original enumeration.
• action — not the tool name — decides the blast radius. status is a plain GET. remediate and unremediate are POSTs that move real mail. One tool name spans a safe read and a destructive write, so any allowlist keyed on tool name grants all three. An agent permitted to check status is, mechanically, permitted to unremediate.
• unremediate is not an undo. It delivers a message Abnormal classified as an attack back into a user's inbox. Treat it as a delivery decision requiring the same approval as the original remediation, not as a correction.

Verify with action: "status" per message after the loop.

Error Handling

Common API Errors

Best Practices

1. Prioritize by attack type - BEC and supply chain threats first
2. Check user interaction - Prioritize threats that were read or clicked
3. Review AI insights - summaryInsights explains why Abnormal flagged the email
4. Correlate account compromise elsewhere - A phishing campaign may lead to account compromise, but nothing on this server detects it; pivot to cipp-users
5. Monitor remediation status - Check action: "status" per message; there is no campaign-level status
6. Track post-remediation - Emails remediated after delivery need immediate attention
7. Never release confirmed threats - unremediate delivers a known attack; escalate to management instead

Related Skills

• Abnormal Cases - Abuse mailbox case management
• Abnormal Messages - Message analysis
• Abnormal API Patterns - API authentication and usage