Detect Impersonation Domains Acquired to Support Voice Phishing Helpdesk Social Engineering in Microsoft Sentinel
Ahead of a voice-phishing (vishing) campaign, actors such as Scattered Spider register a small cluster of domains that impersonate the target organization's IT helpdesk, SSO portal, or MFA self-service enrollment page (e.g., victimcorp-helpdesk[.]com, victimcorp-sso-verify[.]com, victimcorp-okta[.]net). These domains are stood up shortly before the actor calls or SMS-messages an employee — typically posing as IT support — and directs them to the lookalike page to 'verify their identity' or 're-enroll MFA,' harvesting credentials and a live MFA/push-approval in the process. Because the domain is freshly registered specifically for this operation, it has no browsing history in the target environment prior to the campaign, making the very first DNS query or HTTP request to it a high-value signal. Detection focuses on three pillars: (1) DNS/HTTP traffic to domains combining the organization's brand name with helpdesk/SSO/MFA-themed keywords, (2) first-time-ever resolution of such a domain within the environment (no prior 30-day history), and (3) close temporal correlation between a phone-based social-engineering contact recorded in the ticketing/telephony system and a subsequent authentication event or password/MFA reset for the same user.
MITRE ATT&CK
- Tactic
- Resource Development
KQL Detection Query
// THREAT-Infra-VishingHelpdeskDomains (T1583.001) - Impersonation domains for helpdesk/SSO vishing social engineering
// Pillar 1: DNS queries to domains combining org brand + helpdesk/SSO/MFA keywords
let OrgBrand = "victimcorp"; // CUSTOMIZE: replace with your organization's brand token(s)
let HelpdeskKeywords = dynamic([
"helpdesk", "help-desk", "servicedesk", "service-desk", "itsupport", "it-support",
"sso", "okta", "duo", "mfa", "authenticator", "verify", "identity", "reset-password", "password-reset"
]);
DnsEvents
| where TimeGenerated > ago(24h)
| where ResultCode == 0
| where Name has OrgBrand and Name has_any (HelpdeskKeywords)
| extend SuspicionReason = "BrandPlusHelpdeskKeywordDomain"
| project TimeGenerated, Computer, ClientIP, QueryName=Name, ResolvedIPs=IPAddresses, SuspicionReason
| union (
// Pillar 2: First-ever resolution in the environment for a domain matching the brand+keyword pattern (no history in prior 30 days)
DnsEvents
| where TimeGenerated > ago(24h)
| where Name has OrgBrand and Name has_any (HelpdeskKeywords)
| join kind=leftanti (
DnsEvents
| where TimeGenerated between (ago(30d) .. ago(24h))
| distinct Name
) on Name
| extend SuspicionReason = "FirstEverResolutionOfBrandLookalike", ClientIP = ClientIP, ResolvedIPs = IPAddresses
| project TimeGenerated, Computer, ClientIP, QueryName=Name, ResolvedIPs, SuspicionReason
)
| sort by TimeGenerated descTwo-pillar DNS-based detection for helpdesk/SSO impersonation domains registered to support a vishing campaign. Pillar 1 flags any DNS query for a domain containing both the organization's brand token and a helpdesk/SSO/MFA-themed keyword. Pillar 2 narrows to domains matching that same pattern with no resolution history in the prior 30 days within the environment — since a domain registered specifically for an imminent vishing call will, by definition, have zero prior organizational DNS history. Requires the OrgBrand variable to be customized per deployment.
Data Sources
Required Tables
False Positives & Tuning
- The organization's own legitimate IT helpdesk or SSO portal subdomains if they happen to combine the brand token with a helpdesk/SSO keyword (add these to a static allowlist)
- Third-party vendor portals contracted for IT support or identity services that legitimately reference the org's brand in a co-branded subdomain
- Security awareness/phishing-simulation platforms standing up brand-lookalike domains for authorized internal training campaigns
- Newly onboarded SaaS identity tooling (e.g., a new Okta or Duo tenant subdomain) resolved for the first time during legitimate rollout
Other platforms for THREAT-Infra-VishingHelpdeskDomains
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 1DNS Query to Brand-Plus-Helpdesk-Keyword Lookalike Domain
Expected signal: Sysmon Event ID 22: DNS Query event with QueryName='victimcorp-helpdesk-verify.com'. The query will likely NXDOMAIN but the DNS attempt is logged regardless.
- Test 2First-Ever Resolution of SSO-Themed Lookalike Domain
Expected signal: Sysmon Event ID 22: QueryName='victimcorp-sso-mfa-reset.net' with no prior resolution history for this exact name in the environment's DNS logs.
- Test 3Simulated Ticketing-System MFA Reset Correlated to a Risk Event
Expected signal: A synthetic ticketing-audit JSON line simulating an MFAMethodAdded action for [email protected] — in a real environment this would be ingested into the SIEM's ServiceDeskAudit_CL-equivalent index.
Response Playbook
Triage
- Identify the user and endpoint that queried/visited the domain, and immediately check whether that user received an unexpected phone call, SMS, or Teams/Slack message from someone claiming to be IT support in the hours before or after the query.
- Check the organization's telephony/contact-center or IT ticketing system for any inbound or outbound call logged around the same timeframe that does not correspond to a legitimate, user-initiated helpdesk ticket.
- Determine whether the user submitted any credentials or approved an MFA push/enrollment on the suspicious domain — review browser form-submission telemetry and any subsequent successful authentication event on the REAL SSO/IdP for that user immediately after.
- Pull WHOIS/RDAP registration data for the domain: registration date (expect within days of the incident), registrar, and privacy-protection status — a domain registered within 72 hours of the call is very high confidence malicious.
- Check Conditional Access/IdP sign-in logs for the affected user for any new MFA method registration, password reset, or sign-in from an unfamiliar device/location/ISP immediately following the suspected vishing contact.
- Cross-reference the destination IP the domain resolves to against other detections/threat intel — Scattered Spider and similar actors frequently reuse hosting infrastructure across multiple lookalike domains in the same campaign wave.
- If a helpdesk ticket or password/MFA reset was actually processed for this user around the same time, verify through an out-of-band channel (not phone/email, which may be compromised) that the request was genuinely initiated by the employee.
Containment
- If credential submission or MFA approval on the lookalike page is confirmed or suspected: immediately force a password reset via an out-of-band, verified channel and revoke all active sessions/refresh tokens for the affected account.
- Suspend or place a hold on any MFA method changes, new device registrations, or password resets for the affected user pending verified identity confirmation — this directly disrupts the Scattered Spider helpdesk-reset playbook.
- Block the impersonation domain and its resolved IP at DNS resolver, proxy, and firewall; submit takedown requests to the registrar and hosting provider given the clear-cut brand impersonation.
- Alert the real IT helpdesk/service desk team to be on heightened alert for social-engineering call-backs, since actors frequently follow up a failed vishing attempt with a real helpdesk call attempting the same credential/MFA reset pretext.
- If the actor obtained a live session, hunt immediately for the fast follow-on activity typical of this actor set: enumeration of Okta/Entra admin consoles, SIM-swap-adjacent MFA method additions, or immediate access to VPN/citrix/RDP gateways.
- Notify the security awareness team to issue a targeted alert to staff about the specific pretext and domain observed, since these campaigns are frequently waved across many employees in a short window.
Evidence Collection
- DNS/proxy logs for the impersonation domain: querying host, user, timestamp, and resolved IP.
- Telephony/contact-center call detail records (CDRs) or IT ticketing system logs for any call/ticket touching the affected user around the incident window.
- IdP/SSO sign-in logs (Entra ID Sign-in Logs, Okta System Log) for the affected user: authentication method, device, IP/ASN, and any MFA method registration events in the surrounding hours.
- WHOIS/RDAP registration record and certificate transparency log entries for the impersonation domain, establishing registration recency.
- Browser history/cache and any captured form-submission telemetry if the user interacted with the lookalike page.
- Any recorded call audio or chat transcript from the contact-center system, if the vishing call was placed through a monitored corporate line.
Escalation Criteria
- !Confirmed or strongly suspected credential and/or MFA approval on the lookalike domain, especially if followed by a successful sign-in on the real IdP shortly after.
- !A new MFA method (phone number, authenticator app) was registered for the affected account in the surrounding window without independently verified user intent.
- !The affected user holds privileged access (Domain Admin, cloud tenant admin, help desk technician with reset authority) — Scattered Spider specifically targets help desk staff to pivot into broader account-reset capability.
- !Multiple employees report similar vishing contacts referencing the same or structurally similar impersonation domain within a short window, indicating an active, organization-wide campaign wave.
- !Post-authentication telemetry shows enumeration of identity administration consoles, SIM-swap-adjacent activity, or rapid pivot toward VPN/remote-access infrastructure — consistent with the known Scattered Spider/Muddled Libra playbook.
Investigation Guide
Related Techniques
Forensic Artifacts
- >
DNS resolver logs and Sysmon Event ID 22 for the first resolution of the impersonation domain within the environment. - >
Entra ID / Okta Sign-in and Audit logs showing authentication attempts, MFA registration, and any admin-console access for the affected account. - >
Contact-center/telephony CDRs and any call-recording system logs correlating the timing of the social-engineering contact. - >
IT service-desk ticketing system records for any password/MFA reset ticket touching the affected user, including the agent who processed it and the verification method used (or bypassed). - >
Browser form-submission and navigation history for the lookalike domain, if the interaction occurred on a monitored corporate device. - >
WHOIS/RDAP history and certificate transparency logs establishing the domain's registration and TLS issuance timeline relative to the incident.
Tuning Guidance
This detection is intentionally scoped to the organization's own brand token combined with authentication-themed keywords, so false-positive volume should be low once the OrgBrand variable is correctly configured — but requires per-tenant customization to be useful at all. Tuning recommendations: (1) Populate OrgBrand with all common variants of your organization's name (full name, common abbreviation, stock ticker) since actors vary which form they impersonate; (2) Maintain an explicit allowlist of your actual legitimate helpdesk/SSO subdomains to suppress Pillar 1 noise from real infrastructure; (3) The first-seen pillar (Pillar 2) is the highest-fidelity signal — prioritize alerting and consider auto-escalating it to phone verification of the affected user rather than routing through standard triage, given the narrow window actors operate in during an active vishing wave; (4) Where the organization has telephony/CDR or ticketing system logs available, prioritize building the correlation hunting query into a standing detection rather than a manual hunt, since the help-desk-processed-the-reset scenario is this actor set's actual objective and the highest-impact outcome to catch; (5) Brief the help desk team directly on this specific pretext pattern — technical detection alone cannot prevent an agent from being socially engineered into performing the reset themselves, and human-layer controls (callback verification, video identity confirmation) are the primary mitigation for the actual objective this infrastructure supports.
Hunting Queries
Broad 30-day hunt for any brand+authentication-keyword domain, independent of the first-seen-in-24h narrowing used in the primary detection — useful for retroactive campaign scoping once a specific impersonation domain has been identified, to find earlier reconnaissance-stage queries.
// Hunt: Newly-registered-pattern domains combining brand token with any authentication/support keyword, over a 30-day window
let OrgBrand = "victimcorp"; // CUSTOMIZE
DnsEvents
| where TimeGenerated > ago(30d)
| where Name has OrgBrand
| where Name has_any ("helpdesk", "support", "sso", "okta", "duo", "mfa", "verify", "identity", "reset", "portal")
| summarize QueryCount=count(), UniqueClients=dcount(ClientIP), FirstSeen=min(TimeGenerated), SampleClients=make_set(ClientIP, 10) by Name
| order by FirstSeen descindex=sysmon sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=22
| eval OrgBrand="victimcorp"
| eval QueryLower=lower(QueryName)
| where like(QueryLower, "%".OrgBrand."%")
| where match(QueryLower, "(helpdesk|support|sso|okta|duo|mfa|verify|identity|reset|portal)")
| stats count as QueryCount, dc(host) as UniqueClients, earliest(_time) as FirstSeen, values(host) as SampleClients by QueryName
| sort - FirstSeenHunt correlating help-desk-processed password/MFA reset tickets with subsequent identity-risk events for the same user within a 60-minute window — surfaces cases where a successful vishing call resulted in the real help desk performing the reset the actor requested, which the primary DNS-based detection cannot observe directly. Requires the ticketing system's audit trail to be ingested into the SIEM.
// Hunt: MFA method registration events within 60 minutes of a helpdesk/service-desk ticket update for the same user
let TicketEvents = ServiceDeskAudit_CL // adjust to your ticketing system's ingested table
| where TimeGenerated > ago(7d)
| where Action_s in ("PasswordReset", "MFAReset", "MFAMethodAdded")
| project TicketTime=TimeGenerated, UserPrincipalName=User_s, Agent=Agent_s;
AADUserRiskEvents
| where TimeGenerated > ago(7d)
| join kind=inner TicketEvents on UserPrincipalName
| where TimeGenerated between (TicketTime .. TicketTime + 60m)
| project TimeGenerated, TicketTime, UserPrincipalName, Agent, RiskEventType, RiskLevelindex=servicedesk sourcetype="ticketing_audit" Action IN ("PasswordReset","MFAReset","MFAMethodAdded")
| rename User as UserPrincipalName, _time as TicketTime
| join type=inner UserPrincipalName
[ search index=aad sourcetype="AADUserRiskEvents" | rename _time as RiskTime ]
| where (RiskTime - TicketTime) >= 0 AND (RiskTime - TicketTime) <= 3600
| table TicketTime, RiskTime, UserPrincipalName, Agent, RiskEventTypeAtomic Red Team Tests
Resolves a domain combining a placeholder brand token with a helpdesk-themed keyword, simulating the DNS telemetry generated when an employee, following a vishing call, navigates to an actor-registered impersonation portal.
Command
nslookup victimcorp-helpdesk-verify.com 8.8.8.8Expected Telemetry
Sysmon Event ID 22: DNS Query event with QueryName='victimcorp-helpdesk-verify.com'. The query will likely NXDOMAIN but the DNS attempt is logged regardless.
Expected Detection
KQL/SPL Pillar 1 fires on brand token 'victimcorp' plus keyword 'helpdesk'/'verify' match, SuspicionReason=BrandPlusHelpdeskKeywordDomain. Adjust the OrgBrand variable to 'victimcorp' (or run against your own configured brand token) before testing.
Resolves a distinct, never-before-queried domain combining the brand token with an SSO/MFA keyword, validating the first-seen-in-environment pillar of the detection which specifically targets domains with no prior 30-day resolution history.
Command
powershell.exe -Command "Resolve-DnsName 'victimcorp-sso-mfa-reset.net' -Type A -ErrorAction SilentlyContinue"Expected Telemetry
Sysmon Event ID 22: QueryName='victimcorp-sso-mfa-reset.net' with no prior resolution history for this exact name in the environment's DNS logs.
Expected Detection
KQL/SPL Pillar 2 fires because the domain has zero resolution history in the prior 30 days, SuspicionReason=FirstEverResolutionOfBrandLookalike. This is the highest-fidelity pillar and should be the primary alerting signal in production.
Writes a synthetic ticketing-audit record indicating an MFA reset action for a test user, then generates a benign sign-in event for the same user shortly after, exercising the hunting query that correlates helpdesk-processed resets with subsequent identity-risk events.
Command
echo '{"Action":"MFAMethodAdded","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 an MFAMethodAdded action for [email protected] — in a real environment this would be ingested into the SIEM's ServiceDeskAudit_CL-equivalent index.
Expected Detection
This atomic validates the shape of data the hunting-query correlation expects; it does not fire the primary KQL/SPL detections directly since it does not touch DNS telemetry. Use it to confirm your ticketing-system log pipeline populates the fields the hunting query references before relying on it operationally.
Related Detections
Tactic Hub
Detection Variants (2)
Different telemetry and tradecraft for the same technique — pick the one that matches the data you collect.