Detecting Help Desk Social Engineering: Vishing, Callback Phishing, and MFA Reset Abuse

Phone-based social engineering against IT help desks is one of the most effective initial access techniques in active use, and one of the least monitored. Groups like Scattered Spider (UNC3944) and LUNA Moth (Silent Ransom Group) have built entire operational playbooks around calling help desks, impersonating employees, and convincing support staff to reset MFA devices or passwords on their behalf. No exploit required. No phishing link. Just a convincing voice and knowledge of the target’s name and employee ID.

The detection gap is real. Most SIEM deployments have extensive coverage for endpoint and network-layer events, but thin or no coverage for the identity lifecycle changes that happen after a successful help desk call. This guide covers what to instrument and what to look for.

The Attack Chain

The canonical help desk social engineering chain has five steps:

1. Reconnaissance — attacker harvests employee name, title, and email from LinkedIn. Employee ID formats are often predictable (they show up in email signatures, HR portals, and leaked datasets). Some groups call the main company number to get employee IDs directly from a receptionist.
2. Vishing call — attacker calls the IT help desk impersonating the target employee, claims to be locked out or travelling, and requests a password reset or MFA device re-enrollment.
3. MFA bypass — help desk resets MFA or issues a temporary bypass code. With password and MFA both controlled, the attacker authenticates.
4. Session establishment — attacker logs in from a new device, establishes persistence (new MFA device registration, OAuth app consent, device join), and begins internal access.
5. Lateral movement — depends on access level. Enterprise admin accounts are common targets; once inside, groups like Scattered Spider move quickly to cloud infrastructure and data exfiltration.

Callback phishing (LUNA Moth’s specialty) adds a document lure: a fake invoice or IT notification tells the victim to call a number “for support.” The victim calls the attacker, who then remote-controls the victim’s machine or walks them through installing a legitimate RMM tool like AnyDesk. This is harder to detect at the SIEM level because the victim initiates everything.

What to Instrument

You need visibility into three log sources that are often under-integrated:

Directory audit logs — Azure Entra ID audit log or on-premises AD Security event log. The critical events are:

• MFA method added/changed (Entra audit: Update user with StrongAuthenticationMethod modified)
• Password reset by admin (distinct from self-service reset)
• Device registration (Entra: Add registered users to device)
• Role assignment (especially Global Admin, Privileged Role Administrator)

Ticketing system logs — If your help desk uses ServiceNow, Jira Service Management, or Zendesk, extract ticket creation and resolution events. Look for: ticket category “password reset” or “MFA reset,” tickets resolved in under five minutes (unusually fast for verification-complete workflows), tickets opened and closed by the same agent without supervisor approval.

Authentication logs — After a help desk reset, the attacker authenticates from a new IP, often in a different country. Correlate the MFA change event with the next successful login: new IP, new device fingerprint, no prior auth history.

Sigma Rules

MFA Device Added After Admin Password Reset

title: MFA Device Enrollment Following Admin-Initiated Password Reset
id: a3f2b891-cc74-4e1a-9f2d-7b3e5d8a1c90
status: experimental
description: Detects MFA device enrollment occurring within 30 minutes of an admin resetting a user's password — consistent with help desk social engineering.
logsource:
  product: azure
  service: auditlogs
detection:
  password_reset:
    ActivityDisplayName: "Reset user password"
    InitiatedBy.app: null
  mfa_add:
    ActivityDisplayName: "User registered security info"
  condition: password_reset and mfa_add
  timeframe: 30m
  same_target: TargetResources[0].userPrincipalName
falsepositives:
  - Legitimate IT-assisted MFA re-enrollment during onboarding
  - Travel/replacement device setup with IT help
level: medium
tags:
  - attack.t1556.006
  - attack.credential_access

New Country Login After MFA Change

title: Successful Authentication from New Country After MFA Method Change
id: b8d4c213-fa91-4b2e-8c7a-1e6f9a2d4b77
status: experimental
description: Detects successful login from a country not seen in the last 30 days, within 2 hours of an MFA method change. Indicates potential post-social-engineering access.
logsource:
  product: azure
  service: signinlogs
