DET0899: Detect Social Engineering
DET0899 is a detection strategy for Social Engineering (T1684), where adversaries influence users into approving changes, disclosing sensitive information,...
Analyst context for executives and security teams
DET0899 is a detection strategy for Social Engineering (T1684), where adversaries influence users into approving changes, disclosing sensitive information, granting access, or running adversary-supplied instructions while leaving few technical indicators. Its business significance is that the first observable event may be a user decision, help desk action, SaaS approval, or Office Suite interaction rather than malware. Leaders should treat this as a control-validation problem across identity, SaaS workflows, help desk processes, and incident response—not only as a phishing alert problem.
Executive priority
Prioritize this behavior where user approvals, vendor or executive impersonation, help desk workflows, and SaaS/Office Suite access can affect business continuity or sensitive data. The key executive question is whether the organization can prove, during an incident or audit, who approved access or changes, through which channel, and whether that action was verified. Because the ATT&CK object provides no official detection text, coverage should be assessed through local telemetry, process evidence, and control testing rather than assumed from tool presence.
Technical view
SOC, detection engineering, and IR teams should validate detection around the related ATT&CK technique T1684 Social Engineering, which is associated with the stealth tactic and platforms Linux, macOS, Office Suite, and SaaS. Practical validation should focus on user-driven access changes, approval events, sensitive information disclosure signals, help desk or vendor-request workflows, and execution or installation activity that follows suspicious user interaction. Since DET0899 has no official ATT&CK detection guidance, teams should map their own detections to the decision points where social engineering succeeds: identity changes, SaaS consent or sharing events, Office Suite activity, endpoint execution, and help desk verification outcomes.
Likely telemetry
- Identity and access management audit logs for account changes, privilege changes, MFA changes, password resets, and session activity
- SaaS audit logs for consent, sharing, access grants, administrative changes, and unusual user approvals
- Office Suite logs for email, document sharing, collaboration activity, and user-initiated actions tied to suspicious requests
- Help desk, ticketing, chat, voice, or approval workflow records that show requester identity, approver identity, and verification steps
- Endpoint telemetry from Linux and macOS systems for user-initiated execution or installation following suspicious interaction
Detection direction
- Confirm detections are not limited to message content or malware indicators; T1684 may minimize technical indicators and rely on trusted interactions.
- Correlate identity, SaaS, Office Suite, help desk, and endpoint events to identify risky sequences such as request, approval, access change, and follow-on execution.
- Tune for high-risk business workflows where false positives are expected, such as legitimate help desk resets, vendor onboarding, executive approvals, and administrative SaaS changes.
- Validate that user-reported suspicious interactions can be linked to technical evidence for triage and incident scoping.
- Review blind spots in non-email channels, including help desk, vendor communications, collaboration platforms, and voice-driven requests, where logs may be incomplete or outside SOC visibility.
Mitigation priorities
- Establish and test verification procedures for sensitive requests, including access changes, approvals, disclosure of sensitive information, and software execution requests.
- Strengthen identity and SaaS change controls with least privilege, approval review, and auditable administrative workflows.
- Ensure help desk and business approval processes retain evidence sufficient for investigation and compliance review.
- Train users and support teams on escalation paths for suspicious executive, vendor, or help desk scenarios, including voice-based or AI-enabled interactions referenced in the related technique description.
- Integrate social engineering reports into SOC and IR workflows so human-reported indicators can be correlated with identity, SaaS, Office Suite, and endpoint telemetry.
Analyst notes and limits
This take is based on ATT&CK detection strategy DET0899 and its stated relationship detecting T1684 Social Engineering. The detection strategy itself has no official description, platforms, tactics, or detection text, so the technical guidance is derived from the related technique context and kept to validation themes rather than specific detection logic.
ATT&CK provides sparse fields for DET0899. It does not specify official detection analytics, data sources, platforms, or mitigations for this detection strategy. Local environment architecture, business workflows, logging coverage, and incident history are required to determine actual detection coverage and priority.
Detect Social Engineering
No official description is available in the imported ATT&CK source object.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1684 | Social Engineering | This object detects Social Engineering. |
All related ATT&CK context
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | 81159c65c7a7… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack DET0899Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.