What is Social Engineering?

The attacker asks the target to do something the target is already allowed to do. MITRE ATT&CK describes trust built over email, phone calls, chat, recruiting and help-desk interactions to get users to reset a password, change their MFA, approve a payment or run a command for the attacker. Urgency and authority shorten the checking: a deadline, a threatened account lockout, a caller who claims to be from the CEO's office, a reference to something in the news.

Because the victim acts with their own permissions, the deception itself happens in an inbox, on a phone or at a front desk, and the SIEM records none of it. It records the next step: a click, a password reset, a new MFA method, a sign-in. Verizon's 2026 Data Breach Investigations Report found that social engineering by text message and voice call had a success rate 40% higher than email phishing. Those channels leave no mail log, so their evidence sits in identity logs, if anywhere.

Types of social engineering and the trace each one leaves

For what the lures look like, see 15 phishing email examples analyzed by a SOC analyst. A lure whose link points to a genuine Microsoft sign-in page is covered in device code phishing.

Where social engineering sits in MITRE ATT&CK

ATT&CK v20 lists Social Engineering as technique T1684 under the Stealth tactic, with two sub-techniques: Impersonation (T1684.001) and Email Spoofing (T1684.002). The older Impersonation ID, T1656, still appears in many reports and now redirects to T1684.001. MITRE's description says these techniques aim at user-authorized actions "while minimizing technical indicators".

The delivery methods keep their own IDs under other tactics:

• Phishing (T1566) under Initial Access
• Phishing for Information (T1598) under Reconnaissance
• Internal Spearphishing (T1534) under Lateral Movement
• Multi-Factor Authentication Request Generation (T1621) under Credential Access

Tag both kinds when you write up a case. T1684 records that a person was deceived, and the second ID records what the deception got the attacker.

Scattered Spider and the IT help desk

CISA advisory AA23-320A on Scattered Spider, last revised on 29 July 2025, documents social engineering aimed at identity systems in unusual detail. According to CISA, the group:

• targets large companies and their contracted IT help desks;
• calls or texts employees while posing as IT or help-desk staff, to collect credentials or to get them to run commercial remote access tools;
• calls the help desk while posing as an employee, to get the password reset and the MFA moved to a device the attackers control;
• often spends several calls first learning what the help desk asks for during a password reset;
• sends repeated MFA prompts until the employee presses Accept, and carries out SIM swaps;
• has used domains that append -helpdesk or the name of an SSO product to the target's name.

CISA recommends FIDO/WebAuthn or PKI-based MFA, which it describes as resistant to phishing and not susceptible to push bombing or SIM swaps.

A help-desk reset, as the SOC sees it

Simulated example generated by SOCSimulator Research. The tenant, users, IPs and times are invented; the operation names and fields are Microsoft's.

14:02  ServiceDesk  INC-48213 opened: caller says he is j.ortiz (Finance), new phone, locked out
14:09  AuditLogs    Reset password (by admin)        target j.ortiz@contoso.example  by helpdesk.t1@contoso.example
14:10  AuditLogs    Admin deleted security info      target j.ortiz@contoso.example  by helpdesk.t1@contoso.example
14:14  AuditLogs    User registered security info    target j.ortiz@contoso.example  Microsoft Authenticator
14:16  SigninLogs   ResultType 0  j.ortiz@contoso.example  203.0.113.45  AS64512  Office 365 Exchange Online
14:21  SigninLogs   ResultType 0  j.ortiz@contoso.example  203.0.113.45  AS64512  Office 365 SharePoint Online

Help desks reset passwords all day, so no single line here is suspicious. The sequence is: a reset and an MFA method swap on the same account within five minutes, then that account's first sign-in from AS64512. The question that closes it goes to the agent: how was the caller verified? In the example, the real j.ortiz, reached on the number in the HR record, never called.

The query below looks for that sequence. It is written against Microsoft's documented AuditLogs and SigninLogs schemas and has not been run against a live workspace by SOCSimulator. Tune the two-hour window and the 30-day baseline to your tenant.

