Most SIEM use case guides cover the same ground with brute force detection, insider threats, compliance monitoring, and lateral movement. What they often skip is email, even though email remains one of the most common attack vectors and a major source of financial loss in cybercrime.

The standard "top 10 SIEM use cases" article rarely includes a dedicated detection scenario for BEC, vendor email compromise (VEC), account takeover (ATO), or inbox rules abuse. That gap matters. BEC complaints generated adjusted losses exceeding $2.7 billion in a single year.

This guide maps SIEM use cases directly to the email-based attack chains security teams need to detect.

• Standard SIEM use case libraries rarely include dedicated detection logic for BEC, VEC, lateral phishing, or inbox rule abuse, despite email remaining one of the most common attack vectors.
• Effective email SIEM use cases require multi-source correlation across email gateway logs, identity provider logs, endpoint telemetry, and cloud audit logs.
• Each use case maps to specific MITRE ATT&CK techniques, giving SOC teams a structured framework for detection engineering.
• Rule-based SIEM correlation handles known-pattern threats well but often struggles with attacks that produce no traditional indicators of compromise, such as socially engineered BEC.
• Behavioral context layered on top of SIEM telemetry can help close the gap between what SIEM logs and what SIEM detects.

An effective SIEM use case for email attacks combines the right telemetry, cross-source correlation, and a defined response path.

A SIEM use case for email threats requires three components working together: the right data sources, correlation logic that chains related events, and defined response actions. Detecting phishing requires, at minimum, email, web proxy, server application logs, and IDS/IPS as log and event sources.

For cloud email environments, the log surface expands to include M365 logs. Workspace logs require Admin SDK Reports API data, Gmail audit logs, and Alert Center events. A common operational pitfall is ingesting email gateway logs into SIEM while skipping identity logs. Graph APIs carry Entra ID sign-in events and risky user detections rather than the Office 365 Management Activity API.

Without both, SIEM rules often cannot correlate an authentication anomaly with a subsequent email behavior change.

The core design points are straightforward:

• Data Sources: Email gateway logs alone are not enough. Identity logs, cloud audit logs, endpoint telemetry, and relevant network logs provide the context needed to connect delivery, login activity, and post-delivery behavior.
• Correlation Logic: Single-event rules generate noise. Correlation works better when it links related activity across sources, such as email delivery, process execution, and outbound communication.
• Response Actions: Detection should map to a clear next step, such as quarantining a message, disabling an account, revoking OAuth tokens, or escalating to a SOAR playbook.

Without defined responses, detection produces alerts that go nowhere. Attacks that produce limited traditional indicators of compromise, such as socially engineered BEC, are where this design discipline matters most.

These SIEM use cases map email attack phases to specific ATT&CK techniques, log sources, and correlation logic. They are organized by attack phase, from initial access through persistence and collection.

Correlate inbound email metadata with file creation in temporary directories and suspicious process execution. The high-fidelity signal is an Office application (WINWORD.EXE, EXCEL.EXE) spawning PowerShell, CMD, or wscript.exe soon after attachment delivery, followed by an outbound network connection from the child process. Log sources required: email gateway, EDR or Sysmon process creation logs, and network proxy.

Chain email delivery containing an embedded URL with web proxy click-through logs and destination domain evaluation. Enrich with domain age, edit distance from known brand domains, and whether the browser process spawns a shell or scripting binary after the click. For OAuth consent phishing variants, monitor Azure AD Audit Logs for Consent to application events after link click.

Monitor M365 Unified Audit Logs for New-InboxRule or Set-InboxRule operations where the ForwardTo or RedirectTo parameter targets an external domain. Correlate with session context: did the creating session originate from an IP outside the user's login baseline? MITRE T1114.003 documents use by Kimsuky, LAPSUS$, Scattered Spider, Silent Librarian, and Star Blizzard for persistent access even after credential resets.

Extend the forwarding rule use case by analyzing rule content. Rules filtering on keywords like "invoice," "payment," "wire," "ACH," or "remittance" that forward matching messages externally or move them to obscure folders indicate BEC financial targeting. Escalate severity when the account belongs to finance, accounts payable, HR, or executive roles.

Detect inbox rules that suppress evidence. Detect inbox rules that auto-delete messages matching security-related keywords ("alert," "password," "MFA," "verification") or move them to Deleted Items or RSS Feeds folders. M365 logging captures rule creation with conditions natively, making this a high-fidelity, low-noise detection.

This lateral movement technique uses a compromised internal account to phish colleagues. Correlation logic chains an authentication anomaly with a sending volume spike, URLs to newly registered external domains, and targeting of recipients in finance, HR, or executive distribution groups. MITRE T1534 documents threat actors including Gamaredon Group, HEXANE, Kimsuky, and Lazarus Group.

Detect inbound emails where the display name matches an internal executive but the envelope sender domain is external. Enrich with DMARC results (FAIL or NONE), reply-to domain mismatches, recipient role targeting, and financial keyword presence. Organizations running p=none DMARC policies are especially exposed.

Detect emails from known vendor domains where the specific sender address has no prior communication history with the recipient, combined with financial transaction requests or payment detail changes. The email passes SPF, DKIM, and DMARC because the vendor's account is legitimately compromised. Correlation logic: match sender domain against a known vendor list, flag first-contact sender addresses within those domains, and check for financial keywords (invoice, wire, ACH, payment redirect). This use case typically requires behavioral baselines that rule-based SIEM does not generate on its own.

