AN1822: Analytic 1822
The defender correlates call-control capability or telecom role state with subsequent unauthorized call initiation, answer, block, redirect, or concealment behavior by an application outside expected telephony workflows. The analytic prioritizes Android-observable control-plane effects: dangerous or role-gated call-control permissions, default dialer or ConnectionService-related role changes, telecom framework invocation for call placement or handling, write activity against call-log records, and call-control activity occurring from background or locked-device context without recent user interaction.
Analyst context for executives and security teams
This analytic matters because Android call-control abuse can affect trust in mobile communications: an app with call-control capability or a telephony role may be able to place, answer, block, redirect, or hide calls outside normal user-driven workflows. For leaders, the practical question is whether the organization can prove which Android apps have sensitive telephony privileges and whether SOC or mobile security teams can see suspicious call activity when it happens in the background or on a locked device.
Executive priority
Prioritize this as a mobile identity, fraud, and operational resilience concern where Android devices are used for business communication, executive support, field operations, or regulated workflows. The decision value is not just detecting one event; it is validating governance over default dialer roles, dangerous call-control permissions, call-log access, and evidence retention for investigations or compliance reviews. Security leaders should ask whether managed devices restrict unnecessary telephony roles and whether incident responders can reconstruct call-control behavior from available mobile telemetry.
Technical view
For Android, validate whether telemetry can correlate sensitive call-control state with subsequent behavior: dangerous or role-gated call-control permissions, default dialer or ConnectionService-related role changes, telecom framework invocation for call placement or handling, writes to call-log records, and call-control activity from background or locked-device context without recent user interaction. Because no official detection logic is provided, teams should treat AN1822 as an analytic design pattern and test local visibility across MDM/UEM, endpoint/mobile threat defense, Android system logs where available, app inventory, permission state, role changes, and call-log modification evidence.
Likely telemetry
- Android app inventory and package metadata
- Android dangerous permission grants related to call control or call logs
- Default dialer role state and role-change history
- ConnectionService or telecom role-related state where observable
- Telecom framework call placement or call handling events where available
Detection direction
- Build correlation around capability plus behavior: sensitive telephony permission or role state followed by call initiation, answering, blocking, redirection, concealment, or call-log modification outside expected workflows.
- Tune for expected telephony applications, approved dialers, carrier or enterprise communication apps, accessibility or support tools, and device-management software to reduce false positives.
- Pay special attention to call-control events from background execution, locked-device context, or without recent user interaction, as highlighted by the analytic description.
- Validate whether role changes to default dialer or ConnectionService-related functions are logged with enough detail to identify the app, user, device, and time sequence.
- Confirm whether call-log write activity is visible; lack of call-log telemetry is a material blind spot for this analytic.
Mitigation priorities
- Restrict sensitive Android telephony permissions and default dialer roles to approved applications on managed devices.
- Use MDM/UEM policy to control app installation sources, enforce approved communication apps, and review apps requesting call-control or call-log access.
- Maintain an auditable inventory of Android apps with telephony-related permissions and role assignments.
- Require investigation playbooks to preserve mobile app, permission, role, call-log, and user-interaction context when suspicious call behavior is reported.
- Periodically test whether SOC and mobile security tooling can observe the telemetry needed by this analytic before relying on it for detection coverage.
Analyst notes and limits
AN1822 is a MITRE ATT&CK mobile detection analytic for Android. Its value is in the correlation pattern: call-control capability or telecom role state combined with unauthorized call handling or concealment behavior. With no relationship context supplied, the strongest use is as a validation checklist for mobile telemetry, managed device policy, and incident response evidence collection.
The official detection field is not provided, tactics are not specified, and no relationships are supplied. This take therefore does not infer adversary use, impact, attribution, or guaranteed coverage. Local Android version, device-management model, app permissions, logging availability, and privacy constraints will determine how much of the analytic can be implemented.
Analytic 1822
The defender correlates call-control capability or telecom role state with subsequent unauthorized call initiation, answer, block, redirect, or concealment behavior by an application outside expected telephony workflows. The analytic prioritizes Android-observable control-plane effects: dangerous or role-gated call-control permissions, default dialer or ConnectionService-related role changes, telecom framework invocation for call placement or handling, write activity against call-log records, and call-control activity occurring from background or locked-device context without recent user interaction.
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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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.1 | Current bundle | 00d6703f66ba… |
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 AN1822Open 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.