let resetOps = dynamic(["Reset password (by admin)", "Admin deleted security info", "Admin registered security info", "User registered security info"]);
let resets = AuditLogs
| where TimeGenerated > ago(7d) and OperationName in (resetOps)
| extend User = tolower(tostring(TargetResources[0].userPrincipalName))
| project ResetTime = TimeGenerated, User, OperationName, Actor = tostring(InitiatedBy.user.userPrincipalName);
let knownAsn = SigninLogs
| where TimeGenerated between (ago(37d) .. ago(7d)) and ResultType == "0"
| extend User = tolower(UserPrincipalName)
| distinct User, AutonomousSystemNumber;
SigninLogs
| where TimeGenerated > ago(7d) and ResultType == "0"
| extend User = tolower(UserPrincipalName)
| join kind=inner resets on User
| where TimeGenerated between (ResetTime .. ResetTime + 2h)
| join kind=leftanti knownAsn on User, AutonomousSystemNumber
| project ResetTime, OperationName, Actor, SigninTime = TimeGenerated, User, IPAddress, AutonomousSystemNumber, AppDisplayName

MFA fatigue in the sign-in logs

In Entra ID, a failed push lands in SigninLogs with ResultType 500121, Authentication failed during strong authentication request. Microsoft's security operations guide for user accounts lists it next to 50074, Strong Authentication is required, among the interrupts to baseline and alert on. 500121 also covers prompts that timed out, so Microsoft's own Sentinel rule MFA Rejected by User narrows it to the detail MFA denied; user declined the authentication. Many of those for one user in a few minutes is the fatigue pattern. Example query, not run by SOCSimulator:

SigninLogs
| where TimeGenerated > ago(1d) and ResultType == "500121"
| where tostring(Status.additionalDetails) =~ "MFA denied; user declined the authentication"
| summarize Denied = count(), FirstDeny = min(TimeGenerated), LastDeny = max(TimeGenerated), IPs = make_set(IPAddress, 10) by UserPrincipalName, bin(TimeGenerated, 10m)
| where Denied >= 5

Read the result next to the same user's successes. A burst followed by ResultType 0 from one of the same IPs means someone approved. Number matching is on for every Microsoft Authenticator push, so an approval means the user typed the number shown on the attacker's screen: ask who gave it to them. Users who press Report suspicious activity on a prompt are set to high user risk in Entra ID Protection, which gives you a risk event to correlate with the burst.

Okta logs a rejected push as user.mfa.okta_verify.deny_push only in classic (V1) API flows. Okta Identity Engine writes a generic user.authentication.auth_via_mfa failure with a reason instead, so a detection written for one misses the other. Help-desk changes appear as user.account.reset_password, user.mfa.factor.deactivate and user.mfa.factor.reset_all.

From a click to a sign-in

When the lure is a link and Safe Links is in place, UrlClickEvents records the click with the user (AccountUpn) and the message it came from (NetworkMessageId). Joining it to sign-ins in the following half hour finds users who clicked and then authenticated, often on a credential page. Example query, not run by SOCSimulator:

UrlClickEvents
| where TimeGenerated > ago(1d) and ActionType == "ClickAllowed"
| project ClickTime = TimeGenerated, User = tolower(AccountUpn), Url, NetworkMessageId
| join kind=inner (
    SigninLogs
    | where TimeGenerated > ago(1d) and ResultType == "0"
    | project SigninTime = TimeGenerated, User = tolower(UserPrincipalName), IPAddress, AutonomousSystemNumber, AppDisplayName
  ) on User
| where SigninTime between (ClickTime .. ClickTime + 30m)

A hit whose sign-in IP is new for that user is worth a case. Then search for the same NetworkMessageId in other mailboxes to see who else received the lure.

Controls that change what you see

• Phishing-resistant MFA (FIDO2/WebAuthn or PKI). Per CISA, it removes push bombing and SIM swaps as routes, and a password typed into a fake page stops being enough.
• Help-desk verification. MITRE lists account use policies (M1036) as the mitigation that adds verification to help-desk resets, approvals and app consents. In practice: call back on the number in the HR record, or require the manager's approval, before any MFA change, and never reset MFA on the strength of an inbound call.
• Number matching and Report suspicious activity in Microsoft Authenticator, described above.
• DMARC enforcement on your own domains, which MITRE names against email spoofing (T1684.002).
• Training on calls and texts as well as email (MITRE M1017), given Verizon's finding on mobile social engineering.