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

DET0627: Detection of Endpoint Denial of Service

DET0627 is a mobile ATT&CK detection strategy for recognizing behavior associated with Endpoint Denial of Service. The business issue is availability: a mo...

MobileDET0627Detection StrategyObject v1.0 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

DET0627 is a mobile ATT&CK detection strategy for recognizing behavior associated with Endpoint Denial of Service. The business issue is availability: a mobile device that is locked, degraded, or made unusable can interrupt workforce operations, field services, executive communications, and incident response coordination. The supplied ATT&CK context specifically ties this strategy to technique T1642 and notes Android and iOS as related platforms, with Android passcode reset abuse constrained by OS version and device/profile-owner controls.

Executive priority

Treat this as a mobile resilience and governance question, not only a SOC alerting topic. Leaders should ask whether managed mobile devices, high-risk user groups, and operationally critical mobile workflows have enough visibility to prove when a device became unavailable, whether MDM authority was involved, and how quickly access can be restored. This can support incident decision-making, audit evidence for mobile control operation, and prioritization of mobile device management hardening where mobile availability affects business continuity.

Technical view

Because the official detection strategy has no supplied description or detection logic, SOC and IR teams should validate coverage against the related technique, T1642 Endpoint Denial of Service, rather than assume DET0627 provides a complete analytic. Use the relationship context to focus on mobile endpoint availability failures and administrative actions that could prevent user access. For Android, pay attention to OS-version differences and whether Device Administrator, device owner, or profile owner capabilities exist in the fleet. For iOS, avoid assuming the same passcode-reset behavior applies based on the supplied ATT&CK text.

Likely telemetry

  • Mobile device management events, especially device lock, passcode, wipe, policy, ownership, and compliance state changes
  • Android enterprise/device administration or device-owner/profile-owner status and policy-change records where available
  • Mobile OS version and device inventory data to separate legacy Android risk from newer managed-device behavior
  • User helpdesk and incident tickets reporting sudden device lockout or loss of access
  • Authentication and access logs showing abrupt loss of mobile access to corporate services

Detection direction

  • Map existing mobile detections to T1642 explicitly; do not count DET0627 as covered unless telemetry and response playbooks can identify device availability loss or lockout conditions.
  • Correlate MDM administrative actions with user reports and device state changes to distinguish authorized support activity from suspicious or unexpected disruption.
  • Tune for context: passcode, lock, and policy changes may be legitimate during enrollment, recovery, compliance enforcement, or lost-device workflows.
  • Segment logic by platform and OS version, especially for Android behavior before versus after Android 7 as described in the related technique context.
  • Review blind spots around unmanaged devices, partially enrolled BYOD, offline devices, and MDM audit retention, since these can prevent confirmation of cause and timing.

Mitigation priorities

  • Maintain accurate mobile inventory with platform, OS version, enrollment type, and ownership model.
  • Restrict and audit MDM, device-owner, profile-owner, and device administration privileges using least privilege and change control.
  • Define recovery procedures for device lockout or mobile service unavailability, including escalation paths for executives and operationally critical users.
  • Retain MDM and identity logs long enough to support incident reconstruction and compliance evidence.
  • Test mobile incident response workflows for availability events, not only malware or data-loss scenarios.
Analyst notes and limits

The ATT&CK object is a detection strategy in the mobile domain with external ID DET0627 and a relationship indicating it detects T1642 Endpoint Denial of Service. The object itself provides no official description, detection text, tactics, labels, or platforms. Platform guidance in this take is therefore derived only from the related T1642 context, which lists Android and iOS and includes limited Android-specific detail.

This take cannot provide MITRE-authored analytic logic because no official detection field was supplied. It does not assert active exploitation, attribution, customer exposure, or guaranteed detection. Local MDM configuration, mobile enrollment models, OS versions, log retention, and helpdesk processes are required to determine actual risk and coverage.

Official MITRE ATT&CK definition

Detection of Endpoint Denial of Service

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 T1642 Endpoint Denial of Service This object detects Endpoint Denial of Service.
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
d57d792c89b2920d...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.0 Current bundle d57d792c89b2…
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 DET0627
    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.