Detect Email Accounts in Splunk
Adversaries may compromise existing email accounts to support operations. Unlike creating new accounts, compromising legitimate accounts leverages established trust relationships, bypasses reputation-based email filters, and enables thread hijacking. Compromise methods include credential phishing, password reuse from breach dumps, brute force, and insider access (buying credentials from employees). Threat actors including APT28, APT29, Kimsuky, OilRig, Star Blizzard, and LAPSUS$ have all used compromised email accounts to conduct spearphishing, harvest additional credentials, and acquire infrastructure. Because the compromise itself occurs externally, detection must focus on observable post-compromise behaviors within the organization: risky sign-in patterns, impossible travel, inbox rule manipulation, bulk sending anomalies, and thread hijacking indicators.
MITRE ATT&CK
- Tactic
- Resource Development
- Technique
- T1586 Compromise Accounts
- Sub-technique
- T1586.002 Email Accounts
- Canonical reference
- https://attack.mitre.org/techniques/T1586/002/
SPL Detection Query
| union
[
search index=o365 sourcetype="o365:management:activity" Operation IN ("UserLoggedIn", "MailboxLogin")
| eval risk_country=mvfield(ClientInfo, "CountryCode")
| eval detection_branch="SignInActivity"
]
[
search index=o365 sourcetype="o365:management:activity" Operation IN ("New-InboxRule", "Set-InboxRule", "UpdateInboxRules", "Set-Mailbox")
| eval detection_branch="InboxRuleManipulation"
]
[
search index=o365 sourcetype="o365:management:activity" Operation="Send" Workload="Exchange"
| eval detection_branch="EmailSend"
]
```
// Actual primary query — risky sign-ins and inbox manipulation:
index=o365 sourcetype="o365:management:activity"
(Operation IN ("UserLoggedIn", "MailboxLogin") OR
Operation IN ("New-InboxRule", "Set-InboxRule", "UpdateInboxRules", "Set-Mailbox") OR
Operation="Send")
| eval user=coalesce(UserId, Actor{}.ID)
| eval src_ip=ClientIP
| eval operation=Operation
| eval workload=Workload
| eval parameters=Parameters
// Branch 1: Inbox rule manipulation (forwarding/deletion rules)
| eval inbox_rule_flag=if(
(operation IN ("New-InboxRule", "Set-InboxRule", "UpdateInboxRules", "Set-Mailbox")) AND
(match(parameters, "(?i)(ForwardTo|ForwardAsAttachmentTo|RedirectTo|DeleteMessage|MarkAsRead)")),
1, 0)
// Branch 2: Bulk sending anomaly — count sends per user per hour
| eval is_send=if(operation="Send" AND workload="Exchange", 1, 0)
| bin _time span=1h
| stats
count(eval(is_send=1)) as emails_sent,
values(src_ip) as src_ips,
values(operation) as operations,
max(inbox_rule_flag) as has_inbox_rule,
earliest(_time) as first_seen,
latest(_time) as last_seen
by user, _time
| eval bulk_send_flag=if(emails_sent >= 50, 1, 0)
| eval detection_score=has_inbox_rule + bulk_send_flag
| where detection_score > 0 OR has_inbox_rule=1
| eval detection_branches=if(has_inbox_rule=1, "InboxRuleManipulation ", "") . if(bulk_send_flag=1, "BulkEmailSending", "")
| table first_seen, user, src_ips, emails_sent, operations, has_inbox_rule, bulk_send_flag, detection_branches, detection_score
| sort - detection_score, - emails_sentDetects compromised email account post-exploitation using Microsoft 365 Unified Audit Log (o365:management:activity sourcetype). Primary detection branches: (1) inbox rule creation with forwarding, deletion, or redirect actions — a hallmark of adversaries maintaining persistent email access after compromise, and (2) bulk outbound email sending anomalies suggesting the account is being used for phishing distribution. The query bins activity by hour and scores each user based on multiple suspicious indicators. Higher scores indicate stronger compromise confidence.
Data Sources
Required Sourcetypes
False Positives & Tuning
- Legitimate bulk email tools (newsletters, CRM systems) that relay through Exchange and generate high send counts per hour
- IT administrators creating forwarding rules during mailbox migrations, employee offboarding, or shared mailbox configuration
- Automated business workflows (ticketing systems, alert routing) that create inbox rules programmatically
- Marketing or sales staff conducting legitimate email campaigns with high recipient counts
- Service desk accounts that legitimately receive and process high volumes of inbound email with auto-routing rules
Other platforms for T1586.002
Testing Methodology
Validate this detection against 4 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.
- Test 1Simulate Compromised Account Inbox Rule Creation
Expected signal: Office 365 Unified Audit Log: Operation='New-InboxRule', UserId='[email protected]', Parameters containing 'ForwardTo' and '[email protected]'. Event appears in OfficeActivity table in Sentinel within ~15 minutes of creation. ClientIP will reflect the machine running the PowerShell session.
- Test 2Credential Spray Simulation Against Exchange Online
Expected signal: Azure AD SigninLogs: multiple entries with ResultType='50126' (invalid credentials) or '50055' for target UserPrincipalName from the executing machine's IP address. AppDisplayName will show 'Exchange Web Services' or 'Outlook'. AuthenticationProtocol will show 'Legacy' indicating Basic Auth. Failed attempts trigger Azure AD Identity Protection spray detection after threshold.
- Test 3Simulate Bulk Email Send from Compromised Account
Expected signal: OfficeActivity table: multiple Operation='Send' entries from [email protected] within a 1-hour window, UserId matching the test account, ClientIP matching the executing machine. Email count will exceed the BulkSendThreshold (50) for the hourly bucket, triggering the bulk sending branch.
- Test 4Verify Impossible Travel Detection Using VPN Geo-Shift
Expected signal: Azure AD SigninLogs: two entries for the test account within ~20 minutes showing different Location.countryOrRegion values (e.g. 'United States' and 'Germany'). ResultType='0' for both (successful). Azure AD Identity Protection may independently raise a 'impossibleTravel' risk detection within minutes.
References (10)
- https://attack.mitre.org/techniques/T1586/002/
- https://learn.microsoft.com/en-us/azure/active-directory/identity-protection/concept-identity-protection-risks
- https://learn.microsoft.com/en-us/microsoft-365/security/defender/advanced-hunting-officeactivity-table
- https://learn.microsoft.com/en-us/azure/azure-monitor/reference/tables/signinlogs
- https://www.microsoft.com/security/blog/2022/03/22/dev-0537-criminal-actor-targeting-organizations-for-data-exfiltration-and-destruction/
- https://services.google.com/fh/files/blogs/google_threat_horizons_report_#7_march_2022.pdf
- https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-347a
- https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1586.002/T1586.002.md
- https://www.mandiant.com/resources/blog/apt29-microsoft-365
- https://learn.microsoft.com/en-us/exchange/policy-and-compliance/mailbox-audit-logging/mailbox-audit-logging
Unlock Pro Content
Get the full detection package for T1586.002 including response playbook, investigation guide, and atomic red team tests.