Detect Pretexting and Phishing for Information via Helpdesk Social Engineering in Sumo Logic CSE
Reconnaissance-stage social engineering in which attackers contact an organization's helpdesk or employees by phone (vishing) or email under a false pretext — posing as a new hire, executive, or IT staff member — to elicit organizational information: employee IDs, org charts, software/VPN inventory, internal extensions, and password/MFA reset procedures. This intelligence is then weaponized for initial access, most notably by Scattered Spider (UNC3944), which called helpdesks impersonating employees to talk agents into resetting passwords and MFA enrollment ahead of the 2023 MGM Resorts and Caesars Entertainment intrusions. CISA AA23-320A documents the pattern: pretext call/email gathers org info and builds rapport, followed by a credential or MFA reset request that helpdesk staff approve without adequate identity verification. Because the initial contact rarely trips EDR, detection relies on correlating inbound lure emails impersonating IT/helpdesk with anomalous downstream identity operations (mass or unverified resets) performed by helpdesk-privileged accounts.
MITRE ATT&CK
- Tactic
- Reconnaissance
Sumo Detection Query
_sourceCategory=*o365*email* OR _sourceCategory=*office365*management*
| where Workload="Exchange"
| where (Subject matches "*verify your identity*" or Subject matches "*password reset*" or Subject matches "*mfa reset*" or Subject matches "*org chart*" or Subject matches "*employee id*")
| where SenderDisplayName matches "*helpdesk*" or SenderDisplayName matches "*help desk*" or SenderDisplayName matches "*it support*" or SenderDisplayName matches "*service desk*"
| eval ThreatType = "Phishing_InfoGathering_Lure"
| fields _sourceHost, SenderAddress, SenderDisplayName, RecipientAddress, Subject, ThreatType
| count by SenderAddress, SenderDisplayName, RecipientAddress, ThreatType
| sort - _countSumo Logic Cloud SIEM query over Office 365 Exchange management activity logs, flagging inbound mail with a helpdesk-impersonating display name and reset/info-gathering pretext subject language. Combine with a scheduled Sumo Logic scalar-aggregation rule over the AzureActiveDirectory workload (distinct target-user count per actor per hour) to cover the mass-reset follow-through vector.
Data Sources
Required Tables
False Positives & Tuning
- Verified internal IT/helpdesk distribution lists sending genuine password or MFA re-enrollment reminders — add an allow-list lookup table of authenticated helpdesk sending addresses
- Ticketing system auto-notification emails referencing reset tickets or employee IDs as part of routine workflow
- Simulated phishing awareness campaigns run by the security team using helpdesk-pretext templates
Other platforms for THREAT-Recon-PretextingHelpdeskInfoGathering
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 1Simulated Helpdesk-Impersonation Phishing Lure Delivery
Expected signal: EmailEvents record with SenderDisplayName containing 'Help Desk', inbound direction, Subject matching pretext keyword list.
- Test 2Simulated Mass Helpdesk Password Reset (Graph PowerShell)
Expected signal: AuditLogs entries for 'Reset user password' with InitiatedBy matching the test helpdesk operator account, TargetResources listing three distinct users within the same hour.
- Test 3Simulated Post-Reset New-Device MFA Registration
Expected signal: Entra ID authentication methods audit trail showing a new phone method registered for atomic-test-user1 within minutes of the Alert 2 reset event.
Response Playbook
Triage
- For an email-lure alert: identify the sender's true return-path domain and compare against the organization's verified helpdesk/IT domain — confirm SPF/DKIM/DMARC authentication results to rule out a legitimate internal sender.
- For a mass-reset alert: identify the helpdesk operator account that performed the resets and verify against the ticketing system whether each reset has a corresponding, properly identity-verified support ticket.
- Interview the helpdesk agent(s) involved to determine whether they recall a phone call or chat contact preceding the reset, and what identity verification steps (if any) were performed.
- Check whether any of the reset target accounts subsequently registered a new MFA method or signed in from a new device/ASN/geolocation shortly after the reset — this is the strongest indicator the pretext succeeded.
- Cross-reference targeted employees against org chart position (privileged accounts, IT admins, finance) — attackers frequently target high-value accounts identified during a prior reconnaissance pass.
Containment
- If a reset was unverified, immediately re-lock the affected account, force a fresh password reset through a verified channel, and revoke all active sessions and refresh tokens.
- Suspend or revoke any new MFA methods registered on the account since the suspicious reset.
- If the helpdesk operator's credentials or workflow were themselves manipulated (e.g., call-back number spoofing), review and temporarily restrict that operator's reset privileges pending investigation.
- Block the sending domain/IP of the lure email at the email gateway and quarantine matching messages organization-wide.
Evidence Collection
- Full email headers and body of the pretext lure, including SPF/DKIM/DMARC results and originating IP.
- Helpdesk ticketing system record (or lack thereof) and call recording/chat transcript associated with the reset, if available.
- AuditLogs entries for the reset/MFA-update operation, including InitiatedBy, TargetResources, and Result.
- SigninLogs for the targeted account covering the period immediately after the reset — new device, IP, and location details.
Escalation Criteria
- !A password or MFA reset was approved without ticket-verified identity confirmation, and the target account subsequently authenticated from an unrecognized device or location.
- !The targeted or reset account holds privileged access (Global Admin, Domain Admin, finance/payroll systems).
- !Multiple employees report receiving similar pretext calls or emails within a short window, indicating an active targeted campaign rather than an isolated attempt.
- !The helpdesk mass-reset alert involves five or more distinct accounts reset by a single operator within an hour with no matching change ticket.
Investigation Guide
Related Techniques
Forensic Artifacts
- >
Email headers and authentication results (SPF/DKIM/DMARC) for the lure message - >
Helpdesk ticketing system logs and call center recordings/transcripts tied to the reset request - >
Entra ID AuditLogs: 'Reset user password', 'Update user', 'Disable Strong Authentication', 'Update StrongAuthenticationMethod' operations - >
SigninLogs / IdentityLogonEvents for the affected account in the hours following the reset — new device fingerprint, IP, ASN, and location - >
MFA method registration history (Entra ID authentication methods audit trail)
Tuning Guidance
This detection is intelligence-driven rather than purely behavioral: the email-lure keyword list should be reviewed quarterly against current CISA/Mandiant advisories, as pretext phrasing evolves. The identity-side alert is the higher-confidence signal — tune the reset-count and time-window thresholds to your helpdesk's normal daily reset volume (pull a 30-day baseline of resets-per-operator-per-hour before deploying in blocking or high-priority mode). The single most effective structural mitigation is requiring a second, independent identity-verification factor for any helpdesk-initiated password or MFA reset (e.g., manager callback, video verification, or a pre-established verification PIN) — where implemented, correlate reset events against verification-step completion logs to sharply cut false positives and catch bypass attempts.
Hunting Queries
30-day hunt for helpdesk/admin accounts performing password or MFA resets against two or more distinct users on the same day — a lower threshold sweep to surface slower-paced or lower-volume pretext campaigns that the real-time detection's 1-hour/3-user threshold would miss.
AuditLogs
| where TimeGenerated > ago(30d)
| where OperationName in ("Reset user password", "Update StrongAuthenticationMethod", "Disable Strong Authentication")
| extend InitiatedByUPN = tostring(InitiatedBy.user.userPrincipalName)
| extend TargetUser = tostring(TargetResources[0].userPrincipalName)
| summarize ResetCount = dcount(TargetUser), TargetUsers = make_set(TargetUser) by InitiatedByUPN, bin(TimeGenerated, 1d)
| where ResetCount >= 2
| sort by ResetCount descindex=o365 sourcetype="office365:management:activity" Workload=AzureActiveDirectory
(Operation="Reset user password" OR Operation="Update StrongAuthenticationMethod" OR Operation="Disable Strong Authentication")
| stats dc(ObjectId) AS ResetCount values(ObjectId) AS TargetUsers BY ActorUserPrincipalName, _time span=1d
| where ResetCount>=2
| sort - ResetCountAtomic Red Team Tests
Sends a test email with a spoofed helpdesk-style display name and info-gathering pretext subject line to validate the email-gateway detection path.
Command
powershell.exe -Command "Send-MailMessage -From 'IT Help Desk <[email protected]>' -To '[email protected]' -Subject 'Action Required: Verify Your Identity - Password Reset Request' -Body 'Please confirm your employee ID and extension to complete your password reset ticket.' -SmtpServer 'localhost'"Cleanup
N/A - test message should be reviewed and deleted by the SOC analyst from the target mailbox after validation.Expected Telemetry
EmailEvents record with SenderDisplayName containing 'Help Desk', inbound direction, Subject matching pretext keyword list.
Expected Detection
Alert 1 fires: ThreatType=Phishing_InfoGathering_Lure.
Uses Microsoft Graph PowerShell to reset the password/MFA state of three or more test accounts in rapid succession from a single simulated helpdesk operator account, replicating the post-pretext mass-reset pattern.
Command
powershell.exe -Command "Connect-MgGraph -Scopes 'User.ReadWrite.All'; $testUsers = @('[email protected]','[email protected]','[email protected]'); foreach ($u in $testUsers) { Update-MgUser -UserId $u -PasswordProfile @{ForceChangePasswordNextSignIn=$true; Password='TempAtomic!Test2026'} } "Cleanup
Restore original passwords for the atomic-test-user1/2/3 accounts via Update-MgUser and disconnect the Graph session.Expected Telemetry
AuditLogs entries for 'Reset user password' with InitiatedBy matching the test helpdesk operator account, TargetResources listing three distinct users within the same hour.
Expected Detection
Alert 2 fires: ThreatType=Helpdesk_MassReset_PretextFollowThrough, ResetCount>=3.
Registers a new MFA authentication method on a test account immediately after a simulated reset, replicating the attacker follow-through step where a freshly reset account enrolls a new device under attacker control.
Command
az login --identity && az rest --method POST --uri 'https://graph.microsoft.com/v1.0/users/[email protected]/authentication/phoneMethods' --body '{"phoneNumber": "+1 5555550100", "phoneType": "mobile"}'Cleanup
az rest --method DELETE --uri 'https://graph.microsoft.com/v1.0/users/[email protected]/authentication/phoneMethods/<method-id>'Expected Telemetry
Entra ID authentication methods audit trail showing a new phone method registered for atomic-test-user1 within minutes of the Alert 2 reset event.
Expected Detection
Combined with Alert 2, this raises escalation priority per the playbook's escalation criteria (new device/MFA enrollment shortly after an unverified reset).