Live Active security incident? Get immediate response
MITRE ATT&CK® Detection Strategy

DET0687: Detection of Impair Defenses

DET0687 is a mobile ATT&CK detection strategy for identifying attempts to impair defenses, mapped to T1629. Its business value is in confirming whether the...

MobileDET0687Detection StrategyObject v1.0 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

DET0687 is a mobile ATT&CK detection strategy for identifying attempts to impair defenses, mapped to T1629. Its business value is in confirming whether the organization can notice when Android defensive controls, audit visibility, or supplemental mobile security tools are disabled, altered, or made less effective. This matters because loss of mobile security telemetry can delay incident response and weaken compliance evidence even before a separate malicious payload is confirmed.

Executive priority

Treat this as a control-assurance question: can the organization prove that mobile defensive mechanisms remain enabled and observable, especially on Android devices in scope? Leaders should ask whether MDM/EMM, mobile security tooling, and SOC processes produce reliable evidence when protections are disabled or modified. Budget and readiness decisions should prioritize visibility into defense degradation, because impaired defenses can reduce confidence in incident triage, audit reporting, and operational resilience.

Technical view

ATT&CK provides no official description or detection logic for DET0687, so teams should derive validation from its relationship to T1629 Impair Defenses in the mobile domain. For Android environments, SOC and IR teams should test whether they receive timely events when native or supplemental defensive components are disabled, uninstalled, reconfigured, lose permissions, stop reporting, or no longer provide audit data. Detection engineering should distinguish expected administrative actions from suspicious or unexplained changes to mobile protection and monitoring capabilities.

Likely telemetry

  • MDM/EMM compliance and configuration-change logs
  • Android device security posture and policy status events
  • Mobile endpoint or mobile threat defense health/status telemetry
  • Security app install, uninstall, disable, permission, and update events
  • Device administrator, accessibility, VPN, notification, or other security-relevant permission changes where collected

Detection direction

  • Validate that alerts exist for defensive-control disablement, removal, reconfiguration, or loss of reporting on Android devices where T1629 is in scope.
  • Tune detections to account for approved help desk, device lifecycle, policy migration, or user-initiated administrative activity to reduce false positives.
  • Correlate changes in defense status with device identity, user identity, management actions, and subsequent gaps in telemetry.
  • Monitor for both direct impairment of supplemental mobile security tools and degradation of native audit or protection capabilities, as described by the related technique.
  • Identify blind spots where unmanaged devices, incomplete MDM enrollment, missing mobile security health logs, or delayed check-ins would prevent confirmation that defenses were impaired.

Mitigation priorities

  • Establish a baseline inventory of expected Android defensive components, management status, and reporting cadence.
  • Require administrative accountability and audit logging for mobile security policy and tool changes.
  • Prioritize controls that prevent or alert on unauthorized disabling, removal, or reconfiguration of mobile defenses.
  • Define IR procedures for devices that stop reporting or show degraded security posture, including containment and evidence-preservation decisions.
  • Use periodic control validation to prove that mobile defense impairment events reach the SOC and can support compliance evidence.
Analyst notes and limits

The supplied ATT&CK object is a detection strategy with no official description, detection text, tactics, or platforms of its own. The practical interpretation comes from the explicit relationship that DET0687 detects T1629 Impair Defenses, whose supplied context is mobile ATT&CK and Android. Local control design, device management architecture, and available mobile telemetry will determine actual detection feasibility.

This take does not claim active exploitation, attribution, guaranteed coverage, or specific vendor capability. ATT&CK fields are sparse for DET0687, so organizations must validate assumptions against their own Android fleet, MDM/EMM configuration, mobile security tooling, logging retention, and SOC workflows.

Official MITRE ATT&CK definition

Detection of Impair Defenses

No official description is available in the imported ATT&CK source object.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

ATT&CK relationship table

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.

1 rows
Domain ID Name Relationship / procedure
Mobile T1629 Impair Defenses This object detects Impair Defenses.
Relationship explorer

All related ATT&CK context

Change history

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 .

ATT&CK release
19.1
Object version
1.0
Created
Modified
Raw hash
0d8d89754161c5f6...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.0 Current bundle 0d8d89754161…
Raw source

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.

Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    mitre-attack DET0687
    Open source URL
Source and licensing

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.