Detecting T1684 Social engineering

How T1684 social engineering hides inside normal user activity

T1684 Social engineering sits under the Stealth tactic (TA0005), which ATT&CK defines as adversaries trying to hide and conceal their actions so they appear as normal behavior. For an attacker, the technique is a way to move through an environment while blending into ordinary user work on Linux, macOS, Office Suite and SaaS platforms. For a SOC lead, that is the core problem: alerts on T1684 are rare, and the activity that matters often looks like routine use of the same applications that staff open every day. Detection therefore depends on knowing what normal user behavior looks like on each platform before an alert is needed.

The technique has two sub-techniques, and this page treats them at a high level only. Confirm their exact names, descriptions and platform lists against the Enterprise ATT&CK 20.0 entries before you write detection content, because sub-technique scope is the first thing a reviewer will ask about. The mapping on this page targets ATT&CK Enterprise version 20.0. MITRE notes that releases can rename, deprecate or revoke techniques, so every detection rule, coverage claim and audit artifact should state the ATT&CK version it was built against, not just the technique ID.

A practical first step is to decide which user-activity baselines you can actually collect on each in-scope platform, such as process, command and file creation events on endpoints and administrative or sign-in activity in SaaS tenants. Record who owns each baseline and how often it is reviewed. Then compare your coverage against the technique's current detection strategies in the ATT&CK Stealth tactic page and mark any gaps you accept. That record gives leadership a clear view of what T1684 coverage exists today and what still depends on analyst judgment.

Which telemetry reveals T1684 and which open-source collector gathers it

This table maps the data components most often referenced for Stealth techniques to the platforms in scope for T1684 Social Engineering, with the signal to look for and the open-source collector that gathers it. Read each row as a starting point: confirm field availability per platform in your own environment before relying on it, since the mapping targets ATT&CK version 20.0. The main takeaway is that social engineering often leaves its trace in process and file activity after the user acts, so collection must reach endpoints and SaaS audit logs, not only the mail gateway.

Data component	Signal to look for (illustrative)	Open-source collector	Platform check
Process Creation (DC0032)	A user-launched office or browser process spawning a script host, shell or archive utility shortly after opening a message attachment or link	Wazuh agent, Velociraptor	Confirm command line capture is enabled on Linux, macOS and Windows endpoints
Command Execution (DC0064)	Commands run from a document-opening application or interpreter that the user did not normally use, especially those invoked with unusual arguments	Wazuh agent, Velociraptor	Confirm shell history or command audit coverage on each Linux and macOS fleet
File Creation (DC0039)	New executable, script, or archive files written to user profile or download directories following a lure delivery	Wazuh FIM, Velociraptor	Confirm which directories are monitored and that user profile paths are included
Network Connection Creation (DC0082)	Outbound connections from a user session to newly registered or rare domains shortly after a credential prompt or document open	Zeek, Suricata, Security Onion	Confirm sensor placement sees egress from user subnets and that TLS metadata is logged
Network Connection Creation (DC0082), SaaS and browser	Sign-in or consent events from unfamiliar locations or applications, and browser sessions reaching lookalike login pages	Wazuh integration with SaaS audit logs, Zeek HTTP and SSL logs	Confirm the SaaS tenant exports audit and sign-in logs and their retention period with the vendor
Process Creation (DC0032), Office Suite	Macro-enabled documents launching child processes, which is relevant to Office Suite deployments	Wazuh agent, Velociraptor	Confirm Windows endpoint auditing and Office telemetry are available; coverage for macOS office suites may differ

Detection logic for T1684 that SOC teams can tune

The four detection ideas below share one principle: a single event is rarely suspicious on its own, but a document, process, command or SaaS action that breaks from the user's normal pattern is. Each card names the logic, what to tune, and the benign activity that will trigger it, so teams can baseline before alerting. Write each rule against a named ATT&CK version so it stays traceable as the framework changes.

Unusual process lineage from user documents

This card flags a user-opened document, PDF or archive that launches a script interpreter, shell or unfamiliar binary as a child process. Process Creation telemetry (DC0032) carries the parent-child pair, so the rule can compare each pair against what that department normally launches. Start with a baseline of parent-child pairs per role, then alert only on pairs never seen for that group. Expect false positives from IT administration tools, scripted onboarding and approved macros. Tune by allowlisting signed, approved pairs and reviewing the exceptions weekly.

Rare commands from newly observed sources

