DET0311: Detection for Spoofing Tool UI across OS Platforms
DET0311 is a MITRE detection strategy for behavior related to adversaries modifying or spoofing security tool user interfaces. The business significance is...
Analyst context for executives and security teams
DET0311 is a MITRE detection strategy for behavior related to adversaries modifying or spoofing security tool user interfaces. The business significance is that leaders and responders may make bad incident decisions if consoles or endpoint status screens falsely show that controls are healthy while the underlying tool has been degraded or tampered with.
Executive priority
Treat this as an assurance and incident-readiness problem, not only a SOC alerting problem. For the related ATT&CK technique T1685.003, the key executive question is whether security status is independently verifiable across Linux, macOS, and Windows environments, rather than trusted only because a local UI or console appears normal. This matters for response timing, audit evidence, control validation, and confidence in managed detection or endpoint security operations.
Technical view
The supplied ATT&CK object does not include official detection logic, platforms, or tactics, but it detects T1685.003, Modify or Spoof Tool UI, under defense-impairment. SOC and IR teams should validate whether tool-health signals can be corroborated outside the potentially manipulated UI. For Windows, macOS, and Linux systems in scope of the related technique, compare UI-reported security status against backend telemetry, service/process state, sensor heartbeat, policy/configuration state, tamper-protection events, and management-plane records.
Likely telemetry
- Endpoint security tool health and heartbeat records from the management plane
- Local service, daemon, process, and driver/extension status for security tools
- Security tool tamper, configuration-change, disablement, or policy-change events
- Endpoint logs showing agent communication failures or degraded sensor state
- Administrative activity affecting security tooling or its configuration
Detection direction
- Validate that detections do not rely solely on local UI indicators or screenshots of tool health.
- Correlate local endpoint state with centralized management-plane status and recent configuration or tamper events.
- Look for mismatches: UI reports healthy while heartbeat, service state, sensor activity, or policy enforcement indicates degraded or disabled operation.
- Tune for legitimate maintenance, upgrades, agent restarts, and help desk activity to reduce false positives.
- Use the relationship to T1685.003 as context: this is defense-impairment behavior, so prioritize correlation with other signs of security control tampering.
Mitigation priorities
- Establish independent health attestation for security tools rather than relying on local UI status.
- Restrict and audit administrative actions that can modify security tool configuration, services, or presentation layers.
- Ensure endpoint security status is centrally logged and retained for incident response and compliance evidence.
- Test IR playbooks for scenarios where the visible tool status is misleading or stale.
- Periodically validate Linux, macOS, and Windows control health against backend telemetry and local system state.
Analyst notes and limits
MITRE provides the detection strategy name and relationship to T1685.003, but no official detection text or description for DET0311 in the supplied fields. The strongest use of this object is to drive validation of security-tool health evidence and to identify blind spots where teams trust a UI without independent telemetry.
This take is limited by sparse official fields: no DET0311 description, no official detection logic, no tactics, and no platforms on the detection-strategy object itself. Platform references come from the related technique T1685.003. Local tooling, logging architecture, and endpoint management practices are required to determine actual coverage.
Detection for Spoofing Tool UI across OS Platforms
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 | T1685.003 | Modify or Spoof Tool UI Sub-technique | This object detects Modify or Spoof Tool UI. |
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 | 389322d75f9f… |
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 DET0311Open 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.