logon-attempts-after-malicious-email

Hunt Hypothesis

Adversaries may be attempting to compromise user accounts by logging on shortly after receiving malicious emails to exfiltrate data or establish persistence. SOC teams should proactively hunt for this behavior in Azure Sentinel to identify potential credential theft or lateral movement tactics early.

KQL Query

//Find logons that occurred right after malicious email was received
let MaliciousEmail=EmailEvents
| where ThreatTypes has_cs "Malware" 
| project TimeEmail = Timestamp, Subject, SenderFromAddress, AccountName = tostring(split(RecipientEmailAddress, "@")[0]);
MaliciousEmail
| join (
IdentityLogonEvents
| project LogonTime = Timestamp, AccountName, DeviceName
) on AccountName 
| where (LogonTime - TimeEmail) between (0min.. 30min)
| take 10

Analytic Rule Definition

id: 44a5c680-d2ac-4bed-8210-c3aafea47308
name: logon-attempts-after-malicious-email
description: |
  This query finds the 10 latest logons performed by email recipients within 30 minutes after they received known malicious emails. You can use this query to check whether the accounts of the email recipients have been compromised.
requiredDataConnectors:
- connectorId: MicrosoftThreatProtection
  dataTypes:
  - EmailEvents
  - IdentityLogonEvents
tactics:
- Credential Access
query: |
  //Find logons that occurred right after malicious email was received
  let MaliciousEmail=EmailEvents
  | where ThreatTypes has_cs "Malware" 
  | project TimeEmail = Timestamp, Subject, SenderFromAddress, AccountName = tostring(split(RecipientEmailAddress, "@")[0]);
  MaliciousEmail
  | join (
  IdentityLogonEvents
  | project LogonTime = Timestamp, AccountName, DeviceName
  ) on AccountName 
  | where (LogonTime - TimeEmail) between (0min.. 30min)
  | take 10

Required Data Sources

MITRE ATT&CK Context

• Tactic: Credential Access

References

• [Source Query](https://github.com/Azure/Azure-Sentinel/blob/main/Hunting Queries/Microsoft 365 Defender/Credential Access/logon-attempts-after-malicious-email.yaml)

False Positive Guidance

• Scenario: Scheduled System Maintenance Job
  Description: A legitimate scheduled job runs a maintenance script that logs in via email notification, triggering the rule because the login occurs shortly after a known malicious email was sent to the admin.
  Filter/Exclusion: Exclude logons associated with scheduled tasks or system maintenance jobs using the process.name field (e.g., schtasks.exe, task scheduler, or maintenance-script.sh).

• Scenario: Email-Based Password Reset via Service Desk
  Description: An employee receives a malicious-looking email that mimics the company’s password reset tool, but the user actually initiates a legitimate password reset via the service desk portal, which logs in after the email.
  Filter/Exclusion: Exclude logons that occur after email interactions with the service desk or password reset systems (e.g., service-desk@company.com, password-reset@company.com).

• Scenario: Admin Task Triggered by Email Alert
  Description: An admin receives a malicious email that appears to be from a monitoring tool, but the admin then logs in to check the system using a legitimate admin tool (e.g., Splunk, SIEM, or monitoring dashboard).
  Filter/Exclusion: Exclude logons that occur after email interactions with known admin tools (e.g., splunk, siem, monitoring-dashboard, or alert@company.com).

• Scenario: Email Notification for a Scheduled Report
  Description: A user receives an email notification that a report has been generated, and shortly after, they log in to download the report using a legitimate reporting tool (e.g., Power BI, Tableau, or a custom reporting system).
  Filter/Exclusion: Exclude logons that occur after email notifications related to scheduled reports (e.g., report@company.com, Power BI, `Tableau