13.4 Email Thread Analysis

Email Thread Analysis

The mailbox assessment determined whether the mailbox is compromised. This subsection reconstructs what the attacker did inside the mailbox: which email threads they monitored, which vendors they identified as targets, and how they prepared the fraud.

Required role: Microsoft Sentinel Reader. Defender for Office 365 Security Reader for Threat Explorer.

Step 1: Determine what the attacker read

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

// Emails accessed by the attacker — what threads did they monitor?
CloudAppEvents
| where TimeGenerated > ago(30d)
| where ActionType == "MailItemsAccessed"
| where AccountObjectId in (
    SigninLogs
    | where UserPrincipalName == "a.patel@northgateeng.com"
    | distinct UserId
)
| extend Details = parse_json(RawEventData)
| extend ClientIP = tostring(Details.ClientIPAddress)
| extend ClientInfo = tostring(Details.ClientInfoString)
| where ClientIP !in ("192.0.2.10", "192.0.2.15")  // Non-corporate access
| summarize
    EmailsAccessed = count(),
    FirstAccess = min(TimeGenerated),
    LastAccess = max(TimeGenerated),
    AccessMethods = make_set(ClientInfo, 5)
    by ClientIP

What to examine: Total email count accessed from non-corporate IPs tells you the scope of the attacker’s reconnaissance. If 500+ emails accessed over 2 weeks: the attacker conducted deep reconnaissance of a.patel’s entire mailbox. If 20-50 emails accessed over 3 days: targeted reconnaissance of specific threads.

Limitation: MailItemsAccessed does not log the subject line or content of the emails accessed. It logs the count and the access method. To determine which specific threads the attacker targeted, you must correlate: the timing of email access (from MailItemsAccessed) with the inbox rules created (from Step 4 of 12.3 — which keywords did the rules target?) and the vendor identified in the fraudulent email.

Step 2: Reconstruct the targeted vendor thread

1
2
3
4
5
6
7
8
9

// All emails between a.patel and Meridian Precision — the targeted vendor
EmailEvents
| where TimeGenerated > ago(90d)
| where (SenderFromAddress has "meridian" and RecipientEmailAddress == "a.patel@northgateeng.com")
    or (SenderFromAddress == "a.patel@northgateeng.com" and RecipientEmailAddress has "meridian")
| project TimeGenerated, SenderFromAddress, RecipientEmailAddress,
    Subject, DeliveryAction, NetworkMessageId,
    InternetMessageId = tostring(InternetMessageId)
| order by TimeGenerated asc

What to examine: The chronological history of the a.patel ↔ Meridian Precision email thread. Identify: the legitimate thread about the March invoice, the point where the fraudulent bank details email was inserted, and whether the attacker replied within the existing thread (thread hijacking) or started a new conversation.

Thread hijacking indicator: If the fraudulent email has the same Subject line (with “Re:” prefix) and the same InternetMessageId thread header as the legitimate invoice thread — the attacker replied within the existing conversation. This is the most convincing BEC technique because the recipient sees it as a continuation of a conversation they are already having.

Step 3: Identify the fraudulent email

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

// The specific fraudulent email — bank details change request
EmailEvents
| where TimeGenerated between(datetime(2026-03-11T00:00:00Z) .. datetime(2026-03-13T00:00:00Z))
| where RecipientEmailAddress == "a.patel@northgateeng.com"
| where Subject has "bank" or Subject has "payment" or Subject has "invoice"
    or Subject has "meridian"
| project TimeGenerated, SenderFromAddress, SenderMailFromAddress,
    RecipientEmailAddress, Subject,
    AuthenticationDetails, SenderIPv4, NetworkMessageId
| order by TimeGenerated asc

Cross-reference with the legitimate thread. Compare: the SenderFromAddress of the fraudulent email vs the legitimate Meridian emails. If different (even by one character): lookalike domain. If identical: either Meridian is compromised, or the attacker sent the email from a.patel’s compromised mailbox, manipulating the From header.

Extract the sender IP:

1
2
3
4
5

// Sender infrastructure for the fraudulent email
EmailEvents
| where NetworkMessageId == "FRAUDULENT-EMAIL-NETWORK-MESSAGE-ID"
| project SenderFromAddress, SenderMailFromAddress, SenderIPv4,
    AuthenticationDetails

The SenderIPv4 is the mail server that transmitted the fraudulent email. If it matches Meridian’s legitimate mail server: Meridian’s email is compromised. If it is a different server: the attacker used their own infrastructure.

Step 4: Check for other targeted vendor threads

The attacker may have targeted multiple vendors — not just Meridian.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

// Inbox rules with financial keywords — which vendors were targeted?
CloudAppEvents
| where TimeGenerated > ago(30d)
| where ActionType in ("New-InboxRule", "Set-InboxRule")
| extend RuleData = parse_json(RawEventData)
| where tostring(RuleData.UserId) == "a.patel@northgateeng.com"
| extend Conditions = tostring(RuleData.Parameters)
| where Conditions has_any ("invoice", "payment", "bank", "wire",
    "transfer", "account", "remittance")
| project TimeGenerated, Conditions

If the inbox rules target generic financial keywords (not Meridian-specific): the attacker was monitoring ALL vendor payment threads, not just Meridian. Other vendors may have received fraudulent bank detail change requests. Expand the investigation scope to include all vendors a.patel communicates with about payments.

Subsection artifact: The 4 email thread analysis queries above. These form the email analysis section of your BEC investigation playbook.

Knowledge check

Identifying attacker reconnaissance patterns

The MailItemsAccessed data tells you how many emails the attacker read. The inbox rules tell you which keywords they targeted. Combining these two data sources reveals the attacker’s reconnaissance strategy.

Pattern: Targeted reconnaissance. The attacker created an inbox rule targeting “meridian” and accessed 50-100 emails over 3 days. They focused on a single vendor relationship. This suggests: the attacker identified Meridian as a high-value target (large pending invoice) and invested time understanding the payment process before striking.

Pattern: Broad reconnaissance. The attacker created inbox rules targeting generic financial keywords (“invoice,” “payment,” “bank”) and accessed 500+ emails over 2 weeks. They monitored all vendor payment threads, not just Meridian. This suggests: the attacker was evaluating multiple targets and chose the one with the best opportunity (highest amount, simplest approval process, closest payment date).

Pattern: Opportunistic. The attacker created no inbox rules but accessed the mailbox briefly (20-30 emails in a single session). They found the Meridian invoice thread by browsing recent emails and acted quickly. This suggests: a less sophisticated attacker or one with limited time — possibly because the compromised access was detected and revoked quickly, forcing them to act before full reconnaissance.

The reconnaissance pattern tells you: how long the attacker had access (dwell time), how many vendors may have been targeted (scope), and how sophisticated the operation was (informs your detection engineering priorities).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

// Reconstruct the attacker's email reading pattern over time
CloudAppEvents
| where TimeGenerated > ago(30d)
| where ActionType == "MailItemsAccessed"
| where AccountObjectId in (
    SigninLogs
    | where UserPrincipalName == "a.patel@northgateeng.com"
    | distinct UserId
)
| extend ClientIP = tostring(parse_json(RawEventData).ClientIPAddress)
| where ClientIP !in ("192.0.2.10", "192.0.2.15")
| summarize EmailsRead = count() by bin(TimeGenerated, 1d)
| order by TimeGenerated asc

This daily breakdown shows the attacker’s activity pattern. A steady 20-30 emails per day over 2 weeks = methodical reconnaissance. A spike of 200 emails in a single day = rushed exfiltration or broad search.