detection:
  new_country_login:
    ResultType: 0
    LocationDetails.countryOrRegion|not_in_history: true
    AuthenticationRequirement: "singleFactorAuthentication"
  condition: new_country_login
  timeframe: 2h
  after_mfa_change: true
falsepositives:
  - Legitimate international travel
  - Federated login from new region
level: high
tags:
  - attack.t1078
  - attack.initial_access

KQL Detection (Microsoft Sentinel)

Correlating Admin Password Reset with New-Country Login

let mfa_resets = AuditLogs
| where TimeGenerated > ago(7d)
| where ActivityDisplayName == "Reset user password"
| where isempty(InitiatedBy.app.appId)  // admin-initiated, not self-service
| extend TargetUPN = tostring(TargetResources[0].userPrincipalName)
| project ResetTime = TimeGenerated, TargetUPN;

let new_country_logins = SigninLogs
| where TimeGenerated > ago(7d)
| where ResultType == 0
| summarize PriorCountries = make_set(Location) by UserPrincipalName, bin(TimeGenerated, 30d)
| join kind=inner (
    SigninLogs
    | where TimeGenerated > ago(7d)
    | where ResultType == 0
    | project LoginTime = TimeGenerated, UserPrincipalName, Location, IPAddress, DeviceDetail
) on UserPrincipalName
| where Location !in (PriorCountries)
| project LoginTime, UserPrincipalName, Location, IPAddress, DeviceDetail;

mfa_resets
| join kind=inner new_country_logins on $left.TargetUPN == $right.UserPrincipalName
| where LoginTime between (ResetTime .. (ResetTime + 2h))
| project ResetTime, LoginTime, TargetUPN, Location, IPAddress, DeviceDetail
| sort by ResetTime desc

Detecting Rapid MFA Re-enrollment After Password Reset

let AdminResets = AuditLogs
| where TimeGenerated > ago(30d)
| where ActivityDisplayName == "Reset user password"
| extend TargetUPN = tostring(TargetResources[0].userPrincipalName)
| project ResetTime = TimeGenerated, TargetUPN;

AuditLogs
| where TimeGenerated > ago(30d)
| where ActivityDisplayName in ("User registered security info", "User registered all required security info")
| extend TargetUPN = tostring(TargetResources[0].userPrincipalName)
| project EnrollTime = TimeGenerated, TargetUPN
| join kind=inner AdminResets on TargetUPN
| where EnrollTime between (ResetTime .. (ResetTime + 30m))
| project ResetTime, EnrollTime, TargetUPN
| order by ResetTime desc

Behavioural Hunting

Beyond rule-based detection, look for these patterns in hunting:

Help desk ticket velocity anomalies — a single agent processing 10+ MFA resets in a shift, or tickets resolved in under two minutes, warrants review. Automated reset workflows that skip voice verification are a configuration gap, not just a detection gap.

Privileged account targeting — help desk social engineering typically targets accounts that appear important: executives, IT admins, finance staff. Query your directory for accounts with privileged roles and correlate password/MFA resets against those accounts specifically.

RMM tool installation after contact — in callback phishing, the attacker walks the victim through installing AnyDesk, TeamViewer, or ConnectWise ScreenConnect. A legitimate RMM tool installed without a software deployment signature, immediately after the user visited a suspicious domain, is a strong indicator.

Process Controls

Detection alone is insufficient. The help desk process is the vulnerability. Effective controls include:

• Out-of-band verification — before resetting MFA, require the employee’s manager to confirm the request via a separate channel (Slack, Teams call to a verified number). Attackers who can impersonate the employee often cannot impersonate the manager simultaneously.
• Video verification — require the user to appear on a video call from their registered work device before MFA reset. Deepfake risk exists but adds meaningful friction.
• Temporary access codes with time limits — if bypass codes are issued, log their issuance and expiry, and alert if the account authenticated with a bypass code but the subsequent MFA enrollment did not complete within the window.
• Help desk security training — train agents to treat any request that “really needs to happen today” or involves an executive’s account as a social engineering red flag.

MITRE ATT&CK Coverage

The help desk is an authentication bypass that most detection stacks are not built to see. Getting visibility into MFA lifecycle events and correlating them with authentication anomalies closes the biggest gap.