This card looks for command execution (DC0064) on a host, by a user or from a source that has no prior history in the baseline window. The logic combines three keys: the account, the host and the command family, and alerts when the combination is new. Set the baseline window and the minimum history length to match how often your environment changes. Expect false positives from new hires, freshly imaged endpoints, configuration management runs and approved automation. Tune by excluding known management service accounts and tagging onboarding events in advance.

Downloaded files executed within a short window

This card correlates File Creation events (DC0039) in user download or temporary paths with a process launch from the same file within a short time window. The pattern matches a user being persuaded to open and run something they received, which is the human-facing core of T1684. Set the window length in the SIEM and start with a conservative value, then widen it only after reviewing hits. Expect false positives from legitimate installers, package managers and browser-based downloads of approved software. Tune by hash or signer allowlisting for known installers.

SaaS audit anomalies after inbound contact

This card watches SaaS audit logs for changes a user rarely makes, such as new OAuth consent grants, mail forwarding or inbox rule creation, and sudden role or permission changes. It becomes stronger when the alert also records whether the account received unsolicited inbound messages in the preceding hours. Confirm which audit events your SaaS tenants expose and how long they retain them before writing the rule. Expect false positives from help desk resets, scripted onboarding and approved integrations. Tune by requiring a second anomaly on the same account before paging anyone.

Sigma rules pinned to an ATT&CK version

This card covers how to package the rules above so they survive ATT&CK releases. Write each detection in Sigma, a vendor-neutral rule format, then convert it to the query language of your SIEM or Wazuh deployment. Record the ATT&CK version each rule targets, because releases can rename, deprecate or revoke techniques, and attach the data component IDs the rule relies on. Review rule mappings whenever a new version is published, and keep the false positive notes inside the rule so analysts see them during triage.

How to validate a T1684 detection before trusting it

This sequence turns a T1684 Social Engineering detection from an untested rule into a recorded result. It covers scope, authorization, a benign emulation in a private range, telemetry checks and ongoing re-testing. Each step names who acts and what evidence closes it, so security leadership and auditors can review the outcome.

Confirm sub-technique scope and ATT&CK version
The detection engineer and the threat intelligence or red team lead agree which of the two T1684 sub-techniques the rule claims to cover, and which platforms, applications and SaaS tenants are in scope. Record the ATT&CK version the rule targets, because technique names, detection strategies and data component mappings can change between releases. Confirm sub-technique IDs against that version before writing the rule. Done when the scope record names each sub-technique, each platform and the version, and a second reviewer has signed it.
Agree written rules of engagement
Security leadership, the range owner and the SOC lead sign rules of engagement before any test begins. The document names the testing team that owns the emulation, the range or lab systems involved, the test identities and mailboxes, the notification path to the SOC, and stop conditions that end the exercise immediately. It also states who may approve scope changes during a run. Done when every named party has signed and the SOC knows the test window, so the test measures the detection itself.
Write the expected telemetry plan
Before any action runs, the detection engineer lists the events each analytic should produce. Map each event to the Process Creation, Command Execution and File Creation data components and to the log source on each platform, such as endpoint agents, Office Suite audit logs or SaaS audit trails. For each event, record the fields the rule depends on and the alert it should raise. Done when the plan is a table with one row per expected event and someone who did not write the rule has reviewed it.
Run a benign emulation owned by the testing team
The testing team runs harmless actions that imitate the sub-technique behavior in the private cyber range, using test identities and nonproduction data only. Every action gets a start and end timestamp in a run log, and the SOC does not receive the schedule in advance. Do not reuse production credentials or live customer content. Done when the run log lists each action with its time and the range snapshot is saved, so the same run can be repeated later.
Confirm every expected event arrived
Compare the run log with the telemetry plan and check each expected event in the SIEM or open-source platform in use. Confirm the expected fields are present and parsed, not only that a raw record exists. When an event is missing, trace the gap through agent health, forwarding, parsing, field normalization and rule logic, in that order. Keep a coverage matrix marking each event as present, missing or malformed. Done when every row is either present with the expected fields or has a documented cause and a named owner for the fix.
Record latency, fidelity and analyst notes
For each alert, record the time from the benign action to ingestion, to alert creation and to analyst acknowledgement. Classify each alert as a true positive for the test, a false positive or a missed detection, and note what context the analyst needed to decide. Ask analysts to write brief notes on what made triage faster or slower. Confirm with your own SOC which latency targets apply, since this guide does not set them. Done when the scorecard covers every expected alert and the detection owner has decided to approve, tune or hold the rule.
Re-test after rule and version changes
Repeat the affected parts of the plan after any change to the rule, log source, parser, agent version or mitigation configuration, and after each ATT&CK release. When a release renames, deprecates or revokes a technique, or changes its data components, update the scope record and telemetry table before rerunning. Track the ATT&CK updates page for these changes. Done when the new run log and scorecard are filed under the rule version and ATT&CK version, and the previous approval is either renewed or withdrawn.

