THREAT-Recon-VishingPretextEmailFollowup

Low-Signal Pretext Email Followed by Voice Phishing Call to Same Target

Reconnaissance Last updated:

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.

What is THREAT-Recon-VishingPretextEmailFollowup Low-Signal Pretext Email Followed by Voice Phishing Call to Same Target?

Low-Signal Pretext Email Followed by Voice Phishing Call to Same Target (THREAT-Recon-VishingPretextEmailFollowup) maps to the Reconnaissance tactic — the adversary is trying to gather information they can use to plan future operations in MITRE ATT&CK.

This page provides production-ready detection logic for Low-Signal Pretext Email Followed by Voice Phishing Call to Same Target, covering the data sources and telemetry it touches: Email Gateway: Email Content, Application Log: Application Log Content, Microsoft Defender for Office 365 EmailEvents. The queries below are rated high severity at medium confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.

MITRE ATT&CK

Tactic
Reconnaissance
Microsoft Sentinel / Defender
kusto
let LookbackWindow = 24h;
let CorrelationWindow = 2h;
let PretextKeywords = dynamic(["helpdesk", "help desk", "it support", "service desk", "password expir", "password reset", "vpn access", "account verification", "ticket confirmation", "technical support", "account suspended", "mfa re-enrollment"]);
EmailEvents
| where TimeGenerated > ago(LookbackWindow)
| where (Subject has_any (PretextKeywords) or SenderDisplayName has_any (PretextKeywords))
| where AttachmentCount == 0
| where UrlCount <= 1
| where ThreatTypes !has "Malware" and ThreatTypes !has "Phish"
| project EmailTimestamp = TimeGenerated, RecipientEmailAddress, SenderFromAddress, SenderDisplayName, Subject, NetworkMessageId
| join kind=inner (
    PBXCallLog_CL
    | where TimeGenerated > ago(LookbackWindow)
    | project CallTimestamp = TimeGenerated, RecipientEmailAddress = TargetUserPrincipalName_s, CallerNumber_s, CallDirection_s, CallDurationSeconds_d
    | where CallDirection_s == "Inbound"
  ) on RecipientEmailAddress
| where CallTimestamp between (EmailTimestamp .. EmailTimestamp + CorrelationWindow)
| extend MinutesBetweenEmailAndCall = datetime_diff('minute', CallTimestamp, EmailTimestamp), CorrelationSource = "PBXCallLog"
| project EmailTimestamp, CallTimestamp, MinutesBetweenEmailAndCall, RecipientEmailAddress, SenderFromAddress, Subject, CallerNumber_s, CallDurationSeconds_d, NetworkMessageId, CorrelationSource
| union (
    EmailEvents
    | where TimeGenerated > ago(LookbackWindow)
    | where (Subject has_any (PretextKeywords) or SenderDisplayName has_any (PretextKeywords))
    | where AttachmentCount == 0
    | where UrlCount <= 1
    | where ThreatTypes !has "Malware" and ThreatTypes !has "Phish"
    | project EmailTimestamp = TimeGenerated, RecipientEmailAddress, SenderFromAddress, SenderDisplayName, Subject, NetworkMessageId
    | join kind=inner (
        ServiceDeskAudit_CL
        | where TimeGenerated > ago(LookbackWindow)
        | where Action_s in ("TicketCreated", "TicketUpdated", "PasswordReset", "MFAReset")
        | project TicketTimestamp = TimeGenerated, RecipientEmailAddress = User_s, Agent_s, Action_s
      ) on RecipientEmailAddress
    | where TicketTimestamp between (EmailTimestamp .. EmailTimestamp + CorrelationWindow)
    | extend MinutesBetweenEmailAndCall = datetime_diff('minute', TicketTimestamp, EmailTimestamp), CorrelationSource = "ServiceDeskTicket"
    | project EmailTimestamp, CallTimestamp = TicketTimestamp, MinutesBetweenEmailAndCall, RecipientEmailAddress, SenderFromAddress, Subject, CallerNumber_s = Agent_s, CallDurationSeconds_d = real(null), NetworkMessageId, CorrelationSource
  )
