Social Engineering (T1684) is the umbrella technique for persuading people to take actions that give an adversary access, approve changes, disclose information or run adversary-supplied instructions, while keeping technical indicators to a minimum. MITRE places it in the Stealth tactic and lists Linux, macOS, Office Suite, SaaS and Windows as platforms.
It has two sub-techniques, Impersonation (T1684.001) and Email Spoofing (T1684.002), and it often overlaps with Phishing (T1566) and Spearphishing Voice (T1566.004).
How attackers use it
The core idea is that a person does the work. Nothing needs to be exploited if someone resets the password, approves the MFA change or runs the command themselves.
MITRE describes several features of how this is done:
- Trust across channels. Adversaries may build trust through executive, vendor or help desk scenarios, including AI-enabled voice interactions. The aim is a user-authorized action such as a password reset, an MFA change, a financial approval or the disclosure of sensitive information.
- Ordinary business workflows. Requests are shaped to look routine, using email, collaboration platforms, voice calls, recruiting processes, help desk interactions and SaaS consent prompts.
- Current events and pressure. Adversaries may refer to news or themes tied to the victim's role or mission. They may use scare tactics, such as threatening consequences for not complying, or stir emotions to create urgency.
One listed example is a group that used social engineering to demand payment from victims.
The result is hard to spot with traditional controls. The action is performed by a real user with real credentials, so the logs can look clean.
How to detect it
MITRE's detection strategy is about correlation. It looks at a communication event followed closely by a sensitive action. The patterns, by area:
- Commands copied from chats, tickets or emails. Users running pasted commands, scripts launched from temp directories, credential changes, or SSH key additions soon after a message arrived.
- Execution of newly received content. Script launches, Office applications spawning child processes, browser-to-script chains, or credential prompts followed by a new logon session.
- Identity and SaaS actions after user interaction. Consent grants, password resets, role changes, external sharing or token creation shortly after a message, invite or help desk contact. Look for unusual requester relationships, new device context and off-hours approvals.
- Sensitive actions after unfamiliar contact. Inbound communications or collaboration requests followed quickly by file sharing changes, macro enablement, OAuth consent, credential submission or financial approvals that do not match historical relationships or normal approval patterns.
- Downloads followed by execution. On macOS, browser downloads followed by
osascript, shell or installer execution and then network activity.
The thread running through all of them is timing. Sensitive actions that arrive right after an outside contact deserve a second look.
How to reduce the risk
MITRE lists three mitigations.
- Account Use Policies. Add verification to the actions that attackers target by impersonation: help desk resets, approvals and application consents.
- Audit. Correlate email, identity, SaaS and endpoint activity, so that actions that look legitimate on their own can be seen in context.
- User Training. Reduce the success of phishing, voice phishing, impersonation and "human interface" lures.
Turn those into plain practice:
- Give the help desk a script for identity checks that does not rely on information an outsider could find, and let them say no.
- Require approval from a second person for MFA resets and for new payees.
- Send an alert to the user and their manager when an MFA method changes.
- Make a clear, easy way to report something odd, and thank people who do.
- Practice with realistic scenarios, including phone calls and chat messages, not only email.
Check your own environment
- Walk through your own help desk process for a password reset. What proves identity today?
- Review who can approve OAuth consent in your tenant, and whether requests need approval.
- Check whether MFA changes notify anyone besides the user.
- Look at the last month of password resets and MFA changes, and sample a few for a matching ticket.
- Ask three staff members what they would do if "IT" called about an urgent problem.
- Confirm that email, identity provider and endpoint logs can be searched together.
Quick check
Why are social engineering attacks hard to find in logs?
The action is carried out by a real user with real credentials, so there may be no malware or exploit to see. Detection depends on correlating a communication event with a sensitive action that follows it.
Which mitigation covers help desk resets and app consents?
Account Use Policies, which adds verification to the actions most commonly targeted by impersonation.
Which signals does MITRE suggest for identity actions?
Consent grants, password resets, role changes, external sharing or token creation soon after contact, especially with unusual requesters, new devices or off-hours approvals.
Sources
- MITRE ATT&CK, Social Engineering (T1684): https://attack.mitre.org/techniques/T1684