Why ATT&CK version changes affect T1684 detection mappings

Pin every T1684 Social engineering detection to the ATT&CK version it targets, and record that version in the rule metadata. ATT&CK v18, released October 28, 2025, replaced the detections on technique pages with detection strategies (DET IDs) and analytics, made major updates to data components (DC IDs) and deprecated data sources. A detection written against the older detection text may still reference a data component or source that no longer carries the logic. Before you trust an existing T1684 rule, confirm which data components and detection strategy IDs it cites in the version you are running, and update the references where they have changed.

The v19 release, dated April 28, 2026, split the Enterprise Defense Evasion tactic. Stealth keeps the ID TA0005, so mappings that point to Stealth remain valid, but Defense Impairment is a new tactic with ID TA0112. Review any T1684 mapping, dashboard, coverage report or rule tag that still reads Defense Evasion and decide which tactic it belongs under. Check whether your SIEM or detection-as-code pipeline pulls the ATT&CK matrix automatically or from a copy you control, because an unpinned copy can silently mix old and new tactic labels in the same coverage view.

Recheck T1684 mappings on every ATT&CK release. Diff the enterprise-attack bundle for T1684 and its two sub-techniques, covering their detection strategies, data components and the Audit and User Training mitigations, against the version your rules target. The mitre-attack/attack-stix-data repository publishes one STIX 2.1 bundle per domain and version, so treat it as the source of truth and not a secondary summary. Assign a named owner for this review, record the version each finding was checked against, and confirm any change with the ATT&CK release notes before you edit a production rule.

Preventive controls mapped to T1684

ATT&CK maps two mitigations to T1684 Social engineering: User Training and Audit (M1047). Neither one stops a person from responding to a lure, so the cards below pair each control with the outcome it supports, the team that owns it, and the evidence to keep.

User training for lure recognition

User Training (ATT&CK mitigation) builds the human reporting path that often catches social engineering first. Training should cover the lures your staff actually see, such as payment redirects, fake support requests and credential prompts in email, chat and SaaS notifications. Check that staff know how to report a suspicious message, that reports reach the security team quickly, and that training completion and simulated-lure results are tracked by role. Confirm the training content and frequency with your HR and security leads.

Audit of account and mailbox settings

Audit (M1047) means reviewing configuration and logs so that changes enabling a lure path are visible. For T1684, this covers mail forwarding rules, new OAuth app consents, changed payment or vendor details in SaaS finance tools, and new MFA methods on accounts. Assign a named owner for each audited setting and keep dated review records showing what was checked and what was corrected.

Out-of-band verification for payment changes

Requests that change bank details, payees or approval routes are a common social engineering pattern. A written procedure requiring a call-back to a known number, or a second approver who did not receive the request, reduces the chance that a single convincing message moves money. This control is a process rather than a technical block, so the evidence is the approval log, the call-back record and periodic tests of the procedure. The finance and procurement leads should own it.

Helpdesk identity verification procedure

Attackers often pose as employees to ask service desks for password resets, MFA re-enrollment or account unlocks. A written identity check before any credential or MFA change, with escalation for high-privilege accounts, turns a conversation into a controlled process. Keep the scripts, the ticket records showing the check was performed and the list of exceptions approved. The IT service management owner and the identity team should share ownership.

Logging for lure-driven account activity

Audit only helps if the logs exist and are retained. Confirm that identity provider sign-ins, mailbox rule changes, OAuth consent events and SaaS admin actions are forwarded to your central log platform, such as Wazuh, and that the retention period meets your policy. Keep sample queries and a record of the last test that showed each event type arriving. The security operations team owns this evidence.

Triage and response when a T1684 detection fires

Start by confirming that the alert matches the telemetry it was built from. For a T1684 Social engineering detection, pull the underlying Process Creation, Command Execution and File Creation events for the host, and check whether the event is an actual user action or a side effect of an automated process, a browser extension, a sync client or a scheduled job. Record the rule name, the rule version and the ATT&CK version the rule targets, because mappings can change between ATT&CK releases. Then decide whether the user action was legitimate by asking the user or their manager what they were doing, checking the case or ticket queue for a matching business request, and comparing the sequence with that user's normal behavior over the prior few days. Treat an unexplained result as open until the evidence says otherwise.