| sort by EmailTimestamp desc

Two-pillar correlation detection joining low-signal, pretext-themed inbound email (helpdesk/IT-support/password-reset/VPN-themed subject or sender, no attachment, at most one URL, not already flagged by content-based phishing/malware filtering) against telephony and ticketing-system telemetry for the same recipient within a two-hour window. Pillar 1 correlates against inbound PBX/UC call records (PBXCallLog_CL, a custom-ingested table from the organization's telephony platform); Pillar 2 correlates against helpdesk ticketing-system audit records (ServiceDeskAudit_CL) for a ticket created/updated or a password/MFA reset performed for the same user. Both custom tables must be ingested into the workspace via a Data Collector API, Logic App, or equivalent connector from the PBX/UC platform and ticketing system respectively.

high severity medium confidence

Data Sources

Email Gateway: Email Content Application Log: Application Log Content Microsoft Defender for Office 365 EmailEvents

Required Tables

EmailEvents PBXCallLog_CL ServiceDeskAudit_CL

False Positives

  • Genuine IT helpdesk-initiated password-expiry or VPN-access-renewal email campaigns that are legitimately followed by the employee calling the real helpdesk about the same issue
  • Employees who received an unrelated pretext-themed email and separately, coincidentally, have an inbound personal or business call logged in the same window
  • Managed service provider (MSP) or outsourced IT support workflows where an automated ticket-confirmation email is a standard, expected precursor to a support callback
  • Newly onboarded employees receiving routine IT-onboarding emails (VPN setup, account verification) who then call the real helpdesk with setup questions
  • Internal security-awareness vishing-simulation exercises that intentionally pair a pretext email with a follow-up test call

Sigma rule & cross-platform mapping

The detection logic for Low-Signal Pretext Email Followed by Voice Phishing Call to Same Target (THREAT-Recon-VishingPretextEmailFollowup) above is provided in a vendor-neutral form so you can deploy it on any SIEM. The same logic is shipped here as native KQL (Microsoft Sentinel / Defender), SPL (Splunk), Elastic (Elastic Security (EQL)), QRadar (IBM QRadar (AQL)), Sumo (Sumo Logic CSE), YARA-L (Google Chronicle / SecOps), LogScale (CrowdStrike LogScale (CQL)) queries. In Sigma terms, this detection targets the following logsource:

logsource:
  product: azure

Browse the community-maintained Sigma rules for this technique:


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.

  1. 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.

  2. 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.

  3. 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.


Response Playbook

Triage

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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

  1. The full pretext email including headers, sending infrastructure (SPF/DKIM/DMARC results), and any embedded URL or tracking pixel.
  2. PBX/UC call detail records (CDR) for the correlated inbound call: caller ID, carrier/trunk, duration, and recorded audio/transcript if available.
  3. Helpdesk ticketing-system audit trail: ticket creation/update timestamps, the agent who handled it, and the verification steps performed (or bypassed) before any reset.
  4. 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.
  5. 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

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).

Hunting — KQL
kql
// 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 desc
Hunting — SPL
spl
search 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 - CorrelatedCallCount

Campaign-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.

Hunting — KQL
kql
// 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 desc
Hunting — SPL
spl
search 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 - RecipientCount

Atomic Red Team Tests

Test 1 Low-Signal Pretext Email with No Attachment and Zero URLs
windows

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
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.

Test 2 Simulated Inbound PBX Call Record Correlated to the Pretext Email Recipient
linux

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

bash
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.jsonl

Cleanup

bash
rm -f /tmp/atomic_pbx_call_log.jsonl

Expected 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.

Test 3 Simulated Ticketing-System Password Reset Correlated to the Pretext Email Recipient
linux

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

bash
echo '{"Action":"PasswordReset","User":"[email protected]","Agent":"atomic-test-agent","timestamp":"'$(date -u +%Y-%m-%dT%H:%M:%SZ)'"}' >> /tmp/atomic_servicedesk_audit.jsonl

Cleanup

bash
rm -f /tmp/atomic_servicedesk_audit.jsonl

Expected 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.

Related Detections