Phishing & BEC Investigation: Following the Email Trail

Prerequisites

• CIR-K003: Live Response Triage

Why This Lesson Matters

Phishing is the initial access vector in roughly 36% of breaches (Verizon DBIR). Business Email Compromise (BEC) — where an attacker impersonates an executive or vendor to redirect payments — causes more financial loss than any other cybercrime category. Both leave distinctive evidence trails in email headers, authentication logs, and inbox rules. Knowing how to read these trails is a core IR skill.

1. Phishing Investigation: Where to Start

When a user reports a phishing email, your first instinct might be to look at the attachment or link. Start with the email header instead — it tells you where the email actually came from, regardless of what the From: field says.

1.1 Reading Email Headers

An email header is a record of every server that handled the message. Read it bottom-up — the oldest relay is at the bottom, the most recent is at the top.

Received: from mail.corp.local (10.0.0.5) by SRV-MAIL (10.0.0.1)  ← most recent
Received: from smtp.attacker-domain.com (185.220.101.5) by mail.corp.local  ← previous hop
Received: from unknown (originates from attacker)  ← first hop

From: CEO <[email protected]>                         ← SPOOFED — attacker set this
Return-Path: <[email protected]>          ← REAL source for bounces
Reply-To: [email protected]                       ← where replies go (attacker's inbox)

Key fields:

1.2 SPF, DKIM, and DMARC in the Header

Authentication-Results: mx.corp.local;
  spf=fail (sender not permitted) smtp.mailfrom=attacker-domain.com;
  dkim=none (no signature found);
  dmarc=fail (p=none) header.from=corp.local

• spf=fail → The sending server is not authorised to send for that domain
• dkim=none → No cryptographic signature (real emails from corp.local would have one)
• dmarc=fail p=none → DMARC failed but policy is "none" = email was still delivered (this is a configuration weakness)

A p=none DMARC policy means phishing emails that fail SPF and DKIM are still delivered. This is the most common email security gap.

2. Attachment and Link Analysis

2.1 Attachment Triage

# Hash the attachment
sha256sum invoice_Q2.docm

# Submit to VirusTotal (CLI or web)
# Check for macros in Office documents
olevba invoice_Q2.docm    # extract and analyse VBA macros

# Check for embedded URLs
strings invoice_Q2.docm | grep -iE "http|https|://|bit.ly|tinyurl"

# Safe detonation: open in an isolated sandbox (Any.run, Hybrid Analysis, Joe Sandbox)
# Never open on a production machine

Never click a suspicious link or open a suspicious attachment outside of an isolated environment. Even "checking if the link works" is evidence contamination and potential compromise.

2.2 URL Analysis

# Defang the URL before sharing or pasting (prevents accidental clicks)
# Replace http with hxxp and dots before the domain with [.]
# http://evil.com/payload.exe → hxxp://evil[.]com/payload[.]exe

# Check URL reputation
# URLScan.io: submit for screenshot and analysis without visiting
# VirusTotal: /url endpoint
# PhishTank: for known phishing URLs

# Extract domain for infrastructure analysis
whois evil-domain.com | grep -E "Registrar|Created|Updated"
# Newly registered domain (< 30 days) = strong phishing indicator

3. Account Compromise Investigation (Post-Phishing)

If a user clicked the link and entered their credentials, assume the account is compromised. Investigate immediately.

3.1 O365/Azure AD Sign-in Logs

# Requires Microsoft.Graph or AzureAD module
# Get sign-in events for the compromised user (last 7 days)
Get-MgAuditLogSignIn -Filter "userPrincipalName eq '[email protected]'" -Top 100 |
  Select-Object CreatedDateTime, IpAddress, Location, ClientAppUsed, RiskLevelAggregated

# Suspicious signals:
# - Login from country user never visits
# - Login from Tor or VPN IP
# - Login at unusual hour (3 AM local time)
# - Multiple failed logins followed by success from new IP
# - RiskLevelAggregated: high or medium

3.2 Inbox Rule Manipulation (BEC Hallmark)

BEC attackers create inbox rules immediately after compromising an account. The rules silently forward emails to the attacker or delete security alerts.

# Check for suspicious inbox rules (Exchange Online)
Get-InboxRule -Mailbox [email protected] | Select-Object Name, Enabled,
  ForwardTo, ForwardAsAttachmentTo, DeleteMessage, MoveToFolder, SubjectContainsWords

# Red flags:
# ForwardTo → external email address
# DeleteMessage: True + SubjectContainsWords → "invoice", "payment", "wire transfer"
# MoveToFolder → Deleted Items, RSS Feeds (hiding emails)

# Also check audit log for rule creation events
Search-UnifiedAuditLog -StartDate "2026-06-07" -EndDate "2026-06-09" 
  -Operations "New-InboxRule","Set-InboxRule" -UserIds [email protected]

4. BEC Investigation

Business Email Compromise combines account compromise with social engineering. The attacker uses the compromised account (or a convincing lookalike domain) to request fraudulent payments.

4.1 BEC Indicators in Email Logs

Legitimate payment request flow:
  CEO → CFO email → CFO processes payment through normal channels

BEC flow:
  Attacker (as CEO) → CFO email (urgent, outside normal channel)
  → "Wire $50,000 to new vendor ASAP, keep confidential"
  → No approval workflow, direct wire request

BEC email characteristics: - Urgency and secrecy ("do not discuss with anyone") - Request for a new vendor or bank account change - Sent from a lookalike domain: [email protected] vs [email protected] - Sent outside business hours - Reply-To differs from From:

4.2 Log Tampering — Covering Tracks

After compromising an email account, attackers sometimes delete sent emails or modify audit settings to hide their activity. This is why your SIEM must have an independent copy of audit logs.

# Check if audit log was disabled for the user
Search-UnifiedAuditLog -StartDate "2026-06-01" -EndDate "2026-06-09" 
  -Operations "Set-AdminAuditLogConfig","Disable-OrganizationCustomization" |
  Select-Object CreatedDate, UserIds, Operations

# Check for deleted items purged
Search-UnifiedAuditLog -StartDate "2026-06-07" -EndDate "2026-06-09" 
  -Operations "HardDelete" -UserIds [email protected] |
  Select-Object CreatedDate, AuditData

5. Common Mistakes

Mistake 1: Trusting the From: field. The From: field is trivially spoofed. It is cosmetic information. Always look at the Received: headers and the authentication results.

Mistake 2: Only disabling the account without checking inbox rules. An attacker who installed a forwarding rule will continue to receive emails even after the account is disabled — the forwarding fires as the email is processed on the server.

Mistake 3: Not preserving the phishing email as evidence. Export the email as .eml (raw MIME format) before any mail gateway quarantines or deletes it. The full headers are only in the raw .eml.

6. Practice Exercises

1. A colleague forwards you a phishing email. The From: field shows [email protected]. The Authentication-Results shows spf=fail; dkim=none; dmarc=fail (p=quarantine). What does this tell you? Was the email correctly quarantined?

2. You find this inbox rule on a compromised account: Name: "Legal Review", SubjectContainsWords: "invoice,payment,wire", ForwardTo: [email protected], DeleteMessage: True. Describe the impact of this rule and the containment actions required.

3. How do you defang this URL for safe sharing in a report? https://corp-login.evil.net/microsoft/auth?redirect=phish

7. Lab

Assessment mode: flag

challenge_spec_id: 21 — Log tampering

You are given an Exchange audit log export. An attacker compromised a mailbox, created a forwarding rule, then attempted to delete evidence by clearing the audit log.

Task: 1. Find the inbox rule created (name and forwarding address) 2. Find the log-tampering event (which audit operation was called) 3. The flag is: PREFIX{rule_name:forwarding_address:tamper_operation}

8. Framework Alignment

9. Further Reading

• Google Workspace / Microsoft 365 Security Best Practices — Official guidance on email security configuration
• FBI IC3 BEC Advisory — https://ic3.gov — Statistics and case studies on Business Email Compromise
• PhishTool — https://app.phishtool.com — Free email header and phishing analysis
• MXToolbox Email Header Analyzer — https://mxtoolbox.com/emailheaders.aspx — GUI for header parsing

["Read an email header bottom-up to identify the true sending server and distinguish it from a spoofed From: field, and interpret SPF/DKIM/DMARC authentication results", "Identify a malicious inbox rule that forwards and deletes messages, and list the containment and eradication steps required to close the attacker's access to future emails", "Extract indicators (sender IP, lookalike domain, forwarding address) from a described BEC incident and defang them correctly for safe sharing in a report"]

Prerequisites → Why this matters → Phishing investigation: email headers (bottom-up reading, trusted vs untrusted fields) → SPF/DKIM/DMARC in headers → Attachment and link analysis (olevba, VirusTotal, URL defanging) → Account compromise investigation (sign-in logs, anomalies) → Inbox rule manipulation (BEC hallmark, PowerShell queries) → BEC characteristics and log tampering → Common mistakes → Practice exercises → Lab (flag, spec 21) → Framework alignment → Further reading