Once the alert is confirmed as suspicious, scope the affected identity and asset. Identify the account, its recent sign-ins and role assignments, and the host or SaaS tenant where the activity occurred. For SaaS platforms, review the tenant audit log for mailbox rules, OAuth grants, new sessions and changes to sharing settings. Preserve evidence before you change anything: export the relevant logs, take a memory or disk snapshot of the endpoint where your team's procedures allow it, and hash exported files so their integrity can be shown later. Contain the account or session by revoking active tokens, forcing re-authentication and suspending the account if compromise is likely, and isolate the host only when the response plan calls for it, since isolation can alter volatile evidence. Confirm the scope of containment with the owner of the identity platform before you close the step.

Decide on user communication and escalation early, and write those decisions into the incident record. Notify the affected user through a channel you have already verified, avoiding any channel the suspected activity could reach, and give them concrete instructions rather than open-ended warnings. Escalate to the security incident lead when the activity involves privileged roles, a shared mailbox, a second tenant or any data movement, and involve legal, privacy or compliance staff according to the organization's documented thresholds, which you should confirm in advance. After closure, run a lessons-learned review that asks whether the rule fired on the right telemetry, whether the false-positive reason can be documented, and whether the User Training and Audit mitigations need a change. Record each change to detection logic with its date and the reason for it, so the next cyber range rehearsal tests the revised rule.

Rehearsing T1684 detection in a private cyber range

The endpoint range is a small set of isolated Linux and macOS hosts enrolled in the same agent and logging pipeline as production, with user accounts that mirror the client's role model. Illustrative scenario: a purple team plans a user-level social engineering lure that results in a document-opening or script-running action on a workstation, followed by a process chain the team has agreed to look for. The team does not share the exact lure content with the detection engineers in advance, so the test measures what the telemetry actually shows.

Range topology: Two or three endpoints, one log collector and one analyst workstation on a segregated network with no route to production.
Illustrative injects: A staged user action that launches an unexpected interpreter from a user profile directory, and a second action that writes a new file into a startup or autostart location.
Good detection: Process Creation and Command Execution events reach the SIEM within an agreed window, and the alert names the parent process, user and host.
Good response: The on-call analyst isolates the host from the range network, preserves the process tree and confirms the scope against the agreed runbook.
Gaps to record: Missing audit configuration on macOS hosts, or Linux hosts where command auditing was never enabled.

Confirm with your own platform team which audit subsystems are enabled on each endpoint image before the exercise starts.

Questions SOC leads ask about detecting T1684

How do we cut false positives from approved automation for T1684?

Start by inventorying every approved automation account, service principal, script runner and scheduled job that produces the same telemetry as the behavior you are detecting. Record each owner, its purpose, the hosts or tenants it uses and its expected time windows. Tune detections to those baselines, and scope any suppression to a named account and asset pair so the rule still fires for everything else. Review each exclusion when the automation changes, and keep a log of exclusions with an owner and a review date. Reviewing that log during each tuning cycle shows whether exclusions are still justified.

Which data sources should we onboard first for this technique?

Prioritize the telemetry that the topic's detection mapping relies on: Process Creation, Command Execution and File Creation. These data components are the ones ATT&CK detection strategies most often reference for Stealth techniques, and they give you the earliest signal on endpoints and servers. For SaaS and office suite coverage, add the platform's administrative audit logs and identity provider sign-in logs, because most misuse there appears as configuration changes rather than file or process activity. Confirm each log field against the detection strategies in the ATT&CK Enterprise STIX bundle for the version you target before you onboard it.

How do we tell a legitimate SaaS admin action from misuse?

Compare the action with the administrator's role, an approved change record, the usual working hours, the sign-in location and device, and whether peers in the same role perform the same action. Misuse usually shows several weak signals together. Illustrative example: an admin changes a mail forwarding rule at an unusual hour from a new location with no change ticket, then grants a new application access shortly after. Each event alone may be routine, but the sequence warrants triage. Requiring a ticket reference for privileged changes makes the legitimate path easy to verify and makes unexplained actions stand out.

How often should we re-validate T1684 detections?

Set the cadence with the detection owners and write it into the runbook, because the right interval depends on how often your platforms and log sources change. Re-validate after every platform upgrade, after any change to log forwarding or parsing, and after each ATT&CK release that you adopt. ATT&CK v19 was released April 28, 2026, and v20 on October 13, 2026, and releases can rename, deprecate or revoke techniques, so a detection that mapped cleanly last cycle may need review. Also review any rule that has produced no alerts or many false positives for an extended period, since both can indicate a broken data source.

What evidence should we keep for audit readiness on this detection?