Calculate geographic distance between consecutive authentication events for the same user and flag when implied travel speed exceeds physical possibility. Enrich with device fingerprint changes and MFA bypass status. If an inbox rule is created after the anomalous login, escalate immediately. MITRE T1078 documents FIN4, Star Blizzard, and APT29 using valid credentials to access email systems.

OAuth consent phishing often produces little suspicious authentication telemetry. This attack can produce no suspicious authentication event. Monitor for emails containing OAuth authorization URLs with unrecognized client_id values, followed by Consent to application events in Azure AD Audit Logs. Evaluate requested scopes: Mail.Read, Mail.ReadWrite, Contacts.Read, and Files.ReadWrite.All are high-risk. Flag unverified publishers and recently registered publisher domains.

Detect multiple MFA push notifications sent to the same user account within a short window from non-corporate IP addresses. Also monitor for legacy auth protocols (IMAP, POP3, SMTP AUTH) that bypass MFA entirely. Successful legacy protocol authentication warrants immediate investigation.

Local Email Collection via PST/OST File Access (T1114.001)

Monitor Event ID 4663 (attempt was made to access an object) for non-Outlook processes accessing .pst or .ost files. High-risk process names include PowerShell, CMD, 7z, and robocopy. Correlate with outbound data transfers from the same host soon after access.

Detect external authentication to EWS endpoints followed by bulk ResolveNames or FindPeople operations. Flag accounts with no prior EWS usage in their baseline. This reconnaissance technique often precedes targeted phishing campaigns.

SIEM rules often miss email attacks that look legitimate at the log level.

SIEM correlation rules work by matching events against known patterns. That architecture handles brute force attacks, known malware signatures, and policy violations well. It often struggles when email threats produce limited traditional indicators of compromise.

A compromised vendor account sending a payment diversion request from a legitimate domain can pass SPF, DKIM, and DMARC. No malicious attachment, no known-bad URL, and no suspicious IP leaves the SIEM with limited context to match.

Verizon's 2025 DBIR identifies stolen credentials as the most common initial access vector. Once an attacker authenticates with stolen credentials, subsequent actions can appear legitimate to rule-based detection. The SIEM logs the events but may not have enough context to distinguish the attacker from the real user.

Three structural limitations drive that gap:

• No Per-User Behavioral Baseline: Static rules apply the same thresholds to every user. They cannot determine whether a specific inbox rule, sending pattern, or login location is unusual for a specific individual.
• Limited Cross-Technique Correlation: Most SIEM rule sets evaluate events within a single detection domain. Connecting authentication anomalies, internal phishing activity, and inbox rule creation requires pre-built multi-stage rules many organizations do not have.
• No Semantic Content Analysis: SIEM processes structured log fields. It does not interpret urgency framing, authority impersonation, or social engineering language in email body text.

These constraints explain why email-focused SIEM detections work best when they combine correlation with additional context.

Behavioral signals strengthen SIEM email detection by adding context that logs alone do not provide.

The use cases above produce the strongest results when SIEM correlation is enriched with signals that rule-based architecture does not generate on its own.

• Relationship graphs: Identify when a sender-recipient pair has no prior communication history or when a new sender address appears within a trusted vendor domain for the first time. This can turn a clean-authentication VEC email into a higher-confidence alert.
• Identity signals: Connect authentication anomalies with email behavior changes for the same identity across time. A login from a new country, followed by a sending volume spike, followed by inbox rule creation forms a composite account takeover indicator that no single rule captures.
• NLP analysis: Detects manipulation patterns in message text, including urgency language, financial transaction requests, authority impersonation, and instructions to bypass approval processes.
• Post-Compromise Behavioral Indicators: Help determine whether a specific inbox rule creation is suspicious for a specific user. An employee who has never created an inbox rule suddenly creating one targeting financial keywords and forwarding to an external domain after an unusual login is a high-confidence BEC persistence signal.

Together, these signals add relationship, identity, and message context that SIEM rules often lack.

Abnormal is designed to enrich SIEM workflows with email-specific behavioral signals that help analysts prioritize attacks that logs alone may not fully explain.

Traditional SIEM email use cases depend on structured log fields and known indicators. Abnormal is designed to help address the remaining gap by analyzing behavioral signals across cloud email to build identity and relationship models for each organization.

Rather than matching against known-bad indicators, Abnormal's behavioral AI helps surface deviations from established patterns, such as first-contact senders within trusted vendor domains, unusual sending volumes, inbox rule creation that deviates from a user's history, and content exhibiting social engineering characteristics.

Abnormal integrates natively with SIEM tools and exports data fields from inbound email threat and ATO detections. These signals can flow into existing SIEM dashboards and SOAR playbooks, enriching rule-based correlation with identity and behavioral context that static rules cannot generate. Integration setup is completable in minutes, with no changes to mail flow or existing email configuration.

Recognized as a Leader in the Gartner® Magic Quadrant™, Abnormal deploys as a complementary layer alongside existing email security infrastructure, enhancing detection for email threats that rule-based and signature-based approaches often struggle to catch.

The strongest SIEM email programs combine correlation rules with behavioral context because modern email attacks rarely stay inside a single log source.

Email-based attacks are a high-cost, high-volume threat category enterprises face, yet they remain one of the least covered categories in standard SIEM use case libraries. The 13 use cases in this guide give SOC teams a structured starting point, mapped to ATT&CK techniques with defined log sources and correlation logic.

Behavioral context can help teams prioritize suspicious sender relationships, identity shifts, and message patterns that static rules often miss. Organizations that detect BEC, VEC, and ATO most effectively tend to treat SIEM and behavioral detection as complementary layers rather than competing tools.

Book a demo to see how Abnormal's behavioral AI can help enrich your SIEM with high-confidence email threat signals.