Detect Low-Signal Pretext Email Followed by Voice Phishing Call to Same Target in CrowdStrike LogScale
Ahead of a voice-phishing (vishing) attempt, actors frequently send a low-signal reconnaissance or spearphishing-link email to a target employee — often themed as an IT helpdesk notice, password-expiry warning, VPN access request, or service-desk ticket confirmation — that by itself carries little malicious payload (no attachment, a benign or absent link, generic wording) and is easily missed by content-based email filtering. The email's real purpose is to prime the target and establish a plausible pretext ('I'm following up on the ticket I just emailed you about') before the actor places a phone call posing as IT support, a vendor, or a colleague to harvest credentials, MFA codes, or internal information directly from the target. Because neither artifact alone is highly suspicious — a generic IT-themed email and an inbound support call are both routine — the highest-fidelity signal is the temporal correlation between the two: the same recipient receiving a pretext-themed email and then being the subject of an inbound call logged in the PBX/UC platform or a new/updated ticketing-system entry referencing them, within a short window (typically under two hours). Detection focuses on three pillars: (1) identifying low-signal, pretext-themed inbound email to a recipient, (2) correlating that recipient with an inbound call record in PBX/UC/telephony logs shortly afterward, and (3) correlating with a helpdesk/ticketing-system entry created or updated for the same user in the same window, since actors sometimes have the (socially engineered) helpdesk agent open the ticket rather than placing the call themselves.
MITRE ATT&CK
- Tactic
- Reconnaissance
LogScale Detection Query
#event_simpleName=EmailReceived
| Subject=/(?i)(helpdesk|help desk|password reset|vpn access|service desk|account verification)/
| AttachmentCount=0
| rename(field="RecipientEmailAddress", as="CorrelationKey")
| join(query={#event_simpleName=PbxCallInbound | rename(field="TargetUserPrincipalName", as="CorrelationKey")}, field=[CorrelationKey], key=CorrelationKey, mode=inner)
| SecondsBetween := CallTimestamp - EmailTimestamp
| test(SecondsBetween >= 0 && SecondsBetween <= 7200)
| table([EmailTimestamp, CallTimestamp, CorrelationKey, Subject, CallerNumber, SecondsBetween])
| sort(EmailTimestamp, order=desc)CrowdStrike LogScale (Falcon) query correlating pretext-themed inbound email events with subsequent inbound PBX call events for the same recipient within a two-hour window, requiring both the email gateway and PBX/UC platform to be ingested as LogScale repositories.
Data Sources
Required Tables
False Positives & Tuning
- Legitimate helpdesk notification-then-callback workflows
- Coincidental unrelated inbound calls within the correlation window
- Outsourced MSP ticket-confirmation-then-call sequences
Other platforms for THREAT-Recon-VishingPretextEmailFollowup
Testing Methodology
Validate this detection against 3 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 1Low-Signal Pretext Email with No Attachment and Zero URLs
Expected signal: EmailEvents record with Subject containing 'Service Desk Ticket Confirmation' and 'Password Reset', AttachmentCount=0, UrlCount=0, from a sender display name/domain matching helpdesk-themed keywords.
- Test 2Simulated Inbound PBX Call Record Correlated to the Pretext Email Recipient
Expected signal: A synthetic PBX call-log JSON line simulating an inbound call to [email protected] — in a real environment this would be ingested into the SIEM's PBXCallLog_CL-equivalent custom table.
- Test 3Simulated Ticketing-System Password Reset Correlated to the Pretext Email Recipient
Expected signal: A synthetic ticketing-audit JSON line simulating a PasswordReset action for [email protected] — in a real environment this would be ingested into the SIEM's ServiceDeskAudit_CL-equivalent table.
References (5)
- https://attack.mitre.org/techniques/T1598/004/
- https://attack.mitre.org/tactics/TA0043/
- https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-320a
- https://www.mandiant.com/resources/blog/unc3944-sms-phishing-sim-swapping-ransomware
- https://www.crowdstrike.com/blog/scattered-spider-social-engineering-tactics/
Response Playbook
Triage
- Pull the full headers and body of the flagged pretext email and confirm it matches the low-signal profile (no attachment, zero or one benign-looking URL, generic IT/helpdesk/support wording) rather than a standard commodity phish that content filtering would already have caught.
- Retrieve the correlated call record (PBX/UC CDR) or ticketing-system entry and note the caller ID/extension, claimed identity, call duration, and — if recorded — obtain the call audio or transcript.
- Interview the targeted employee (via a verified out-of-band channel, not by calling back the number from the suspicious call) about what information or credentials they were asked for and whether they provided any.
- Check the real IT helpdesk/service desk ticketing system to confirm whether a matching, employee-initiated ticket actually exists for this contact — the absence of a legitimate ticket is a strong indicator the call was a pretext follow-up rather than routine support.
- Review the target's authentication logs (Entra ID / Okta sign-in and audit logs) for any password reset, new MFA method registration, or unusual sign-in in the hours immediately following the correlated call.
- Check whether the same sender domain/display-name pattern and a similarly timed call have hit other recipients in the organization, indicating an active, wider vishing wave rather than an isolated incident.
- Assess the target's access level and role — help desk staff, finance, and privileged IT accounts are disproportionately targeted by this pretext-then-call pattern because they have the authority actors actually want to abuse.
Containment
- If the employee is confirmed or suspected to have disclosed a password, MFA code, or approved a push notification: force an immediate credential reset via a verified out-of-band channel and revoke all active sessions/refresh tokens for the account.
- Place a temporary hold on password resets, MFA method changes, and new device registrations for the affected user pending verified identity confirmation, since this is the actor's likely next move.
- Block the sending domain/address of the pretext email at the mail gateway and, where the caller ID/number is known and not spoofed from a legitimate source, flag it in the telephony platform for monitoring.
- Notify the real IT helpdesk/service desk team of the specific pretext observed so agents can recognize and refuse to action a matching social-engineering call-back attempt against the same or other users.
- If the actor obtained a live session or reset, hunt for immediate follow-on activity typical of vishing-driven initial access: enumeration of identity admin consoles, new MFA method additions, or access to VPN/Citrix/RDP gateways.
- Where the ticketing system shows the reset was actually performed by a (socially engineered) real agent, review and, if needed, temporarily tighten the identity-verification requirements for phone-based reset requests.
Evidence Collection
- The full pretext email including headers, sending infrastructure (SPF/DKIM/DMARC results), and any embedded URL or tracking pixel.
- PBX/UC call detail records (CDR) for the correlated inbound call: caller ID, carrier/trunk, duration, and recorded audio/transcript if available.
- Helpdesk ticketing-system audit trail: ticket creation/update timestamps, the agent who handled it, and the verification steps performed (or bypassed) before any reset.
- Entra ID / Okta sign-in and audit logs for the affected user spanning the email, call, and several hours after, covering authentication, MFA registration, and password-reset events.
- Any recorded interview notes or written statement from the targeted employee describing what was asked and disclosed during the call.
Escalation Criteria
- !Confirmed or strongly suspected disclosure of a password, MFA code, or push approval during the correlated call, especially if followed by a successful sign-in shortly after.
- !A password reset, MFA method change, or new device registration occurred for the account in the correlation window without independently verified employee intent.
- !The targeted user is a help desk agent, or holds privileged/administrative access, since actors specifically target help desk staff to pivot into broader account-reset capability for other users.
- !Multiple employees show the same email-then-call correlation pattern within a short window, indicating an active, organization-wide vishing campaign rather than an isolated attempt.
- !Post-call telemetry shows enumeration of identity administration consoles, rapid MFA-method churn, or pivot toward VPN/remote-access infrastructure consistent with known vishing-driven initial-access playbooks.
Investigation Guide
Related Techniques
Forensic Artifacts
- >
EmailEvents / mail-gateway logs for the low-signal pretext email, including sender infrastructure and authentication results. - >
PBX/UC call detail records and, where the organization records support calls, the audio or transcript of the correlated call. - >
Helpdesk ticketing-system audit trail showing ticket creation/update and any reset action taken, including the handling agent. - >
Entra ID / Okta sign-in and audit logs for the affected user around the email and call timestamps. - >
Any user-reported statement or awareness-training incident report describing the pretext used.
Tuning Guidance
This detection depends entirely on two custom-ingested telemetry sources (PBXCallLog_CL and ServiceDeskAudit_CL, or their SPL index equivalents) being onboarded from the organization's telephony/UC platform and ticketing system — without them, only the low-signal email pillar is observable and false-positive volume from routine IT correspondence will be high. Tuning recommendations: (1) Expand PretextKeywords to match the organization's actual internal IT/helpdesk terminology and any observed campaign-specific wording, since generic keyword lists drift out of date quickly; (2) Tighten or widen CorrelationWindow based on observed actor tradecraft in your environment — two hours is a reasonable starting point but some campaigns call within minutes while others wait until the next business day; (3) Maintain an allowlist of the organization's own legitimate helpdesk/vendor sending domains and known MSP support-call caller IDs to suppress routine, expected email-then-call sequences; (4) Prioritize alerting on the ServiceDeskAudit_CL correlation pillar (Pillar 2) above the raw PBX pillar, since a ticket that resulted in an actual password/MFA reset represents the actor's realized objective rather than a mere contact attempt; (5) Because the human-layer objective of this technique (a helpdesk agent or employee being verbally persuaded to disclose or reset a credential) cannot be fully prevented by telemetry correlation alone, pair this detection with mandatory callback/video identity verification procedures for any phone-initiated credential or MFA reset request.
Hunting Queries
Broad 30-day hunt widening the correlation window to 4 hours and summarizing by recipient, to retroactively scope a vishing campaign once one confirmed pretext-then-call incident has been identified, or to identify recipients who received the pretext email but for whom no call was yet logged (indicating either an unsuccessful attempt, a call placed outside monitored telephony, or reconnaissance-only targeting).
// Hunt: All pretext-themed emails in the last 30 days with ANY correlated PBX call or ticket within 4 hours, widened window for retroactive campaign scoping
let PretextKeywords = dynamic(["helpdesk", "help desk", "it support", "service desk", "password expir", "password reset", "vpn access", "account verification", "ticket confirmation"]);
EmailEvents
| where TimeGenerated > ago(30d)
| where Subject has_any (PretextKeywords) or SenderDisplayName has_any (PretextKeywords)
| project EmailTimestamp = TimeGenerated, RecipientEmailAddress, SenderFromAddress, Subject
| join kind=leftouter (
PBXCallLog_CL
| where TimeGenerated > ago(30d)
| project CallTimestamp = TimeGenerated, RecipientEmailAddress = TargetUserPrincipalName_s, CallerNumber_s
) on RecipientEmailAddress
| where isnull(CallTimestamp) or CallTimestamp between (EmailTimestamp .. EmailTimestamp + 4h)
| summarize EmailCount = dcount(NetworkMessageId), CallCount = countif(isnotnull(CallTimestamp)) by RecipientEmailAddress
| where EmailCount >= 1
| order by CallCount descsearch index=email sourcetype="o365:management:activity"
| eval PretextKeywords="helpdesk|help desk|it support|service desk|password expir|password reset|vpn access|account verification|ticket confirmation"
| where match(lower(Subject), PretextKeywords) OR match(lower(SenderDisplayName), PretextKeywords)
| eval EmailTimestamp=_time
| join type=left RecipientEmailAddress
[ search index=telephony sourcetype="pbx:call:log"
| rename TargetUserPrincipalName as RecipientEmailAddress, _time as CallTimestamp
| fields RecipientEmailAddress, CallTimestamp ]
| eval WithinWindow=if(isnotnull(CallTimestamp) AND (CallTimestamp-EmailTimestamp)>=0 AND (CallTimestamp-EmailTimestamp)<=14400, 1, 0)
| stats count as EmailCount, sum(WithinWindow) as CorrelatedCallCount by RecipientEmailAddress
| sort - CorrelatedCallCountCampaign-scoping hunt identifying a single sending domain used to reach three or more distinct recipients with pretext-themed subjects within a two-week window, useful for surfacing a wider vishing wave before every individual target has also received a correlated call.
// Hunt: Same sender infrastructure (domain) used against multiple distinct recipients within a short campaign window
EmailEvents
| where TimeGenerated > ago(14d)
| where Subject has_any ("helpdesk", "password reset", "vpn access", "account verification")
| summarize RecipientCount = dcount(RecipientEmailAddress), Recipients = make_set(RecipientEmailAddress, 20), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated) by SenderFromDomain
| where RecipientCount >= 3
| order by RecipientCount descsearch index=email sourcetype="o365:management:activity"
| where match(lower(Subject), "helpdesk|password reset|vpn access|account verification")
| stats dc(RecipientEmailAddress) as RecipientCount, values(RecipientEmailAddress) as Recipients, earliest(_time) as FirstSeen, latest(_time) as LastSeen by SenderFromDomain
| where RecipientCount >= 3
| sort - RecipientCountAtomic Red Team Tests
Simulates receipt of a low-signal, IT-helpdesk-themed pretext email carrying no attachment and no embedded link, validating that Pillar 1/2 keyword matching correctly flags subject-line and sender-display-name content without relying on payload-based indicators.
Command
powershell.exe -Command "$msg = New-Object System.Net.Mail.MailMessage; $msg.From = '[email protected]'; $msg.To.Add('[email protected]'); $msg.Subject = 'Service Desk Ticket Confirmation - Password Reset Follow-up'; $msg.Body = 'Your recent password reset ticket has been logged. Our support team will follow up shortly to verify your identity.'; Write-Output 'Simulated pretext email constructed (not sent) for telemetry validation.'"Expected Telemetry
EmailEvents record with Subject containing 'Service Desk Ticket Confirmation' and 'Password Reset', AttachmentCount=0, UrlCount=0, from a sender display name/domain matching helpdesk-themed keywords.
Expected Detection
KQL/SPL Pillar 1 matches on Subject/SenderDisplayName keyword hit with AttachmentCount==0 and UrlCount<=1; the email alone will not trigger a full alert until correlated with a call or ticket record in the same window.
Writes a synthetic PBX call-detail record for the same recipient shortly after the pretext email, exercising the Pillar 1 email-to-call correlation join.
Command
echo '{"TargetUserPrincipalName":"[email protected]","CallerNumber":"+1-555-0100","CallDirection":"Inbound","CallDurationSeconds":312,"timestamp":"'$(date -u +%Y-%m-%dT%H:%M:%SZ)'"}' >> /tmp/atomic_pbx_call_log.jsonlCleanup
rm -f /tmp/atomic_pbx_call_log.jsonlExpected Telemetry
A synthetic PBX call-log JSON line simulating an inbound call to [email protected] — in a real environment this would be ingested into the SIEM's PBXCallLog_CL-equivalent custom table.
Expected Detection
Validates the shape of data the Pillar 1 join expects; combined with the pretext-email atomic above and a matching timestamp within the CorrelationWindow, the join produces a correlated Pillar-1 detection row.
Writes a synthetic ticketing-audit record showing a password reset performed for the pretext-email recipient shortly after, exercising the Pillar 2 email-to-ticket correlation join covering the case where the vishing call resulted in a real helpdesk agent performing the reset.
Command
echo '{"Action":"PasswordReset","User":"[email protected]","Agent":"atomic-test-agent","timestamp":"'$(date -u +%Y-%m-%dT%H:%M:%SZ)'"}' >> /tmp/atomic_servicedesk_audit.jsonlCleanup
rm -f /tmp/atomic_servicedesk_audit.jsonlExpected Telemetry
A synthetic ticketing-audit JSON line simulating a PasswordReset action for [email protected] — in a real environment this would be ingested into the SIEM's ServiceDeskAudit_CL-equivalent table.
Expected Detection
Validates the shape of data the Pillar 2 join expects; confirm your ticketing-system log pipeline populates the User/Action/timestamp fields the query references before relying on this pillar operationally.