MITRE ATT&CK T1684 Social Engineering: Detecting Evasion

When an attacker persuades an employee to reset a password, approve an app or run a command, the action is performed by a legitimate user and leaves almost no technical trace of an attack. That is why MITRE ATT&CK v20 places T1684 Social Engineering under the Stealth tactic (TA0005): the technique is defined by influencing users to take actions that grant access, approve changes, disclose information or run adversary-supplied instructions "while minimizing technical indicators". This guide covers the ATT&CK view of the technique: its two sub-techniques, the procedure examples recorded in ATT&CK, the detection strategy DET0899 and its five analytics, the mitigations, and how to test them. It is for SOC, identity, help desk and email security teams. For the psychology of influence and running an awareness programme, see the Social Engineering Guide; this page does not repeat it.

Key takeaways

• Stealth, not just initial access. ATT&CK treats social engineering as a way to make malicious requests look routine, so the evidence is a legitimate action that follows an unusual conversation.
• Two sub-techniques replace two older entries. T1684.001 Impersonation and T1684.002 Email Spoofing now hold the content of the earlier standalone Impersonation and Email Spoofing techniques, which ATT&CK v20 revoked; update detection mappings that still use the old IDs.
• Detection is correlation. DET0899 pairs a communication event (external chat, help desk ticket, inbound email) with a sensitive action shortly after it: a reset, an MFA change, an OAuth consent, a script launch.
• Verification beats vigilance. ATT&CK's M1036 Account Use Policies adds verification to help desk resets, approvals and app consents, which holds even when the caller is convincing.
• Non-human identities are a frequent prize. Recent cases ended with an approved connected app, a remote support session or a reset that gave lasting machine-level access.

What the technique covers

ATT&CK v20 created T1684 in April 2026 for Linux, macOS, Office Suite, SaaS and Windows. It names trust-building across executive, vendor and help desk scenarios, including AI-enabled voice interactions, and abuse of normal business workflows: email, collaboration platforms, voice, recruiting, help desk interactions and SaaS consent mechanisms. It also covers emotional pressure such as urgency and threats of repercussions, and notes that it may include patterns like MITRE ATT&CK T1566 Phishing and Spearphishing Voice (T1566.004).

How adversaries use it: cases from ATT&CK

• ShinyHunters (G1057), the parent technique's procedure: ATT&CK cites the FBI's May 2026 alert on attacks against a learning management system. The FBI describes extortion emails signed "ShinyHunters", real or exaggerated claims about stolen data, harassment by text and phone, and warns that stolen data could fuel spearphishing that impersonates faculty, IT support or financial aid offices. See the ShinyHunters Threat Actor Profile.
• Salesforce Data Exfiltration (C0059): ATT&CK records actors impersonating IT support in voice calls. Google Threat Intelligence Group describes UNC6040 walking employees to Salesforce's connected app setup page to approve a modified Data Loader, in one case named "My Ticket Portal", using a connection code. The approval created an integration that exported CRM data. See the ShinyHunters Salesforce data theft campaign analysis.
• Scattered Spider (G1015): ATT&CK records the group compelling help desk staff to reset passwords and MFA tokens and posing as IT support in Microsoft Teams. The CISA and FBI advisory AA23-320A adds SIM swapping, MFA fatigue and lookalike domains such as victimname-sso[.]com, and notes that contracted help desks were targeted too. See the MGM Resorts breach analysis, where a help desk call using details from a professional networking profile preceded claimed administrator access to the identity provider.
• Storm-1811 (G1046): Microsoft described the group flooding inboxes with subscription spam, then calling the user as IT support, later also using Teams accounts with display names such as "Help Desk", and persuading users to grant a Quick Assist remote session that led to Black Basta ransomware. See the Email Bombing and Help Desk Impersonation over Teams Guide.
• LAPSUS$ (G1004): ATT&CK records calls to victims' help desks impersonating users with previously gathered information to reach privileged accounts.
• TeamPCP (G1056): ATT&CK records the group impersonating legitimate maintainers to push imposter commits to the Trivy repository, social engineering aimed at code review rather than a person on the phone.
• Kimsuky (G0094) and email spoofing: Proofpoint reported the group, tracked as TA427, spoofing think tanks and NGOs whose DMARC policy was p=none, opening with harmless questions and setting the reply-to address to an attacker-controlled free mail account.

Where identity fits

Many of the cases end at an identity control: a password or MFA reset, a new authenticator, an OAuth grant, a connected app or a remote support tool. Those outcomes create or modify credentials that outlive the call. The UNC6040 approvals produced a connected app, a non-human identity with API access that kept working after the conversation ended, and Google notes that MFA alone does not stop a user being talked into approving one. Treat app consent and integration approval as privileged identity events. See the Account Recovery and Help Desk Security Guide and the Consent Phishing and Illicit OAuth Grants Guide.

What to detect and where

DET0899 has five analytics, one per platform. Each looks for a sensitive action shortly after a communication event, with tunable time windows.

For the sub-techniques, DET0286 looks for SendAs and SendOnBehalf activity where the sending identity does not match account ownership, and new or unusual delegation. DET0431 looks for SPF, DKIM or DMARC failures in message traces and mismatches between the From domain and the return path.

NHI Mgmt Group recommends three practical additions:

• Join help desk tickets to identity logs: every reset or MFA change should carry a ticket ID; alert on resets of privileged accounts, resets followed by new device registration within minutes, and resets requested from a new phone number.
• Watch remote support tools: AA23-320A recommends allowlisting approved remote access tools and reviewing their execution; alert on unapproved tools and on approved ones started without a ticket.
• Baseline approvals: new connected apps, OAuth grants with broad scopes and payment detail changes should be rare; alert on first-time approvers and approvals outside normal hours, matching the AN2034 tunables for requester novelty and after-hours definition.