Keep a versioned record for each rule, including the ATT&CK version it targets, the author, the approval date and the change history. Add the cyber range validation records with dates, the test scenarios run and the alerts produced, along with sample triage notes and the tuning exceptions with their owners. Store the response runbook versions and the mitigation mapping for Audit and User Training, with control IDs referenced rather than control text copied in. DeployOpen can prepare these systems, controls and evidence, but independent auditors and certification bodies are the ones who issue assessment results, so confirm early which evidence format your assessor expects.

How do the Audit and User Training mitigations support detection?

The Audit mitigation means enabling and retaining the logs the detection depends on, so it is a prerequisite for detection rather than an optional add-on. User Training reduces how often staff act on lures, which lowers the volume of events that reach your queue, but it does not replace technical detection. Training outcomes help you tune: when staff report a suspicious request that the detection missed, that report becomes a test case for the cyber range. Track which teams report, how quickly they do so, and which lure types succeed, and feed those findings back into both the training program and the rule set.

Can our own SOC run this detection work without outside help?

Yes, if your team has the skills and capacity to manage log pipelines, write and test detection rules and run exercises. The main factors that drive effort are the number of platforms in scope, how many SaaS tenants and endpoint fleets you operate, how well your logs are already normalized, and whether you have an existing rule pipeline. Ask any partner to set out the scope, deliverables and timelines in writing before work starts, and ask whether ongoing testing and tuning is covered by a fixed-scope project or a retainer. Your internal team should own the final approvals for detections that affect production.

What evidence to keep for T1684 readiness reviews

A readiness review for T1684 Social engineering turns on whether you can show that each detection works as claimed, so start by keeping versioned detection records rather than screenshots. For every rule or analytic, store the source file under version control, the ATT&CK version it targets (for example, Enterprise ATT&CK 20.0, using the mapping in the attack-stix-data repository), and the data components it depends on, such as Process Creation, Command Execution and File Creation. Because ATT&CK releases can rename, deprecate or revoke techniques, a rule without its target version is hard to defend in review. Keep a mapping that shows which T1684 sub-technique each rule covers, and confirm with your assessor how they want that mapping presented.

Validation records and alert samples show that the rules fire on the behavior they describe. For each analytic, keep a dated test record that names the controlled activity, the expected alert, the alert that actually appeared, the time to alert, and the analyst who reviewed it. Keep representative alert samples with their raw events, along with a tuning history that records each change, the reason for it, and the false positives it removed. Range exercise reports from your private cyber range add the second line of evidence: what the blue team saw, what they did, and where the response process broke down. The User Training and Audit mitigations also need records, such as training completion data and confirmation that the logging needed for these analytics is enabled and retained.

DeployOpen prepares this evidence as part of implementation and testing, but independent auditors and certification bodies decide any assessment outcome, and DeployOpen does not issue audit reports or attestations. Before the review, agree with your assessor who owns the evidence store, how long records are retained, and how they will sample alerts and exercise reports. Confirm these requirements in writing with the assessor and your compliance lead rather than assuming a format. A short internal check helps: pick one T1684 analytic and ask whether someone outside the detection team could trace it from the rule file to a test record, an alert sample, and a tuning entry within a few minutes.

How DeployOpen builds T1684 detections and range scenarios

DeployOpen approaches T1684 Social engineering as a written, fixed-scope engagement inside the client's own infrastructure. The work covers detection content, validation in a private cyber range and the documentation a security team needs to run it after handover.

How we scope

Agree in writing which platforms, telemetry sources and T1684 sub-techniques the engagement covers before work starts.
Confirm which ATT&CK version the detection mappings will target, since releases can rename or deprecate techniques.
Record which mitigations, Audit and User Training, are already in place and which need configuration or evidence.

How we build

Map the logging sources for Process Creation, Command Execution and File Creation to the client's Linux, macOS, Office Suite and SaaS estate.
Write detection logic in open-source formats such as Sigma rules and test it against Wazuh or Security Onion pipelines.
Confirm log retention and parsing so the detection fires on the fields it depends on, not on assumptions about default settings.

How we hand over

Deliver detection content with the ATT&CK version, data component mapping and known blind spots documented alongside it.
Provide range exercise runbooks so the security team can rehearse detection and response for T1684 without production impact.
Run a handover session with the analysts who will own the rules, alerts and tuning after the engagement closes.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope work completes.
Retainers can cover rule updates when MITRE revises T1684 or its data components in a later ATT&CK release.
Ask for the support boundaries, response expectations and change process in the written quote before signing.

T1684 Social engineering