Mitigations

ATT&CK lists M1036 Account Use Policies, M1047 Audit and M1017 User Training for the parent, M1019 Threat Intelligence Program for impersonation, and M1054 Software Configuration for email spoofing. The controls below put them into practice; where they go beyond ATT&CK text they are NHI Mgmt Group recommendations.

• M1036, verification by process: help desk resets of privileged accounts need a call-back to a number on record, manager or second-agent approval, or in-person or video identity proofing. Payment changes need confirmation through a known channel. App consents need administrator approval.
• Phishing-resistant authentication: AA23-320A recommends FIDO/WebAuthn or PKI-based MFA, which resists push bombing and SIM swapping. See the MFA Fatigue and Bypass Guide.
• Restrict who can approve integrations: Google's UNC6040 guidance is to limit the API Enabled permission, restrict Customize Application and Manage Connected Apps to trusted administrators, and set IP ranges for connected app policies.
• M1054 for spoofing: publish SPF and DKIM, move DMARC from p=none to p=quarantine then p=reject, and turn on anti-spoofing in the mail gateway. See the DMARC, SPF and DKIM Guide.
• Remote support hygiene: Microsoft advises removing or blocking Quick Assist and similar tools where unused, and reviewing external access in Teams.
• M1047 Audit: keep identity, mail, collaboration and endpoint logs in one place long enough to correlate them.
• M1017 and M1019: train the help desk and finance teams on current pretexts from threat intelligence, and tell staff exactly what IT will never ask for.

How to put it in place

1. List the actions an attacker wants a user to perform: resets, MFA enrolment, app consent, payment changes, remote sessions, code merges. Name the owner of each workflow.
2. Add verification to each, starting with privileged account resets and app approvals. Pilot with one help desk team, measure call handling time, then roll out.
3. Enforce email authentication. Run DMARC at p=none with reporting until legitimate senders pass, then move to quarantine with a percentage tag, then reject. Roll back by lowering the policy, not removing the record.
4. Centralise logs and build correlations for AN2033 and AN2034 first, since SaaS and Office Suite carry most of the recent cases.
5. Tune on the mutable elements: time windows, trusted domain allowlist, approval amount threshold and requester novelty days.
6. Exercise: run authorised vishing tests against the help desk and check that the reset was refused or the alert fired.

Decision guidance

• Outsourced help desk: AA23-320A notes contracted help desks were targeted. Put verification steps in the contract and get reset logs from the provider.
• Small organisations: start with phishing-resistant MFA for administrators, DMARC enforcement and a written call-back rule for payments. These need little tooling.
• Large organisations: invest in the ticket to identity log correlation and an approval baseline, because volume makes manual review impossible.
• Verification friction: strong proofing for every reset slows the help desk. Apply the strongest checks to privileged and high-value accounts and self-service recovery with phishing-resistant factors for the rest.

Measurement

• Percentage of privileged resets with completed out-of-band verification and a ticket ID.
• Percentage of administrators using phishing-resistant MFA.
• DMARC policy and pass rate for every sending domain you own.
• Number of OAuth consents and connected apps approved without administrator review (target: zero).
• Help desk pass rate in authorised vishing exercises.
• Time from a user report of a suspicious call or message to containment of any action taken.

Common failure patterns

• Verifying with public facts: date of birth, manager name or employee ID are findable; the MGM case shows details from a professional networking profile were enough.
• Trusting the internal channel: Teams or Slack messages from accounts named "IT Support" are treated as internal; check the external tag and tenant.
• MFA as the end of the story: MFA does not stop a user approving a connected app or starting a remote session for an attacker.
• Stale detection mappings: rules still tagged with the revoked standalone Impersonation or Email Spoofing IDs drop out of coverage reports built on ATT&CK v20.
• Training without process: staff are told to be careful but have no call-back number, no escalation route and no permission to refuse a senior caller.

Framework mapping

Practitioner checklist

• Privileged account resets require out-of-band verification and a ticket ID.
• Administrators use phishing-resistant MFA.
• OAuth consent and connected app approval are restricted to administrators.
• Every owned domain publishes SPF and DKIM and enforces DMARC.
• Unused remote support tools are removed; approved ones are allowlisted and logged.
• Identity, mail, collaboration and endpoint logs are correlated in one place.
• DET0899 style correlations run for SaaS and Office Suite at minimum.
• Detection content uses T1684.001 and T1684.002, not the revoked IDs.
• Help desk and finance staff are exercised against current pretexts at least yearly.

Standards and references

• MITRE ATT&CK: T1684 Social Engineering
• MITRE ATT&CK: T1684.001 Impersonation
• MITRE ATT&CK: T1684.002 Email Spoofing
• CISA and FBI: Scattered Spider advisory AA23-320A
• FBI IC3: ShinyHunters cyber criminal group attacks learning management system
• Google Threat Intelligence Group: The cost of a call, from voice phishing to data extortion
• Microsoft Threat Intelligence: Threat actors misusing Quick Assist in social engineering attacks
• Proofpoint: Social engineering and DMARC abuse, TA427

Related NHI Mgmt Group resources: ATT&CK Stealth and Defense Impairment Tactics Guide, Help Desk Social Engineering Incident Playbook, Scattered Spider Threat Actor Profile, Deepfake and AI Impersonation Guide.